[osg-users] Intersector optimization
Hi, I'm working on an application that manipulates a 3d terrain (one big single geometry). I'm using OSG for 3d rendering as well as for internal data manipulation. I need to calculate the visibility of each point of a result grid from a certain position P. I have setup the simplest algorithm for this. It goes like this for each point of my grid --compute the 3D position P' on the terrain --create a segment between P and P' --call the intersector with the segment on the terrain --if there is an intersection flag the point as hidden do it again As you can imagine, this is going fairly slow. I suppose the main issue is that the intersector is testing every single triangle for an intersection. Any idea to optimize this ? Thanks, Jean-Charles[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42908#42908 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector distance and Transform
Peter Hrenka wrote: I had a partial fix which helped as long as there is no projection involved. Unfortunately that is probably the main use-case... I think the proper way to do this involves storing the inverse matrices in the result-structure and back-transforming the intersection points before sorting. Has anyone resolved this bug with incorrect distance reported by the PolytopeIntersector when objects are scaled? cheers, nick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42907#42907 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] performance problems in OSG 2.8.2 tried LOD, Culling etc.
Hi, I am using OSG version 2.8.2 on a Windows XP x64 System (i7 system, 8GB RAM) and I am trying to implement a driving simulator with OSG. First I testet all the scene with a small city and had no performance problems when I was driving thru the city. But now I loaded the hole city into the scene and than it was not possible to drive because I had one frame per second. (loaded .ive 3d city-file was about 80Mb ...mem usage of the fully loaded scene is around 323MB) First, I added backface-culling to every geode in the scene with following lines: Code: rootNode-getOrCreateStateSet()-setMode( GL_CULL_FACE, osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE ); I used OVERRIDE so that all the child nodes has the same property. This works a little bit faster but is still no good performance. Than I modified my camera settings with following lines: Code: camera-setCullingMode(osg::CullSettings::ENABLE_ALL_CULLING); camera-setSmallFeatureCullingPixelSize(30.f); This was again a little bit faster but was not enough. Than I used LODNodes: Code: osg::ref_ptrosg::Node lodLevel3 = originalGeode; osg::ref_ptrosg::Node lodLevel2 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osg::ref_ptrosg::Node lodLevel1 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osg::ref_ptrosg::LOD lodNode = new osg::LOD(); lodNode-addChild( cowLevel1.get(), 200.0f, 2.0f ); lodNode-addChild( cowLevel2.get(), 50.0f, 200.0f ); lodNode-addChild( cowLevel3.get(), 0.0f, 50.0f ); Again it was a little bit faster but the performance still sucks. I read somewhere that OSG supports frustum culling by default but it seems that this is not working. Because when I am driving in the small city the peformance is perfect and when I am loading more city structure to the scene and drive thru the same city part it is horrible lame (but you see on the screen the same polygones like in the small city) My open scene graph looks like this: Code: root +-scene objects | +-trafficSigns | +-trafficLight | +-triggerObjects +-city root | +-roads | | +-road geode1 | | +-road geode2 | | +-road geode3 | | +-road geode4... | +-houses | | +-house geode1 | | +-house geode2 | | +-house geode3 | | +-house geode4... | +-trees | | +-tree geode1... | +-... +-lights | +-light souce.. +-HUD geode I have no idea what I can do. If someone had the same problem like me and found a solution, it would be great if he can post it here. I hope my english is ok. Thanks alot! Cheers, Marcus[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42898#42898 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] Question about map() of index buffer
Dear Zhen, yes you are right. osgCompute::MAP_DEVICE_INDICES is already documented and it will be included in the code in the upcoming release. We are sorry for any confusion. Best regards, Mick SVT Group -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42909#42909 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] Experiences with osgCompute
Dear Bart, thanks a lot for your very detailed annotations. Many of your comments are based on the combination of CUDA and OSG which is sometimes not an easy task since interoperability with GL is still tricky. We try to answer the questions later in the day. Best regards, Mick SVT Group -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42910#42910 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersector optimization
Hi Jean-Charles, The OSG supports KdTrees for ray intersections with geometry in the scene, this improves performance an enormous amount. You can enable KdTree generation for loaded models with the osgDB::Options::BuildKdTreesHint or osgDB::Registry::setBuildKdTreesHint(..), or the OSG_BUILD_KDTREE=ON evn var. If you want to assign the KdTree datastructures on models that are already loaded/created you can osg::KdTreeBuilder. Robert. On Wed, Sep 21, 2011 at 10:45 AM, Jean-Charles Quillet jean-charles.quil...@alyotech.fr wrote: Hi, I'm working on an application that manipulates a 3d terrain (one big single geometry). I'm using OSG for 3d rendering as well as for internal data manipulation. I need to calculate the visibility of each point of a result grid from a certain position P. I have setup the simplest algorithm for this. It goes like this for each point of my grid --compute the 3D position P' on the terrain --create a segment between P and P' --call the intersector with the segment on the terrain --if there is an intersection flag the point as hidden do it again As you can imagine, this is going fairly slow. I suppose the main issue is that the intersector is testing every single triangle for an intersection. Any idea to optimize this ? Thanks, Jean-Charles[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42908#42908 ___ 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] performance problems in OSG 2.8.2 tried LOD, Culling etc.
Hi Marcus, Performance optimization is a huge topic and most of the time it comes down to creating a well balanced scene graph. You really need to make sure that the whole scene graph is built with performance in mind, one typically can't just enable something or apply some high level trick to suddenly get performance so to tricks you've already tried are really in this territory. What you need to do is take a step back and start learning how different scene graphs/effects affect performance, what the bottlenecks are and what different techniques you can employ to improve the scene graphs to render at the desired framerates. As I said this is a *huge* topic so if you are new to real-time graphics it will seem rather daunting. Various aspects of performance optimization has been discussed many times on the osg-users mailing list/forum so I'd recommend have a look through the archives. FYI, the OSG by default does view frustum culling and provide lots of other ways of doing culling too, how effective they are depends upon the scene graph itself - the OSG is professional class scene graph used in many simulators worldwide - it has what it takes to deliver the performance that simulators needs but as much as it's very capable it can't fix scene graphs that are not built well. Robert. On Tue, Sep 20, 2011 at 2:32 PM, Marcus Rabe film_foot...@yahoo.de wrote: Hi, I am using OSG version 2.8.2 on a Windows XP x64 System (i7 system, 8GB RAM) and I am trying to implement a driving simulator with OSG. First I testet all the scene with a small city and had no performance problems when I was driving thru the city. But now I loaded the hole city into the scene and than it was not possible to drive because I had one frame per second. (loaded .ive 3d city-file was about 80Mb ...mem usage of the fully loaded scene is around 323MB) First, I added backface-culling to every geode in the scene with following lines: Code: rootNode-getOrCreateStateSet()-setMode( GL_CULL_FACE, osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE ); I used OVERRIDE so that all the child nodes has the same property. This works a little bit faster but is still no good performance. Than I modified my camera settings with following lines: Code: camera-setCullingMode(osg::CullSettings::ENABLE_ALL_CULLING); camera-setSmallFeatureCullingPixelSize(30.f); This was again a little bit faster but was not enough. Than I used LODNodes: Code: osg::ref_ptrosg::Node lodLevel3 = originalGeode; osg::ref_ptrosg::Node lodLevel2 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osg::ref_ptrosg::Node lodLevel1 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osg::ref_ptrosg::LOD lodNode = new osg::LOD(); lodNode-addChild( cowLevel1.get(), 200.0f, 2.0f ); lodNode-addChild( cowLevel2.get(), 50.0f, 200.0f ); lodNode-addChild( cowLevel3.get(), 0.0f, 50.0f ); Again it was a little bit faster but the performance still sucks. I read somewhere that OSG supports frustum culling by default but it seems that this is not working. Because when I am driving in the small city the peformance is perfect and when I am loading more city structure to the scene and drive thru the same city part it is horrible lame (but you see on the screen the same polygones like in the small city) My open scene graph looks like this: Code: root +-scene objects | +-trafficSigns | +-trafficLight | +-triggerObjects +-city root | +-roads | | +-road geode1 | | +-road geode2 | | +-road geode3 | | +-road geode4... | +-houses | | +-house geode1 | | +-house geode2 | | +-house geode3 | | +-house geode4... | +-trees | | +-tree geode1... | +-... +-lights | +-light souce.. +-HUD geode I have no idea what I can do. If someone had the same problem like me and found a solution, it would be great if he can post it here. I hope my english is ok. Thanks alot! Cheers, Marcus[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42898#42898 ___ 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] Intersector optimization
Thanks a lot for your quick answer Robert, I didn't know this structure was implemented in OSG. That would be the way to go. Unfortunately my application uses OSG 2.8.2 and KD-Tree support is not present yet in this version. So it'll be worth upgrading. I don't want to have much trouble upgrading. I've seen that version 2.8.3 has KD-Tree support. Do you reckon KD-Tree support was mature enough in this version ? Jean-Charles -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42913#42913 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersector optimization
Hi Jean-Charles, On Wed, Sep 21, 2011 at 1:34 PM, Jean-Charles Quillet jean-charles.quil...@alyotech.fr wrote: Thanks a lot for your quick answer Robert, I didn't know this structure was implemented in OSG. That would be the way to go. Unfortunately my application uses OSG 2.8.2 and KD-Tree support is not present yet in this version. So it'll be worth upgrading. I don't want to have much trouble upgrading. I've seen that version 2.8.3 has KD-Tree support. Do you reckon KD-Tree support was mature enough in this version ? I don't recall the specifics of the KdTree support between 2.8.x and 3.0.x, I don't think it will have evolved too much. However, 3.0.x has lots of improvements over 2.8.x and for the most part porting between the two should be straight forward - often it will be little more than a recompile. I would recommend looking at 3.0.x. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intersector optimization
Hi Jean-Charles Another option is render occlusion geometry to depth texture from P point of view (like in shadowmap generation), then draw buffer with points that u need to test with visibility testing against depth map in vertex or geometry shader, streaming out result via transform feedback. To connect this output data to your c++ structures you can add vertex attribute with some sort of hash (or even pointer to your data structure stored in one\two 32 bit uints, depending on whether you building 32\64bit app ) to each vertex, and stream out both visibility check result and this hash to be able to connect this data to your high level structures. This option is very fast, but you will have some precision issues (for correct checking of points that lie exactly on visible surface you need to use polygon offset or instead some threshold in your shaders when checking against depth map, which could cause some points to be counted as visible when they aren't). Also this require quite a bit of effort to get it working, unless you are familiar with opengl low-level stuff. Cheers, Sergey. 21.09.2011, 13:45, Jean-Charles Quillet jean-charles.quil...@alyotech.fr: Hi, I'm working on an application that manipulates a 3d terrain (one big single geometry). I'm using OSG for 3d rendering as well as for internal data manipulation. I need to calculate the visibility of each point of a result grid from a certain position P. I have setup the simplest algorithm for this. It goes like this for each point of my grid --compute the 3D position P' on the terrain --create a segment between P and P' --call the intersector with the segment on the terrain --if there is an intersection flag the point as hidden do it again As you can imagine, this is going fairly slow. I suppose the main issue is that the intersector is testing every single triangle for an intersection. Any idea to optimize this ? Thanks, Jean-Charles[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42908#42908 ___ 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] performance problems in OSG 2.8.2 tried LOD, Culling etc.
On 9/20/2011 7:32 AM, Marcus Rabe wrote: This was again a little bit faster but was not enough. Than I used LODNodes: Code: osg::ref_ptrosg::Node lodLevel3 = originalGeode; osg::ref_ptrosg::Node lodLevel2 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osg::ref_ptrosg::Node lodLevel1 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osg::ref_ptrosg::LOD lodNode = new osg::LOD(); lodNode-addChild( cowLevel1.get(), 200.0f, 2.0f ); lodNode-addChild( cowLevel2.get(), 50.0f, 200.0f ); lodNode-addChild( cowLevel3.get(), 0.0f, 50.0f ); I don't see where you are reducing the geometry/complexity of the lower LOD nodes. If you're not doing that, then LOD won't help you; it would still draw the full resolution regardless of your eye distance / pixel size. I read somewhere that OSG supports frustum culling by default but it seems that this is not working. Because when I am driving in the small city the peformance is perfect and when I am loading more city structure to the scene and drive thru the same city part it is horrible lame (but you see on the screen the same polygones like in the small city) My open scene graph looks like this: Code: root +-scene objects | +-trafficSigns | +-trafficLight | +-triggerObjects +-city root | +-roads | | +-road geode1 | | +-road geode2 | | +-road geode3 | | +-road geode4... | +-houses | | +-house geode1 | | +-house geode2 | | +-house geode3 | | +-house geode4... | +-trees | | +-tree geode1... | +-... +-lights | +-light souce.. +-HUD geode Scene graphs do frustum cull, OSG included. It's the reason that scene graphs exist. But currently you have a rather flat organization, resulting in O(n) performance. You should try organizing your scene graph in more of a spatial quad tree (for example) to achieve O(log(n)) performance. (This all assume your scene graph is cull limited...) -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RTT multipass on same geometry
Hello, I've have a question regarding RenderToTexture in a multipass setup. I have to RTT cameras, the first one has DEPTH and 3 color attachments, while the second has only one color attachment. I need to use the data from the first RTT-pass in the second camera, so the renderorder is set accordingly. Basically my scene is organized like this: root | RTTCamera_1 ||Model RTTCamera_2 ||Model Booth cameras use the same geometry, viewport, transform. Yet the Model graph is culled twice. Is there any way to prevent the second cull traversal? I.e. reuse the batch collected in the first culling? cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT multipass on same geometry
On 9/21/2011 10:54 AM, Sebastian Messerschmidt wrote: Hello, I've have a question regarding RenderToTexture in a multipass setup. I have to RTT cameras, the first one has DEPTH and 3 color attachments, while the second has only one color attachment. I need to use the data from the first RTT-pass in the second camera, so the renderorder is set accordingly. Basically my scene is organized like this: root | RTTCamera_1 ||Model RTTCamera_2 ||Model Booth cameras use the same geometry, viewport, transform. Yet the Model graph is culled twice. Is there any way to prevent the second cull traversal? I.e. reuse the batch collected in the first culling? In OSG, culling (the CullVisitor) also collects state. Since you are almost certainly using two different shaders (one that writes to three targets, another which writes to one), it's unlikely that OSG's state graph can be reused in your situation. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT multipass on same geometry
Thank you Paul, It seems a little bit more obvious now. Basically I need to write some additional value to one of the COLOR attachments alpha channel, which is derived from the first pass. So my second approach (which seems to be failing) is somehow to write only to those texels in my color attachment of the second pass, where depth != far. Right now I really feel stupid, as I thought that there must be any easy way to do so. Any ideas how to render extra properties to the color buffer attachment at the positions that have been written in the first pass without re-rendering the whole scene? On 9/21/2011 10:54 AM, Sebastian Messerschmidt wrote: Hello, I've have a question regarding RenderToTexture in a multipass setup. I have to RTT cameras, the first one has DEPTH and 3 color attachments, while the second has only one color attachment. I need to use the data from the first RTT-pass in the second camera, so the renderorder is set accordingly. Basically my scene is organized like this: root | RTTCamera_1 ||Model RTTCamera_2 ||Model Booth cameras use the same geometry, viewport, transform. Yet the Model graph is culled twice. Is there any way to prevent the second cull traversal? I.e. reuse the batch collected in the first culling? In OSG, culling (the CullVisitor) also collects state. Since you are almost certainly using two different shaders (one that writes to three targets, another which writes to one), it's unlikely that OSG's state graph can be reused in your situation. -Paul ___ 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] [osgCompute] Experiences with osgCompute
Hi Bart! We try to give you some answers to your questions. Please let us know if you need more details in some areas. Actually, a lot of the design decisions are based on the internal and detailed knowledge about OSG and GL. Bart wrote: 1) OsgCompute does not seem to support CUDA constant memory. I have to do a plain CUDA call: cudaMemCpyToSymbol Right - constant memory is not supported as a buffer object. Thus, you need to transfer data to the constant memory by using cudaMemCpyToSymbol. However it would be very easy to integrate such a behavior into a cuda memory object by defining an additional alloc-hint. 2) About the init function: 2.1) It was not clear to me that I can do stuff with osgCompute only after the init() function has been called. I wanted to fill CUDA memory objects with data before the init function was called (see 2.2 for the reason why). I was unaware that this was not possible and it took me a while to figure this out. What do you mean exactly by init-function? Each memory object has a init-function which checks the object's parameters for consistency which is implicitly called when using the memory object! There is no need to call init manually (like _tmpBuffer-init()). In the examples we do it mostly just for clarification. But be careful: when using the dimension of an e.g. a texture and geometry objects should be initialized first manually. 2.2) The lazy allocation with the init function, which is called before the launch function, is not desirable, especially not in real-time applications. Often you want to set up as much as possible at the start of your application and not do this during run-time (from a real-time performance perspective). I would prefer that the user should have the responsibility of initializing his data (e.g. in constructor) and not force the user to declare an init function. The lazy allocation is exactly implemented the way OSG does the allocation. If you want to prevent such a lazy allocation (e.g. for performance issues) you can simply map the buffer to the device and init its memory right after you created the buffer, eg.: Code: cudaMemset( curBuffer-map(osgCompute::MAP_DEVICE_TARGET ), 0x0, curBuffer-getByteSize() ); 2.3) The init function causes me to declare a lot of variables globally. Normally the constructor receives all the necessary data and consequently I use this data for initialization purposes only once, so there is no need to store the received data globally. But now if I want to do some fill CUDA memory with data or copy a constant to CUDA memory, I have to do this in the init function and not in the constructor. Consequently I store all this data globally, so the init function can access it. Actually it is not quite clear to me what kind of init and which constructor you mean. Please give us an short example (unfortunately I did not look into your source code yet). 2.4) What does the init function do in the Resource class (and subsequently in subclasses Module and Memory)? Documentation is not really concrete on this: Init will check for internal parameters applied to resources and will create device dependent objects Please see the answer to 2.1. But you are right - we should go more into details in the documentation. 2.5) I tried to get rid of this init function somehow and use constructors again. But then I had to remove the META_Object macro and that gave me more errors than I would like see and I did not want to spend too much time on this anymore. Please see my answer to 2.3. The init-function really seems to bother you :-) If you clarify what you want to do maybe we could help with some examples/code how to deal with the initialization of memory objects. 3) About the map function: 3.1) When and what is synchronized between device and host? It's described rather vaguely. And are we talking about a complete memory copy or a simple pointer-copy between OpenGL and CUDA context? Device means GPU-memory, host means CPU-memory. Thus, synchronization needs to copy the memory between device and host. Please note, the synchronization is taking place automatically when using map (see 3.2). 3.2) In the osgEndianness demo we allocate a Memory object (corresponding to a cudaMalloc) and there is still a map() function called. As far as I know mappings are only performed on GL-buffer objects to map them from OpenGL context to CUDA context. Secondly, I think in (one of) the other examples you call map() each frame of a Memory object. Why? It makes sense to do this if we are dealing with a GL-buffer object, since GL manages the buffer object and may choose to move the buffer in memory somehow. But a map() on Memory object seems strange, since it is not a GL-buffer object. It is even stranger to call this map() each frame, since cudaMalloc gives us a device pointer that remains
Re: [osg-users] RTT multipass on same geometry
Sebastian Messerschmidt wrote on 2011-09-21: Thank you Paul, It seems a little bit more obvious now. Basically I need to write some additional value to one of the COLOR attachments alpha channel, which is derived from the first pass. So my second approach (which seems to be failing) is somehow to write only to those texels in my color attachment of the second pass, where depth != far. Right now I really feel stupid, as I thought that there must be any easy way to do so. Any ideas how to render extra properties to the color buffer attachment at the positions that have been written in the first pass without re-rendering the whole scene? You could write to the stencil buffer in the first pass, then render a full-screen quad with the stencil test enabled on the second pass to only write to the pixels written to in the first pass. osgPPU might be useful to you for doing this. On 9/21/2011 10:54 AM, Sebastian Messerschmidt wrote: Hello, I've have a question regarding RenderToTexture in a multipass setup. I have to RTT cameras, the first one has DEPTH and 3 color attachments, while the second has only one color attachment. I need to use the data from the first RTT-pass in the second camera, so the renderorder is set accordingly. Basically my scene is organized like this: root | RTTCamera_1 ||Model RTTCamera_2 ||Model Booth cameras use the same geometry, viewport, transform. Yet the Model graph is culled twice. Is there any way to prevent the second cull traversal? I.e. reuse the batch collected in the first culling? In OSG, culling (the CullVisitor) also collects state. Since you are almost certainly using two different shaders (one that writes to three targets, another which writes to one), it's unlikely that OSG's state graph can be reused in your situation. -Paul -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GraphicsWindow has not been created successfully
Hi, Hope somebody will be able to help me :s I am under Mac OS X 10.7, and I have OSG 3.0.1, that I compiled with g++ (and not LLVM) I can run osgviewer, and my own program which loads a 3d model. But when I want to create a sphere (still my old sphere problem :-) ) OSG yields : GraphicsWindow has not been created successfully. View::setUpViewAcrossAllScreens() : Error, no WindowSystemInterface available, cannot create windows. Viewer::realize() - failed to set up any windows and the programs goes on until it quits (without entering the main loop). So why didn't it manage to create the window for a sphere? I really don't get it. I don't find anything on the internet, and I really don't know where to start my investigation... Yann___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] performance problems in OSG 2.8.2 tried LOD, Culling etc.
Hi, Paul you are right I forgot to write the hole code for the LOD implementation, sorry. Code: osg::ref_ptrosg::Node lodLevel3 = originalGeode; osg::ref_ptrosg::Node lodLevel2 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osg::ref_ptrosg::Node lodLevel1 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osgUtil::Simplifier simplifier; simplifier.setSampleRatio( 0.5 ); lodLevel2-accept( simplifier ); simplifier.setSampleRatio( 0.1 ); lodLevel3-accept( simplifier ); osg::ref_ptrosg::LOD lodNode = new osg::LOD(); lodNode-addChild( lodLevel1.get(), 200.0f, 2.0f ); lodNode-addChild( lodLevel2.get(), 50.0f, 200.0f ); lodNode-addChild( lodLevel3.get(), 0.0f, 50.0f ); Sorry I am a complete OSG noob. I have no idea how a good scene graph has to look like. But I am going to use the seach function to find a solution in the forum. Thanks guys! -Marcus -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42922#42922 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting problem when using help or stats handler
After some more digging I kind of have a feeling for what is happening but again I have too little knowledge of the OSG internals to really understand what is going on... When looking at the culling phase I see that there is the root render stage, then 2 levels of pre render bins (excluding root level). First the root render stage has the correct light attribute in its _renderStageLighting and a null _inheritedPositionalStateContainer, then the 1st level _preRenderList render bin's _inheritedPositionalStateContainer is from the parent render stage _renderStageLighting. Its _renderStageLighting however is not inherited and contains no light attributes. Therefore on the 2rd level pre render bin the _inheritedPositionalStateContainer is from the 1st level _renderStageLighting, but this has an empty _attrList... Basically it seems that when having a hierarchy of pre render stages / bins the light attribute does not trickle down the hierarchy and is not applied before my geometry is drawn... Not sure if that makes sense... Any idea ? cheers, guillaume From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier, Guillaume Sent: September-19-11 5:16 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Lighting problem when using help or stats handler Hi Paul and al., Yes the geometries do have color and normal arrays. From what I understand the problem is that the scene light is applied only after the geometry is drawn, therefore using last frame light settings when drawing the geometry. Since the help / stats handlers apply their default light at the end of the frame, it will be used for the next frame scene render. This render order issue seems to be directly related to the implementation of the EffectNode and its overriding of the traverse() and cull() functions. cheers, guillaume From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: September-19-11 4:56 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Lighting problem when using help or stats handler On 9/19/2011 2:43 PM, Poirier, Guillaume wrote: Hello OSG users, My problem is simple to describe: When in our application we press 's' or 'h' to display either the stats or help, the lighting changes when it should not. Check to make sure that all Geometry objects in your scene specify a color array and a normal array. OSG does not provide a default if these are missing, so they inherit the value last set in the OpenGL state machine. Both affect lighting (color affects lighting because OSG's default is to enable GL_COLOR_MATERIAL if no Material StateAttributes are present). -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] performance problems in OSG 2.8.2 tried LOD, Culling etc.
Hi, Did you had a look on the result of the simplifier ? I'm not OSG'simplifier master but sometimes simplifiers just cannot simplify more, so the results remains nearly the same. Maybe you could create your own simplified geometries for example a (colored) cube for a building (6 faces, even 5 if you don't need the lower one). You also can use fog to hide the far building and so avoid having to load them, or just use LOD with no child as lower detailed level geometry so nothing to cull and draw. These are just ideas, but I can ensure you that a 80MB ive file is not something heavy and OSG is certainly able to manage your scene. Hope it helps ! Regards, Vincent. 2011/9/21 Marcus Rabe film_foot...@yahoo.de Hi, Paul you are right I forgot to write the hole code for the LOD implementation, sorry. Code: osg::ref_ptrosg::Node lodLevel3 = originalGeode; osg::ref_ptrosg::Node lodLevel2 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osg::ref_ptrosg::Node lodLevel1 = dynamic_castosg::Node*( lodLevel3-clone( osg::CopyOp::DEEP_COPY_ALL ) ); osgUtil::Simplifier simplifier; simplifier.setSampleRatio( 0.5 ); lodLevel2-accept( simplifier ); simplifier.setSampleRatio( 0.1 ); lodLevel3-accept( simplifier ); osg::ref_ptrosg::LOD lodNode = new osg::LOD(); lodNode-addChild( lodLevel1.get(), 200.0f, 2.0f ); lodNode-addChild( lodLevel2.get(), 50.0f, 200.0f ); lodNode-addChild( lodLevel3.get(), 0.0f, 50.0f ); Sorry I am a complete OSG noob. I have no idea how a good scene graph has to look like. But I am going to use the seach function to find a solution in the forum. Thanks guys! -Marcus -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42922#42922 ___ 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] Texture two faces of a triangle independently
Hi, I'm having problems texturing triangles. Currently I'm using setState along with an osg::Texture2D to texture a series of triangles. The thing is, I want one face of the triangle to have one texture, and the other face of the triangle to have a different texture. So when looking at two different sides the user will see two different things. Sorry about the beginner question. Thank you, James. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42927#42927 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please suggest ways to get PagedLOD nodes to pre-load when switching nodes.
Hi, For anyone searching for answer for how to preload a pageLOD this is what I hacked together which was 'good enough' for a proof of concept. Using osgCompositeViewer.cpp I was able to set up a second viewport and slaved the camera to the primary view. Then I was able to shrink the viewport of the 2nd camera down to a small block at the bottom of the window. I set the scene of this view to the next frame I want to render. I suspect render to texture will work even better. I tried using the settings from osgAutoCapture to manipulate how the database pager would load but nothing seemed to make any noticeable difference except setting LODScale() . Cheers, Eric -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42928#42928 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
