Hi,
how does a plugin get noticed when osg releases an opengl context and
the plugin caches nodes (which are currently not used in the users
scenegraph)?
Richard
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Ok, got it.
Registry caches nodes by name or by objectCacheHint.
Richard
Hi,
how does a plugin get noticed when osg releases an opengl context and
the plugin caches nodes (which are currently not used in the users
scenegraph)?
Richard
, Richard, SDGE1
[EMAIL PROTECTED] wrote:
Hi,
I got some questions about the stategraph build by osg while
culltraversal.
So the primary question is: Why is the stategraph build from the root to
the leafs of the scenegraph and not the other way around?
To explain it a bit, lets make an example:
You want
Hi,
I got some questions about the stategraph build by osg while
culltraversal.
So the primary question is: Why is the stategraph build from the root to
the leafs of the scenegraph and not the other way around?
To explain it a bit, lets make an example:
You want to display a model (a car for
Depending on our hardware, the viewer may run in multithreaded mode, which
means you can't access the openGL context everytime everywhere. Try setting
your viewer into singlethreaded mode with ViewerBase::setThreadingModel( ... )
. The context should be available all the time now...
Richard
To answer the question: Real Time Ray-Tracing: The End of
Rasterization?
Yeah, I think so.
Interesting topic for graphics freaks :-)
http://blogs.intel.com/research/2007/10/real_time_raytracing_the_end_o.
html
--
Adrian Egli
Yep, I gonna fix it and send it in asap.
Richard
On Nov 13, 2007 2:24 PM, Schmidt, Richard, SDGE1
[EMAIL PROTECTED] wrote:
This would require a huge a amount of change, however it's compilant
to
glsl than... (is it?!)
While it would be the nice to have the same convention as GLSL, the
OSG's
Hi,
if you have problems with multiple lightsources in your scenegraph not
glEnableling/glDisableing correctly this may be a solution for you.
First lets recap the error:
osg::Light* l1 = new osg::Light();
osg::Light* l2 = new osg::Light();
osg::StateSet* stateSet = new
the assumption that the
light number/clip plane number is invariant once assigned. This is
done for efficiency purposes and is a trade off in the design.
Robert.
On 10/23/07, Schmidt, Richard, SDGE1 [EMAIL PROTECTED] wrote:
Hi,
if you have problems with multiple lightsources in your scenegraph
the assumption that the
light number/clip plane number is invariant once assigned. This is
done for efficiency purposes and is a trade off in the design.
Robert.
On 10/23/07, Schmidt, Richard, SDGE1 [EMAIL PROTECTED] wrote:
Hi,
if you have problems with multiple lightsources in your scenegraph
Is hat intented?
A CullCallback may store Statesets and push/pop them on the cullvisitor.
It would be nice if those GL Objects get released as well.
Richard
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi
Daniel
Ulrich presented a nice outlining technique on his homepage:
http://www.sandbox.de/osg/
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Daniel
Moos
Sent: Sunday, October 07, 2007 1:52 PM
To: osg-users@lists.openscenegraph.org
Subject:
Another problem is, that nodes which are currently not connected to the
sceneview/camera won't release their GL objects.
Richard
On 9/17/07, Rafa Gaitan [EMAIL PROTECTED] wrote:
viewer.getSceneData()-releaseGLObjects(); // or getCamera()...
Hi,
I think the problem here is that some manipulators take the bounding box
of the scenegraph to calculate the home position. Setting the nodemask
to zero will not affect the bounding box, so the whole hierarchy is
still regarded.
One solution may be to fully detach the invisible node from the
14 matches
Mail list logo
