Options

HOOPS Luminate engine options can be set up on the three main classes of the visualization cluster: the resource manager, the window and the viewpoint. Setting up an option requires to access the RED::IOptions interface from the object that needs to be configured.

Options in HOOPS Luminate follow an inheritance rule in the following order:

  1. Resource manager (RED::IResourceManager)

  2. Window (RED::IWindow)

  3. Viewpoint (RED::IViewpoint)

The schema below, illustrates the hierarchy of options in HOOPS Luminate:

../../../_images/API_OptionsInherit.png

The HOOPS Luminate option inheritance model

Every option defined at the window level overloads the value set on the cluster’s resource manager. Every option defined at the viewpoint level overrides the value set on the window(s) the viewpoint belongs to. Whenever an option has not been set on a cluster object, the value used for it is taken from its ‘parent’ from the inheritance rule perspective: the window and then the resource manager for a viewpoint; the resource manager for a window. Note that it’s possible to remove option values that may have been set on an object calling RED::IOptions::RemoveOverloadedOptions.

So in the example above, the RED::OPTIONS_RAY_SHADOWS is disabled at the resource manager level, and enabled at the window level. The window setup has a precedence over the resource manager setup, and viewpoint 1 and 2 will therefore benefit of the option value (the option has not been setup for viewpoint 1 and 2, therefore, they search the option value to use in their parent window, and on the resource manager if the window has not overriden the option).

See the RED::IOptions interface for further details on options.

Setting Up Options

As a general rule, it’s better to setup options at the deepest possible place in the hierarchy. It’s often better to setup an option at the viewpoint level rather than at a higher level - window or resource manager. The reason is that any option set on a window will potentially affect all the cameras in the window. So for example, if a ray-tracer option is enabled at the window level, all cameras in that window will potentially render using ray-tracing options, unless the same option has been overloaded for each of them!

Practically, option setup is easy to do:

Setup Engine Options

// Assuming 'resmgr' is the cluster's resource manager, 'window' is a window object, 'viewpoint1'
// and 'viewpoint2' are two viewpoints inserted into 'window'.

// Accessing the 'window' option interface:
RED::IOptions* iwinopt = window->As< RED::IOptions >();
// Modifying a display option:
RC_TEST( iwinopt->SetOptionValue( RED::OPTIONS_SHADOW_MAP_DEPTH, 3, iresmgr->GetState() ) );

// Modifying the same option for 'viewpoint1':
RED::IOptions* iv1opt = viewpoint1->As< RED::IOptions >();
RC_TEST( iv1opt->SetOptionValue(  RED::OPTIONS_SHADOW_MAP_DEPTH, 0, iresmgr->GetState() ) );

For the example above, ‘window’ has two child viewpoints named ‘viewpoint1’ and ‘viewpoint2’. The RED::OPTIONS_SHADOW_MAP_DEPTH is set to 3 at the window level, and to 0 on ‘viewpoint1’. Consequently, ‘viewpoint1’ will be rendered with a value of 0 for the option, and ‘viewpoint2’ will be rendered with a value of 3 for the option, due to the inheritance model.