search

RenderKit / ospray

An Open, Scalable, Portable, Ray Tracing Based Rendering Engine for High-Fidelity Visualization
http://ospray.org
Apache License 2.0
1.02k stars 186 forks source link

Nested models not supported? #256

Closed favreau closed 6 years ago

favreau commented 6 years ago

Hi, I recently tried to use nested models by using the following API / pseudo-code:

model1 = ospNewModel(); model2 = ospNewModel(); ... instance2 = ospAddInstance(model2, (osp::affine3f&)ospcommon::one); ospAddGeometry(model1, instance2); instance1 = ospAddInstance(model1, (osp::affine3f&)ospcommon::one); ospAddGeometry(rootModel, instance1); ... ospCommit(rootModel); The rendering unfortunately fails in the following line of model.ih: geom->postIntersect(geom,model,dg,ray,flags); In the model.ih file, the comments make it pretty clear that the feature is not yet supported.

Note that if I do not have more that 1 level of children under the 'root' model, things work fine.

Will nested models be fully supported in the future? In OSPRay 2.0?

Many thanks for you help there. Cyrille

jeffamstutz commented 6 years ago

Hi Cyrille,

You are correct, nested instancing is not support in OSPRay. The API, as it is currently expressed, leads you to believe that nested instancing is supported, but we intend to change that.

We've decided to stick with single-level instancing in OSPRay API itself, though we support multi-level instancing in ospray_sg (our scene graph which continues to mature). After some discussion with the team, multi-level instancing is somewhat at-odds with the spirit of the OSPRay API. OSPRay does not want to get in the business of allowing client applications to query information which the application set (i.e. values of parameters). This is fine when there's a 1:1 mapping of objects/parameters to API calls. However, multi-level instancing would start creating additional objects on behalf of the application, which begs for additional functionality to allow querying of those objects and setting parameters on them.

Thus, we still do deliver that functionality (not withstanding future improvements), but deliver it in a place which makes more sense: a traversable representation of a scene.

In OSPRay v2.0, we will make the API more obvious to the single-level instancing design decision. It won't require too much of a change from the current API, but it will be spelled differently...perhaps by introducing an OSPWorld for the root-level scene.

FWIW, this decoupling also lets us consider potential differences in the roles of the OSPRay API and the scene graph. (ex: instancing lights inside models)

Hope that helps!

Cheers, Jeff