[osg-users] LineSegmentIntersector and line width
Hi, I'm using osgUtil::LinesegmentIntersector to pick objects from my scene. It works all fine except Geode containing line geometry (with LineWidth stateset). But, I want to pick somes thick lines, how can I do? Thanks in advance! Aude Créez votre adresse électronique [EMAIL PROTECTED] 1 Go d'espace de stockage, anti-spam et anti-virus intégrés. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector and line width
Hi Aude, a.lagnier schrieb: Hi, I'm using osgUtil::LinesegmentIntersector to pick objects from my scene. It works all fine except Geode containing line geometry (with LineWidth stateset). But, I want to pick somes thick lines, how can I do? LinesegementIntersector cannot pick lines (or points). You can use osgUtil::PolytopeIntersector instead. Have a look at the osgkeyboardmouse example for example code. Thanks in advance! Aude Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer addView threading issue on Windows?
Hi JS,
On Thu, Nov 20, 2008 at 7:12 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
As we don't know whether this is the cause of the problem yet, I've
modified J-S's osgviewer.cpp to do the resize. Could users who've
seen problems try this version out, if this works then we have
workaround that end users can apply to existing apps, and we can
figure out a solution to fix it permanently in svn/trunk.
Well, seems like that didn't change anything.
Darn I was hoping that fix would the end of this. The lack of
resize does look to be a bug to me, just not the one causing the
hang/crash in your case...
But following your hint I
checked where the renderingTraversals was stuck:
// wait till the dynamic draw is complete.
if (_endDynamicDrawBlock.valid())
{
// osg::Timer_t startTick = osg::Timer::instance()-tick();
_endDynamicDrawBlock-block();
// osg::notify(osg::NOTICE)Time waiting
osg::Timer::instance()-delta_m(startTick,
osg::Timer::instance()-tick())std::endl;;
}
It's hung on the _endDynamicDrawBlock-block(); line.
When it hung, I had just created a 4th view (=4th context).
Uncoincidentally, there are 4 threads on GraphicsThread::run(), which calls
GraphicsContext::makeCurrent(), which calls
GraphicsWindowWin32::makeCurrentImplementation, which is stuck on the
wglMakeCurrent() call. One of those 4 is stuck in the middle of the graphics
driver DLL, but I'm not sure that's relevant.
I'm not sure how I can see if one of the graphics threads is crashed, as you
indicated... They all seem to be running, just blocked.
Other than those 5 threads (main thread with renderingTraversals() + 4 draw
threads, one per context) there are 7 other threads in the process. I can't
see specifically what they're doing since they're all in graphics driver
code (more or less deeply).
(this all coincides with the stack traces I sent before, but I just thought
explaining it in words would help me understand eventually, and perhaps
others too)
The fact that threads are sitting on a block or bariier is nothing to
worry about unless, it's more that fact that threads that haven't yet
joined it are the problem.
It would be worth looking at exactly when the problem occurs - is it
on the stopThreading, the addView, or the startThreading or
thereafter?
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DataVariance
Hi Paul P. You will have to debug this on your own I'm afraid, this type of issue is not something one can resolve without seeing it first hand. The best I can do is recommend that look into the using DataVariance set to DYNAMIC on all StateSet and Drawable that you have in your scene. This is the most likely cause of problems like this, but we've already recommended this and you've made no comment whether you've tried this. There have been lots written on this topic on osg-users so please don't overlook the archives. Robert. On Thu, Nov 20, 2008 at 7:32 PM, [EMAIL PROTECTED] wrote: When I change to SingleThreaded, I do not see the problem. The standard OSG examples work fine. Other cases of my problem also work fine. Clearly, it's something in this app that is causing problems. In the problem case, I'm rendering to two different image buffers and then reading the images out on the CPU. My scene is a normal scene except I have two cameras with each rendering to these different textures (i.e. a top and bottom view of the scene). I also have another camera rendering an orthogonal projection on top of the scene. Paul P. - Original Message From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, September 17, 2008 11:03:33 AM Subject: Re: [osg-users] DataVariance Hi Paul, I can't say why your app might be hanging. Do the standard OSG example hang on your machine? Try running the view single threaded as something that might at least flesh out whether threading is an issue at all. Robert. On Wed, Sep 17, 2008 at 3:52 PM, [EMAIL PROTECTED] wrote: Thanks for the quick response... Then, any idea why my application is hanging when I attempt to render my first frame?? Below is the call stack of the two OSG threads. The problem seems to exist when I include two different parts of my scene graph. My scene graph consists of two Camera's at the root. Each renders to a different image array (using camera-attach(..., image);). Each camera then has shared subgraphs attached which also contain a Camera node (for Ortho view for part of the scene) but with no attachments. The osgViewer's camera is unchanged (and I really don't need to render anything). Am I doing something wrong with these camera's? While I'm at it, one more questions: Is there a way to turn on the OSG statistics overlay without using the keyboard. I've added the StatsHandler event handler. With osgProducer, I used to be able to do viewerEventHandler-setFrameStatsMode(mode). Paul P. THREAD #1 #0 0x4146627d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #1 0x41235a66 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libc.so.6 #2 0x40b1e364 in OpenThreads::Condition::wait (this=0x8281f88, mutex=0x8281f80) at /src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/OpenThreads/pthreads/PThreadCondition.c++:137 #3 0x40ad9241 in OpenThreads::BlockCount::block (this=0x8281f80) at Block:133 #4 0x40ad7506 in osgViewer::ViewerBase::renderingTraversals (this=0x827ab58) at /src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/osgViewer/ViewerBase.cpp:733 #5 0x40ad6a88 in osgViewer::ViewerBase::frame (this=0x827ab58, simulationTime=0) at /src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/osgViewer/ViewerBase.cpp:592 #6 0x080858a7 in MyViewer::frame (this=0x827aad8, simTime=0) at MyViewer.hpp:131 THREAD #2 #0 0x4146627d in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #1 0x41235a66 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libc.so.6 #2 0x40b1e364 in OpenThreads::Condition::wait (this=0x82786dc, mutex=0x82786d4) at /src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/OpenThreads/pthreads/PThreadCondition.c++:137 #3 0x400aedf5 in OpenThreads::Block::block (this=0x82786d4) at Block:42 #4 0x40a8cdc7 in osgViewer::Renderer::TheadSafeQueue::takeFront ( this=0x82786cc) at /src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/osgViewer/Renderer.cpp:136 #5 0x40a8ee38 in osgViewer::Renderer::draw (this=0x8278640) at /src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/osgViewer/Renderer.cpp:340 #6 0x40a9085e in osgViewer::Renderer::operator() (this=0x8278640, context=0x8272258) at /src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/osgViewer/Renderer.cpp:640 #7 0x4086352d in osg::GraphicsContext::runOperations (this=0x8272258) at /src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/osg/GraphicsContext.cpp:688 #8 0x4086c3ee in osg::RunOperations::operator() (this=0x829ea70, -context=0x8272258) at /src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/osg/GraphicsThread.cpp:134 #9 0x4086bc7d in osg::GraphicsOperation::operator() (this=0x829ea70, object=Internal: global symbol `Object' found in RissAnimationPath.cpp psymtab but not in symtab. Object may be an inlined function, or may be a template
Re: [osg-users] Texture coordinates question
Hi John, You'll need to duplicate your vertices to be able to have different tex coordinates as osg::Geometry only support per vertex bindings for tex coordinates. For performance it's a false economy to vertex indices or per primitive bindings as they drop the OSG down on to OpenGL slow paths. Use overall, per primitive set or per vertex bindings for best performance. The only slow paths should also be considered deprecated as neither OpenGL ES no OpenGL 3.x support this only slow paths. Robert. On Thu, Nov 20, 2008 at 8:22 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Gentlemen, Is there a way to force vertex B to have a different texture coordinate in each of triangle ABC and triangle BCD? Texture coordinate indices? I don't understand how those are applied. If the binding is per_primitive, will each of my triangles be textured by a single pixel? John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ 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] Dual screen support on Linux using TwinView
HI Michael, Does you two views move together, i.e. they look different directions but as the viewpoint moves around both projector outputs should update relative to this? If this is the case they you have one View but with two slave Cameras each with a project and view offset from the View's master Camera. If two projector outputs are wholly independent w.r.t viewpoint, and require same camera controls such as seprate CameraManipulator then you do have a case which is logically two different views. Robert. On Thu, Nov 20, 2008 at 11:52 PM, Michael [EMAIL PROTECTED] wrote: Hey Robert We have 2 separate logical views (I guess). Essentially we have 2 projectors that can each be placed at any location and orientation in the room and they project onto objects in the room. This is not a tiled display, and we are not worried about overlap. We are also doing some render to texture operations which is why we have different views. Each monitor output is driving a single projector. So, we have 2 projectors and a couple of RTT cameras. The projectors have their own projection and view matrices, but share the same scene graph data for drawing. One of the projectors does shadow removal for the other one, so we need to control the render order. So, we need each monitor output to drive one of our views for the projector, using the 1 graphics context. I appreciate the help (and patience!) Cheers Michael On Thu, Nov 20, 2008 at 7:38 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Michael, On Thu, Nov 20, 2008 at 12:09 AM, Michael [EMAIL PROTECTED] wrote: This fails on the second display because OSG can't connect to screen 0:1, because there is only 1 xscreen. Clearly I am doing this wrong, but I'm not sure of the correct way. If you have only only X screen then you'll only be able to open up a window on that one... so you'll need to use the screenNum set to 0 fro both contexts, or Something like this? 1. Create a single GraphicsContext on screen 0, with width=2048 (both displays) 2. Create my views, and somehow tell each one to only render on half of the context? If you a grabbing the whole of both displays I would create a single graphics context that goes across both physical displays. Otherwise you'll need to create two graphics contexts on the same X11 screenNum but with the second window starting at a xpos of 1024. Now what to do about the views depends upon you actual needs. Do you have two separate logical views of doing you have single view that is just made up of two cameras (like looking out of two adjacent real-world windows that share the same view). If you have only single view, then do the two halves of it but up against each other or do they overlap? Could you have a bash at explain what you are specifically trying to achieve as the advice to give is different for all the different cases. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Two VirtualPlanetBuilder problems
Hi Robert, On Fri, Nov 21, 2008 at 2:07 AM, Kramer, Robert W [EMAIL PROTECTED] wrote: I have a very large imagery set (~1 million files). When running VirtualPlanetBuilder 0.9.9, I am limited to about 482 -t imagery files for a given vpbmaster command before I get ERROR 4: Failed to open file /mp2/osg/file482.tif for each -t file listed after the 482nd file listed in the script and the *.ive files are not created. VPB can handle hundres of thousands of input files, but OS's consoles can't so it's very likely that you've just hit the limit of what your command line can delivery. The best way to handle large number of input files is to use the -t directory or -d directory support, osgdem/vpbmaster will automatically detect the use of directory and go a collect all the files contained within it. The ERROR 4 is a GDAL warning, so perhaps there is something else wrong with the files. Perhaps the files are corrupted. Secondly, a test of a small VPB database of 1.34GB of CADRG imagery produced 14.941GB of *.ive files using VPB 0.9.7 in 23 minutes time. The same test with VPB Version 0.9.9 produced 14.826GB of *.ive files in 32 minutes. I was not expecting the newer VPB to only produce a tiny (1%) amount of compression, while taking about 40% more time. Furthermore, I'm perplexed that my resulting output files are 11 times the input imagery (1m black and white Controlled Imagery Base). Using the --compressed option made no difference to the resulting *.ive sizes. I require all levels of detail, so expect some increase in database size, but can anybody help me reduce this to a smaller multiple as I'm running out of disk space! What do I need to do to turn on Heightfield compression, for example. The HeightField compression will now be on by default and is what is giving you the 1% improvement - not great, but then most of the data is elsewhere. The --compression option only hints to use OpenGL compressed textures, but this has been on by default anyway - so this is why it's not made any difference. To enable the .ive compression you'll need to add an extra ReaderWriter::Options string using the -O compression to hint to the .ive plugin to use zlib compression. Later on I'll refine the command line options in VPB so that all the compression options are under one roof. Another tool for compression is to switch off mipmapping (--no-mip-mapping) and to tell the build that it can use non power of two textures (--npot). But in the end, if you are having disk space problems the solution is to buy more disk space, as running out of disk space is one good way to give yourself corrupted files, and disk space is cheap. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Two VirtualPlanetBuilder problems
Robert Osfield wrote: On Fri, Nov 21, 2008 at 10:22 AM, J.P. Delport [EMAIL PROTECTED] wrote: Can one just tack -O compression onto the back of the vpbmaster command line, or is the process more involved? Just tack it on the osgdem/vpbmaster line. thanks, I'll try it soon. Then wait for full moon and carry out a dance to the moon god covered in goose feathers. Already did this when I tried to convince our cluster to boot ;) jp Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Two VirtualPlanetBuilder problems
On Fri, Nov 21, 2008 at 10:52 AM, J.P. Delport [EMAIL PROTECTED] wrote: Then wait for full moon and carry out a dance to the moon god covered in goose feathers. Already did this when I tried to convince our cluster to boot ;) Did it work? If so it might be worth collecting all these proven techniques up on the wiki. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Two VirtualPlanetBuilder problems
Robert Osfield wrote: On Fri, Nov 21, 2008 at 10:52 AM, J.P. Delport [EMAIL PROTECTED] wrote: Then wait for full moon and carry out a dance to the moon god covered in goose feathers. Already did this when I tried to convince our cluster to boot ;) Did it work? No, it turned out Debian and NFS hated me :( I'm now fearlessly trying to compress a database using osgconv in.ive out.ive -O compressImageData will report the results. If so it might be worth collecting all these proven techniques up on the wiki. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DataVariance
Hi, i have encountered some similiar problems with multithreading (and the datavariance stuff). One thing I have considered is changing the design of osg::Statesets and osg::StateAttribute to immutable classes. So once the stuff is created you can only change it by cloning it. At least for those objects you don't have to think about datavariance anymore. Attached you will find a 'setup' design pattern, which helps you spawning immutable objects. Richard PS.: Just an idea. TestClass.cpp Description: TestClass.cpp TestClass.h Description: TestClass.h Test.cpp Description: Test.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Two VirtualPlanetBuilder problems
On Fri, Nov 21, 2008 at 10:22 AM, J.P. Delport [EMAIL PROTECTED] wrote: Can one just tack -O compression onto the back of the vpbmaster command line, or is the process more involved? Just tack it on the osgdem/vpbmaster line. Then wait for full moon and carry out a dance to the moon god covered in goose feathers. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Two VirtualPlanetBuilder problems
Hi Robert, Robert Osfield wrote: To enable the .ive compression you'll need to add an extra ReaderWriter::Options string using the -O compression to hint to the .ive plugin to use zlib compression. Later on I'll refine the command line options in VPB so that all the compression options are under one roof. Can one just tack -O compression onto the back of the vpbmaster command line, or is the process more involved? jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Two VirtualPlanetBuilder problems
Robert Osfield wrote: On Fri, Nov 21, 2008 at 10:22 AM, J.P. Delport [EMAIL PROTECTED] wrote: Can one just tack -O compression onto the back of the vpbmaster command line, or is the process more involved? Just tack it on the osgdem/vpbmaster line. Just to clarify, after reading the source, the correct option is: -O compressed jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSetSwitchNode suggestion.
Hi Robert, The most general approach is the best, and the performance differences will almost certainly be negligible between your suggest SwitchStateSetNode and my suggest Layer node with nodemask. Feel free to implement both and test them against each other w.r.t cull traversal time and overall framerate. I implemented the LayerNode approach and tested both versions using a composite viewer. The StateSetSwitchNode is a tiny bit faster as predicted, but I agree with you that the difference is negligible. The other penalty that I worte about earlier is however large. My scene:==- My scene contains 40308 nodes. - A full traverse results in visiting 380941 nodes (lot of reused geometry). Pre-processing the scene with LayerNodes:==- 2356 LayerNodes are inserted. - Each LayerNode is one Group node with 5 child Group nodes. - Each child node share the same children as the other child nodes.- I apply optimizations from osgUtil::Optimizer.- Result: - 5 nodes totally in the scene. - 11446441 visits during a full traverse. Pre-processing the scene with StateSetSwitchNode:==- 2356 StateSetSwitchNodes are inserted. - This is one Group node that has 5 Group nodes embedded. - All 5 embedded nodes share the same children as the StateSetSwitchNode. - None of the 5 embedded nodes has any parents.- I use the same optimizations as above.- Result: - 42664 nodes totally in the scene. - 540844 visits during a full traverse. The penalty:=Our viewer is a osgViewer::CompositeViewer.Calling the run function of the osgViewer::CompositeViewer is quite dramatically different from the LayerNode to the StateSetSwitchNode approach.The LayerNode approach use approximately 20 times longer time from we call run until the scene appears on screen.11446441 divided by 540844 = 21. Conclusion after this testing:===- We do not need the StateSetSwitchNode if the viewer initialization penalty is somehow fixed. New questions:===- What does the osgViewer::CompositeViewer do when we call run and until render starts?- Is this something that would be possible to do in a pre-processor and save in a .ive file?- Other ways to get around this problem? Regards,Viggo _ Hold kontakten med Windows Live Messenger. http://clk.atdmt.com/GBL/go/msnnkdre001003gbl/direct/01/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSetSwitchNode suggestion.
Hi Viggo, I really can't comment without the actual problem and solutions in front of me, it's just too complex a topic to accumulate a whole thread and then generate in my head what the possible code and scene graph you have going on at your side. One thing I can say is that the number of nodes you are playing with looks pretty excessive. I have no clue what type of application you have and what you are trying to do, but there may well may a wholly better way of tackling your problem than throwing a massive scene graph at it. Robert. On Fri, Nov 21, 2008 at 1:07 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi Robert, The most general approach is the best, and the performance differences will almost certainly be negligible between your suggest SwitchStateSetNode and my suggest Layer node with nodemask. Feel free to implement both and test them against each other w.r.t cull traversal time and overall framerate. I implemented the LayerNode approach and tested both versions using a composite viewer. The StateSetSwitchNode is a tiny bit faster as predicted, but I agree with you that the difference is negligible. The other penalty that I worte about earlier is however large. My scene: == - My scene contains 40308 nodes. - A full traverse results in visiting 380941 nodes (lot of reused geometry). Pre-processing the scene with LayerNodes: == - 2356 LayerNodes are inserted. - Each LayerNode is one Group node with 5 child Group nodes. - Each child node share the same children as the other child nodes. - I apply optimizations from osgUtil::Optimizer. - Result: - 5 nodes totally in the scene. - 11446441 visits during a full traverse. Pre-processing the scene with StateSetSwitchNode: == - 2356 StateSetSwitchNodes are inserted. - This is one Group node that has 5 Group nodes embedded. - All 5 embedded nodes share the same children as the StateSetSwitchNode. - None of the 5 embedded nodes has any parents. - I use the same optimizations as above. - Result: - 42664 nodes totally in the scene. - 540844 visits during a full traverse. The penalty: = Our viewer is a osgViewer::CompositeViewer. Calling the run function of the osgViewer::CompositeViewer is quite dramatically different from the LayerNode to the StateSetSwitchNode approach. The LayerNode approach use approximately 20 times longer time from we call run until the scene appears on screen. 11446441 divided by 540844 = 21. Conclusion after this testing: === - We do not need the StateSetSwitchNode if the viewer initialization penalty is somehow fixed. New questions: === - What does the osgViewer::CompositeViewer do when we call run and until render starts? - Is this something that would be possible to do in a pre-processor and save in a .ive file? - Other ways to get around this problem? Regards, Viggo Få Hotmail du også. Windows Live Hotmail med 5000 MB gratis lagringsplass. ___ 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] setUpdateCallback fails under slave-camera
Hi Users, We have a strange error (perhaps bug).. when we have a geode that has a setUpdateCallback and that geode is a child of a slave camera then the callback is never called. This is also valid for drawables update callbacks anyone? -- Regards, Peter Wraae Marino www.osghelp.com - OpenSceneGraph support site ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSetSwitchNode suggestion.
Hi Robert, I really can't comment without the actual problem and solutions in front of me, it's just too complex a topic to accumulate a whole thread and then generate in my head what the possible code and scene graph you have going on at your side. One thing I can say is that the number of nodes you are playing with looks pretty excessive. I have no clue what type of application you have and what you are trying to do, but there may well may a wholly better way of tackling your problem than throwing a massive scene graph at it. Ok, I'll explain what we are doing :-) We are creating a simulator for vehicles, people and combat. A typpical world that we display is 15000x15000 meters. The terrain is populated with cities, roads, light-poles at the side of the road, lots of forests, lots of stones laying around in the terrain and other debree. The example I tested with is actually quite simple compared to what we will need to use. We are going to show a realistic sea that use GPU side vertex displacement from a real-time generated height-map for waves. The water surface will reflect the world and refract the sub-sea terrain. We are going to add shadows and volumetric fog. The combat scenes will use an extensive ammount of particles. The complexity level is high both on what we demand of our shaders and for the detail of items in the world. We are also considering implementing deferred lighting. Our simulators will be possible to configure to run low detail if the customer chose to use a graphics card that is not too powerful, and high detail if the customer wants to spend money on high end hardware. The complexity of this demands a good system for shaders. We must LOD the geometry in the world and also LOD the shaders we apply onto them. Rendering one frame image of our scene requires multiple pre-rendering cameras and some times multiple post-rendering cameras. Our world is so large that we will re-use the node-tree for all the cameras and use the node masks to determine what to render. We test performance on small scenes and on large scenes. The size of the scene used in an example does not neccessarily matter when you are discussing a specific technology/problem. I tested both approches on one palm-tree instead of the whole world. It too has a similar initialization time problem, but it is so small that it is hard to measure it properly. Other computer activities will disturb too much (we are talking Windows, and Windows does not handle multitasking in the best possible way) :-) So, in this case, throwing a large scene at the problem make a lot of sense, the numbers stand more out this way. I am so far impressed by the speed and useability that OSG provide. OSG is a very good engine. It is great to work with it. I am going to run a profiler on the initialization problem. That is probably a great way of figuring out where the time goes. Perhaps also do a single-step journey into the run function to see what it actually do. Have a nice weekend, Viggo _ Mest sett denne måneden på MSN Video. http://video.msn.com/?mkt=nb-nofrom=HMTAG___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Screen Space Ambient Occlusion
Hi Adrian, *Interesting links about SSAO :* * http://rgba.scenesp.org/iq/computer/articles/ssao/ssao.htm http://meshula.net/wordpress/?p=145 http://ati.amd.com/developer/SIGGRAPH08/Chapter05-Filion-StarCraftII.pdf* *Others Similar technique :* * http://developer.nvidia.com/object/siggraph-2008-HBAO.html http://developer.download.nvidia.com/presentations/2008/GDC/GDC08_Ambient_Occlusion.pdf http://vcg.isti.cnr.it/Publications/2006/TCM06/Tarini_FinalVersionElec.pdf http://www.shalinor.com/research.html http://graphics.uni-konstanz.de/publikationen/2006/unsharp_masking/Luft%20et%20al.%20--%20Image%20Enhancement%20by%20Unsharp%20Masking%20the%20Depth%20Buffer.pdf http://www.cs.berkeley.edu/b-cam/Papers/Kirk-2007-RTA/ * *SSAO technique based on :* * http://www.ppsloan.org/publications/ProxyPG.pdf* Yann -- Yann Le Paih ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgbrowser linker error
Hi Robert, After an update this morning, I'm getting a linker error in the osgbrowser example: 32osgbrowser.obj : error LNK2019: unresolved external symbol public: static class osg::ref_ptrclass osgWidget::BrowserManager __cdecl osgWidget::BrowserManager::instance(void) ([EMAIL PROTECTED]@osgWidget@@[EMAIL PROTECTED]@osgWidget@@@osg@@XZ) referenced in function _main I wonder, I do not have any of the XUL libraries, so should that example even be included in that case? I imagine it won't do anything if it can't create an embedded browser... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] pragma warnings disabled in headers
2008/11/21 Wojciech Lewandowski [EMAIL PROTECTED]: Hi, Guys Some middle step solution could be CMake define which would activate warning disable in osg\Export. Would this be acceptable ? What do other OSG windows developers think ? Sounds good to me. Though perhaps we should go whole hog and make it so each individual warning can be enabled or disabled. If you want to post a modified CMakeLists.txt here I'll give it a test. btw, had you ever noticed the /FI option? I didn't notice it till I was looking at the warning stuff; could be handy. -- The truth is out there. Usually in header files. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSetSwitchNode suggestion.
Hi Viggo, Thanks for the explanation. I don't think your needs are particular different from most who are writing games/simulators with the OSG. While large scenes LOD's is crucial, and for massive scenes Paging is also crucial. The OSG supports both so should scale to larger scenes. The other approach you could take is having custom nodes or drawables that wrap up a the whole rendering of a class of object, or a how collection of objects. The later is something would suit trees/forests. These approaches would all reduce the number of objects in your scene graph in memory and in the view frustum on each frame and thereby cut the update, cull and draw dispatch costs. If your switch node helps in keeping the number of objects down then thumbs up for it. W.r.t init time, typically this is pretty low. Shaders can be expensive. Texture objects and drawables aren't typically too expensive - the osgmemorytest example illustrate this. Robert. On Fri, Nov 21, 2008 at 3:02 PM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi Robert, I really can't comment without the actual problem and solutions in front of me, it's just too complex a topic to accumulate a whole thread and then generate in my head what the possible code and scene graph you have going on at your side. One thing I can say is that the number of nodes you are playing with looks pretty excessive. I have no clue what type of application you have and what you are trying to do, but there may well may a wholly better way of tackling your problem than throwing a massive scene graph at it. Ok, I'll explain what we are doing :-) We are creating a simulator for vehicles, people and combat. A typpical world that we display is 15000x15000 meters. The terrain is populated with cities, roads, light-poles at the side of the road, lots of forests, lots of stones laying around in the terrain and other debree. The example I tested with is actually quite simple compared to what we will need to use. We are going to show a realistic sea that use GPU side vertex displacement from a real-time generated height-map for waves. The water surface will reflect the world and refract the sub-sea terrain. We are going to add shadows and volumetric fog. The combat scenes will use an extensive ammount of particles. The complexity level is high both on what we demand of our shaders and for the detail of items in the world. We are also considering implementing deferred lighting. Our simulators will be possible to configure to run low detail if the customer chose to use a graphics card that is not too powerful, and high detail if the customer wants to spend money on high end hardware. The complexity of this demands a good system for shaders. We must LOD the geometry in the world and also LOD the shaders we apply onto them. Rendering one frame image of our scene requires multiple pre-rendering cameras and some times multiple post-rendering cameras. Our world is so large that we will re-use the node-tree for all the cameras and use the node masks to determine what to render. We test performance on small scenes and on large scenes. The size of the scene used in an example does not neccessarily matter when you are discussing a specific technology/problem. I tested both approches on one palm-tree instead of the whole world. It too has a similar initialization time problem, but it is so small that it is hard to measure it properly. Other computer activities will disturb too much (we are talking Windows, and Windows does not handle multitasking in the best possible way) :-) So, in this case, throwing a large scene at the problem make a lot of sense, the numbers stand more out this way. I am so far impressed by the speed and useability that OSG provide. OSG is a very good engine. It is great to work with it. I am going to run a profiler on the initialization problem. That is probably a great way of figuring out where the time goes. Perhaps also do a single-step journey into the run function to see what it actually do. Have a nice weekend, Viggo Windows Live Messenger på mobilen. Hold kontakten hvor som helst når som helst. ___ 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] osgbrowser linker error
Hi JS, Sorry about this, it's simply that I missed adding a OSGWIDGET_EXPORT in front of the class declarations. I've now added these could do an svn update. Robert. On Fri, Nov 21, 2008 at 3:49 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Robert, After an update this morning, I'm getting a linker error in the osgbrowser example: 32osgbrowser.obj : error LNK2019: unresolved external symbol public: static class osg::ref_ptrclass osgWidget::BrowserManager __cdecl osgWidget::BrowserManager::instance(void) ([EMAIL PROTECTED]@osgWidget@@[EMAIL PROTECTED]@osgWidget@@@osg@@XZ) referenced in function _main I wonder, I do not have any of the XUL libraries, so should that example even be included in that case? I imagine it won't do anything if it can't create an embedded browser... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.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] pragma warnings disabled in headers
Hi Robert, Explicit casts could remove some of the warnings. But those related to template exports could be hard to fix without using pragmas. I suspect that osg/Config is perhaps the only OSG header modified by CMake. So its probably the only place where these pragmas or (define activating them in osg/Export) could be added. I will try to make this addition. Wojtek Hi Wojtek, Perhaps the middle ground is to place the #pagma's in the CMake generated include/osg/Config file? The other approach is to to an explicit casts to avoid the warnings in the first place. This is more wordy and while of dubious practical value would at least fix the warnings. Robert. On Fri, Nov 21, 2008 at 2:13 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi, Guys Unfortunately we don't always want or can use precompiled headers. Besides, argument about precompiled headers is double sided sword. Such precompiled headers could be also used to enable these warnings after all osg headers with disabled warnings were included. In my humble opinion this new policy will cause more problems when more windows developers update repository. I have just updated osg from SVN. My application is modular and is build from twenty something dlls. Most of them use osg. And of course during compilation of the code under VisualStudio 9.0 I see a tons of OSG related warnings (excerpt from compiler output below). On the other hand we don't use precomiled headers because we want the code to be linux portable. Sure I can disable warnings in compiler properties for these projects. But I think that this is bad idea to force this every windows OSG application developer to change all their projects. In my opinion this problem should be fixed at OSG level - compilation of OSG headers should not produce warnings (at least not such number) even if this is actually VisualStudio problem. I also agree that disabling these warnings permanently in osg/Export was also controversial as it suppressed them in user applications. But in former version we did not see bogus VisualStudio warnings and those who wanted them could enable them again. This time we all will see them and will have to change their existing projects. It looks like only good solution could be wrapping osg classes with pragma push/pop disabling warnings only when these classes are built. But here I expect that Robert will object and say again that fixes for over sensitive compiler warnings could actually bring some errors. Some middle step solution could be CMake define which would activate warning disable in osg\Export. Would this be acceptable ? What do other OSG windows developers think ? Cheers, Wojtek Lewandowski 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/BufferObject(374) : warning C4251: 'osg::PixelBufferObject::_bufferEntryImagePair' : struct 'std::pair_Ty1,_Ty2' needs to have dll-interface to be used by clients of class 'osg::PixelBufferObject' 24 with 24 [ 24 _Ty1=osg::BufferObject::BufferEntry, 24 _Ty2=osg::Image * 24 ] 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Array(169) : warning C4251: 'osg::Array::_vbo' : class 'osg::ref_ptrT' needs to have dll-interface to be used by clients of class 'osg::Array' 24 with 24 [ 24 T=osg::VertexBufferObject 24 ] 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Quat(366) : warning C4244: 'argument' : conversion from 'const osg::Quat::value_type' to 'osg::Vec3f::value_type', possible loss of data 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Quat(366) : warning C4244: 'argument' : conversion from 'const osg::Quat::value_type' to 'osg::Vec3f::value_type', possible loss of data 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Quat(366) : warning C4244: 'argument' : conversion from 'const osg::Quat::value_type' to 'osg::Vec3f::value_type', possible loss of data 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Quat(369) : warning C4244: 'argument' : conversion from 'const osg::Quat::value_type' to 'osg::Vec3f::value_type', possible loss of data 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Matrixd(585) : warning C4244: 'argument' : conversion from 'const osg::Matrixd::value_type' to 'osg::Vec3f::value_type', possible loss of data 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Matrixd(585) : warning C4244: 'argument' : conversion from 'const osg::Matrixd::value_type' to 'osg::Vec3f::value_type', possible loss of data 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Matrixd(585) : warning C4244: 'argument' : conversion from 'const osg::Matrixd::value_type' to 'osg::Vec3f::value_type', possible loss of data 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Matrixd(601) : warning C4244: 'argument' : conversion from 'const osg::Matrixd::value_type' to 'osg::Vec3f::value_type', possible loss of data 24C:\dev\OSG_SVN\OpenSceneGraph\include\osg/Matrixd(601) : warning C4244: 'argument' : conversion from 'const osg::Matrixd::value_type' to 'osg::Vec3f::value_type', possible loss of data
[osg-users] bug - resources aren't properly deallocated when a viewer is destroyed
Hi,
I have a simple example that shows that if you run a viewer, tear it
down and run it again, textures are missing. (winXP, 2.6.0). It appears
that resources such as Textures and DisplayLists are leaking and
corrupting runs.
The attached example simply creates a viewer and loads the cow.osg file.
Press esc to exit the viewer which removes the cow from the scene and
tears the viewer down. Then another viewer is created and the cow is
loaded again. This time, the cow has no textures.
What calls are necessary to properly deallocate resources when tearing
down the viewer so that future viewers can be created and load the next
resources?
Thanks,
Brett
#include osg/ref_ptr
#include osgDB/ReadFile
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
#include osgDB/ReadFile
#include osgDB/WriteFile
void testViewerTeardown()
{
{
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
osg::ref_ptrosg::Group root = new osg::Group;
viewer-setUpViewOnSingleScreen(0);
viewer-setSceneData(root.get());
viewer-setCameraManipulator(new osgGA::TrackballManipulator());
viewer-realize();
{
std::string originalFile = Cow.osg;
osg::ref_ptrosgDB::ReaderWriter::Options options =
osgDB::Registry::instance()-getOptions();
osg::ref_ptrosg::Node modelNode =
osgDB::readNodeFile(originalFile, options.get());
root-addChild(modelNode.get());
viewer-run();
root-removeChildren(0,root-getNumChildren());
}
}
{
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
osg::ref_ptrosg::Group root = new osg::Group;
viewer-setUpViewOnSingleScreen(0);
viewer-setSceneData(root.get());
viewer-setCameraManipulator(new osgGA::TrackballManipulator());
viewer-realize();
{
std::string originalFile = Cow.osg;
osg::ref_ptrosgDB::ReaderWriter::Options options =
osgDB::Registry::instance()-getOptions();
osg::ref_ptrosg::Node modelNode =
osgDB::readNodeFile(originalFile, options.get());
root-addChild(modelNode.get());
viewer-run();
root-removeChildren(0,root-getNumChildren());
}
}
} ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] bug - resources aren't properly deallocated when a viewer is destroyed
Hi Brett,
The Viewer does it best to deallocate and clean up all buffers on the
scene graphs that it knows about, but your code is hidding the scene
graph from it by removing them from the view's scene graph so these
removed elements do go throw the OpenGL clean up process.
If you really want to use the OSG in this kack handed way then call
releaseGLObjects() on the subgraph that you've detacthed.
You example code was pretty ropey - it's not an app in its own right
so one had covert it into a application, and then because of adding of
adding of the scene graph after realize and that no home was recent
the viewer's camera wasn't pointed at the scene graph, so one could
verify anything. In future could you please provide example codes
that can be run as-as, and ones that you can actually see something.
Robert.
On Fri, Nov 21, 2008 at 4:49 PM, brettwiesner [EMAIL PROTECTED] wrote:
Hi,
I have a simple example that shows that if you run a viewer, tear it down
and run it again, textures are missing. (winXP, 2.6.0). It appears that
resources such as Textures and DisplayLists are leaking and corrupting runs.
The attached example simply creates a viewer and loads the cow.osg file.
Press esc to exit the viewer which removes the cow from the scene and
tears the viewer down. Then another viewer is created and the cow is loaded
again. This time, the cow has no textures.
What calls are necessary to properly deallocate resources when tearing down
the viewer so that future viewers can be created and load the next
resources?
Thanks,
Brett
#include osg/ref_ptr
#include osgDB/ReadFile
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
#include osgDB/ReadFile
#include osgDB/WriteFile
void testViewerTeardown()
{
{
osg::ref_ptrosgViewer::Viewer viewer = new
osgViewer::Viewer;
osg::ref_ptrosg::Group root = new osg::Group;
viewer-setUpViewOnSingleScreen(0);
viewer-setSceneData(root.get());
viewer-setCameraManipulator(new
osgGA::TrackballManipulator());
viewer-realize();
{
std::string originalFile = Cow.osg;
osg::ref_ptrosgDB::ReaderWriter::Options options =
osgDB::Registry::instance()-getOptions();
osg::ref_ptrosg::Node modelNode =
osgDB::readNodeFile(originalFile, options.get());
root-addChild(modelNode.get());
viewer-run();
root-removeChildren(0,root-getNumChildren());
}
}
{
osg::ref_ptrosgViewer::Viewer viewer = new
osgViewer::Viewer;
osg::ref_ptrosg::Group root = new osg::Group;
viewer-setUpViewOnSingleScreen(0);
viewer-setSceneData(root.get());
viewer-setCameraManipulator(new
osgGA::TrackballManipulator());
viewer-realize();
{
std::string originalFile = Cow.osg;
osg::ref_ptrosgDB::ReaderWriter::Options options =
osgDB::Registry::instance()-getOptions();
osg::ref_ptrosg::Node modelNode =
osgDB::readNodeFile(originalFile, options.get());
root-addChild(modelNode.get());
viewer-run();
root-removeChildren(0,root-getNumChildren());
}
}
}
___
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] osgSDL::Viewport to osg::Viewport
Hi sorry for the newbie question... I am trying to merge to apps that use different libraries... One uses osgSDL:: and the other, which needs to be integrated with the first, uses osg::. where I am having trouble is setting a camera to do RTT. I have a osgSDL::Viewport to for which I want a camera to project the scene to a texture! I am not realy certain how this works but static or const casts canot convert. As well, if I use dynamic_cast, the operation proceeds but the pointer to my osg::Viewport created as shuch (osg::Viewport* ovp = dynamic_castosg::Viewport *( vp );) is still set to NULL eventhough my osgSDL::Vewport* vp contains valid info... The camera viewport gets set no problem to the null viewport but the second app I am using (osgPPU) crashes when it tries to create a new local viewport using the copy operator as such: osg::ref_ptrosg::Viewport vp = new osg::Viewport(*(fp._processor-getCamera()-getViewport())); (normal as the pointer is still null) Last thing is if I use reinterpret_cast, my assignment to the camera does not get accepted and my app crashes there... Any idea how I could get these two to work togethere? Thanks Patrick Castonguay H: 613 435 2235 C: 613 325 1341 Technology Innovation Management (TIM) Student - Modeling and Simulation stream Carleton University, Ottawa, ON ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] Patch for Philips WOWvx Displays
Hi Robert, Do you get that error on exit? The comments on the code around the place it fails under windows suggests there are threading issues to do with deleting the PixelBuffers, and setting single threaded mode on the viewer made the problem go away. But in any case, I think you are right, (although WOWvx is pretty unusable for my scenes without that change), I agree it needs some more thought to do it in a better way. I have stuggled in the past with solutions involving near and far planes, but the problem seemed to be that OSG would often use a near plane distance where all the pixels actually rendered to the depth map get a value close to 1.0. I think this effect is shown clearly with my go inside the box example. I did have an earlier discussion about near-far planes on the user list in relation to this problem, but we didn't come up with anything that helped (well, apart from my understanding of the 'depth' of the problem lol.) I think your idea for using shaders to calculate the min depth is the right way to go, indeed I did consider that, but I couldn't work out how to do it. Shaders have two types right? One type for vertices and one for pixels, I need the minimum depth value in the pixel shader, but neither type seemed the right place to sample all the depth values to calculate the minimum value. CCing osg-users for ideas! Cheers Chris. - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: Chris Denham [EMAIL PROTECTED]; OpenSceneGraph Submissions [EMAIL PROTECTED] Sent: Friday, November 21, 2008 4:57 PM Subject: Re: [osg-submissions] Patch for Philips WOWvx Displays Hi Chris, I can reproduce the problem with going inside the box reliably so thumbs up on a good test case. I've merged and test the code and under Kubuntu 7.10 and get the error: Got an X11ErrorHandling call display=0x70a410 event=0x7fffb8f1bd70 GLXBadPbuffer Major opcode: 128 Minor opcode: 28 Error code: 138 Request serial: 56 Current serial: 57 ResourceID: 4294967295 Got an X11ErrorHandling call display=0x70a410 event=0x7fffb8f1c460 Which is not too dissimilar the error you've see under Windows. This strongly suggests that the is problem with the visuals that are been requested for this window. Having reviewed the wider algorothim that you are using here, I can't help but feel that doing a read back to main memory and then analysing depth this data on the CPU is really poor solution performance wise. Could one not use the computed near/far planes of the RTT camera handling the rendering of the scene? Or if you really have to analyse the depth data then this really should be done using a shader down on the GPU. Given that the submission produces known errors on two platforms, and implements are very inefficient technique I feel that this submission is not ready to merge - it introduces more problems than is solves. Perhaps a discussion on osg-users might strike us some different ideas on how to tackle the issues with the current implementation. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgSDL::Viewport to osg::Viewport
Hi Partick, A dynamic_castosg::Viewport*(vp) will return 0 if the object vp is not an osg::Viewport or vp doesn't subclass from osg::Viewport. I knowing about osgSDL so I can't comment on how osgSDL::Viewport is implemented. This a basic C++ that you really should look at C++ texts for understanding of. Might I suggest that you just copy the viewport info across. Robert. On Fri, Nov 21, 2008 at 5:34 PM, Patrick Castonguay [EMAIL PROTECTED] wrote: Hi sorry for the newbie question... I am trying to merge to apps that use different libraries... One uses osgSDL:: and the other, which needs to be integrated with the first, uses osg::. where I am having trouble is setting a camera to do RTT. I have a osgSDL::Viewport to for which I want a camera to project the scene to a texture! I am not realy certain how this works but static or const casts canot convert. As well, if I use dynamic_cast, the operation proceeds but the pointer to my osg::Viewport created as shuch (osg::Viewport* ovp = dynamic_castosg::Viewport *( vp );) is still set to NULL eventhough my osgSDL::Vewport* vp contains valid info... The camera viewport gets set no problem to the null viewport but the second app I am using (osgPPU) crashes when it tries to create a new local viewport using the copy operator as such: osg::ref_ptrosg::Viewport vp = new osg::Viewport(*(fp._processor-getCamera()-getViewport())); (normal as the pointer is still null) Last thing is if I use reinterpret_cast, my assignment to the camera does not get accepted and my app crashes there... Any idea how I could get these two to work togethere? Thanks Patrick Castonguay H: 613 435 2235 C: 613 325 1341 Technology Innovation Management (TIM) Student - Modeling and Simulation stream Carleton University, Ottawa, ON ___ 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] osgbrowser linker error
Hi Robert, Sorry about this, it's simply that I missed adding a OSGWIDGET_EXPORT in front of the class declarations. I've now added these could do an svn update. Yep, that did the trick for building. I've yet to test it though. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgviewerWX not displaying obj files on linux
Hello All, With the osgviewerWX example, i can only view 3D models that are stored in osg file format. When invoked with an obj or stl file, (for instance http://orion.math.iastate.edu/burkardt/data/obj/cube.obj), osgviewer displays only a blank (blue) screen. If obj or stl files are converted to osg with osgconv, everything works as expected. Has anyone experienced such a behaviour ? (osg 2.6.1, wxwidgets 2.8.7, debian linux) Regards, Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgbrowser linker error
On Fri, 2008-11-21 at 16:06 +, Robert Osfield wrote: Hi JS, Sorry about this, it's simply that I missed adding a OSGWIDGET_EXPORT in front of the class declarations. I've now added these could do an svn update. I just did quick look at the osgWidget/Browser object you've added; if you wanted, you could have: Widget* createBrowserWidget() ...and have the method return a Widget properly sized and having it's setImage()/setTexture() method called. That'd give you power to just kinda plug it right into osgWidget anywhere, although if you have your own event handler you'll need to set the Widget's eventMask to EVENT_NONE so my code doesn't intercept yours. :) Robert. On Fri, Nov 21, 2008 at 3:49 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Robert, After an update this morning, I'm getting a linker error in the osgbrowser example: 32osgbrowser.obj : error LNK2019: unresolved external symbol public: static class osg::ref_ptrclass osgWidget::BrowserManager __cdecl osgWidget::BrowserManager::instance(void) ([EMAIL PROTECTED]@osgWidget@@[EMAIL PROTECTED]@osgWidget@@@osg@@XZ) referenced in function _main I wonder, I do not have any of the XUL libraries, so should that example even be included in that case? I imagine it won't do anything if it can't create an embedded browser... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.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] extracting heading, pitch, roll from rotation matrix...
Is there any method or class in OSG that extracts heading, pitch, and roll angles from a rotation matrix? I've searched and haven't seen anything. I just want to make sure there isn't anything out there before I embark on writing my own. Thanks in advance, -Shayne smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
