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:
| ||||||||||||||||||||||||||||||||||||
|
For CLOD implementation (Continuous Level of Detail) approach to terrain see Demeter (http://www.terrainengine.com/) and Virtual Terrain Project (http://www.vterrain.org/) for detailed open source approaches. OSG also loads Terrex TerraPage tiles OSG can also load the Open Flight output of Multigens Creator Terrain Studio and Creator Terrain Pro products At some point OSG may have a Meta-Flight loader again for output from Creator Terrain Studio ( depends if I ever write one or some one else)
| ||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
When your class is derived from osg::Drawable and you derived drawImplementation is called only once, this typically means that you have enable Display Lists for the drawable So try disabling the use of display list for your derived class. myDrawable->setUseDisplayList( false ); | ||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
This normally means that you have disabled Run-time Type identification (RTTI), You will need to enable the run-time type identification for you compiler With Visual Studio, you can simply add /GR switch in the project options. Also you can find the option in the development environment, select Settings on the Project menu. Then select the C/C++ tab, and select C++ Language in the Category box. There's a checkbox right therefor "Enable RTTI" make sure you have it selected and ticked.
| ||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
First look have a lLook in your Visual Studio directory of the Openg Scen Graph install see the "read me" file located in therefor the latest information For syntax highlighting in VisualStudio which the standard C++ style headers found in the OSG : Visual-Studio6.0 Substitute or merge the LANDEXT.DAT file found in this directory with the one found C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin VisualStudio .NET Install the highlightXX.reg (just double click it). This will update Extensionless file for Visual Studio. Don't worry, it will keep the current extensionless files (STL ones) intact. the important files are : C:\OpenSceneGraph\VisualStudio\MUST_READ_ME.txt OpenSceneGraph\VisualStudio\highlight71.reg OpenSceneGraph\VisualStudio\highlight70.reg OpenSceneGraph\VisualStudio\LANGEXT.DAT
| ||||||||||||||||||||||||||||||||||||
|
This could be one of a couple of things By default OSG compiles a display list of geometry the first time it is drawn and subsequently uses the display list to draw the geometry rather than using immediate mode rendering, this is a useful optimisation. OSG does not currently track the state of the geometry, you have to tell OSG to update the geometry, so you need to call the function m_geometry->dirtyDisplayList() after you have updated your geometry. Alternatively you can turn the use of display list of with m_geometry->setUseDisplayList( false ); , all though only do this if you changing the data every frame. Another problem may be that you are changing the number of primitives being draw, again you have to tell OSG that you have changed the number of primitives in use with DrawArrays::setCount() Finally you may also need to call m_geometry->dirtyBound(); | ||||||||||||||||||||||||||||||||||||
The other alternative is to write your own format loader. Take a look at any of the plugin source as an example of how to do this. You will need to derive your loader from osgDB::ReaderWriter and implement the following functions The function readNode() will be passed the name of the file to parse and should return a pointer to the subgraph created after parsing the file. You will also need to declare a proxy instantiation of your class, something like (If your class is named KGLLoader): osgDB::RegisterReaderWriterProxy<KGLLoader> g_kglLoader_Proxy; This has be compiled in to a dynamic shared object .so (Unix), dll (Windows), or bundle (Mac OS). osgDB will then load this module at run time when a file named .kgl (or whatever extension acceptsExtension() returns true for).
| ||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
You can convert files to the IVE format simply using the OSG program osgconv For examples ( basic usage osgconv [args] inputFile(s) outputFile osgconv my_file01.flt my_file02.flt my_file03.flt my_file99.flt my_big_Database.ive
| ||||||||||||||||||||||||||||||||||||
|
osgconv is a Open Scene Graph utility program for reading in 3d databases formats and writing them out to its native *.ive binary format and the *.osg ASCII format ( similar to Vega Prime's *.vsb and Performer's *.pfb binary formats) osgconv can also apply
optimizations to the files it reads, compact multiple files in to one output
file, inline textures in to the file. The resultant binary files will load
considerably faster in Open Scene Graph compared to loading native 3d formats
such as 3ds, OBJ, WRL files etc.
| ||||||||||||||||||||||||||||||||||||
|
For a full list of command line options supported type:( see http://www.openscenegraph.org/index.php?page=UserGuides.Osgconv as well ) osgconv --help Which will print out out the following: usage: osgconv [options] infile1 [infile2 ...] outfile command options:
| ||||||||||||||||||||||||||||||||||||
|
The most probable cause for gridlines may come from the OpenGL texture edge wrap setting. Such that when your S and T wrap modes are set to GL_CLAMP, you will sample some of the default black at the texture edge. The fix is to change your S and T wrap mode to GL_CLAMP_TO_EDGE. This clamps S and T values such that the edge is never sampled. In raw OpenGL, you'd use glTexParameter to do this. OSG has a similar mechanism. However, this will introduce a new problem though; when tiling textures, you will see a visible seam at high magnifications this will not as bad as the black gridlines, but visible nonetheless. thereare a couple ways you can work around this. One way is to go back to GL_CLAMP, but actually set the texture edge to contain a copy of neighbour texture border data. To do this, you'll need to make your textures a power of 2 plus 2 in both width and height. Yet another way is to essentially do the same thing, but then resample the texture back down to a power of 2 and stick with GL_CLAMP_TO_EDGE -- the benefit here being that you can use S3TC compression (which doesn't allow texture edges) | ||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
thereis no direct relationship between an osg::State's contextID, it is in fact, arbritrary, and the graphics context, other than the fact that theremust be a one to one correspondence. During rendering, a context is made current, and all rendering that occurs while that context is current will use texture handles and display list handles that were created with in that context | ||||||||||||||||||||||||||||||||||||
|
Attempting to have one scene view between multiple graphics contexts, may either not be possible or be very hard. The right way to do this is to have a scene view for each graphics context (note: each unique RenderSurface will need a unique context - when contexts are made current, they are made current along with the window/drawable/RenderSurface). What is shared is the scene graph. The SceneView is not a heavy data structure and little is gained by trying to share it. A scene graph, however, can carry quite a large memory footprint, so replicating it is not efficient. All that is replicated are texture handles and display list handles, like this:
| ||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
Each rendering window has its own OpenGL context which is separate from all other contexts. OSG doesn't know how you set up your windowing environment, you thus need to ensure that each osg::State object is tied to a unique OpenGL context. To do that you do something along the lines of:
Note, that context ID's are used as indices in to vectors that grow automatically, so avoid setting large numbers, start counting from 0 and then increment by one each time
| ||||||||||||||||||||||||||||||||||||
|
Yes you can use Open Scene Graph with or without Producer, even if you are creating your own windows See the osgsimple sample program for an example of using Open Scene Graph with a generic windowing environment OSG itself is windowing system agnostic, so setting up the window and OpenGL graphics context will be up to your application Note osgsimple uses Producer, but has been written in a way to provide you the skeleton to use your own windowing system. Another aproach to consider it to use the Producer infrastructure in your own windowing environment as well by setting each Camera's RenderSurface to the window you have created. Along the lines of:
| ||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
See the OSG website for the latest available documentation, the recommendation on the OSG web site it to "Use the Source" While having access to the source is a good thing for many , I have to disagree with some of the sentiments found in "Use the Source". Having the source assumes you readily understand how it all works or that you can deduce this from the code; this is not true for many who are new to OSG or to the simulation world and can be seen by many of the question on the mailing lists. Further the search the source can be a real time waster trying to find a solution to the problem your trying to solve when you don't really know what part of OSG may help you solve the problem. A good Programmers guide can really help you find what you looking for and how things relate very quickly SGI's Opengl Performer's programmer guide is a good example of this and is actually quite useful in understanding on how much of OSG works ( Links to Performer Docs) While OSG has documents generated from headers and source, a lot of material found there is does not have context and can thus be difficult to assimilate, again a good programmers guide and reference manual can give the require context Hopefully one day OSG will have these documents its one of the things that really lets OSG down for many users and potential user IMO, in the mean time, search forums, search mailing list, search the examples and tutorials you can find at 3dscenegraph.com and the OSG web site
| ||||||||||||||||||||||||||||||||||||
|
Basically different markets is the main difference OSG is aimed at the traditional 3d real-time simulation market ( e.g flight Sim) , while OpenSG is more aimed at the CAD/CAM markets, unfortunately the names do cause some confusion but I doubt that either will be changing its name any time soon. Don Burns wrote this in the subject The quick answer is that, no, there is no connection between Open Scene Graph and OpenSG. Robert and I know the author of OpenSG, Dirk Reiners, and have often engaged in lively conversation with him regarding scene graphs, visualization and the price of tea in China. One might consider us as "in competition", whatever that means in an open source world, but with mutual respect and cooperative attitudes toward each other. The initial purpose of the two projects seems quite similar at first glance, but a closer look will reveal that the focus is a bit different. One might think of the difference in a historical context as the difference between Inventor and Performer. OpenSG is used primarily in CAD and manufacturing circles (though that may have changed over the years), where frame rates need only be interactive, whereas Open Scene Graph is focused on higher performance real-time rendering. Neither seems to be exclusive of the needs of the other, but our respective expertise shows through in the final emphasis. There are many other differences from an architectural, modularity and software design perspective. These are arenas where the programmer must decide what works best with their environment. We are, of course, biased here. What is unfortunate is the coincidence of the names. It is not to be totally unexpected, however. Both projects became public the same year. This is the same year, not coincidentally, that Farenheit (some of you may recall) took a belly flop onto a large concrete slab. This ill fated belly flop, however, took place only _after_ putting the taste of a cross-platform, high-level, scene graph based rendering package in our mouths. Open Source responded as Open Source often does. The idea of having an open source, cross platform, scene graph was not unique to the genius behind either of the two projects. In fact, there were many, many, open source scene graphs that sprung to life at this time. It is, in fact, somewhat remarkable that only two of us came up with the most generic name "Open Scene Graph". What motivated the choice of OpenSG rather than Open Scene Graph, on Dirk's part, I can only speculate about (and I will). Ok, for the record (and I'm not making a huge deal over this, nor am I attempting to instigate contention), we were there first. Try this from a Unix machine: % whois Open Scene Graph.org | grep Created Created On:15-Oct-1999 08:39:02 UTC % whois opensg.org | grep Created Created On:05-Nov-1999 15:09:16 UTC
So, my speculation is that the OpenSG folks wanted the name, but it was taken, so they settled on OpenSG instead of Open Scene Graph, throwing the entire known free world into a state of chaotic confusion and economic meltdown. Well... that might be an exaggeration. The truth is, we once got each others' SIGGRAPH BOF attendees when the meetings were held at the same hotel. OpenSG was in Salon A of Tower I and Open Scene Graph was in Salon A of Tower II, both held at nearly the same time. If these were conventional, commercial ventures, we might be spending a lot of money on lawyers (which would, of course, be reflected in the price of the conventional, commercial product) to sort this out. Thank goodness we can simply just chuckle about it together over a beer. In all cases, the other interesting attribute of Open Source software is that it places it in to an arena where "survival of the fittest" determines longevity. The list of useful open source scene graphs is getting shorter. Open Scene Graph is growing very quickly at the current time, and OpenSG seems to holding its own. One might argue then that as the field narrows, perhaps we could ease everyones confusion and change one of the names so it didn't look so much like the other one | ||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
To transform a particle system inside this reference frame you should transform only the emitters, not the ParticleSystem drawables. If you apply a transform above "fountain.osg" you actually apply a translation/rotation to both emitters and particle systems; To get a correct behavior you should traverse the scene graph and avoid applying the transform to any geodes containing ParticleSystem drawables (courtesy Marco Jez)
| ||||||||||||||||||||||||||||||||||||
|
Yes this can be done but does takes a little work, but it is entirely possible to use OSG within a pre-existing rendering engine First of all, the central object you should know about is osgUtil::SceneView. This class will manage the OSG specific rendering tasks. If you want to take advantage of OSG's animation capabilities, you will also want to maintain your own FrameStamp object. The setup of these two objects will look something like this:
Note, just replace rootNode with your actual root node for you OSG models. NOTE: The call to setComputeNearFarMode is very important. If you don't do this, then OSG will use a different near and far plane when rendering its objects, and they will have different values in the depth-buffer than the rest of your scene. This can lead to very odd effects. If you want to use lighting that is different from what the rest of your renderer is using, you might want to call either:
That's basically it for setup. Now you just need to call SceneView for rendering, and this requires a little extra work. First off, it is recommended that you call glPushAttribs( GL_ALL_ATTRIB_BITS ) and glPushMatrix for each of the modelview, projection and texture matrices before calling your other OpenGL code, and the corresponding pop fuctions afterwards, and do the same with OSG. This prevents OSG and your other OpenGL code from interfering with each other. For example:
The next important thing for using SceneView is that you need to tell it about your pre-existing viewport and projection and modelview matrices. The code to do that looks like this:
The next step is to update your FrameStamp object (if you are using your own):
If you do all of that, you should be able to successfully use OSG within your pre-existing rendering system, thereby gaining many of the advantages of OSG, without having to scrap your existing system
| ||||||||||||||||||||||||||||||||||||
|
OSG's multithreaded support is done through Producer. Not only does Producer provide multithreading support, it provides an improved mult-threading model over those offered by Vega, Performer and Vega Prime, by accomplishing this without the overhead of multi-buffering. This provides single-threaded performance, linearly scalable with the addition of processors and graphics subsystems. APIs with multi-buffering have reduced scalability with the increase in processing units. While the statement is technically correct (OSG on its own does not offer multithreaded support) the omission of Producer's contribution is a gross underevaluation of capability. There was mention of Keyboard and Mouse capabilities on this FAQ question as well, so I'm led to believe that the answer did not come at the exclusivity of Producer. On the other hand, with Robert's direction with CameraNode (the intention of which is anyone's guess) the statement might be prophetic
| ||||||||||||||||||||||||||||||||||||
|
Q: How Can I get a Borderless window on win32 for a windowed application, not a full screen application You can achieve this with by using the following which needs to be called after you have called viewer.realize();
| ||||||||||||||||||||||||||||||||||||
|
On Windows I would recommend that you use WinCVS, this has a nice GUI interface you can also use command lines commans with the program was well You can get WinCVS from here http://www.wincvs.org ( Note WinCVS require TCL and Python to be installed ) Plain old CVS itself can be found here : https://www.cvshome.org
| ||||||||||||||||||||||||||||||||||||
|
You can force the lighting to be OFF for a node and its children using something like the following
| ||||||||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||||||||
|
You can force the Texturing mode to be OFF for a node and its children using something like the following
| ||||||||||||||||||||||||||||||||||||
|
You can force the Texturing mode to be ON for a node and its children using something like the following
| ||||||||||||||||||||||||||||||||||||
|
You can force the Wireframe mode to be ON for a node and its children using something like the following
| ||||||||||||||||||||||||||||||||||||
|
You can force the Wireframe mode to be OFF(normal fill Mode) for a node and its children using something like the following
| ||||||||||||||||||||||||||||||||||||
|
Q: I am using two windows to display my scene, I have a single HUD overlay ortho2D but the HUD overlay is showing up duplicated in both windows. How do I just get a single HUD overlay that is spread over both windows Reply from OSG Mailing List: This is quite simple to fix. In essence, you want the CULL traversal that occurs for the left camera to have one setting for the ortho2D matrix (e.g. 0, 1280, 0, 1024) and the CULL traversal that occurs in the right camera to have a different ortho2D matrix (1280, 2560, 0, 1024). There are a couple of ways to handle this, one is to use a Cull callback on your Projection node, and set the ortho2D matrix depending on which traversal (left or right) calls the callback. You can also use a multi-path approach, which would place two projection nodes under one Group node. Each projection node would then be given a node mask, and each Cull traversal a traversal mask (see the FAQ for code examples for this). Both projection nodes would then share the rest of the HUD sub graph below them. If I were implementing this, I'd take this approach. You could also use Producer::Camera's to do this. Unfortunately, the only scene handler implemented for OSG is osgProducer::OsgSceneHandler, which enforces its own screen clears and disallows the sharing of Render Surfaces by multiple cameras without a series of complicated additions to the scene graph with Clear Nodes, etc. to override this. Had OsgSceneHandler been implemented according to Producer's design, this would be trivial. Another approach to consider is possibly using the new osg::CameraNode, placing one camera in the left camera's scene graph's root where the camera will be nested within the camera's scene graph camera node. The right camera will then sit under the right camera scene graph as a camera node and would have a sub graph containing a camera nested within a camera. | ||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||
|
© Copyright 2003-2006 Gordon Tomlinson All Rights Reserved. All logos, trademarks and copyrights in this site are property of their respective owner. | ||||||||||||||||||||||||||||||||||||
1
