Hi Atonie, On 6/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Thanks for the answer. Actually, getting two osg::State is what I am looking for. One of the viewer is a true viewer displaying a scene graph the other is running a parrallel terrain generation. The latter should not break the first.
This is a bit not standard setup, but I can understand where you are comming from. You could probably do what youwant with two seperate apps.. but what you are trying to do should be possible as is. Thinking about it now you probably already have two seperate osg::State one for each RenderSurface (each viewer will have one RenderSurface in your setup), all you should need to do is modify the second viewer so its osg::State contextID is set to 1. To ge this you'll need to get the OsgSceneHandler, which manages the internal SceneView, which has the osg::State. Do a setContextID(1) on this State.
I have seen that osgTerrain::DataSet has a setState(osg::State*) method but was not able to use it properly. Is there a way to create an independent graphic context without going for a full osgProducer::Viewer.
osgTerrain needs a context so that it can use OpenGL to do texture compression and mipmapping. You can create a context easily using a RenderSurface. osgdem does this, see the GraphicsContext class at the top of the applications/osgdem/osgdem.cpp
I also had a look at the osgcamera example but it currently does not work on my machine (Error while redimensionning texture because the OpenGL context is not valid) and it is written in the source code that it is not stable yet. It looks like another level of abstraction for the OSG runtime and camera without using Producer. Is that right?
osgcamera is proof of concept, not something to base your own work on. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
