Re: [osg-users] Migration of OpenThreads to subversion & future of OpenThreads project management.
Take a look at svn:externals feature. (http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html). Using svn:externals you can keep OpenThreads in a separate repo and still use it in OpenSceneGraph repo as if it is actually there. -- Orhun Birsoy ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Creating a minimap
Hello Peter, > As I´m quite a newbie in OpenSceneGraph, I´m not sure about the steps to > create the minimap (Camera Node etc.). > > Any help that outlines those steps would be very helpful. I don't have practical experience in what you describe, but my intuition would be to do this: 1) Create a render-to-texture camera which will be over the moving entity at the required distance to make a minimap view. 2) Texture a quad in your HUD with the resulting texture. 3) This is what will determine the performance hit of your minimap and also its look: use LODs on all your objects and terrain which will, at the minimap-camera's distance, look like what you want your minimap to look like (perhaps with switch nodes to only enable the minimap LODs when rendering to your minimap camera). Again, sorry if this isn't really concrete advice with code examples (I'm not even sure all this is practically feasible), but your e-mail made me think about it so I just thought I'd send my thoughts. Good luck, and be sure to tell us how you do it in the end. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgProducer Viewer window disappears
I solved the picking issue by switching to using an osg::Camera for my ortho view, rather than creating my own projection and modelview nodes. I'm not sure why it works now, but it does. Thanks, Julian. Julian Looser wrote: Hi Robert, Thanks for your suggestions. I've got the latest CVS version and converted my application to use osgViewer rather than osgProducer:::Viewer. As you said, it wasn't too painful. However, my picking code no longer works with the new viewer. :-( When I call: viewer->computeIntersections(x, y, intersections) picker->containsIntersections() inside View::computeIntersections returns false. Can you think of a difference between the old and new implementations that would cause this to fail? My code looks the same as that in the osgPick example (which works fine), so perhaps it is my geometry? It's just a 2D app using an ortho projection and selectable geodes. Any help greatly appreciated! Julian. Robert Osfield wrote: Hi Julian, On 2/14/07, Julian Looser <[EMAIL PROTECTED]> wrote: I would be interested in switching to osgViewer, although it would have to be something I can achieve very quickly. If I get the latest CVS version of OSG, is it typically a straightforward process? I'm competent with OSG.. just on a tight deadline and don't want to introduce any other problems. Between a rock and hard place, CVS might introduce problems, and it might solve them... Just visit the download page and following the links to the CVS instructions. You'll need to the CVS version of OpenThreads and OpenSceneGraph, but can probably get away with using the 1.1 Producer release. Producer is now just required of osgProducer and osgproducerviewer. Also, I'm using the osgProducer::Viewer's picking functions... is there an equivalent implementation in osgViewer? Perhaps you're looking for osgViewer::Viewer::computeIntersections(,):-) My guess is porting across will be quite straight forward for you. Use viewcvs to look at the changes between the examples before the move to osgViewer and after: http://openscenegraph.org/viewcvs/ For instance to see the difference in examples/osganimate/osganimate.cpp before and after: http://openscenegraph.org/viewcvs/examples/osganimate/osganimate.cpp?r1=1.9&r2=1.10 Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgProducer Viewer window disappears
Hi Robert, Thanks for your suggestions. I've got the latest CVS version and converted my application to use osgViewer rather than osgProducer:::Viewer. As you said, it wasn't too painful. However, my picking code no longer works with the new viewer. :-( When I call: viewer->computeIntersections(x, y, intersections) picker->containsIntersections() inside View::computeIntersections returns false. Can you think of a difference between the old and new implementations that would cause this to fail? My code looks the same as that in the osgPick example (which works fine), so perhaps it is my geometry? It's just a 2D app using an ortho projection and selectable geodes. Any help greatly appreciated! Julian. Robert Osfield wrote: Hi Julian, On 2/14/07, Julian Looser <[EMAIL PROTECTED]> wrote: I would be interested in switching to osgViewer, although it would have to be something I can achieve very quickly. If I get the latest CVS version of OSG, is it typically a straightforward process? I'm competent with OSG.. just on a tight deadline and don't want to introduce any other problems. Between a rock and hard place, CVS might introduce problems, and it might solve them... Just visit the download page and following the links to the CVS instructions. You'll need to the CVS version of OpenThreads and OpenSceneGraph, but can probably get away with using the 1.1 Producer release. Producer is now just required of osgProducer and osgproducerviewer. Also, I'm using the osgProducer::Viewer's picking functions... is there an equivalent implementation in osgViewer? Perhaps you're looking for osgViewer::Viewer::computeIntersections(,):-) My guess is porting across will be quite straight forward for you. Use viewcvs to look at the changes between the examples before the move to osgViewer and after: http://openscenegraph.org/viewcvs/ For instance to see the difference in examples/osganimate/osganimate.cpp before and after: http://openscenegraph.org/viewcvs/examples/osganimate/osganimate.cpp?r1=1.9&r2=1.10 Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Migration of OpenThreads to subversion & future of OpenThreads project management.
Its only good news to have fewer dependencies. The question is, how many is using OpenTHreads without OpenSceneGraph? I mean there are boost::threads also? (and a zillion other thread toolkits). I have a class that I wanted to add to OpenThreads. I got ok several months ago, but nothing has happened... So perhaps I can email you the stuff instead Robert so you can review them for inclusion into OpenThreads? I would like to lift that class outside of osgHaptics. Also, the osgDB::reentrentMutex is another class that should go into OpenThreads, right? Its really better suited for OpenThreads than osgDB. I really like to use that kind of Mutex to avoid locks in the api. Costs more but lets you think of the api instead of what methods that can call eachoter.. /Anders On 2/17/07, Joakim Simonsson <[EMAIL PROTECTED]> wrote: On Fri, 16 Feb 2007 21:25:14 +0100, Robert Osfield <[EMAIL PROTECTED]> wrote: > > Or should be just roll include/OpenThreads and src directories into > OpenSceneGraph/include/src and maintain it along with the rest of the > OSG? > > Thoughts? Aspirations? Just some quick thoughts. I think the svn repo structure choosen is a very good one. As revisions are shared for both osg and openthreads. If you want to use OpenThreads in a non-osg project, this is also possible with the current repo-structure. -- Joakim Simonsson ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ -- Anders Backman Email:[EMAIL PROTECTED] HPC2N/VRlab Phone:+46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Creating a minimap
Hello, I´m just trying to create a minimap of the scene depicted in a corner of the screen. Furthermore I don´t want to use osgProducer::Viewer but osgViewer::SimpleViewer (because of Qt). As I´m quite a newbie in OpenSceneGraph, I´m not sure about the steps to create the minimap (Camera Node etc.). Any help that outlines those steps would be very helpful. Thanks in advance, Peter ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Multi-threading issues on Windows - a little bit more information
Hi Robert, It makes a lot of sense. osglauncher is not playing by the rules for sure. Setting the data variance for its text objects to DYNAMIC (from UNSPECIFIED) solves the problem. Sorry if I missed that discussion, but shouldn't UNSPECIFIED behave like DYNAMIC with regards to threads blocking updates, since it means we don't really know if the content will change ? André -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: February-17-07 12:14 PM To: osg users Subject: Re: [osg-users] Multi-threading issues on Windows - a little bit more information Hi André, I'm still digest your email (threading is a complex issue), but I'll dive in provide some guidance on osgText - updating the texture field and rendering at the same time is not permitted and mutexing it while doable is really masking a higher level issue in the affected apps. What should be happening is that text fields that are updated during the frame should have their DataVariance set to DYNAMIC, this will tell the draw traversals to block the next frame till all the DYNAMIC text drawables+state are drawn. This DataVariance requirement applies to all Geometry and StateSet/StateAttributes setup/usage, so isn't a Text specific issue, a relates to the lightweight way that I've enabled parallel threading of update & cull with draw - only the static parts of the scene graphs leaves can be run in parallel, all dynamic parts must be dispatch in draw before the next frame commenses. If the Drawable and StateSet's don't declare that they are DYNAMIC then the frame block won't happen and update will run in parallel with draw and bug crashes will happen. Play by the rules at use DYNAMIC/STATIC correctly then things should run smoothly. The next question has to be which examples aren't yet playing by this rule. Robert. On 2/17/07, André Garneau <[EMAIL PROTECTED]> wrote: > Hi Robert, > > Here is an update on previous testing results I reported earlier this week. > Since then I concentrated mainly on characterizing crashes occurring in > multi-threading modes. > > * I have traced the stack for all crashes and they are all from the same > location (in some NVIDIA code). OpenGL errors are reported > (GL_INVALID_OPERATION). That error condition is triggered by the call to > glDrawBuffer() within RenderStage::drawInner. > > * If I remove the 6150 screen from the system, all tests but 2 will pass > (osgimpostor & osgprerendercubemap). The two tests that are still crashing > have the same stack trace as previously. Note that even though the other > tests pass, they still all generate the GL_INVALID_OPERATION error. > > * If I start osgdistortion from the command line, it will work. If I start > it from osglauncher, it will crash (as when the 6150 is present). > > At this point what I'm trying to determine is if we're hitting a bug in the > NVIDIA driver and if so, if there is something done that exacerbates the > condition. There seems to be a correlation between the OpenGL error and the > test (possibly) crashing after. Removing the 6150 from the system is only > hiding the condition in my opinion, since it can still happen (when launched > through osglauncher for instance). > > On another subject, while doing these tests I came across a multi-thread > issue with the Text class. In DrawThreadPerContext and > CullDrawPerCameraDrawThreadPerContext modes, allowing updates to text > instances while the draw threads are rendering causes race conditions since > there is one structure in Text that is used at draw time and can be cleared > at update time. The field in question is Text::_textureGlyphQuadMap. > > To replicate the issue, simply start osglauncher in a multi-screen setup and > move the mouse quickly across all pictures; in a matter of seconds you > should get an access violation. The two conflicting threads are one graphics > thread and the main thread doing its event traversal and handling the > intersection event with one picture (this will cause the setText method to > be invoked which will clear the _textureGlyphQuadMap while it is being > iterated upon by the draw threads). > > I have prepared a fix for this but it involves mutexing all set methods and > the draw method for the Text class (not something very pretty). I will > include it in a submission later today. > > Finally, I have also made the fix for the aspect ratio issue occurring when > one or more screens in the system have different aspect ratios. I will > include it in the same submission. > > One last note: It would be very interesting (and informative) to see if > other Windows users on this list also see the osgdistortion test crashing > when started from osglauncher (in dual-screen mode in multi-threaded modes) > or OpenGL errors being reported (through the following message: Warning: > detected OpenGL error 'invalid operation' after RenderBin::draw) for the > same test. > > André > > ==
Re: [osg-users] Multi-threading issues on Windows - a little bit more information
Hi André,
I'm still digest your email (threading is a complex issue), but I'll
dive in provide some guidance on osgText - updating the texture field
and rendering at the same time is not permitted and mutexing it while
doable is really masking a higher level issue in the affected apps.
What should be happening is that text fields that are updated during
the frame should have their DataVariance set to DYNAMIC, this will
tell the draw traversals to block the next frame till all the DYNAMIC
text drawables+state are drawn.
This DataVariance requirement applies to all Geometry and
StateSet/StateAttributes setup/usage, so isn't a Text specific issue,
a relates to the lightweight way that I've enabled parallel threading
of update & cull with draw - only the static parts of the scene graphs
leaves can be run in parallel, all dynamic parts must be dispatch in
draw before the next frame commenses. If the Drawable and StateSet's
don't declare that they are DYNAMIC then the frame block won't happen
and update will run in parallel with draw and bug crashes will happen.
Play by the rules at use DYNAMIC/STATIC correctly then things should
run smoothly.
The next question has to be which examples aren't yet playing by this rule.
Robert.
On 2/17/07, André Garneau <[EMAIL PROTECTED]> wrote:
Hi Robert,
Here is an update on previous testing results I reported earlier this week.
Since then I concentrated mainly on characterizing crashes occurring in
multi-threading modes.
* I have traced the stack for all crashes and they are all from the same
location (in some NVIDIA code). OpenGL errors are reported
(GL_INVALID_OPERATION). That error condition is triggered by the call to
glDrawBuffer() within RenderStage::drawInner.
* If I remove the 6150 screen from the system, all tests but 2 will pass
(osgimpostor & osgprerendercubemap). The two tests that are still crashing
have the same stack trace as previously. Note that even though the other
tests pass, they still all generate the GL_INVALID_OPERATION error.
* If I start osgdistortion from the command line, it will work. If I start
it from osglauncher, it will crash (as when the 6150 is present).
At this point what I'm trying to determine is if we're hitting a bug in the
NVIDIA driver and if so, if there is something done that exacerbates the
condition. There seems to be a correlation between the OpenGL error and the
test (possibly) crashing after. Removing the 6150 from the system is only
hiding the condition in my opinion, since it can still happen (when launched
through osglauncher for instance).
On another subject, while doing these tests I came across a multi-thread
issue with the Text class. In DrawThreadPerContext and
CullDrawPerCameraDrawThreadPerContext modes, allowing updates to text
instances while the draw threads are rendering causes race conditions since
there is one structure in Text that is used at draw time and can be cleared
at update time. The field in question is Text::_textureGlyphQuadMap.
To replicate the issue, simply start osglauncher in a multi-screen setup and
move the mouse quickly across all pictures; in a matter of seconds you
should get an access violation. The two conflicting threads are one graphics
thread and the main thread doing its event traversal and handling the
intersection event with one picture (this will cause the setText method to
be invoked which will clear the _textureGlyphQuadMap while it is being
iterated upon by the draw threads).
I have prepared a fix for this but it involves mutexing all set methods and
the draw method for the Text class (not something very pretty). I will
include it in a submission later today.
Finally, I have also made the fix for the aspect ratio issue occurring when
one or more screens in the system have different aspect ratios. I will
include it in the same submission.
One last note: It would be very interesting (and informative) to see if
other Windows users on this list also see the osgdistortion test crashing
when started from osglauncher (in dual-screen mode in multi-threaded modes)
or OpenGL errors being reported (through the following message: Warning:
detected OpenGL error 'invalid operation' after RenderBin::draw) for the
same test.
André
=
I did some testing yesterday evening on Windows and here are my results:
{ Platform: Athlon X2 4200+, 2GB RAM, Windows XP latest patches, NVIDIA
GF7900GT & low-end NVIDIA 6150, 3 screens }
Running runexamples.bat for each threading model
Single-Threaded
===
osgimpostor (extremely slow)
osgplanets (corrupted image on center & right screens - left screen OK) -
will double check my setup
all other examples perform well
CullDrawThreadPerContext
osgprecipitations (slow)
crashes for:
osgdistortion
osgdepthshadow
osgimpostor
osgprerender
osgpreren
[osg-users] Multi-threading issues on Windows - a little bit more information
Hi Robert,
Here is an update on previous testing results I reported earlier this week.
Since then I concentrated mainly on characterizing crashes occurring in
multi-threading modes.
* I have traced the stack for all crashes and they are all from the same
location (in some NVIDIA code). OpenGL errors are reported
(GL_INVALID_OPERATION). That error condition is triggered by the call to
glDrawBuffer() within RenderStage::drawInner.
* If I remove the 6150 screen from the system, all tests but 2 will pass
(osgimpostor & osgprerendercubemap). The two tests that are still crashing
have the same stack trace as previously. Note that even though the other
tests pass, they still all generate the GL_INVALID_OPERATION error.
* If I start osgdistortion from the command line, it will work. If I start
it from osglauncher, it will crash (as when the 6150 is present).
At this point what I'm trying to determine is if we're hitting a bug in the
NVIDIA driver and if so, if there is something done that exacerbates the
condition. There seems to be a correlation between the OpenGL error and the
test (possibly) crashing after. Removing the 6150 from the system is only
hiding the condition in my opinion, since it can still happen (when launched
through osglauncher for instance).
On another subject, while doing these tests I came across a multi-thread
issue with the Text class. In DrawThreadPerContext and
CullDrawPerCameraDrawThreadPerContext modes, allowing updates to text
instances while the draw threads are rendering causes race conditions since
there is one structure in Text that is used at draw time and can be cleared
at update time. The field in question is Text::_textureGlyphQuadMap.
To replicate the issue, simply start osglauncher in a multi-screen setup and
move the mouse quickly across all pictures; in a matter of seconds you
should get an access violation. The two conflicting threads are one graphics
thread and the main thread doing its event traversal and handling the
intersection event with one picture (this will cause the setText method to
be invoked which will clear the _textureGlyphQuadMap while it is being
iterated upon by the draw threads).
I have prepared a fix for this but it involves mutexing all set methods and
the draw method for the Text class (not something very pretty). I will
include it in a submission later today.
Finally, I have also made the fix for the aspect ratio issue occurring when
one or more screens in the system have different aspect ratios. I will
include it in the same submission.
One last note: It would be very interesting (and informative) to see if
other Windows users on this list also see the osgdistortion test crashing
when started from osglauncher (in dual-screen mode in multi-threaded modes)
or OpenGL errors being reported (through the following message: Warning:
detected OpenGL error 'invalid operation' after RenderBin::draw) for the
same test.
André
=
I did some testing yesterday evening on Windows and here are my results:
{ Platform: Athlon X2 4200+, 2GB RAM, Windows XP latest patches, NVIDIA
GF7900GT & low-end NVIDIA 6150, 3 screens }
Running runexamples.bat for each threading model
Single-Threaded
===
osgimpostor (extremely slow)
osgplanets (corrupted image on center & right screens - left screen OK) -
will double check my setup
all other examples perform well
CullDrawThreadPerContext
osgprecipitations (slow)
crashes for:
osgdistortion
osgdepthshadow
osgimpostor
osgprerender
osgprerendercubemap
osgshadowtexture
osgsimulation
DrawThreadPerContext
osgprecipitations (slow)
update processing seems to be out-of-sync
(very fast movements when mouse is used)
No smoke/fire effects visible for:
(probably due to issue above)
osgblendequation
osgmultitexture
crashes for:
osgdistortion
osgdepthshadow
osgimpostor
osgprerender
osgprerendercubemap
osgshadowtexture
osgsimulation
osgpick
osgspheresegment
CullThreadPerCameraDrawThreadPerContext
===
osgprecipitations (slow)
update processing normal but performance generally sluggish on all examples
crashes for:
osgdistortion
osgdepthshadow
osgimpostor
osgprerender
osgprerendercubemap
osgshadowtexture
osgsimulation
osgpick
osgfxbrowser
I will try to look at some of these issues this evening.
André
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] nVidia CUDA Documentation
for those who are interested in CUDA http://developer.nvidia.com/object/cuda.html /adegli ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Wiiki and CVS to Subversion migration
Hi Paul, On 2/16/07, Paul Martz <[EMAIL PROTECTED]> wrote: Thanks, Robert -- Everything builds fine now on current SVN in VS8. No problems with running anything either. Thanks for the feedback. Good work on the transition to SVN! We owe Jose for his expertise ;-) Will the current CVS no longer be maintained or updated from this point forward? CVS will be active for a while longer, but its my intention not updated with new changes to the OSG, all the new changes will go to SVN. If needs be I can patch the old CVS respositories, but I'd prefer to minimize my workload and just concentrate of SVN here on out. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] changing the image size for imagestream? works ok + TextureRectangle texcoords question
Hi Eric,
See the example osgtexturerectangle. You can see it at work there.
best regards
Raymond
Robert Osfield wrote:
Hi Eric,
On 2/16/07, Eric Sokolowsky <[EMAIL PROTECTED]> wrote:
I know that this thread is quite cold, but I was wondering if it was
ever implemented as a way to use normalized texture coordinates with
non-power-of-two size images. If not, I might want to take a stab at it.
To help this task Iadded the follow method and functionality into
osg::TexMat:
/** Switch on/off the post scaling of the TexMat matrix by the
size of the last applied texture rectangle.
* Use a TexMat alongside a TextureRectangle with this
scaling applied allows one to treat a TextureRectnagles texture
coordinate
* range as if it were the usual non dimensional 0.0 to 1.0
range.
* Note, the TexMat matrix itself is not modified by the post
scaling, its purely an operation passed to OpenGL to do the post
scaling once the
* the TexMat matrix has been loaded.*/
void setScaleByTextureRectangleSize(bool flag) {
_scaleByTextureRectangleSize = flag; }
/** Get whether the post scaling of the TexMat matrix, by the
size of the last applied texture rectangle, is switched on/off.*/
bool getScaleByTextureRectangleSize() const { return
_scaleByTextureRectangleSize; }
So you need to add a TexMat alongside the texture being applied with
changing sizes, and set it up to automatically scale, and then just
let the classes do their stuff.
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Migration of OpenThreads to subversion & future of OpenThreads project management.
On Fri, 16 Feb 2007 21:25:14 +0100, Robert Osfield <[EMAIL PROTECTED]> wrote: Or should be just roll include/OpenThreads and src directories into OpenSceneGraph/include/src and maintain it along with the rest of the OSG? Thoughts? Aspirations? Just some quick thoughts. I think the svn repo structure choosen is a very good one. As revisions are shared for both osg and openthreads. If you want to use OpenThreads in a non-osg project, this is also possible with the current repo-structure. -- Joakim Simonsson ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
