Re: [osg-users] Really Big Scenes and clipping
Hi Richard, The OSG supports high level and low control over draw order via the StateSet::RenderBinDetails. Basically the rendering backend is constructed as a graph of what is called RenderStage(s) and RenderBin(s), the StateSet::RenderBinDetails tells the cull traversal how to build this graph, both the type of RenderBin to create/use and what order it should drawn in. Its a very powerful feature, but its is one of the more advanced and complex to understand ones so you'll need to be patient and steadily bite into rather than diving straight in the deep end and expect understand it all right away. To learn about making a subgraph draw first have a look at the osghangglide example - it has a skydome that it renders first, and you can switch off depth testing for it. The osgvertexprogram example also has a skybox that is view dependant. For general rendering order control have a browse through the osgreflect example. The osgprerender example also provides another example, this time using render to texture cameras. Robert. On Dec 17, 2007 11:22 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) Richard On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Traversing
Hi Renan,
The intersections data structure has a list of hit objects, and these
will include the NodePath down to the hit object and also the Drawable
leaf.
Robert.
On Dec 18, 2007 3:43 AM, Renan Mendes [EMAIL PROTECTED] wrote:
Hi, everyone.
I have a class called Point that is derived from MatrixTransform. An
instance of this class always has a Geode child, which has a Drawable, which
is a ShapeDrawable. For better understanding of things, I'll use a simple
shape for a drawable, let's say a sphere.
Let's suppose I have an instance of my Point class, which is attached
to the viewer, being displayed on the screen
I use a PickHandler class that is as follows:
bool PickHandler::handle(const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter aa)
{
osgViewer::Viewer* viewer = dynamic_castosgViewer::Viewer*( aa );
osgUtil::LineSegmentIntersector::Intersections intersections;
if(!viewer)
{ return false; }
switch( ea.getEventType())
{
case(osgGA::GUIEventAdapter::PUSH):
{
if(Intersecao(viewer, ea))
{ ... } // I'LL TALK ABOUT THESE BRACKETS FURTHER AHEAD
}
}
}
bool PickHandler::Intersecao(osgViewer::Viewer* viewer, const
osgGA::GUIEventAdapter ea,
osg::Util::LineSegmentIntersector::Intersections intersections)
{
return
(viewer-computeIntersections(ea.getX(),ea.getY(),intersections));
}
So, I guess my question is: what do I write inside those brackets
that I marked above to traverse till the drawable and change its color? What
I really need here is some language learning, not only theoretical, OK? In
other words: if you could write a little bit of source code to clarify what
you are saying, that'd be great.
Thanks, everyone. If you manage to explain
how it's done to the newbie you're talking to, I'd be grateful.
Renan M Z Mendes
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] realizeImplementation error with GraphicsWindowEmbedded
Hi Shuxing,
I'm afraid mixing PixelBuffers with GraphicsWindowEmbedded isn't going
to work, as osgViewer won't have the neccesary hooks in the graphics
context that it needs. The graphics window embedded feature is not a
fully feature implemented, rather an adapter to make it really
straight forward to glue a viewer into the window.
In 2.3.0 dev release made last night (and SVN) the osgviewerQT example
now has two implementations of integration with QT, one the
GraphicsWindowEmbedded that you are familiar, and a second that
instead of using QGLWidget uses QWiget and osgViewer itself to create
the graphics contexts using GraphicsWindowWin32/X11/Carbon. This
later technique has the advantage that osgViewer now nows much more
about the graphics contexts and can correctly share them.
Robert.
On Dec 18, 2007 3:51 AM, Shuxing Xiao [EMAIL PROTECTED] wrote:
I'm using osgviewerQT as my windowing system, so the graphicswindow it uses
is GraphicsWindowEmbedded.
But when it comes to realizeImplementation() function of PixelBufferWin32
class, I got the following runtime error:
Run-Time Check Failure #3 - The variable 'hglrc' is being used without being
defined.
I traced the stack, and found in bool
PixelBufferWin32::realizeImplementation()
if (_traits-sharedContext)
{
HGLRC hglrc;
GraphicsWindowWin32* graphicsWindowWin32 =
dynamic_castGraphicsWindowWin32*(_traits-sharedContext);
if (graphicsWindowWin32)
{
hglrc = graphicsWindowWin32-getWGLContext();
}
else
{
PixelBufferWin32* pixelBufferWin32 =
dynamic_castPixelBufferWin32*(_traits-sharedContext);
if (pixelBufferWin32)
{
hglrc = pixelBufferWin32-getWGLContext();
}
}
wglShareLists(hglrc, _hglrc);
}
Since my graphicswindow is GraphicsWindowEmbedded, then the two dynamic_cast
will all return NULL.
And then the hglrc will be uninitialized when wglShareLists is invoked. That
causes the error. However, I've no idea how to fix this runtime error.
BTW, This error doesn't happen when I first setup my scene and view it, but
when I modified the scene and changed one of its node.
Any help will be great appreciated, thanks a lot.
Sincerely yours,
Shuxing Xiao
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] realizeImplementation error withGraphicsWindowEmbedded
Thanks very much for the clarification. Robert
Honestly, I myself don't how come there's such kind of mixed up in my
application, I only updated the version of osg from 2.0 to 2.2.
Whatever, So may I now only check out the newest version of osgviewerQT
without change my version of osg? Because it will take a lot of time to
change the osg libraries on every machine of my lab.
Hi Shuxing,
I'm afraid mixing PixelBuffers with GraphicsWindowEmbedded isn't going
to work, as osgViewer won't have the neccesary hooks in the graphics
context that it needs. The graphics window embedded feature is not a
fully feature implemented, rather an adapter to make it really
straight forward to glue a viewer into the window.
In 2.3.0 dev release made last night (and SVN) the osgviewerQT example
now has two implementations of integration with QT, one the
GraphicsWindowEmbedded that you are familiar, and a second that
instead of using QGLWidget uses QWiget and osgViewer itself to create
the graphics contexts using GraphicsWindowWin32/X11/Carbon. This
later technique has the advantage that osgViewer now nows much more
about the graphics contexts and can correctly share them.
Robert.
On Dec 18, 2007 3:51 AM, Shuxing Xiao [EMAIL PROTECTED] wrote:
I'm using osgviewerQT as my windowing system, so the graphicswindow it
uses
is GraphicsWindowEmbedded.
But when it comes to realizeImplementation() function of PixelBufferWin32
class, I got the following runtime error:
Run-Time Check Failure #3 - The variable 'hglrc' is being used without
being
defined.
I traced the stack, and found in bool
PixelBufferWin32::realizeImplementation()
if (_traits-sharedContext)
{
HGLRC hglrc;
GraphicsWindowWin32* graphicsWindowWin32 =
dynamic_castGraphicsWindowWin32*(_traits-sharedContext);
if (graphicsWindowWin32)
{
hglrc = graphicsWindowWin32-getWGLContext();
}
else
{
PixelBufferWin32* pixelBufferWin32 =
dynamic_castPixelBufferWin32*(_traits-sharedContext);
if (pixelBufferWin32)
{
hglrc = pixelBufferWin32-getWGLContext();
}
}
wglShareLists(hglrc, _hglrc);
}
Since my graphicswindow is GraphicsWindowEmbedded, then the two
dynamic_cast
will all return NULL.
And then the hglrc will be uninitialized when wglShareLists is invoked.
That
causes the error. However, I've no idea how to fix this runtime error.
BTW, This error doesn't happen when I first setup my scene and view it,
but
when I modified the scene and changed one of its node.
Any help will be great appreciated, thanks a lot.
Sincerely yours,
Shuxing Xiao
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] realizeImplementation error withGraphicsWindowEmbedded
Hi Shuxing,
You could just grab the osgviewerQT source code by browsing SVN online.
As for managing OSG versions across a lab, why not just share the OSG
build/binary/lib directory across the network.
Robert.
On Dec 18, 2007 10:03 AM, Shuxing Xiao [EMAIL PROTECTED] wrote:
Thanks very much for the clarification. Robert
Honestly, I myself don't how come there's such kind of mixed up in my
application, I only updated the version of osg from 2.0 to 2.2.
Whatever, So may I now only check out the newest version of osgviewerQT
without change my version of osg? Because it will take a lot of time to
change the osg libraries on every machine of my lab.
Hi Shuxing,
I'm afraid mixing PixelBuffers with GraphicsWindowEmbedded isn't going
to work, as osgViewer won't have the neccesary hooks in the graphics
context that it needs. The graphics window embedded feature is not a
fully feature implemented, rather an adapter to make it really
straight forward to glue a viewer into the window.
In 2.3.0 dev release made last night (and SVN) the osgviewerQT example
now has two implementations of integration with QT, one the
GraphicsWindowEmbedded that you are familiar, and a second that
instead of using QGLWidget uses QWiget and osgViewer itself to create
the graphics contexts using GraphicsWindowWin32/X11/Carbon. This
later technique has the advantage that osgViewer now nows much more
about the graphics contexts and can correctly share them.
Robert.
On Dec 18, 2007 3:51 AM, Shuxing Xiao [EMAIL PROTECTED] wrote:
I'm using osgviewerQT as my windowing system, so the graphicswindow it
uses
is GraphicsWindowEmbedded.
But when it comes to realizeImplementation() function of PixelBufferWin32
class, I got the following runtime error:
Run-Time Check Failure #3 - The variable 'hglrc' is being used without
being
defined.
I traced the stack, and found in bool
PixelBufferWin32::realizeImplementation()
if (_traits-sharedContext)
{
HGLRC hglrc;
GraphicsWindowWin32* graphicsWindowWin32 =
dynamic_castGraphicsWindowWin32*(_traits-sharedContext);
if (graphicsWindowWin32)
{
hglrc = graphicsWindowWin32-getWGLContext();
}
else
{
PixelBufferWin32* pixelBufferWin32 =
dynamic_castPixelBufferWin32*(_traits-sharedContext);
if (pixelBufferWin32)
{
hglrc = pixelBufferWin32-getWGLContext();
}
}
wglShareLists(hglrc, _hglrc);
}
Since my graphicswindow is GraphicsWindowEmbedded, then the two
dynamic_cast
will all return NULL.
And then the hglrc will be uninitialized when wglShareLists is invoked.
That
causes the error. However, I've no idea how to fix this runtime error.
BTW, This error doesn't happen when I first setup my scene and view it,
but
when I modified the scene and changed one of its node.
Any help will be great appreciated, thanks a lot.
Sincerely yours,
Shuxing Xiao
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Richard, I've seen this type of thing before in my scenes with cracks in the terrain. Adjusting of lines 242-243 in DepthPartitionNode.cpp seemed to fix this for me: znear *= 0.99; zfar *= 1.01; - D. On Dec 17, 2007 5:30 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Donald, Thanks... that's a pretty easy looking solution. However, I seem to be doing something unorthodox somewhere that is preventing this node from working as intended. I get a moving gap cut through the world that is more or less parallel to the camera plane, and that moves around as the camera moves (I am moving my camera manually). Have you seen this effect before (see below)? Richard On Dec 17, 2007, at 9:03 AM, Donald Cipperly wrote: Have a look at the osgdepthpartition example. I use depth partitioning to solve z-fighting issues in really large scenes. - D. On Dec 17, 2007 7:17 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode (osgUtil::CullVisitor:: DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Traversing
Hi, Robert. I'm sorry, Robert, but would you mind explaining a little bit more on how do I get access to this list? And from this, how do I choose specifically the Drawable leaf? Thanks, Renan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Traversing
On Dec 18, 2007 1:08 PM, Renan Mendes [EMAIL PROTECTED] wrote: Hi, Robert. I'm sorry, Robert, but would you mind explaining a little bit more on how do I get access to this list? And from this, how do I choose specifically the Drawable leaf? All the info is in the header files, just look up the definition of Intersections in the LineSegmentIntersector/PolytopeIntersector. Also look at the osgpick example. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robert, Robert Osfield wrote: An external script that invokes the 3D app only works when entering an application, not once its running, so it does have a bit of limited applicability. I understand that, however, how often do you need to change resolution once the application is running? If it is needed only once when starting it, then it is not a problem. You can always make the app called and the path application/user definable with a sensible default for each platform one doesn't need to hard wire it - if a platform doesn't have anything sensible then you'd just have a blank app string and would therefore not call the res changing app. That could work, but I am not sure whether it is actually worth the trouble - the original poster only wanted to change the resolution before starting the application, not during runtime, so this could be an overkill. Perhaps a poll to figure out whether this is a one-off request or a more general issue would be a good thing to do. BTW, I'm just trying to explore possible solutions here. I see. I would say that a most future-proof solution would be to implement support for the RandR extension (http://keithp.com/~keithp/talks/randr/). This is now supported by everything running X.Org X servers (Linux, various BSDs), however proprietary Unix doesn't support it (SGI, Sun, HP). I am not sure whether that would be a significant issue or not. However, it is not 100% foolproof solution, because not all drivers support it (ATI and nVidia do, though). Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHZ8mAn11XseNj94gRAhHgAJ9/CrXu2NKFpUVHT/DRfM545Gc2oQCg7KA+ J/mRwxs5trWZaUFQIa9cHyc= =HOut -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Thanks, scaling just a little bit more than you did the trick. This is a pretty useful node! Richard On Dec 18, 2007, at 7:36 AM, Donald Cipperly wrote: Richard, I've seen this type of thing before in my scenes with cracks in the terrain. Adjusting of lines 242-243 in DepthPartitionNode.cpp seemed to fix this for me: znear *= 0.99; zfar *= 1.01 ; - D. On Dec 17, 2007 5:30 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Donald, Thanks... that's a pretty easy looking solution. However, I seem to be doing something unorthodox somewhere that is preventing this node from working as intended. I get a moving gap cut through the world that is more or less parallel to the camera plane, and that moves around as the camera moves (I am moving my camera manually). Have you seen this effect before (see below)? Richard On Dec 17, 2007, at 9:03 AM, Donald Cipperly wrote: Have a look at the osgdepthpartition example. I use depth partitioning to solve z-fighting issues in really large scenes. - D. On Dec 17, 2007 7:17 AM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera-setComputeNearFarMode (osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a 'standardized' technique for this (it can't be that unusual), none of the example programs seem to have this kind of configuration. Richard ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Robert, Yes, mastery of a new technology certainly is a long term investment ;-) Thanks for this explanation, it is a valuable insight. As I continue to grok more of the OSG philosophy, I'm sure more of this will become more intuitive to me. I have now found three different solutions to my original problem that all work, so I feel I have moved another rung or two up the ladder ;-) I will also look at the examples you recommended for further insights. Richard On Dec 18, 2007, at 4:16 AM, Robert Osfield wrote: Hi Richard, The OSG supports high level and low control over draw order via the StateSet::RenderBinDetails. Basically the rendering backend is constructed as a graph of what is called RenderStage(s) and RenderBin(s), the StateSet::RenderBinDetails tells the cull traversal how to build this graph, both the type of RenderBin to create/use and what order it should drawn in. Its a very powerful feature, but its is one of the more advanced and complex to understand ones so you'll need to be patient and steadily bite into rather than diving straight in the deep end and expect understand it all right away. To learn about making a subgraph draw first have a look at the osghangglide example - it has a skydome that it renders first, and you can switch off depth testing for it. The osgvertexprogram example also has a skybox that is view dependant. For general rendering order control have a browse through the osgreflect example. The osgprerender example also provides another example, this time using render to texture cameras. Robert. On Dec 17, 2007 11:22 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: Robert, Thanks, yes I have used the Fog approach before, it is especially effective for underwater scenes. However, I need to be able to see quite a ways distant (flight sim). If I was NOT using a scene graph, I would draw the sky dome as a unit sphere, and just rotate it by the camera transform, but not translate it (thus, appearing infinitely distant). I would draw it first, and not write to the depth buffer. Here's where the OSG newbie kicks in... doesn't the scene graph reorder the nodes at will (ok, I know it's not random, but you get my point)? Is there a way I have missed to say this node must always be drawn first? If so, I can easily manipulate the matrix of the sky dome to get the effect I want, and I bet I can turn off depth writing using the state mechanism. I have however, missed the draw me first flag ;-) Richard On Dec 17, 2007, at 11:19 AM, Robert Osfield wrote: Hi Richard, You could play multi-pass tricks like done in the osgdepthpartion example, or just manage the visible distance so that the furthest distance is never too far away. For instance a common trick is to use Fog to make far objects fade away until eventually nothing beyond a certain distance can be seen - so you simply cull it and this pull in the far plane. The skydome could also be computed dynamically to just fits the size of the scene required for that frame instead of the whole model. Robert. On Dec 17, 2007 1:17 PM, Richard S. Wright Jr. [EMAIL PROTECTED] wrote: I'm working on my first OSG project (so be gentle ;-) I'm using OSG 2.2 on OS X (Leopard). I have a terrain in a .osga file, a skydome, and some .3ds models. Everything loads fine, and I have a flight sequence working that takes off and lands on an aircraft carrier. There are lots of samples that made this part pretty easy to figure out (just load and move objects around). I'm a little lost however as to how OSG is handling the near and far clipping planes, and object scale. Actually, OSG seems to be monkeying with these settings in a manner that is probably a nice feature once I understand how to best make use of it. The terrain is really big, the skybox is really big, and the models are really small in comparison. OSG seems to recomputing the near and far clipping planes depending on the objects in view. For example, on the deck of the carrier, all is well. If I turn so that the terrain is also in view (off in the distance), the near clipping plane seems to be changed and parts of the carrier disappear (the same happens with the large skydome...) apparently to accommodate the display of the much larger model that is now in view. I did find an old message that says this: Camera- setComputeNearFarMode (osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); prevents this... however, then I need a giant frustum to hold everything and we all know what a bucket of z-fighting joy that brings. It is not clear to me how to arrange these objects correctly to make this rescaling of the scenes objects work correctly. Currently, the terrain database, the skydome, and the ship models are all hanging off the root of the scene graph with just a transform that scales, translates and rotates them as necessary. Is there a
[osg-users] changing colors of a geode
Hi all, I'm new to OSG. I cannot find a way to change the primary color of OpenGL in order to draw the same object twice in two different places with two different colors. I mean that in OpenGL I can do that in this way: glColor3fv(color1); // set model view matrix // draw object A glColor3fv(color2); //set model view matrix //draw object A Instead in OSG I should create two geodes with the same geometry, but different color, in order to do that. I tried to search a way to change the color in the osg::MatrixTransform, without finding it. Actually I don't want to duplicate the geometry data just to change a color! Furthermore, changing the primary color in an osg::Node would be really useful to quickly change the behavior of lit objects. I mean that in OpenGL I can set material properties by: glColorMaterial(...); and then change the behaviour just changing the primary color, before drawing the objects. I hope someone can help me. Thanks in advance, Gianluca Natale. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Asynchronous file loading via DatabasePager questions
Tim Moore wrote:
The other thing to keep in mind is that readNodeFile and friends aren't
necessarily
thread safe, but you don't have access to the lock that the pager uses to
serialize
access to those functions. Either you stop doing any file loading calls from
your main
thread once the pager has started, or you need to do the locking yourself by
installing
read callback functions that do the locking. The bugs you're seeing sound like
random
corruption of this kind.
I believed that osgDB::Registry operations were thread safe. The plugins may
not be thread safe but the registry has to be thread safe.
No ?
Tim Moore wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Colin Branch wrote:
Hi all,
What I'm trying to do:
Asynchronous model loading using OSG 2.2
How I'm currently doing it:
I'm trying to use the Database Pager's requestNodeFile.
I just did this for the FlightGear project and it works well there.
I created a new node class that I can add (as well as place temporary
objects) that I can add and will stay in the scene.
class DtDelayedModelNode : public osg::Group
{
...
DtDelayedModelNode(const std::string filename, osgDB::DatabasePager*
pager) : osg::Group()
{
osg::FrameStamp fs;
fs.setFrameNumber(INT_MAX);
pager-requestNodeFile(filename,this,1.0,fs);
}
...
};
For this application you probably do want to check out ProxyNode as Bryan Thrall
suggested. If I had known about ProxyNode I might have used it instead of
calling
requestNodeFile directly.
What you've done here won't reliably work. You need to call requestNodeFile
every frame
until your request is satisfied. You will only find this out by looking closely
at the
implementation of ProxyNode and PagedLOD or by googling in the mailing list :)
Problems:
#1 Very limited documentation of the Pager class and no example on how
to use it. I've searched the osgusers archive but haven't found
anything too helpful, the 1.x examples don't seem relevant anymore.
See above about ProxyNode and PagedLOD.
#2 Occasional texture corruption. This is difficult to reproduce
however it appears that sometimes the width of the texture is 1px
creating a streaking effect.
#3 Certain actions cause the main app to lock, for example bringing up
the Stats HUD.
The other thing to keep in mind is that readNodeFile and friends aren't
necessarily
thread safe, but you don't have access to the lock that the pager uses to
serialize
access to those functions. Either you stop doing any file loading calls from
your main
thread once the pager has started, or you need to do the locking yourself by
installing
read callback functions that do the locking. The bugs you're seeing sound like
random
corruption of this kind.
Questions:
Is the Database Pager the proper way to be doing this?
It works for the FlightGear flight simulator project. I created a very small
subclass
of DatabasePager in order to have access to the _childrenToDeleteList of the
pager.
What if any calls should I make to the pager around frame() (ie it
doesn't appear that startFrame endFrame are needed, any other calls)?
None if you're using osgViewer. Otherwise look closely at the osgViewer::Viewer
source
code.
The value of the frame stamp appears to control deletion of requests. Ie
if I pass in the current frame stamp, the model is actually deleted in
compileGLObjects. Unless I set it to some value in the future (currently
using INT_MAX) I can't guarantee it will load. Could someone explain the
purpose of the framestamp and the proper usage?
See above. Normally you check every frame if a request has been satisfied; if
not, you
make it again with the current frame stamp. The OSG clients of DatabasePager,
ProxyNode
and PagedLOD, make these requests from the cull traversal, so this usage gives
a way
to cancel a request if the object drops out of the field of view.
Is there anyway to get status feedback while a file loads?
You can tell if a load is completed by checking if an object has been added to
the group
you passed to requestNodeFile. Otherwise no, though you could arrange for the
readNodeFile
callback you're going to write :) to return an empty error object of some kind.
Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHY5HHeDhWHdXrDRURAqMHAJ9EwsSEmq/km+Kmm66vQR7QHypqxgCfXtcb
AYMB1dGywN0upP0wEE9JErc=
=mNg5
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] changing colors of a geode
Hi Gianluca, You can use the osg::Material StatAattributeto control colour - attach this to a StateSet that decorate a subgraph and this state will be inherted down to the leaves. This only works when OpenGL lighting is on though as it uses glMaterial to set the material parameters. As a general note glFunction maps to osg::Function. Robert. On Dec 18, 2007 2:19 PM, Gianluca Natale [EMAIL PROTECTED] wrote: Hi all, I'm new to OSG. I cannot find a way to change the primary color of OpenGL in order to draw the same object twice in two different places with two different colors. I mean that in OpenGL I can do that in this way: glColor3fv(color1); // set model view matrix // draw object A glColor3fv(color2); //set model view matrix //draw object A Instead in OSG I should create two geodes with the same geometry, but different color, in order to do that. I tried to search a way to change the color in the osg::MatrixTransform, without finding it. Actually I don't want to duplicate the geometry data just to change a color! Furthermore, changing the primary color in an osg::Node would be really useful to quickly change the behavior of lit objects. I mean that in OpenGL I can set material properties by: glColorMaterial(...); and then change the behaviour just changing the primary color, before drawing the objects. I hope someone can help me. Thanks in advance, Gianluca Natale. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
Hi Jan, On Dec 18, 2007 1:22 PM, Jan Ciger [EMAIL PROTECTED] wrote: An external script that invokes the 3D app only works when entering an application, not once its running, so it does have a bit of limited applicability. I understand that, however, how often do you need to change resolution once the application is running? If it is needed only once when starting it, then it is not a problem. The OSG is a general purpose graphics library so it needs to accommodate a wide range of application usage, and also try to make it seemless across platforms - this is the advantage with wrapping it up with existing OSG interfaces for it - ones that are only implemented for Win32 so far. You can always make the app called and the path application/user definable with a sensible default for each platform one doesn't need to hard wire it - if a platform doesn't have anything sensible then you'd just have a blank app string and would therefore not call the res changing app. That could work, but I am not sure whether it is actually worth the trouble - the original poster only wanted to change the resolution before starting the application, not during runtime, so this could be an overkill. Perhaps a poll to figure out whether this is a one-off request or a more general issue would be a good thing to do. BTW, I'm just trying to explore possible solutions here. I see. I would say that a most future-proof solution would be to implement support for the RandR extension (http://keithp.com/~keithp/talks/randr/). This is now supported by everything running X.Org X servers (Linux, various BSDs), however proprietary Unix doesn't support it (SGI, Sun, HP). I am not sure whether that would be a significant issue or not. However, it is not 100% foolproof solution, because not all drivers support it (ATI and nVidia do, though). RandR support would be a reasonable way forward. SGI and other older workstation class machines are not so prone to users wishing to change resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92 this didn't change till my final contact with SGI's with the Oynx IR2... If if users do wish support on these platforms they can step forward and implement it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] changing colors of a geode
The best way to do this in OSG is to create two Geometry objects. Make them both share the same VertexArrays, NormalArray, TexCoordArray (if you're texture mapping), and PrimitiveSets. Then give each of them different color arrays and specify a color binding of BIND_OVERALL. Primary color, normal, texcoord, edge flag, etc., are not StateAttributes in OSG. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gianluca Natale Sent: Tuesday, December 18, 2007 7:20 AM To: Osg Users Subject: [osg-users] changing colors of a geode Hi all, I'm new to OSG. I cannot find a way to change the primary color of OpenGL in order to draw the same object twice in two different places with two different colors. I mean that in OpenGL I can do that in this way: glColor3fv(color1); // set model view matrix // draw object A glColor3fv(color2); //set model view matrix //draw object A Instead in OSG I should create two geodes with the same geometry, but different color, in order to do that. I tried to search a way to change the color in the osg::MatrixTransform, without finding it. Actually I don't want to duplicate the geometry data just to change a color! Furthermore, changing the primary color in an osg::Node would be really useful to quickly change the behavior of lit objects. I mean that in OpenGL I can set material properties by: glColorMaterial(...); and then change the behaviour just changing the primary color, before drawing the objects. I hope someone can help me. Thanks in advance, Gianluca Natale. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] changing colors of a geode
Gianluca Natale wrote: Hi all, I'm new to OSG. I cannot find a way to change the primary color of OpenGL in order to draw the same object twice in two different places with two different colors. Just to throw in a third alternative, you could create a simple shader that took a colour parameter. Depending on your application, this may be overkill, but if later on you want to get more complicated with your shading this method will scale nicely. This is really just an illustration of how the same thing can be done in different ways with OSG. -JD __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
That could work, but I am not sure whether it is actually worth the trouble - the original poster only wanted to change the resolution before starting the application, not during runtime, so this could be an overkill. Perhaps a poll to figure out whether this is a one-off request or a more general issue would be a good thing to do. Actually I want the resolution to be able to be changed anytime in the application. So the user starts the application, finds that the the application runs a little slow, changes some settings for detail and resolution, and now the application performs at a good rate. And a smart application would be even nicer where it tests the users machine and automatically configures this stuff for them (but still allows them to change it). I see. I would say that a most future-proof solution would be to implement support for the RandR extension (http://keithp.com/~keithp/talks/randr/). This is now supported by everything running X.Org X servers (Linux, various BSDs), however proprietary Unix doesn't support it (SGI, Sun, HP). I am not sure whether that would be a significant issue or not. However, it is not 100% foolproof solution, because not all drivers support it (ATI and nVidia do, though). RandR support would be a reasonable way forward. SGI and other older workstation class machines are not so prone to users wishing to change resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92 this didn't change till my final contact with SGI's with the Oynx IR2... If if users do wish support on these platforms they can step forward and implement it. That's what I was thinking as the solution is already not 100% foolproof. Because if you compile your code on Linux/BSD/Unix/etc. and expect it to work the same on every platform, it doesn't (works on Mac and Windows though). So at least including the Linux/BSD and others that support X.Org is a little better than not supporting any at all. Currently OSG just silently fails when making this call, which you could still do for those platforms that don't support the RandR extension. Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Hello Richard, However, I also have some transparent items, so the sky still needs to be drawn first (and I did neglect to mention this to be fair). Just set your transparent bin to be a larger number than the skybox. Then, the order will be: 1. Opaque objects 2. Skydome 3. Transparent objects Anyways, it's a relatively minor thing. If you're not fill-limited, don't even waste time on this... I was just mentioning it so you know, and might consider it for future projects. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Really Big Scenes and clipping
Hello Chase, It sounds like he wants to render it first because he's placing a unit sphere around the eyepoint, which is probably closer than everything else and surely won't get clipped by the far plane. That way, everything that's rendered later will overwrite it as if occluding it, leaving only unoccluded areas of the sky still visible without any fear of z-fighting. By changing the depth test as was done in the code I posted, that's not a problem. The skybox/skydome will be rendered, regardless of its size, wherever nothing has written in the depth buffer before (more precisely, wherever the depth is at maximum, so at the far plane itself). J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
For many games (particular on Windows of yesteryears) and applications, I have changed resolutions and 3D effects once the application or game has started depending on the frame rate performance. Thus if possible it would be best to implement a feature into OSG to change resolution, though how this would be done internal can be very platform dependent, so more work would be needed to implement this feature. My 2c worth. Rizzen Lucas Goss wrote: That could work, but I am not sure whether it is actually worth the trouble - the original poster only wanted to change the resolution before starting the application, not during runtime, so this could be an overkill. Perhaps a poll to figure out whether this is a one-off request or a more general issue would be a good thing to do. Actually I want the resolution to be able to be changed anytime in the application. So the user starts the application, finds that the the application runs a little slow, changes some settings for detail and resolution, and now the application performs at a good rate. And a smart application would be even nicer where it tests the users machine and automatically configures this stuff for them (but still allows them to change it). I see. I would say that a most future-proof solution would be to implement support for the RandR extension (http://keithp.com/~keithp/talks/randr/). This is now supported by everything running X.Org X servers (Linux, various BSDs), however proprietary Unix doesn't support it (SGI, Sun, HP). I am not sure whether that would be a significant issue or not. However, it is not 100% foolproof solution, because not all drivers support it (ATI and nVidia do, though). RandR support would be a reasonable way forward. SGI and other older workstation class machines are not so prone to users wishing to change resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92 this didn't change till my final contact with SGI's with the Oynx IR2... If if users do wish support on these platforms they can step forward and implement it. That's what I was thinking as the solution is already not 100% foolproof. Because if you compile your code on Linux/BSD/Unix/etc. and expect it to work the same on every platform, it doesn't (works on Mac and Windows though). So at least including the Linux/BSD and others that support X.Org is a little better than not supporting any at all. Currently OSG just silently fails when making this call, which you could still do for those platforms that don't support the RandR extension. Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Collada-Plugin-problems and suggestions for correction
Hello Collada-Pluginfans,
here are some problems with collada plugin:
1. Problem + Solution:
-
can someone please verify it this a feature or a bug in the current osg-svn
version:
Assumed error in if statement:
in daeWriter line 92:
- snip
//### provide a name to node
std::string daeWriter::getNodeName(const osg::Node node,const std::string
defaultName)
{
std::string nodeName;
if ((node.getName().empty()) || (node.getName()!=)) -- assumed to be
wrong
nodeName=uniquify(defaultName);
else
nodeName=node.getName();
return nodeName;
}
snip
suggestion replace != with ==:
if ((node.getName().empty()) || (node.getName()==)) -- assumed to be
correct
2. Problem + Solution:
---
Compiling current svn version of osg and current svn version of collada_dom
I got errors using vc7.1 and compiling daeRMaterials.cpp every time
something like this occurred:
NULL != SetParamArray[i]-getFx_basic_type_common()
NULL != SetParamArray[i]-getFx_basic_type_common()-getFloat4()
Errormessage: no binary operator '!=': no global operator found accepting
type 'const domFx_baisc_type_commonRef' (-- this is a rough translation
from German Visual-Studio to English ). It seems there is a problem in
converting dae-smart-ptr I could eliminate errors by adding .cast() at the
end:
NULL != SetParamArray[i]-getFx_basic_type_common().cast()
NULL != SetParamArray[i]-getFx_basic_type_common()-getFloat4().cast()
Did anyone else had the same Problem with vc7.1? Can this be integrated to
current osg-svn?
Best Regards
Bjoern
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Traversing
Hello Renan,
As Robert mentioned, you really need to learn how to read the API
documentation (doxygen-generated) and click links on it to find out
how to connect things together.
For your current situation, take a look at the osgpick example. The
PickHandler::handle() method calls PickHandler::pick(), which looks
like this:
void PickHandler::pick(osgViewer::Viewer* viewer,
const osgGA::GUIEventAdapter ea)
{
osgUtil::LineSegmentIntersector::Intersections intersections;
std::string gdlist=;
if (viewer-computeIntersections(ea.getX(),ea.getY(),intersections))
{
for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr =
intersections.begin();
hitr != intersections.end();
++hitr)
{
std::ostringstream os;
if (!hitr-nodePath.empty()
!(hitr-nodePath.back()-getName().empty()))
{
// HERE YOU HAVE THE NODE THAT WAS PICKED
}
else if (hitr-drawable.valid())
{
// HERE YOU HAVE THE DRAWABLE THAT WAS PICKED!
// This is what you want, so you can probably remove the
// above if statement...
// Insert the code you want here... For example:
osg::ShapeDrawable* shapeDrawable =
dynamic_castosg::ShapeDrawable*(hitr-drawable);
if (shapeDrawable)
{
shapeDrawable-setColor(osg::Vec4(1,0,0,1));// Red
}
}
// ...
}
}
// ...
}
As you can see, the OSG examples are a great source of hints on how to
do things. Also, looking at the doxygen would have helped you.
Hope this helps,
J-S
--
__
Jean-Sebastien Guay [EMAIL PROTECTED]
http://whitestar02.webhop.org/
This message was sent using IMP, the Internet Messaging Program.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and Chromium
Hi there, we have successfully built a Cave (4 renderind planes. 12 projectors. 6 graphical nodes x 2 nvidia 8800 ) environment using OSG 2.1.1 for rendering and mpi for synchronization and data distribution. it is feasible. osg is well suited for some aspects. for example swap buffers synch for 2 displays in the same machine. But to build a rendering cluster you need multi-machine synchronization .. a frame lock so every machine swaps buffers at the same time. for this we used mpi's barrier and a extension of the osgViewer. but i think one can implement a simpler barrier using sockets. Another thing... glFinish is pretty important... on a rendering cluster. Rui On Dec 12, 2007 5:45 PM, syed tayyab [EMAIL PROTECTED] wrote: Hi folks I am a student and want to use OSG for my project , as part of my project i have to do parallel rendering over the grid or Cluster. Does any one now the feasibility of this scenario. or any other combination. Looking forward to hear from you. Regards Syed Tayyab Messenger on the move. Text MSN to 63463 now! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
Hi All, After a long search in OSG SVN revision, I found this is a fonts file issue. I downdate my SVN and rebuild OSG for the revision 7648, just before integration of Text3D 7500, 7300, 7000, 6900, 6500, ~ here begin dependancy with external OpenThreads 6400, ~ here begin dependancy with external Producer 6200, 6000 problem is always present I downdate my freetype version to 2.2 2.1.10 2.1.9 2.0.9 problem is always present g finally .. I try to my own arial.ttf file provide by the package mstcorefonts-2.0.1. This package is created with a script provided by mstcorefont project. This script download font on Microsoft site and make a rpm with them. To conclude, this is a font file problem. I submit the file on osg-submissions now. Cheers David 2007/12/17, Robert Osfield [EMAIL PROTECTED]: Hi Paul, On Dec 16, 2007 7:53 PM, Paul Martz [EMAIL PROTECTED] wrote: Thanks, Robert -- Unfortunately, this change had no effect. Maybe another avenue of attack might be to add DEBUG_INFO messages to osgText to display components that contribute to the final size of SCREEN-aligned glyphs? Then we could compare my DEBUG_INFO output against yours to see if that sheds any light? Today is going to be a very busy day for me so I won't be able to go chase this up right now. A close review of the changes that David made might reveal some possibilities. Adding more debugging as you suggest might also provide more time. Something for later in the week, unless others can jump in and help. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
For many games (particular on Windows of yesteryears) and applications, I have changed resolutions and 3D effects once the application or game has started depending on the frame rate performance. Thus if possible it would be best to implement a feature into OSG to change resolution, though how this would be done internal can be very platform dependent, so more work would be needed to implement this feature. This feature is already in OSG and works already on Windows and Mac (the function in question is setScreenResolution in the osgViewer library). So it's already implemented on two platforms, but not on any *nix platform. Lucas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Thanks for the Help! Another newbie question
Thank you Robert Osfield. Your help is greatly appreciated! I now have a functioning OSG 2.2 installation on Windows! I have another newbie question: Does anyone know how to control the size of the output graphics window? I don't know its technical name but I think it's the Viewer object. However, I've no idea what methods to call to control the actual size of that window and to keep it from maximizing. Thanks again! :-) -- Sincerely, Allen Senior Software Engineer EDO-CAS, Inc Ps 34:5 I sought the Lord, and he heard me; and he delivered me from all my fears ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Thanks for the Help! Another newbie question
Hi All, To control the size you need to set the size of the GraphicsWindow that you attach to the Viewer's Camera. Have a look at the osgcamera or osgwindows examples to see how it can be done. There is also a convinience method osgViewer::View::setUpViewInWindow(x,y,w,h) that wraps up the lower level set up you'll see in osgcamera/osgwindows. For some the examples (such as osgviewer) you can also provide a command line option --window x y w h, or set an env var OSG_WINDOW x y w h to force them to open up in a window. Robert. On Dec 18, 2007 3:43 PM, Allen [EMAIL PROTECTED] wrote: Thank you Robert Osfield. Your help is greatly appreciated! I now have a functioning OSG 2.2 installation on Windows! I have another newbie question: Does anyone know how to control the size of the output graphics window? I don't know its technical name but I think it's the Viewer object. However, I've no idea what methods to call to control the actual size of that window and to keep it from maximizing. Thanks again! :-) -- Sincerely, Allen Senior Software Engineer EDO-CAS, Inc Ps 34:5 I sought the Lord, and he heard me; and he delivered me from all my fears ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Traversing
Hello, Jean-Sébastien. Although it didn't seem so, I have looked through the doxygen documentation. The thing is that they aren't good enough for someone who hasn't any experience what so ever with this kind of programming. Some of the methods aren't fully explained, at least to my understanding, and even if they were, is kind of weird reading that whole documentation without knowing what you are looking for. This last part, I believe, is the function of a tutorial or something alike. For instance, I didn't know that an intersection was made directly with the Drawable, even though my instance connected to the viewer is a MatrixTransform... But I think now I can at least use the Intersections properly, even if I don't fully understand it. I thank you and Robert for the help. Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Traversing
Hello Renan, Although it didn't seem so, I have looked through the doxygen documentation. The thing is that they aren't good enough for someone who hasn't any experience what so ever with this kind of programming. Some of the methods aren't fully explained, at least to my understanding, and even if they were, is kind of weird reading that whole documentation without knowing what you are looking for. This last part, I believe, is the function of a tutorial or something alike. I understand it can be daunting at first. There are a few tutorials that might be useful, for instance Paul Martz's OSG Quick Start Guide, and the NPS tutorials which are on the Wiki now - see http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials . The latter even have a picking tutorial IIRC. For instance, I didn't know that an intersection was made directly with the Drawable, even though my instance connected to the viewer is a MatrixTransform... A MatrixTransform does not have any geometry, so it cannot be intersected itself... The MatrixTransform has a child Geode, which contains a Drawable (ShapeDrawable in your case, but could be Geometry) and this is what actually checks if it was intersected (on the polygon level). Therefore, that is what is returned in the intersections list. Hope this helps, J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Traversing
Hi, Jean-Sébastien. I'm gonna take advantage of the fact you are there and ask you one thing. I tried using that last part of code you've given me, but my compiler acused an error: 1.\Classe Pick Handler.cpp(23) : error C2682: cannot use 'dynamic_cast' to convert from 'osg::ref_ptrT' to 'osg::ShapeDrawable *' 1with 1[ 1T=osg::Drawable 1] given that the line where the error ocurred was: osg::ShapeDrawable* shapedrawable = dynamic_castosg::ShapeDrawable*(hitr-drawable); Can you tell me what's wrong? Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Traversing
Hello Renan, 1.\Classe Pick Handler.cpp(23) : error C2682: cannot use 'dynamic_cast' to convert from 'osg::ref_ptrT' to 'osg::ShapeDrawable *' 1with 1[ 1T=osg::Drawable 1] given that the line where the error ocurred was: osg::ShapeDrawable* shapedrawable = dynamic_castosg::ShapeDrawable*(hitr-drawable); Can you tell me what's wrong? hitr-drawable is not an osg::Drawable* like I thought, but a ref_ptrosg::Drawable. Just add .get() to the end, like this, to get the pointer. osg::ShapeDrawable* shapedrawable = dynamic_castosg::ShapeDrawable*(hitr-drawable.get()); Sorry for not mentioning the code was not tested. It was just an example... J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PositionalStateContainer
Hi, I'm working my way through the osgShadow-shadowmap source code in an attempt to understand how it works. One thing that confuses me is the osgUtil::PositionalStateContainer. What exactly is it used for? There doesn't seem to be any documentation for it. Thanks, Kim.* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PositionalStateContainer
On Dec 18, 2007 4:43 PM, Kim C Bale [EMAIL PROTECTED] wrote: Hi, I'm working my way through the osgShadow-shadowmap source code in an attempt to understand how it works. One thing that confuses me is the osgUtil::PositionalStateContainer. What exactly is it used for? There doesn't seem to be any documentation for it. Its for wrapping up management of positional state, i.e. lights, eye linear texgen, clipplanes, these all require a specific modelview matrix to position them correctly in space so can't be handled like normal state. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
Hi David -- Thanks for looking at this. I'm not sure this is a font file problem. In a previous post, I stated that the font is big with current SVN, current osgText, and current freetype. If I simply switch osgText back to the 2.2 version but leave everything else the same, the font appears normal size. This indicates the problem is with osgText, not the font. Are you actually able to reproduce the problem on Windows? As far as I know, I'm the only one seeing the issue. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Callu Sent: Tuesday, December 18, 2007 8:38 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Big fonts in current SVN Hi All, After a long search in OSG SVN revision, I found this is a fonts file issue. I downdate my SVN and rebuild OSG for the revision 7648, just before integration of Text3D 7500, 7300, 7000, 6900, 6500, ~ here begin dependancy with external OpenThreads 6400, ~ here begin dependancy with external Producer 6200, 6000 problem is always present I downdate my freetype version to 2.2 2.1.10 2.1.9 2.0.9 problem is always present g finally .. I try to my own arial.ttf file provide by the package mstcorefonts-2.0.1. This package is created with a script provided by mstcorefont project. This script download font on Microsoft site and make a rpm with them. To conclude, this is a font file problem. I submit the file on osg-submissions now. Cheers David 2007/12/17, Robert Osfield [EMAIL PROTECTED]: Hi Paul, On Dec 16, 2007 7:53 PM, Paul Martz [EMAIL PROTECTED] wrote: Thanks, Robert -- Unfortunately, this change had no effect. Maybe another avenue of attack might be to add DEBUG_INFO messages to osgText to display components that contribute to the final size of SCREEN-aligned glyphs? Then we could compare my DEBUG_INFO output against yours to see if that sheds any light? Today is going to be a very busy day for me so I won't be able to go chase this up right now. A close review of the changes that David made might reveal some possibilities. Adding more debugging as you suggest might also provide more time. Something for later in the week, unless others can jump in and help. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3rd Party from osgToy SVN
Hi, sorry, but my vs71 development is frozen, I dont have that compiler anymore. you're free to fork a 3rdParty repository starting with my vs71 build scripts. cheers -- mew On Tue, December 18, 2007 05:07, Adrian Egli wrote: https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty Mike, can you please update the VS2003 (3rdParty_win32binaries_vs71) as you did for VS 2005, thanks adrian -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Newbie for OSG 2.2; can not find the dsw for OSG2.2 in the source for windows...
Hi, from a pragmatic user-interface perspective, if there are docs/faqs describing the new cmake build process, then they're failing to be found in a way people expect. (This is not a user-problem of finding the docs; it's a doc-problem of not being where they're expected to be found.) Perhaps there could be a file in the source tree entitled WHERE_ARE_VS_PROJECT_FILES.txt containing the jumpstart clues? -- mew On Mon, December 17, 2007 14:26, Paul Martz wrote: would someone please inform me as to where I may find the OSG2.2 dsw project file for MS VS 2005 (C++ ver 8.x)? I can not find it in the binaries or the source .zips / .exes for Windows. You need to generate the VS project files using CMake. Try searching for Cmake at openscenegraph.org for more info. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] location of VS runtime libs (WAS: Newbie for OSG 2.2; can not find the dsw for OSG2.2 in the source for windows...)
On Mon, December 17, 2007 14:26, Paul Martz wrote: Sounds like osgDB is having problem finding the plugins. Others have reported similar problems with the Windows binaries. Maybe if Mike Weiblen is reading this, he can post a status update? I don't recall that anyone has arrived at a bullet-proof solution for this problem. Hi, Here's my plan for addressing this problem in the next build of the win32 installer: Background: The current installed filesystem was based on my over-conservative reading of MS license for their redistributable libraries (see C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\redist.txt), specifically quote For your convenience, we have provided the following folders for use when redistributing VC++ runtime files. Subject to the license terms for the software, you may redistribute the folder (unmodified) in the application local folder as a sub-folder with no change to the folder name. You may also redistribute all the files (*.dll and *.manifest) within a folder, listed below the folder for your convenience, as an entire set. /quote I followed the redistribute the folder (unmodified) sentence for the current installer. However, the sentence after does permit the runtime file files themselves to be merged into our bin directory, simplifying the filesystem just like the good old days. So the current complexity is my doing, and I guess I owe MS an appology (tho their text is a bit convoluted) So my plan for the next win32 installer is 1) put the MS redist libs directly into bin, manifests and all. 2) preserve but cull OSG_PATH to the necessary values. Any comments on the bulletproof-ness of this solution? cheers -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] changing colors of a geode
Thank you very much, that should solve my problem. This way I need to duplicate just osg::Geometry objects, but they still share VertexArrays, NormalsArrays, etc. via ref_ptr. So I'm also sure that they are destroyed only when the last geometry is destroyed. Thank you Gianluca Natale _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Tuesday, December 18, 2007 3:34 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] changing colors of a geode The best way to do this in OSG is to create two Geometry objects. Make them both share the same VertexArrays, NormalArray, TexCoordArray (if you're texture mapping), and PrimitiveSets. Then give each of them different color arrays and specify a color binding of BIND_OVERALL. Primary color, normal, texcoord, edge flag, etc., are not StateAttributes in OSG. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gianluca Natale Sent: Tuesday, December 18, 2007 7:20 AM To: Osg Users Subject: [osg-users] changing colors of a geode Hi all, I'm new to OSG. I cannot find a way to change the primary color of OpenGL in order to draw the same object twice in two different places with two different colors. I mean that in OpenGL I can do that in this way: glColor3fv(color1); // set model view matrix // draw object A glColor3fv(color2); //set model view matrix //draw object A Instead in OSG I should create two geodes with the same geometry, but different color, in order to do that. I tried to search a way to change the color in the osg::MatrixTransform, without finding it. Actually I don't want to duplicate the geometry data just to change a color! Furthermore, changing the primary color in an osg::Node would be really useful to quickly change the behavior of lit objects. I mean that in OpenGL I can set material properties by: glColorMaterial(...); and then change the behaviour just changing the primary color, before drawing the objects. I hope someone can help me. Thanks in advance, Gianluca Natale. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and Chromium
VrJuggler (www.vrjuggler.org) is also an option. We are using it on a 48 node, dual graphics card cluster with 24 projectors with osg 2.2. http://www.vrac.iastate.edu/c6.php biv On Dec 18, 2007 9:16 AM, Adrian Egli [EMAIL PROTECTED] wrote: Or you can have a look at http://www.equalizergraphics.com/ 2007/12/18, Ryven [EMAIL PROTECTED] : Hi there, we have successfully built a Cave (4 renderind planes. 12 projectors. 6 graphical nodes x 2 nvidia 8800 ) environment using OSG 2.1.1 for rendering and mpi for synchronization and data distribution. it is feasible. osg is well suited for some aspects. for example swap buffers synch for 2 displays in the same machine. But to build a rendering cluster you need multi-machine synchronization .. a frame lock so every machine swaps buffers at the same time. for this we used mpi's barrier and a extension of the osgViewer. but i think one can implement a simpler barrier using sockets. Another thing... glFinish is pretty important... on a rendering cluster. Rui On Dec 12, 2007 5:45 PM, syed tayyab [EMAIL PROTECTED] wrote: Hi folks I am a student and want to use OSG for my project , as part of my project i have to do parallel rendering over the grid or Cluster. Does any one now the feasibility of this scenario. or any other combination. Looking forward to hear from you. Regards Syed Tayyab Messenger on the move. Text MSN to 63463 now! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Freetype plugin not building on Windows VS8?
Hi Robert -- I updated to current CVS a couple hours ago. I just tried to reproduce the font problem with David's new font file, and much to my surprise found that I did not have a freetype plugin. For some reason, current SVN CMake is unable to find my freetype installation and therefore is not adding the freetype plugin to my VS solution/project files. I'm using Mike's 3rd party binaries and have 3rdparty as a sibling to OpenSceneGraph. This has worked with current SVN up until now. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Newbie for OSG 2.2; can not find the dsw for OSG2.2 in the source for windows...
On Dec 18, 2007 5:15 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Hi, from a pragmatic user-interface perspective, if there are docs/faqs describing the new cmake build process, then they're failing to be found in a way people expect. (This is not a user-problem of finding the docs; it's a doc-problem of not being where they're expected to be found.) Perhaps there could be a file in the source tree entitled WHERE_ARE_VS_PROJECT_FILES.txt containing the jumpstart clues? Well there is a README.txt in the root directory that mentions very clearly about CMake... and the Getting Started guide has CMake as its second entry... If we did write a WHERE_ARE_VS_PROJECT_FILES.txt then even this wouldn't be read by everyone, and where do you stop with trying to guess what questions users might ask but haven't come across the answer elsewhere. An occasional question on osg-users might suggest a lack of clear notification, but it also can suggest that the list is just a friendlier and easier place to ask questions than going hunting for an answer in the source code or online docs. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Freetype plugin not building on Windows VS8?
On Dec 18, 2007 5:52 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- I updated to current CVS a couple hours ago. I just tried to reproduce the font problem with David's new font file, and much to my surprise found that I did not have a freetype plugin. For some reason, current SVN CMake is unable to find my freetype installation and therefore is not adding the freetype plugin to my VS solution/project files. I'm using Mike's 3rd party binaries and have 3rdparty as a sibling to OpenSceneGraph. This has worked with current SVN up until now. There hasn't been any recent changes to the CMakeModules/FindFreeType.cmake. Perhaps the new freetype version is not being picked up so the FindFreeType.cmake needs to be updated to find it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: RandR support would be a reasonable way forward. SGI and other older workstation class machines are not so prone to users wishing to change resolution - Once I had 1280x1024 on an SGI Indigo Elan back in 92 this didn't change till my final contact with SGI's with the Oynx IR2... If if users do wish support on these platforms they can step forward and implement it. I guess RandR it is then, because some people voiced the support for changing the resolution on the fly. RandR is the only reasonable way how to do this on Unix at the moment. The older X extensions change resolution, but do not resize the root window, leaving you with a panning virtual desktop. BTW, when speaking about these features - is the setting of the window title working on Unix again? It used to work before 2.0, but then it was not implemented once the renderer was redone. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHaCPtn11XseNj94gRAovCAKCzhzfd6TAm+/b5lJehm/CEgz1AiACePfph xkvSoUdrhOp8Hz/TDfQtkZs= =9Yzx -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Freetype plugin not building on Windows VS8?
Hi Robert -- I updated to current CVS a couple hours ago. I just tried (I meant SVN of course.) to reproduce the font problem with David's new font file, and much to my surprise found that I did not have a freetype plugin. For some reason, current SVN CMake is unable to find my freetype installation and therefore is not adding the freetype plugin to my VS solution/project files. I'm using Mike's 3rd party binaries and have 3rdparty as a sibling to OpenSceneGraph. This has worked with current SVN up until now. There hasn't been any recent changes to the CMakeModules/FindFreeType.cmake. Does CMake use FindFreeType.cmake on Windows platforms? If so, then I don't know how this ever worked, as FindFreeType.cmake does not search in the sibling 3rdParty directory. Perhaps the new freetype version is not being picked up so the FindFreeType.cmake needs to be updated to find it. CMake was finding the new freetype version and adding the freetype plugin subdirectory up until very recently. Were there any other changes to CMake that could've caused this issue? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Asynchronous file loading via DatabasePager questions
Thanks guys,
ProxyNode is what I was looking for.
-Colin
Tim Moore wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Colin Branch wrote:
Hi all,
What I'm trying to do:
Asynchronous model loading using OSG 2.2
How I'm currently doing it:
I'm trying to use the Database Pager's requestNodeFile.
I just did this for the FlightGear project and it works well there.
I created a new node class that I can add (as well as place temporary
objects) that I can add and will stay in the scene.
class DtDelayedModelNode : public osg::Group
{
...
DtDelayedModelNode(const std::string filename, osgDB::DatabasePager*
pager) : osg::Group()
{
osg::FrameStamp fs;
fs.setFrameNumber(INT_MAX);
pager-requestNodeFile(filename,this,1.0,fs);
}
...
};
For this application you probably do want to check out ProxyNode as Bryan Thrall
suggested. If I had known about ProxyNode I might have used it instead of
calling
requestNodeFile directly.
What you've done here won't reliably work. You need to call requestNodeFile
every frame
until your request is satisfied. You will only find this out by looking closely
at the
implementation of ProxyNode and PagedLOD or by googling in the mailing list :)
Problems:
#1 Very limited documentation of the Pager class and no example on how
to use it. I've searched the osgusers archive but haven't found
anything too helpful, the 1.x examples don't seem relevant anymore.
See above about ProxyNode and PagedLOD.
#2 Occasional texture corruption. This is difficult to reproduce
however it appears that sometimes the width of the texture is 1px
creating a streaking effect.
#3 Certain actions cause the main app to lock, for example bringing up
the Stats HUD.
The other thing to keep in mind is that readNodeFile and friends aren't
necessarily
thread safe, but you don't have access to the lock that the pager uses to
serialize
access to those functions. Either you stop doing any file loading calls from
your main
thread once the pager has started, or you need to do the locking yourself by
installing
read callback functions that do the locking. The bugs you're seeing sound like
random
corruption of this kind.
Questions:
Is the Database Pager the proper way to be doing this?
It works for the FlightGear flight simulator project. I created a very small
subclass
of DatabasePager in order to have access to the _childrenToDeleteList of the
pager.
What if any calls should I make to the pager around frame() (ie it
doesn't appear that startFrame endFrame are needed, any other calls)?
None if you're using osgViewer. Otherwise look closely at the osgViewer::Viewer
source
code.
The value of the frame stamp appears to control deletion of requests. Ie
if I pass in the current frame stamp, the model is actually deleted in
compileGLObjects. Unless I set it to some value in the future (currently
using INT_MAX) I can't guarantee it will load. Could someone explain the
purpose of the framestamp and the proper usage?
See above. Normally you check every frame if a request has been satisfied; if
not, you
make it again with the current frame stamp. The OSG clients of DatabasePager,
ProxyNode
and PagedLOD, make these requests from the cull traversal, so this usage gives
a way
to cancel a request if the object drops out of the field of view.
Is there anyway to get status feedback while a file loads?
You can tell if a load is completed by checking if an object has been added to
the group
you passed to requestNodeFile. Otherwise no, though you could arrange for the
readNodeFile
callback you're going to write :) to return an empty error object of some kind.
Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHY5HHeDhWHdXrDRURAqMHAJ9EwsSEmq/km+Kmm66vQR7QHypqxgCfXtcb
AYMB1dGywN0upP0wEE9JErc=
=mNg5
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Freetype plugin not building on Windows VS8?
Hello Paul, Does CMake use FindFreeType.cmake on Windows platforms? If so, then I don't know how this ever worked, as FindFreeType.cmake does not search in the sibling 3rdParty directory. I think on Windows, it checks for the 3rdParty sibling directory and if found, just sets the paths for all the standard 3rd party libs - png, tiff, jpg, zlib, freetype - automatically. I don't think it even uses FindFreeType.cmake on Windows. I'm not sure though. CMake was finding the new freetype version and adding the freetype plugin subdirectory up until very recently. Were there any other changes to CMake that could've caused this issue? One thought - did you delete your CMakeCache.txt and re-do the CMake config after updating to Mike's new 3rdParty binaries? If not, there might be some stale reference to the old lib name (freetype219.lib instead of freetype235.lib) somewhere that might cause this problem. Maybe try checking the Show Advanced Values checkbox in CMakeSetup and seeing if there are any old values there... J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Freetype plugin not building on Windows VS8?
On Dec 18, 2007 7:48 PM, Paul Martz [EMAIL PROTECTED] wrote: Does CMake use FindFreeType.cmake on Windows platforms? If so, then I don't know how this ever worked, as FindFreeType.cmake does not search in the sibling 3rdParty directory. Perhaps the new freetype version is not being picked up so the FindFreeType.cmake needs to be updated to find it. CMake was finding the new freetype version and adding the freetype plugin subdirectory up until very recently. Were there any other changes to CMake that could've caused this issue? I don't know of any, there hasn't been any major changes to CMake since 2.2. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking towards 2.4, and what might go into it.
On Dec 18, 2007 7:47 PM, Jan Ciger [EMAIL PROTECTED] wrote: I guess RandR it is then, because some people voiced the support for changing the resolution on the fly. RandR is the only reasonable way how to do this on Unix at the moment. The older X extensions change resolution, but do not resize the root window, leaving you with a panning virtual desktop. Any volunteers, pretty please ;-) BTW, when speaking about these features - is the setting of the window title working on Unix again? It used to work before 2.0, but then it was not implemented once the renderer was redone. Yep its working in 2.2, osgViewer is more rounded and complete in 2.2 than 2.0, and in SVN its a little bit further on still. Note quite viewer/windowing nirvana yet, but the closest the OSG has come in its history. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Freetype plugin not building on Windows VS8?
Hello Paul, Hm. It's possible this hasn't been working all along, and I simply didn't realize it because the OLD (OSG v2.2) freetype plugin was being found and used. This would be because the plugin directory version number didn't change until the 2.3 release: plugins now go in a different directory, so there's no way to accidentally pick up an out-of-date plugin. Possible, indeed... BTW I resolved the issue by hardcoding the freetype include and lib info into the CMake GUI dialog. Yeah, I did that too since on Windows, it's hard to autodetect some optional dependencies (Collada, OpenVRML, QuickTime, etc.) so I always hate having to re-do the CMake config from scratch. Good to know it works now! J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
- Original Message From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Friday, December 14, 2007 3:05:38 PM Subject: Re: [osg-users] ANN: Reference Manual for v2.2 now available On Dec 14, 2007 7:59 PM, Zachary Hilbun wrote: To me an API is only as good as it's documentation. I'd suggest that the OSG is proof that point of view is a perhaps just a little flawed. Good documentation but a poor API and implementation don't make for successful end user applications. However, with a good API and implementation you do have a least have chance of making something useful. When I say an API is only as good as it's documentation what I mean is that if I don't know how to use something it has no value to me. I've bought/obtained/read the documentation/examples on OSG but found it to be rather incomplete. Because of the lack of documentation I could wind up blowing a few hundred to a few thousand dollars extra of my time trying to use OSG. I could instead spend that money buying a package that was already documented. If a person is a student or hobbiest then they might not value their time that highly. For me it's a big issue. I'm not suggesting not having good documentation is not a great thing to have, obviously great documentation and great API and implementation is all what a perfect project would be composed of. From my experience with the OSG project, its the software that solves the problems at the end of the day, and the majority of contributors to the OSG and clients who pay for parts of the OSG to be developed have a problem to solve so they write the code or fund the work to do it. One can say write the documentation first then the software, it might work for you, but so far for the hundreds of contributors to the OSG this hasn't been the case, the gifts that are given tend to be source code. Thoughts? Robert. If it were me paying for parts of the OSG to be developed I would want to pay extra to have it documented properly. My opinion would be that it is cheaper to pay the writer to document it properly than to pay my employes to try to learn it without that documentation. I would try to impress upon the people doing the funding that their overall costs might be lower if they paid for documentation. === Zachary Hilbun Software Contractor Dallas, Tx 214-350-4207 Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
On Fri, 2007-12-14 at 20:23 +, Robert Osfield wrote: Hi Jeremy, The alignment problem is a known problem that David (the author of the recent changes to osgText) knows about and will be looking into. Should this be fixed in 2.3? If so, I'm still seeing it in SVN. Just wondering if it's me, or still an unresolved issue... The texture based fonts themselves haven't actually changed apart from the internals being reworked in terms of the new TexBase class, the actual rendering process should be the same. Robert. On Dec 14, 2007 5:53 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I would just like to jump in here and say I'm also having font problems w/ SVN as of either yesterday or the day before. My problems aren't like the ones Paul is seeing, but they're definitely new differences that weren't there Tuesday... Attached is a picture of the osghudlabel example from osgHUD. In the past, the text rendered has been nice and reasonably compact, but now there is almost an entire row of blank space between real row of text. This is the case for both my own fonts and the Times font provided w/ OSG. HOWEVER, this could just be my imagination, but was the font clarity improved with the recent changes to osgText? Even the spacing is wonky, I can swear they actually look a little crisper... not subpixel-aligned (as that would take a minimum of 3 passes so I hear), but still good. :) On Thu, 2007-12-13 at 13:11 -0700, Paul Martz wrote: Current SVN head seems to have extra-large screen oriented fonts. See the attached screen shots. This is on Windows VS8; don't know about other platforms? I get the same for screen oriented fonts in the osgtext example. While my failing eyesight certainly appreciates the increased font size, I can't help but think this is a bug. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Crash on exit, Mac Os X
Hi, Before stating the issue we have, please let us thank you very much for OSG 2.2. Quality is continuously improving in OSG. We have moved our app to this version, 2.2.0. We are now using osgViewer::Viewer wrapped into a QT 4 Widget as in osgviewerQT. We currently have a crash on application exit under Mac OS X. Everything goes OK until the osgViewer:Viewer is destroyed. System stack trace is pasted below. Are there any other report of such thing ? Could it be that destructor is not called at the right time during the update cycle ? Thanks in advance for your answers, Antoine --- Date/Time: 2007-12-10 23:43:26.285 +0100 OS Version: 10.4.11 (Build 8S2167) Report Version: 4 Command: LePetitPoucet Path: /Users/bruno/tmp/pti_bin/LePetitPoucet/LePetitPoucet.app/Contents/MacOS/LePetitPoucet Parent: WindowServer [60] Version: ??? (???) PID:26946 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x0e2570a8 Thread 0 Crashed: 0 GLEngine0x0f3c9db1 glDeleteTextures_Exec + 11 1 libGL.dylib 0x92b2698e glDeleteTextures + 90 2 libosg.2.2.0.dylib 0x00460019 TextureObjectManager::flushAllTextureObjects(unsigned) + 83 3 libosg.2.2.0.dylib 0x00460079 osg::Texture::flushAllDeletedTextureObjects(unsigned) + 37 4 libosg.2.2.0.dylib 0x003fab7e osg::GraphicsContext::close(bool) + 1002 5 libosgViewer.2.2.0.dylib0x00233268 osgViewer::Viewer::~Viewer [not-in-charge]() + 306 6 LePetitPoucet 0x000276d9 ptiApp::QOsgWidget::~QOsgWidget [in-charge deleting]() + 145 7 LePetitPoucet 0xd2e6 ptiApp::PtiMainWindow::~PtiMainWindow [in-charge deleting]() + 68 8 LePetitPoucet 0x00013526 ptiApp::Application::cleanUpAndExit() + 36 9 LePetitPoucet 0x00018002 ptiApp::Application::qt_metacall(QMetaObject::Call, int, void**) + 328 10 libQtCore.4.dylib 0x0213aa5e QMetaObject::activate(QObject*, int, int, void**) + 1228 11 libQtCore.4.dylib 0x0214e5e1 QCoreApplication::aboutToQuit() + 49 12 libQtCore.4.dylib 0x0212f3ab QCoreApplication::exec() + 217 13 LePetitPoucet 0x0001708a main + 502 14 LePetitPoucet 0x83a6 _start + 216 15 LePetitPoucet 0x82cd start + 41 Thread 1: 0 libSystem.B.dylib 0x90026d5c kevent + 12 1 ...ple.CoreServices.CarbonCore 0x90cb8c68 PrivateMPEntryPoint + 51 2 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 2: 0 libSystem.B.dylib 0x900248c7 semaphore_wait_signal_trap + 7 1 ...ple.CoreServices.CarbonCore 0x90cb8e0d MPWaitOnQueue + 198 2 com.apple.DesktopServices 0x9271e953 TNodeSyncTask::SyncTaskProc(void*) + 143 3 ...ple.CoreServices.CarbonCore 0x90cb8c68 PrivateMPEntryPoint + 51 4 libSystem.B.dylib 0x90024227 _pthread_body + 84 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x0e252020 ebx: 0x92b26942 ecx: 0x edx: 0x0288fc00 edi: 0xa2b2400c esi: 0xb3b0 ebp: 0xb3a8 esp: 0xb350 ss: 0x001f efl: 0x00010286 eip: 0x0f3c9db1 cs: 0x0017 ds: 0x001f es: 0x001f fs: 0x gs: 0x0037 Binary Images Description: ... - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Newbie for OSG 2.2; can not find the dsw for OSG2.2 in the source for windows...
On Dec 18, 2007 5:15 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Perhaps there could be a file in the source tree entitled WHERE_ARE_VS_PROJECT_FILES.txt containing the jumpstart clues? Well there is a README.txt in the root directory that mentions very clearly about CMake... and the Getting Started guide has CMake as its second entry... Yes, every developer should _always_ go thru the README, no excuses. Tho realistically the audience and content of a README.txt can be quite wide. Cant tell you how many source trees I've looked at where the README.txt is full of worthless junk beginning AppWizard has created this application for you. Gee thanks :-P If we did write a WHERE_ARE_VS_PROJECT_FILES.txt then even this wouldn't be read by everyone, and where do you stop with trying to guess what questions users might ask but haven't come across the answer elsewhere. Understood. My thought was 1) this has been asked before, and 2) the person asking has already browsed the filesystem looking for filenames of the non-existent project files, so why not have a filename that directly addresses what they seek? 'twas just a thought. -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Freetype plugin not building on Windows VS8?
BTW I resolved the issue by hardcoding the freetype include and lib info into the CMake GUI dialog. Yeah, I did that too since on Windows, it's hard to autodetect some optional dependencies (Collada, OpenVRML, QuickTime, etc.) so I always hate having to re-do the CMake config from scratch. FYI, I _did_ delete my CMake cache as you suggested, but CMake was still unable to find the latest Windows freetype lib/header in the 3rdParty sibling directory. I _had_ to enter the paths and filename by hand. I can understand it not finding the library, as the filename has changed (perhaps a CMake wizard can help with this problem?). However, CMake should have found the freetype include directory. But it did not. So that's still a mystery. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GraphicsContext cannot open display.
I'm running OSG 2.2 ssh'd into a remote linux system. When I run a program using viewer it opens windows fine. ie osgViewer(); viewer-realize(); works just fine. When I use a graphics context I get the message: 'Error: Unable to open display :0.0' and osg::GraphicsContext::createGraphicsContext(traits.get()); returns NULL. I have the DISPLAY variable set and I'm using X11 forwarding actively for other tasks. Why does this work when I use viewer to build a window and not work when I try to manually create a graphicsContext??? Thanks, Steven Powers ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Freetype plugin not building on Windows VS8?
Hello Paul,
FYI, I _did_ delete my CMake cache as you suggested, but CMake was still
unable to find the latest Windows freetype lib/header in the 3rdParty
sibling directory. I _had_ to enter the paths and filename by hand.
Sorry, I was just checking. I did it that way too, I just didn't try
to do it automatically before doing it manually so I didn't know if
that worked or not.
I can understand it not finding the library, as the filename has changed
(perhaps a CMake wizard can help with this problem?). However, CMake should
have found the freetype include directory. But it did not. So that's still a
mystery.
It might not be... From CMakeModules/Find3rdPartyDependencies.cmake :
FIND_DEPENDENCY(FREETYPE ft2build.h
freetype;freetype219;freetype234;freetype234MT
${OSG_3RDPARTY_BIN} _D)
IF(FREETYPE_FOUND)
#forcing subsequent FindFreeType stuff to not search for other
#variables kind of a hack
SET(FREETYPE_INCLUDE_DIR_ft2build ${FREETYPE_INCLUDE_DIR}
CACHE PATH )
SET(FREETYPE_INCLUDE_DIR_freetype2 ${FREETYPE_INCLUDE_DIR}
CACHE PATH )
MARK_AS_ADVANCED(FREETYPE_INCLUDE_DIR_ft2build
FREETYPE_INCLUDE_DIR_freetype2)
ENDIF(FREETYPE_FOUND)
I'm not a CMake wizard by any stretch of the imagination, but what I
understand from the above is:
If I find the ft2build.h include file AND freetype library in the 3rd party
directory
Then:
Set the include dir to the 3rd party include directory
Stop looking for freetype.
Endif
The problem is that the real freetype lib we have (freetype235) is not
listed above, so it is not found, and therefore it cannot find the
freetype include dir (regardless of whether it's in 3rdParty or
elsewhere, since there is no such thing as a standard /usr/include or
/usr/local/include on Windows).
I imagine if you add freetype235 to the list of libs it looks for, it
will work... But it might still be nice if a _real_ CMake wizard could
tell us if there's a way to put a wildcard there, so we don't need to
update it next time... :-)
J-S
--
__
Jean-Sebastien Guay [EMAIL PROTECTED]
http://whitestar02.webhop.org/
This message was sent using IMP, the Internet Messaging Program.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
Hi, I believe Paul @ Skew Matrix and Bob @ Blue Newt would be delighted to be of service! Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Zachary Hilbun Sent: Tuesday, December 18, 2007 2:41 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ANN: Reference Manual for v2.2 now available ... If it were me paying for parts of the OSG to be developed I would want to pay extra to have it documented properly. My opinion would be that it is cheaper to pay the writer to document it properly than to pay my employes to try to learn it without that documentation. I would try to impress upon the people doing the funding that their overall costs might be lower if they paid for documentation. === Zachary Hilbun Software Contractor Dallas, Tx 214-350-4207 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Traversing
Hey, don`t you ever worry about it! I'm lucky enough you do answer my questions. Thanks again, Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
Warning... I'm in rare form tonight ;-) I sort of agree with both views on this. OSG is a great API regardless of whether anyone can use it? That's a bit like saying medicine that will save your life is wonderful, however it is in a locked box that you cannot open... It's still great medicine though right? Sounds like something from Hitchhikers guide to the Galaxy! There is nothing that has intrinsic value (except perhaps human beings, but I dare not tread on the philosophical here) outside of the value placed on it by those who need or desire it. This is basic economics. Just because you value something does not mean it IS valuable, to the universe or anyone else, but it IS valuable to you. The previous assertion that an API is only as good to this one gentleman as it's documentation is perfectly valid. He should certainly be qualified to determine what is of value to him. Studying source code and pouring over example programs is simply the most inefficient means possible of learning a large and complex API. I really don't see how anyone can mount a reasonable defense against that fact, and a good many people find this frustrating to the point of abandoning or ignoring the technology. However... Initial efficiency is not the only criteria, both from a business point of view and a pedagogical (learning) point of view. A somewhat weak but still valid argument could be made that learning the API this way lends to a deeper and more powerful understanding of it. Sometimes people will skim good documentation, find only what they need to know and move on without ever appreciating the elegance of design, or the depth of power that an API provides. Many open source advocates and technologist are very deeply offended by this... my opinion is that those sorts of people aren't really bad, they just need a good beer and to get laid once and a while. (By-the-way, if anyone on this list who has ever helped me is in the Orlando area, I would gladly buy you a beer... but your own your own for the latter.) The fact that the documentation is poor or non-existent is the nature of open source. These technologies are built by volunteers, with no overbearing boss. Only the most uptight when given a deadline or time constraint will voluntarily write good documentation first. Good documentation and tutorials take significantly more time to create than source code. Simple economics and entropy usually intervene to circumvent the best of intentions. I used to say OpenSource is only free to those who's time is worthless. Mr. Hilburn would probably agree, but I have come to realize that this was rather ignorant on my own part as well. Nothing in life is ever free, especially in the fields most on this list practice in. You will always pay either with time, or money; and typically you will choose to pay with whichever you have the most of. If you don't have either, your just broke... and in good company, so there is no point in complaining about it. Although I am currently learning OSG in the worst possible manner (as concerning time), it is still vastly faster than if I had to build my own scene graph technology from scratch. It's rather like being stuck in traffic... I could walk faster... yes it seems that way for the moment, but you will certainly not actually get home faster by leaving your car behind. I've built quite enough custom OpenGL engines over the last ten years, and looking at OSG I realize there is a lot to be gained by a couple months sacrifice on my part. This makes good business sense when you look at the larger picture instead of just focusing on a single project that is in emergency mode because no time was alloted for RD before coding was to begin... or someone quit and left you holding the bag. (I am not making veiled speculation about Mr. Hilburn's possible situation... but rather my own!). It is my observation (let me remind detractors that you cannot disagree with my observations... they are mine not yours, although admittedly they may not reflect the true nature of the universe ;-) that most developers try to master technologies far too fast. Usually with a deadline looming. There is a reason we send engineers to school before giving them jobs, they need a head start. In industry as well, it is best to allocate enough time to get familiar with a new technology before trying to build something with it. Alas, again economics and entropy often intervene, as I myself have experienced on may occasions as well. I have money (well, some money). I have not found a better technology than OSG that I can pay money instead of time for (although I am still keeping my eye's open ;-). In the mean-time I will spend some of that money on some OSG training as soon as it comes to town... Perhaps one day I'll provide a tutorial or two with the time I'll save on future projects VBG. Richard
[osg-users] Problem compiling OSG from SVN in Cygwin
Hello Robert,
It's your worst nightmare again. I tried compiling the svn version
again from trunk since you were asking folks to check various
platforms.
I downloaded fresh from svn and did the ccmake and then ran make and I
get this error:
[ 78%] Building CXX object
src/osgPlugins/ive/CMakeFiles/osgdb_ive.dir/Visibilit
yGroup.o
Linking CXX shared module
./../../lib/osgPlugins-2.2.0/cygwin_osgdb_ive.dll
[ 78%] Built target osgdb_ive
Scanning dependencies of target osgdb_cfg
[ 78%] Building CXX object
src/osgPlugins/cfg/CMakeFiles/osgdb_cfg.dir/CameraCon
fig.o
In file included from /usr/src/OpenSceneGraph/include/osg/Vec2f:17,
from /usr/src/OpenSceneGraph/include/osg/Vec2d:17,
from /usr/src/OpenSceneGraph/include/osg/Vec3d:17,
from /usr/src/OpenSceneGraph/include/osg/Matrixd:18,
from /usr/src/OpenSceneGraph/include/osg/Matrix:17,
from
/usr/src/OpenSceneGraph/src/osgPlugins/cfg/Camera.h:19,
from
/usr/src/OpenSceneGraph/src/osgPlugins/cfg/CameraConfig.h:
19,
from
/usr/src/OpenSceneGraph/src/osgPlugins/cfg/CameraConfig.cp
p:34:
/usr/src/OpenSceneGraph/include/osg/Math: In function `bool
osg::isNaN(float)':
/usr/src/OpenSceneGraph/include/osg/Math:206: error: `isnan' undeclared
(first u
se this function)
/usr/src/OpenSceneGraph/include/osg/Math:206: error: (Each undeclared
identifier
is reported only once for each function it appears in.)
/usr/src/OpenSceneGraph/include/osg/Math: In function `bool
osg::isNaN(double)':
/usr/src/OpenSceneGraph/include/osg/Math:207: error: `isnan' undeclared
(first u
se this function)
make[2]: ***
[src/osgPlugins/cfg/CMakeFiles/osgdb_cfg.dir/CameraConfig.o] Error
1
make[1]: *** [src/osgPlugins/cfg/CMakeFiles/osgdb_cfg.dir/all] Error 2
make: *** [all] Error 2
[EMAIL PROTECTED] /usr/develop/obj/osg
So then in include/osg/Math I change line 206 from this:
inline bool isNaN(float v) { return isnan(v); }
to
inline bool isNaN(float v) { return isnanf(v); }
and I change line 207 to return various forms of isnand, _isnan,
_isnand just to see what will happen and
then the build blows up much earlier on Animationpath in OpenThreads as
follows:
[EMAIL PROTECTED] /usr/develop/obj/osg
$ make
[ 0%] Built target OpenThreads
[ 1%] Building CXX object src/osg/CMakeFiles/osg.dir/AnimationPath.o
In file included from /usr/src/OpenSceneGraph/include/osg/Vec2f:17,
from /usr/src/OpenSceneGraph/include/osg/Vec2d:17,
from /usr/src/OpenSceneGraph/include/osg/Vec3d:17,
from /usr/src/OpenSceneGraph/include/osg/Matrixf:18,
from
/usr/src/OpenSceneGraph/include/osg/AnimationPath:21,
from
/usr/src/OpenSceneGraph/src/osg/AnimationPath.cpp:13:
/usr/src/OpenSceneGraph/include/osg/Math: In function `bool
osg::isNaN(double)':
/usr/src/OpenSceneGraph/include/osg/Math:207: error: `_isnand'
undeclared (first
use this function)
/usr/src/OpenSceneGraph/include/osg/Math:207: error: (Each undeclared
identifier
is reported only once for each function it appears in.)
make[2]: *** [src/osg/CMakeFiles/osg.dir/AnimationPath.o] Error 1
make[1]: *** [src/osg/CMakeFiles/osg.dir/all] Error 2
make: *** [all] Error 2
[EMAIL PROTECTED] /usr/develop/obj/osg
$
This error which would lead me to believe that during the early stages
of the compile - isnan is defined and then it disappears by the time I
get to osgdb_config.
Further on this is that I found if I change line 206 to
inline bool isNaN(float v) { return isnanf(v); }
and line 207 to
inline bool isNaN(double v) { return __isnand(v); }
then everything compile - any thought on this
bk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Big fonts in current SVN
Hi Jeremy I submit patch to Robert. So coming soon If all work fine. David David 2007/12/18, Jeremy Moles [EMAIL PROTECTED]: On Fri, 2007-12-14 at 20:23 +, Robert Osfield wrote: Hi Jeremy, The alignment problem is a known problem that David (the author of the recent changes to osgText) knows about and will be looking into. Should this be fixed in 2.3? If so, I'm still seeing it in SVN. Just wondering if it's me, or still an unresolved issue... The texture based fonts themselves haven't actually changed apart from the internals being reworked in terms of the new TexBase class, the actual rendering process should be the same. Robert. On Dec 14, 2007 5:53 PM, Jeremy Moles [EMAIL PROTECTED] wrote: I would just like to jump in here and say I'm also having font problems w/ SVN as of either yesterday or the day before. My problems aren't like the ones Paul is seeing, but they're definitely new differences that weren't there Tuesday... Attached is a picture of the osghudlabel example from osgHUD. In the past, the text rendered has been nice and reasonably compact, but now there is almost an entire row of blank space between real row of text. This is the case for both my own fonts and the Times font provided w/ OSG. HOWEVER, this could just be my imagination, but was the font clarity improved with the recent changes to osgText? Even the spacing is wonky, I can swear they actually look a little crisper... not subpixel-aligned (as that would take a minimum of 3 passes so I hear), but still good. :) On Thu, 2007-12-13 at 13:11 -0700, Paul Martz wrote: Current SVN head seems to have extra-large screen oriented fonts. See the attached screen shots. This is on Windows VS8; don't know about other platforms? I get the same for screen oriented fonts in the osgtext example. While my failing eyesight certainly appreciates the increased font size, I can't help but think this is a bug. :-) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Traversing
Hello Renan, Hey, don`t you ever worry about it! I'm lucky enough you do answer my questions. You're very welcome. :-) J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: Reference Manual for v2.2 now available
Apparently I ran on and on and tried to be too clever and should have just stayed quiet. I did not intend to further the debate, but perhaps capture the nature of open source and community driven projects for those who can't understand why OSG isn't as easy to pick up as say Qt. This nature is not suitable for all developers, but it is still quite useful to many (myself included). Sometimes I enjoy playing devils advocate a little too much ;-) I do not think that OSG is worthless without documentation (to me). I also greatly appreciate the efforts of everyone on this list (including you if I'm not mistaken) to help the newbies, and create the tutorials and sample code for OSG. I do think the level of documentation is sufficient for my needs, but could always be better (I really got quite the head start via Paul's great book). Mailing lists such as these can be more valuable than many books. In fact in a previous posting weeks ago, I stated that I found OSG to be quite refreshing in that it has more tutorials and documentation than most other open source projects I have encountered. I haven't changed my mind. But I am an experienced developer who understands (and was trying to convey in a long winded way) that mastery of a new technology is a significant investment. I was simply (oh, no I suppose there was nothing simple about it) saying, this other gentleman has a valid point... but shouldn't whine about it. I think he probably expected the reference guide to be something like the MSDN reference, or Qt's Assistant. You can't go to Amazon and find several books on OSG, etc. Many people really need this level of support to pick up a new API. no one in the not enough docs camp steps up to change that. I have written one or two sample programs and tutorials in my time... when I graduate from newbie, I promise to contribute something back myself. So can we just agree to disagree? I'm not sure what we disagree on. I see both sides of the argument is all. I haven't been following the thread, and probably should not have just jumped in at the end. I think we can both agree that I haven't gotten enough sleep lately and have probably OD'd on caffeine. I promise to shut up for a while ;-) Richard On Dec 18, 2007, at 8:43 PM, Jean-Sébastien Guay wrote: Hello Richard, Warning... I'm in rare form tonight ;-) Yeah... Well... I don't really see your point in continuing this debate. No one willingly says Hey, you know what? We don't need documentation. You want to pay for it? Why bother!. I think this subject is on the top-5 (maybe even top-2) list of beating a dead horse subjects on this mailing list. On the one hand, you're saying the OSG is worthless without documentation. We all agree with the principle, but the fact of the matter is that a large number of people find what little documentation exists is sufficient to get started, and once you're rolling, everything comes easily. So either your argument is too white or black, or OSG is a counter-example to your argument. I suspect a little of both. See the documentation and tutorials sections on the wiki for great documentation that is not only free, but was also contributed freely by members of the community. See Paul Martz's books for great documentation in the more traditional sense. See the examples in the source code for short, to-the-point code samples. Of course, there can never be enough (and even less too much) documentation. But the debate in itself does not help, since we all have our take on the subject and no one in the not enough docs camp steps up to change that. So can we just agree to disagree? J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
