OpenSceneGraph (OSG) 
|
|
|
OpenSceneGraph (OSG) |
|
|
|
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
|
OSG is based around the concept of a Scene-Graph, it provides an object oriented framework on top of OpenGL
freeing the developer from implementing and optimizing low level
graphics calls, and provides many additional utilities for rapid
development of graphics applications. For more details on what Open Scene Graph is visit the OSG Web Site
| ||||||||||||||||||||||||
|
In the 3d simulation world many of the people use OSG and Open Scene Graph interchangeably. So yes in the is it is the same thing but the acronym OSG is used else were out side the 3d simulation world for other meanings, a quick google will show this to be the case But in the 3d World if you use OSG most people will know what you doing
| ||||||||||||||||||||||||
The stated goal of Open Scene Graph is to make the benefits of scene graph technology freely available to all, both commercial and non commercial users. OSG is written entirely in Standard C++ and OpenGL, it makes full use of the STL and Design Patterns, and leverages the open source development model to provide a development library that is legacy free and focused on the needs of end users. The stated key strengths of Open Scene Graph are its performance, scalability, portability and the productivity gains associated with using a fully featured scene graph, in more detail: The
Open Scene Graph also supports easy customization of the drawing process, such as
implementation of Continuous Level of Detail (CLOD) meshes on top of
the scene graph (see Virtual Terrain Projection and Demeter).
3D database loaders include
Image loaders include
OSG also has a set of Node Kits which are separate libraries that can be compiled in with your applications or loaded in at runtime, which add support for
The core OSG library is completely windowing system independent, which makes it easy for users to add their own window-specific libraries and applications on top. In the distribution
thereis already the osgProducer library which integrates with OpenProducer,
and in the Community/Applications section of this website one can find
examples of applications and libraries written on top of GLUT, Qt, MFC,
WxWindows and SDL. Users have also integrated it with Motif, and X. OSG will not only run on
portables all the way up to Onyx Infinite Reality Monsters, but also
supports the multiple graphics subsystems found on machines like a
multi-pipe Onyx ( Note the above is more or less pulled straight from the OSG Web Site )
| ||||||||||||||||||||||||
You can down load pre-compiled binaries from the OSG downloads page Or you can retrieve the source for OSG from a CVS repository and build it your self using one of the following methods
| ||||||||||||||||||||||||
|
Yes thereare currently four public OSG mailing lists:
| ||||||||||||||||||||||||
|
The OSG user forum can be found here http://www.3dRealTimeSimulation.com/3dsceneBB
| ||||||||||||||||||||||||
|
thereis also sample and example code as part of the distribution Some more OSG examples can be found here by Gordon Tomlinson's
| ||||||||||||||||||||||||
See the OSG distribution for the latest full list of supported formats | ||||||||||||||||||||||||
OSG supports the following Image formats See the OSG distribution for the latest full list of supported formats
| ||||||||||||||||||||||||
|
Why does OSG use header files without an extension such as .h or hh etc. The leads on OSG deem this to be so, its been argued by many people that this is an unpopular decision and breaks many tools. But the fact is its not going to change and basically their stance is tough fix your tools, Personally I dislike the way the headers are in OSG and would much prefer the standard approach of using an extension. Here's a couple of links to some threads and responses on this subject
| ||||||||||||||||||||||||
It all depends on your editor and platform, some possibilities include: if getline(1) =~ '-*-c++-*-' set filetype=cpp endif
| ||||||||||||||||||||||||
|
To get a Bounding Box of an osg::Node have to convert the Bounding Sphere to a BoundingBox along the following line:
Note that OSG use Bounding Box's at the Drawable leaves level. | ||||||||||||||||||||||||
|
OSG stores a bounding sphere for all internal nodes (osg::BoundingSphere) Simply call the following to get the bounding sphere:
| ||||||||||||||||||||||||
|
Yes you can use the osg::Node::ComputeBoundingSphereCallback mechanism to do this void setComputeBoundingSphereCallback(ComputeBoundingSphereCallback* callback) You will need to derive your own class from override the osg::Node::ComputeBoundingSphereCallback then you ovveride the computeBound function (virtual BoundingSphere computeBound(const osg::Node&) ) with this function you place your logic in to identify the nodes of interest etc. I have not seen this used in an samples as yet.
| ||||||||||||||||||||||||
|
To move a node in OSG you need to attach that node to an osg::PositionAttitudeTransform or osg::Transform ( if the node is note one of these types) For example using a osg::PositionAttitudeTransform postion a node ate x = 100.00, y = 250.0 and z = 75.0
or if your node is already an osg::PositionAttitudeTransform simply
| ||||||||||||||||||||||||
|
To set the orientation of an node in OSG you need to attach that node to an osg::PositionAttitudeTransform or osg::Transform ( if the node is note one of these types) OSG does note provide nice convenience functions for setting HPR angles like Performer or Vega Prime supply In OSG you have to use Matrices or Quaternion's for example To set the Heading you can do something along the lines of:
To set the Pitch you can do something along the lines of:
To set the Roll you can do something along the lines of:
Setting HPR all at once you can do something along the lines of:
| ||||||||||||||||||||||||
|
Why does OSG ignore my Near Far Clipping Planes When using osgUtil::SceneView, OSG is set up by default such that near and far clipping planes are recomputed on the fly based on eye point and viewable scene. This means that your setting will be overwritten This is designed in OSG and is used optimize the near/far range of the depth buffer, which might otherwise contain "z-fighting" artefacts if near and far are set to unreasonably small or large values, which is fine for certain applications for many others it is not fine and is a pain that catches many users out. Thankfully thereis a simple work around to this, you can override this behaviour by calling:
If you are using osgProducer::viewer use:
| ||||||||||||||||||||||||
|
You can do something along the lines of:
| ||||||||||||||||||||||||
|
The problem you seeing is that your normals are being scaled along with your geometries and vertices. To keep your normals 'normalized', you can set the following attribute on appropriate stateset(s):
Also you could consider using an osgUtil::SmoothingVisitor
| ||||||||||||||||||||||||
In code you can call the following with the level of output required
| ||||||||||||||||||||||||
|
For example:
Note the for the message to be displayed to the console the level must be equal to or less than level set by osg::setNotifyLevel Avaliable Levels in increasing levels of output
| ||||||||||||||||||||||||
|
Yes its is quiet possible that OSG is culling away your geometry or points ( assuming you do not have LODS, that my be doing this), its another one of those little annoying gotchas that you come across ;(, ( This is where a OSG Programmers Guide would really really help) OSG by default uses small feature culling to cull out objects that occupy a predetermined screen size. This is a valuable feature for models with many details which do not contribute to the visual quality of the model when viewed from a distance. You can completely disable small feature culling by defining the cullingMode on osgUtil::SceneView with:
| ||||||||||||||||||||||||
1
