Release Notes > osgNV-0.6.0

Release date: 18 August 2004

In sync with OpenSceneGraph-0.9.7-2

This release of osgNV shows a completely revamped class design, with improved flexibility and robustness. This means, however, that you will need to modify your existing client code to align it to the new structure.

Major changes:

1. osgNVCg::Context isn't a state attribute anymore. Instead, osgNVCg::Program has been promoted to state attribute. This means that if you want to apply a Cg program to a StateSet you will need to apply the program itself, not its context:

   // BEFORE:
stateset->setAttribute(program->getContext());
// - or -
stateset->setAttribute(context);

// NOW:
stateset->setAttribute(program);


   This is much more intuitive and consistent with the underlying API. Furthermore, you can have multiple programs of the same kind in a context and therefore you can share global parameters between them. This change also improves state management and avoids possible state inconsistency problems.
2. When constructing an instance of osgNVCg::Program you MUST pass the profile identifer to the constructor, you can't assign it later. This is because the Program class is now a StateAttribute that uses the program profile as attribute type identifier, so that programs with different profile can act "orthogonally" without being mutually overridden.
3. Shader parameters are now decoupled from their values. This means you must actually set two objects to define a shader parameter: an instance of one of the classes derived from DynamicTypeParameter, and an instance of one of the classes derived from ParameterValue, which will be assigned to the parameter. The former defines the nature of the parameter (that is, whether it is a Cg local parameter, a Cg global parameter, a raw vertex program parameter, etc.). The latter provides the get/set interface and storage mechanism for the actual value (vector, matrix, array, etc.). Example:

   // BEFORE:
osgNVCg::VectorParameter *vp = new osgNVCg::VectorParameter(program, "myparam", 1.0f);
program->addParameter(vp);

// NOW:
osgNVCg::LocalParameter *vp = new osgNVCg::LocalParameter("myparam");
vp->setValue(new osgNV::VectorParameterValue(1.0f));
program->addParameter(vp);


4. Note that if you don't specify the program object when constructing the parameter, it will be automatically assigned when you call program->addParameter(). As usual, the osgNVCg::Program class provides some "shortcuts" to help setting parameters quickly:

   // BEFORE:
program->addVectorParameter("myparam")->set(1.0f);

// NOW:
program->addVectorParameter("myparam")->set(1.0f);


   As you can see, the shortcut form hasn't changed that much. There is a difference however: the object returned by addVectorParameter() was a VectorParameter before, while now it is a VectorParameterValue which is automatically assigned to the newly-created parameter. Actually there are tons of constructors for both LocalParameter and GlobalParameter that help initializing the parameter object in a single line of code.
5. As a consequence of point (3), a single ParameterValue object can be assigned to any number of Parameter objects. This means you can share the same value between several parameters, even in different programs and contexts, having a centralized point where to change the value for all those parameters.
6. new features of Cg 1.2 are supported, except for unsized arrays (will be included soon). The most important feature is parameter instancing, which is implemented in osgNVCg::GlobalParameter. This parameter class is different from osgNVCg::LocalParameter because it is to be assigned to contexts rather than programs. Once you have added a global parameter to a Cg context you can bind it to any number of local parameters and have them automatically updated whenever you update the global parameter. Please note that this behavior is different from the sharing described at point (4) because it is provided by the Cg runtime and may be faster. Furthermore there are situations in which you are forced to use this mechanism, for example when you have to provide a concrete implementation for an abstract structure (interfaces).

The structure of namespaces has also changed a bit. All classes in the osgNV namespace that implement specific nVIDIA extensions (such as register combiners, vertex programs, etc.) have been moved to a new module/namespace named osgNVExt. This leaves in the osgNV namespace only the base framework for shader abstraction (parameters, values, callbacks, parameter sets, etc.) and could help removing unwanted dependancies when not using low-level nVIDIA extensions.

All these changes will make it possible to add support for the GLSL shading language with much less effort, making osgNV the perfect library to help migrating your shaders or simply provide support for both kinds of shaders, in case one of them is not available at runtime.