-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-level instancing? #304
Comments
Hi, Only single-level instancing is supported in OSPRay. In OSPRay v2.0+, we intend on making this explicit in the API by having OSPGeometry-->OSPGeometryInstance-->OSPWorld, where OSPWorld replaces OSPModel. This will directly express the single-level instancing constraint in the API, but allow us to introduce multi-level instancing later if we can do so with a satisfactory design (i.e. introduce recursively defined OSPInstanceGroup). The biggest issue we face with multi-level instancing is the meta-data around what instances represent in the scene (i.e. overriding attributes such as material lists). Our scene graph which we implement on top of OSPRay does support multi-level instancing, but it is yet-to-be documented... The solution for OSPRay v1.x is to flatten all instances into a single OSPModel, where each OSPModel that is instanced represents the smallest group of geometries to be instanced. Cheers, |
Dang, so my hunch was right 😞 The section of the docs under Model is then a bit too general as it claims, without mentioning the one-level limit
|
Well, the truth is somewhere in-between "supporting" and "not supporting" multi-level instancing. The original goal (as written in the documentation) was to support it, but the current implementation has several limitations and hacks (so we opted for a clean cut in OSPRay v2). For "simple" materials and multi-level instances of "basic" geometries it should work. More complex setups (nested material lists, geometry lights) will likely be broken. I just tried myself, it worked. Be sure to commit each instance / model / geometry, otherwise a zero-only transformation matrix will be used (and the instances just vanish); i.e. call |
(see RenderKit/ospray#304), so we need to work around that. Changed the geometry plugin load function to return a list of (OSPModel, xform) pairs, which will get instanced in the top-level "world" OSPModel. There is still a bug in that the transform applied to the Blender object is not applied to the instanced geometry. Unrelated tweaks to code that updates bbox mesh during export, to see if this fixes a segfault.
I'm trying to debug some code that is not showing any geometry in the rendered output, so I wanted to verify if what I'm doing is actually supported when it comes to instancing. See the code below, should the multiple levels of wrapping an ospGeometry into an ospModel followed by instancing, i.e. base -> container -> world, actually work? Or is it limited to two levels?
The text was updated successfully, but these errors were encountered: