Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

In this Discussion

Tags in this Discussion

Optix rtObject buffer
  • Vote Up1Vote Down DefiniteIntegral
    Posts: 18
    Hello,

    I am trying to divide my Optix scene into distinct sections where each exists in an entirely separate tree structure, and to connect them via portals. That way tracing always starts at a location guaranteed to require rendering (as determined by the host), and other sections won't even be checked for bounding unless requested (via re-cast into new root in portal material). However, I am having trouble doing so.

    Selector nodes won't do the trick, since they can't access rtPayload semantic. Simply applying a transform and re-casting in the portals hit program also won't work, because that would require all calls to rtTrace to start at the same root object, so the entire scene would need to be in one tree.

    I can achieve the effect by having multiple root objects, but at the moment I am doing so like this:

    rtDeclareVariable(rtObject, rootObject0, , );
    rtDeclareVariable(rtObject, rootObject1, , );
    ...

    Which is of course quite undesirable.

    I am wondering if it is possible to access rtObject's via a buffer? For example:

    rtBuffer< RTgroup > rootObjectBuffer;

    I could do this by passing an array of RTgroup objects obtained from optix::Group::get(). However I have no idea whether this is safe to do. Will calls to rtTrace accept rtObject's passed this way, or only using the rtObject type and the rtDeclareVariable macro?

    Thanks
  • 8 Comments sorted by
  • Vote Up0Vote Down DefiniteIntegral
    Posts: 18
    Edit: removed
  • Vote Up0Vote Down DefiniteIntegral
    Posts: 18
    Edit: removed. edited original post.
  • Vote Up0Vote Down Crog
    Posts: 53 Accepted Answer
    Even though the documentation does not say it, accessing the RayPayload inside a Selector is not invalid behavior. The Ray-payload is simply a pointer to a location in memory and to use it inside a selector you should use a switch based on ray-type to access it as the correct data type or have all your ray-payloads derive from a common base type which means you can access the payload safely for all your rays.

    So the ray payloads:

    struct PerRayData_Global
    {
    float tEye
    };
    struct PerRayData_Radiance : PerRayData_Global
    {
    float3 colour;
    };
    struct PerRayData_Shadow : PerRayData_Global
    {
    bool shadow;
    };


    Then in the 'Selector' program:

    rtDeclareVariable(PerRayData_Global, prd, rtPayload, ); //, We read just the global base data of the ray

    RT_PROGRAM void selectorProgram()
    {
    if ( prd.tEye < kSomeValue )
    rtIntersectChild( 0 );
    }
  • Vote Up0Vote Down DefiniteIntegral
    Posts: 18
    Hmm ok, thanks. Actually the Optix programming guide specifically indicates that payload data is not (supposedly) available for visit programs (see page 32). So I am a bit worried that future Optix version would "fix" the "bug" where the semantic is available in selector programs...
  • Vote Up0Vote Down James Bigler
    Posts: 39 Accepted Answer
    The docs have been updated for 2.5 (check the new release candidate). It's safe to access the rtPayload from a selector.

    Also, you can't put rtObjects into a buffer and call them with rtTrace right now. The only technical limitation to this is on our end. The current code is setup to determine what the source of the rtTrace parameter is, and if it comes from memory (such as a buffer access, we can't determine the type and fail). Technically the only thing rtTrace needs is the pointer that corresponds to the RTobject, so it shouldn't matter if that value comes from a single variable or from a buffer, but we force it to be a variable for the time being for better error checking.

    I'll go ahead and file a bug against this, so we can evaluate loosening this restriction.
  • Vote Up0Vote Down DefiniteIntegral
    Posts: 18
    OK thanks.
  • Vote Up0Vote Down DefiniteIntegral
    Posts: 18
    Hmm, it seems using selectors in this manner to divide the scene doesn't work as I am trying to do it (similar to Crog's answer). When I have Selector nodes attached to the root group, the program fails to compile with error indicating the scene has an invalid bounding box. However if I remove the selector and attach the geometry group directly to the root group, it compiles normally.

    So I guess for now I will have to resort to hard-coding a set number of root objects passed via variable.
  • Vote Up0Vote Down DefiniteIntegral
    Posts: 18
    Sigh, having multiple rtObject variables doesn't work so well either. Having 1 or 2 is fine, but if I have for example 16, then the program gets stuck on Optix compile(), and will still be compiling even after 10 minutes, at which point I terminate the application.

    So... anyone have some tips on trying to divide the scene in this way?
Add a Comment