-
Most of examples complain about texture images and shader sources not being found. What's wrong?
Some examples need the data files that are shipped with osgNV and can be found in the ./data directory. You need to modify the OSG_FILE_PATH environment variable in order to include the osgNV data directory in the search path.
-
I can't get state matrices work in osgNVCg. Although I'm correctly setting a LocalParameter with the right StateMatrixParameterValue object, my shader keeps getting the wrong matrix.
The Cg runtime grabs state matrices like MODELVIEW and PROJECTION at the time the parameter is uploaded, instead of tracking them when the shader runs. This means that if you apply a state matrix parameter above a subgraph it will upload the state matrix accumulated until that point, discarding all subsequent Transform nodes that could eventually be present in the subgraph.
-
Why did you include support for GLSL? Wasn't osgGL2 enough?
osgNVSlang, the module which provides GLSL support in osgNV, is not meant to be a replacement for osgGL2. The latter is a lightweight, simple-to-use piece of software and has certainly the advantage of being integrated into OpenSceneGraph.
However, as most of the additional sub-libraries in OSG, it is not meant to be the ultimate solution for developing and running shader-enabled applications. It can satisfy the majority of users, but a lot of them will still prefer to use a dedicated library like osgNV.
These are the main advantages that osgNV offers to its users w.r.t. GLSL support:
- As a dedicated library, osgNV is expected to grow and new features will be added over time. The osgNV library can become the reference point for all shader-related works, including a set of pre-defined effects and a framework for shader composition. Since OpenSceneGraph have to stay more focused on scene graphs rather than additional features, osgNV still remains the ideal place for implementing any kind of new shader stuff.
- osgNV has a good shader abstraction framework. In fact, both osgNVCg and osgNVSlang are just two specific implementations of it. Having a common base for both GLSL and Cg shaders makes it possible to create applications that can use GLSL, Cg or assembly shaders interchangeably, providing more fallback paths for osgFX effects and allowing cooperation of shaders across different shading languages.
- While the GLSL language is relatively new and therefore not widely supported, it is supposed to become more popular once hardware vendors begin to support OpenGL 2.0. The osgNV library provides the means for transitioning from Cg to GLSL smoothly and easily.
- True, GLSL is standard and it's going to work on all compatible graphics cards, but another truth is that hardware vendors will always be adding proprietary features and optimizations to make things faster on their cards. osgNV will continue to support nVIDIA hardware natively, so osgNV-powered applications will be able to both "just work" (through GLSL) and work faster on nVIDIA hardware through Cg and other nVIDIA extensions. It is not excluded that in the future other brands' extensions could be supported as well (if you want to contribute, send an ATI card to the author :-).
