RenderKit / ospray

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

SetParam vs SetObject #406

Closed aowen87 closed 4 years ago

aowen87 commented 4 years ago

I've noticed since updating to the 2.0 release that when to use SetParam vs SetObject has become pretty ambiguous. For instance, when setting up a transfer function, the only way I can seem to configure "valueRange" is by calling ospSetParam, and the only way I can set "color" is by calling ospSetObject. In the documentation, there doesn't seem to be any distinction between these two parameters in regards to how they are configured; they are both referred to as "Parameters accepted by the linear transfer function." Is there a way to know which method is required for a given parameter?

jeffamstutz commented 4 years ago

At the end of the day, all parameters are set by ospSetParam. The existence of ospSetObject is a hold over from v1.x, where we had ospSet* functions for various types. However, now ospSetParam takes all types found in OSPDataType. Thus ospSetObject is just an alias to ospSetParam (see here).

FWIW, if you are using C++, the ospray_cpp wrappers will deduce the OSPDataType from the C++ type of the passed parameter to setParam. These tend to be easier to use, where you can see them in action here: https://github.com/ospray/ospray/blob/master/apps/ospTutorial/ospTutorial.cpp.

aowen87 commented 4 years ago

Okay, that makes sense. Thanks for the quick response.

The project I'm extending already has the old C style OSPRay incorporated into it from an older version, so switching over to the cpp interface would be a pretty large refactor. We may end up going that route eventually, but we're going to need to weigh both options.

jeffamstutz commented 4 years ago

Cool!

Also, FWIW the C++ wrappers can be progressively used, so it's not all-or-nothing. Each wrapper has a constructor which takes an existing C-handle, where this is considered a "move" operation. In other words, once the C++ wrapper is constructed by the C handle, the handle takes full responsibility of calling ospRelease for you when it goes out of scope (i.e. don't call ospRelease yourself anymore). However, the wrapper isn't doing anything more than calling the C interface with more convenience to C++ and automatic tracking of ospRetain/ospRelease calls, so there isn't anything illegal about mixing the two.

aowen87 commented 4 years ago

Good to know! Thanks for the info.