TestIntersection Of USDImagingGlEngine Does Not Return Normal For Arnold Hydra Delegate.

[SimonCSmith]

I have been tring to use the TestIntersection call from the USDImagingGlEngine interface to get a basic raycast going. Whilst this will return a world location, it does not return the normal of the surface hit as the normal AOV is not being rendered - which I believe is dictated by what is present in the GetDefaultAovDesctiptor() call. I compare this with what USDView does with its hover tooltip functionality.

To reproduce/see this in action, just debug under the UsdImagingGLEngine::TestIntersection call and down to the picking task itself (HdxPickFromRenderBufferTask). In here you can see whilst the prim, instance, element, depth, & camera render buffers are valid, the normal one is not present.

So, should Arnold expose this pass by default so to support calls like TestIntersection of the USDImageingGlEngine? Is that something I need to add programatically (which I assume that the TestIntersection() code just pick up). Or is the USDImageingGlEngine just "an example" of what can be done, and really I should be implementing my own.

Side note: I'm compiled against the Pixar USD 23.08 codebase, and i'm working in tandem with USDView and my C++ Qt/OpenGL test application to understand how to get things working properly across multiple Hydra delegates. The aim being able to get IPR rendering running and use the USD API to "raycast" and get back the hit world location, hit world normal, and incident world ray. I should also add that i'm fairly new on the USD/Hydra front here so may have a few concepts not quite correct in my head.

[cpichard]

Hi @SimonCSmith ,
to my knowledge, UsdImagingGLEngine is an example of an hydra viewer that can be used as is, but ideally you might want to rewrite a dedicated one for your application, adding or removing passes (like the selection highlight which is really slow) or adding 3d gizmos, aovs, etc.

@sebastienblor would you know if there is a reason why we don't return the normals ?

[sebastienblor]

The Arnold render delegate is not meant as a ray server where you would send rays yourself. You ask it to run a full render with provided render settings, and Arnold will handle the whole thing : full picture, buckets, imagers, denoising, etc... This is needed to have a correct and consistent render, so we're not planning to expose anything lower level than this.

About the normals being set as invalid, I see the commit was done here a long time ago
49afdf3
I'm not sure what would be the consequence of returning a proper descriptor for normals and why it wasn't simply done in this original commit. One thing we don't want, is that changing this forces all Solaris renders to suddenly have an additional AOV for normals. Although the performance for additional AOVs is small, it's not null, so we only want the AOVs to be exposed it they're needed, or requested by the user.
I remember some AOVs had to be automatically added, like primID (for selection) and a few others.

[SimonCSmith]

Thanks for both your answers there. As I mentioned, i've been using the UsdImagingGLEngine to see what that can do "out of the box". I understand hydra is not meaning to be a ray server (as echoed by Pixar too) but the HdxPick system is an interesting way of getting a rough "acceptable" answer by using a thin frustum down where you want to "ray cast" and use the id/depth/normal buffers to resolve. I could perhaps get the same data out if aov's for world position and world normal were created too I guess.

So how should I correctly go about adding a normal AOV to the render list then? When I look at how the task controller sets up the render outputs, it checks what has been requested against the delegates default aov descriptors, but for Arnold, the GetDefaultAovDescriptor call for a normal/Neye pass will always return an invalid descriptor (the default aov descriptor creates an invalid one) so will always be removed.

The closer I look the more I appreciate the complexity of it all. Seeing that the Storm delegate has special code going on inside the USD codebase, I see why other delegates behave differently (ie, in the task controller, Storm uses Pick tasks, others use PickFromRenderBuffer tasks which use different AOV's - neye vs normal).