Making geometry available for IPR rendering
tdapper last edited by
Our plugins have two generator objects that both produce two vastly different representations for editor display and for rendering. We decide which one to create by the existence of
BUILDFLAGS::EXTERNALRENDER. That produces problems with all sorts of IPR renderers, because they use the editor representation. However, I noticed, that this is being solved somehow. For example, when using Multi-Instances and setting them to display boxes in the viewport, most IPR renderers (I tried Arnold and heard it works in Redshift as well) do show the render geometry. Same appears to work happen (at least in Arnold) with the Subdiv object. The editor shows the editor detail, in the IPR I get the render subdivision.
I am not sure how this happens (or whether both of the above cases use the same mechanism), but I would like to figure out how this works, so we can do the same.
I am aware, that we could just create both, editor and render geometry always and just set the visibility flags in the cache. However, at least with one of our objects that would be less than ideal, because generating the full detail representation also takes a bit.
Hope someone can help, ideally with some insight on how the two examples, I described above, work.
r_gigante last edited by
Hi Tim, thanks for reaching out to us.
I see your point but I think the cases you've reported might not be fully representative: for the Multi-instances, external renderers usually implements an in-rendering instancing mechanism so the fact that the viewport represent a bounding-box and the IPR shows the right instanced geometry as expected.
At the same time, I think Arnold shows up subdivided geometry in IPR, not because it's retrieving a different (more-detailed) representation than the one shown in the viewport, but rather because it generates on-the-fly in-rendering subdivided geometry once it finds a geometry child of a subdiv modifier.
Given the cases you mentioned, I think they are all managed on the rendering-engine/-integration side but what you could think of is about implementing a mechanism similar to what offered in R23 to grant 3rd-party renderers accessing scene-nodes cached geometry.
The idea is easy: you inform all the rendering vendors you deem relevant to your customers about a message(s) your ObjectData is listening to that could trigger your generator to return back different LOD geometry (or geometries) based on the message fired. This could give them the chance to retrieve your high-level detail cache also in IPR.
tdapper last edited by tdapper
Thanks for helping me out here. Couple followup questions:
- We actually have been thinking about offering a mechanism for rendering vendors to retrieve the full geometry, my observations just made me think that there might be a better way (meaning: a standard way that wouldn't have to be vendor specific). Anyway, the way we thought about it was to use the function publishing interface and implement a call on our object, similarly to what the Hair module does. What would be your reasoning to prefer using messages instead?
- Another approach we thought about was dropping the full geometry into the cache always, and allowing a different editor representation not by using the
GetVirtualObjects(), but by overwriting the
Draw()method and just drawing different viewport geometry ourselves (e.g. by building one or more
PolygonObject's and drawing them using
ObjectData::DrawPolygonObject(). Do you have any thoughts on this? Will this come with a performance penalty, or is that basically what is done internally?
Thanks for your awesome support, @r_gigante!