Re: [osg-users] How to get osg::State?
Hi Sebastian, this is a little off-topic, but this might interst others as well. I have been using gDebugger 5.8 (the last before AMD decided to make it a visual studio 2010 plugin, damn it!) until 2 days ago, when my free 1-year-licence expired. Since then I was unable to run it again, I tried uninstall-reinstall, asked gRemedy if it was possible to renew the licence, but didn't get any reply... Did someone get stuck on the same issue? Any suggetion? Thank you, Ricky On Tue, Jan 24, 2012 at 23:52, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote: I strongly suggest using gDebugger. It solved about 99% of my problems, as it can break at OpenGL errors and step into source code. cheers Sebastian I just hacked the State constructor and now I get this message:. Warning: detected OpenGL error 'invalid value' at Geometry::drawImplementation() after vertex arrays setup. Ok, so now I know there is an openGL error in the middle of the Geometry::drawImplementation() method. Is there an easy way to find out WHAT causes this error? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.**org/viewtopic.php?p=44996#**44996http://forum.openscenegraph.org/viewtopic.php?p=44996#44996 __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** openscenegraph.orghttp://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] How to get osg::State?
Same here... No solution :( msvs rocks and stuff, but dropping linux support is total fail 27.01.2012, 12:29, "Riccardo Corsi" riccardo.co...@kairos3d.it:Hi Sebastian,this is a little off-topic, but this might interst others as well.I have been using gDebugger 5.8 (the last before AMD decided to make it a visual studio 2010 plugin, damn it!)until 2 days ago, when my free 1-year-licence expired.Since then I was unable to run it again, I tried uninstall-reinstall, asked gRemedy if it was possible to renew the licence, but didn't get any reply... Did someone get stuck on the same issue? Any suggetion?Thank you,RickyOn Tue, Jan 24, 2012 at 23:52, Sebastian Messerschmidt sebastian.messerschm...@gmx.de wrote:I strongly suggest using gDebugger. It solved about 99% of my problems, as it can break at OpenGL errors and step into source code. cheers SebastianI just hacked the State constructor and now I get this message:. Warning: detected OpenGL error 'invalid value' at Geometry::drawImplementation() after vertex arrays setup.Ok, so now I know there is an openGL error in the middle of the Geometry::drawImplementation() method. Is there an easy way to find out WHAT causes this error? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44996#44996 ___ 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 listosg-users@lists.openscenegraph.orghttp://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] osgdem segmentation fault
On 26 January 2012 20:50, Mohammed Rashad mohammedrasha...@gmail.com wrote: still same error.. can you give me a step by step explanation I did tell you all the steps you need to do and present a number of different routes you can try. I really can't add much more. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
As a side note: if you were using vbo's instead of display lists for drawing i think you werent get into this problem in first place, as with vbos 5500 draw calls would happily kill your performance even on one screen, so you have to optimize your models. Nvidia drivers are great at optimizing consecutive calls to draw display lists so they become cheap as dirt and you can do thousands of them, may be this fails on multiple screen setups? 26.01.2012, 23:12, Jason Daly jd...@ist.ucf.edu: On 01/26/2012 01:02 PM, Tim Moore wrote: That is what I found at the time of that thread, testing with some models supplied by NIST. Newer hardware is highly optimized for massive geometry. For the record, I don't think the problem is bus contention, but lock contention in the NVidia driver. The amount of bus traffic involved in the OpenGL command stream is tiny. Thanks for that. A couple of people have mentioned bringing this to NVidia's attention. We'll probably end up doing that. The key to OpenGL performance in the 21st century is reducing the number of OpenGL function calls to a minimum... so says Captain Obvious. I'm glad the mesh optimizers turned out to be useful! Yeah, once you get down to the data itself, it ends up being pretty obvious (5,500 draw calls runs slower than 9 draw calls? Really? :-) ). There was a bit of digging to do before we got to that point, though. At the outset, we originally thought that an OpenGL program wasn't showing the same problem that an OSG program was, which pointed the blame at OSG. Turns out that we weren't doing an apples-to-apples comparison with the data sets. It wasn't until we could get precisely the same set of data into the OpenGL program that we could start looking at the data itself as the culprit. Definitely a big thanks for the mesh optimizers. I was all set to start writing something myself, but then I realized they were already there :-) Btw, the Linux tool oprofile is mentioned later in the thread, but I find the newer tool perf to be more useful. Thanks, I'll check that out. --J ___ 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] Render osgViewer::View main camera view solely to texture using FBO
On Thu, Jan 26, 2012 at 5:58 AM, Adam Bruce apalan...@gmail.com wrote: Hi again, Thanks for following up. I've tried it before with an attached pbuffer, but was - and still have been - getting unpredictable results. As before, if I simply place a camera as a node in the scene and attach a texture with FBO implementation, it will render the subgraph to the texture no problem. If I attach a texture to the main or slave camera of a view, whether I use a pbuffer for offscreen rendering or have a separate window, the texture will simply be filled with random data in video memory. The camera will otherwise work properly, as if I comment out any RTT-related lines and change the graphics context to the window's, it will render to a viewport without issues. I would have simply used the currently working method and updated the camera's matrices directly, but we're using more complex manipulators and making that functionality redundant is an ugly solution. I took a look at examples like osgdistortion, and, implementation purposes aside, can't see any differences in camera and scene setup that might cause this. It clearly has to be me, given the fact that this exact functionality is used as an example and I've gotten the same result on two different computers (running Windows 7 on Nvidia GTX460/560). You might take a look at the floating point depth buffer example, osgfpdepth, which does RTT using a slave camera in the viewer. I know this is similar to osgdistortion, but there are more knobs to tweak for the FBO configuration. Tim -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45029#45029 ___ 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] Play audio files
Thank you Chris for your reply.
I am still trying to solve the problems. One thing that have helped me is
changing this line:
AudioSink(osg::AudioStream* audioStream): _started(false), _paused(false),
_audioStream(audioStream) {play();}
for this line:
AudioSink(osg::AudioStream* audioStream): _started(false), _paused(false),
_audioStream(audioStream) {}
I don't know if there is a logical reason for that, but when deleting the
play(), the cutting in the audio seems to disappear. OK, it still makes some
cuts, but they are very small and it is possible to hear the audio without
problems (with the previous cuts it was impossible to hear the audio).
But I am still facing the problem of the delay. The audio starts delayed for
some reason that I can't still figure out. Could it be because I am using
openAL soft instead of openAL? Maybe that's not the problem, because it is
working fine with audio files, but who knows...
Best regards
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris
'Xenon' Hanson
Sent: jueves, 26 de enero de 2012 18:04
To: OpenSceneGraph Users
Subject: Re: [osg-users] Play audio files
On 1/26/2012 2:45 AM, Héctor Martínez wrote:
Hi Laurens,
If anyone can give an idea about the problem, you are welcome.
I'd love to help you, but I only wrote the FMOD side of osgAudio -- the
openAL/openalpp side was part of osgAL, and I never really worked with it
because I couldn't get openAL to work on my Vista box at the time.
--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting.
Contracting.
There is no Truth. There is only Perception. To Perceive is to Exist.
- Xen ___
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] Is a render to texture master camera critical?
2012/1/17 Martin Großer grosser.mar...@gmx.de: Hello all, A few weeks ago, I want to render my scene into a texture, which I want to use in the final rendering on a screen aligned quad. My first problem was I lost the shadows, because view dependent shadow techniques don't work with nested cameras. So I used a RTT slave camera. Now my Callbacks don't work, because they don't work with slave cameras (no update visistors for slave scene graphs). So now my rtt camera is the master camera and my ortho camera for the quad is a nested camera (see the render_to_texture_scene_graph.png). It looks fine, but I am not sure whether it is a good idea. There are any special explanatory notes for me? Is it a good or bad scene graph pattern for my use case? A couple of points: The default for a slave camera is to use the master camera's scene graph. In that case you don't need to worry about callbacks in the main scene graph. You can install an UpdateSlaveCallback if you really need it. See osg/View. If you set up your windows and contexts explicitly and assign them to slave cameras before calling Viewer::realize() or Viewer::run(), then the master camera will not be given a graphics context and won't be used for rendering. The manipulators will still update the master and Its view and projection matrices will be used to control the slave cameras if desired. When I play with RTT, I like to open the window and set up the graphics context with GraphicsContext::createGraphicsContext(), then assign that to the slave cameras that render the scene graph and display the rendered texture on the screen. I don't put the RTT camera in the scene graph. Tim Cheers Martin -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ 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] Compilation fails with recent version of osg for IOS / opengl es-builds
Hi Robert, Am 26.01.12 19:02, schrieb Robert Osfield: So disabling the feature would be fine for OpenGL ES, but on setting a non zero RowLength osg::Image under OpenGL ES it should emit a warning that it's not supported. thanks for the explanation, I'll code + submit a fix for review. cheers, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi Jason -- I agree that the system bus is a likely source of the scaling issue. It is certainly a single resource that has to be shared by all the GPUs in the system. To make a case for bus bandwidth limitation, you might work through the math. Bb FPS = Nw * Nd * Sd + O Where Bb is the bus bandwidth in bytes, Nw is the number of windows you're rendering to, Nd is the number of drawing commands, Sd is the size of the drawing commands in bytes, and O is the per frame OpenGL command overhead in bytes. The knowns: Bb = 500 MB/sec (PCIe 2.0) Nw = 4 Nd = 5500 Sd is a little harder to compute. It'll depend on the draw technology you're using (buffer objects or display lists) and the underlying OpenGL implementation. You could make a very rough guess here by figuring a fullword per OpenGL command, and a fullword per OpenGL command parameter. Just for the same of example, let's says Sd = 64 (16 fullwords to draw a single osg::Geometry). O encompasses all the per-frame OpenGL commands that OSG emits: glClear, glClearColor, glClearMask, dlDepthMask, matrices, light sources, swap, etc. You could plug in a rough guess like you would for Sd. Again, just as an example, let's use O = 2048. Plugging all that into a calculator, I get FPS = 371. But if Nw dropped to a single window, then FPS would jump to over 1400 -- or, more likely, you'd become limited by some other single resource in the system. The nice thing about algebra is that you can solve for the unknown, so of course you have the FPS, and if you have a pretty good guess for O (which can actually be pretty sloppy anyhow), then you ought to be able to solve for Sd and ask yourself if that result makes sense. I hope this helps. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 1/27/2012 7:17 AM, Paul Martz wrote: Sd is the size of the drawing commands in bytes gDebugger might be able to help you estimate this too. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 1/27/2012 7:17 AM, Paul Martz wrote: Bb FPS = Nw * Nd * Sd + O Where Bb is the bus bandwidth in bytes, Upon rereading this, a few corrections: Bb FPS = -- Nw * (Nd * Sd + O) And note that Bb is bandwidth in bytes/sec, of course (not bytes). Anyhow, this is all just back of the napkin stuff. With a little more effort I imagine you can refine the formula, and of course you have access to the actual data and values. I'd be interested in hearing if this line of investigation confirms the bus limitation theory. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/27/2012 04:38 AM, Sergey Polischuk wrote: As a side note: if you were using vbo's instead of display lists for drawing i think you werent get into this problem in first place, as with vbos 5500 draw calls would happily kill your performance even on one screen, so you have to optimize your models. Nvidia drivers are great at optimizing consecutive calls to draw display lists so they become cheap as dirt and you can do thousands of them, may be this fails on multiple screen setups? Hi, Sergey, I did play around with VBO vs. display lists early on. It didn't really change the performance much regardless of which I used. Keep in mind that this is all static geometry which is going to be resident on the GPU. I don't think modern drivers would distinguish much between VBO's in STATIC_DRAW mode and display lists. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer::GraphicsWindowCocoa::WindowData dynamic_cast returns 0
Hey guys, I'm trying to pass an osgViewer::GraphicsWindowCocoa::WindowData to my traits object with CreateOnlyView specified. For some reason whenever my WindowData is dynamic_cast in GraphicsWindowCocoa.mm it just returns 0. If I switch them to static_cast they work. Here's my code: Code: // OSGWindow.h osgViewer::GraphicsWindowCocoa::WindowData* windowData; // OSGWindow.cpp windowData = new osgViewer::GraphicsWindowCocoa::WindowData (osgViewer::GraphicsWindowCocoa::WindowData::CreateOnlyView); osg::ref_ptrosg::GraphicsContext::Traits traits = new osg::GraphicsContext::Traits(); traits-x = 100; traits-y = 100; traits-width = 1280; traits-height = 720; traits-red = 8; traits-blue = 8; traits-green = 8; traits-alpha = 8; traits-depth = 24; traits-windowDecoration = false; traits-doubleBuffer = true; traits-vsync = false; traits-stencil = 1; traits-samples = 8; traits-sampleBuffers = 1; traits-inheritedWindowData = windowData; osg::ref_ptrosg::GraphicsContext context = osg::GraphicsContext::createGraphicsContext (traits.get()); This is what's in GraphicsWindowCocoa.mm that returns 0: Code: GraphicsWindowCocoa::WindowData* windowData = traits-inheritedWindowData ? dynamic_castGraphicsWindowCocoa::WindowData*(traits-inheritedWindowData.get()) : NULL; I tried expanding it into if statements and the traits-inheritedWindowData returns true. I also tried copying and pasting this line into my file where I create my traits object and it returns properly. Any ideas? Cheers, Sean -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45082#45082 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render osgViewer::View main camera view solely to texture using FBO
Hi Tim, Thanks for the suggestion. I'll definitely take a look at it. I saw your response in another thread about RTT and was going to PM you before I saw you respond here. From reading the OpenGL specification, FBOs can't be shared between graphics contexts, so it doesn't look like I have an option, anyway. After making this change, everything looks as expected. I was just hesitant to attach a graphics context I didn't intend to draw to to the secondary view only to be used for RTT, but as its main camera is set to render to texture via FBO only, I suppose this isn't a problem. Is there anything wrong with this implementation? Thanks, Adam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45083#45083 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi, Paul, As Tim pointed out earlier, the more limiting resource is likely to be lock contention in the NVidia driver instead of bus contention. Note that Bb is going to be 4000 MB/sec (500 MB/sec * 8), per Quadroplex (PCI-e 2.0 8x) on the NIST machine. On my system I have an X58 chipset, so it's even wider (500 MB/sec * 16) per card. Also, the NIST machine's FSB is limited to 1.6 GT/sec, which is less than the 5 GT/sec that PCI-e provides. Given that the data is static (we're not transferring any vertex data over the bus, just making glDrawElements calls to VBOs in STATIC_DRAW mode), I doubt that the OpenGL command stream is going to be getting anywhere near the actual bus bandwidth. On 01/27/2012 09:17 AM, Paul Martz wrote: Hi Jason -- I agree that the system bus is a likely source of the scaling issue. It is certainly a single resource that has to be shared by all the GPUs in the system. To make a case for bus bandwidth limitation, you might work through the math. Bb FPS = Nw * Nd * Sd + O Where Bb is the bus bandwidth in bytes, Nw is the number of windows you're rendering to, Nd is the number of drawing commands, Sd is the size of the drawing commands in bytes, and O is the per frame OpenGL command overhead in bytes. The knowns: Bb = 500 MB/sec (PCIe 2.0) Nw = 4 Nd = 5500 Sd is a little harder to compute. It'll depend on the draw technology you're using (buffer objects or display lists) and the underlying OpenGL implementation. You could make a very rough guess here by figuring a fullword per OpenGL command, and a fullword per OpenGL command parameter. Just for the same of example, let's says Sd = 64 (16 fullwords to draw a single osg::Geometry). O encompasses all the per-frame OpenGL commands that OSG emits: glClear, glClearColor, glClearMask, dlDepthMask, matrices, light sources, swap, etc. You could plug in a rough guess like you would for Sd. Again, just as an example, let's use O = 2048. Plugging all that into a calculator, I get FPS = 371. But if Nw dropped to a single window, then FPS would jump to over 1400 -- or, more likely, you'd become limited by some other single resource in the system. The nice thing about algebra is that you can solve for the unknown, so of course you have the FPS, and if you have a pretty good guess for O (which can actually be pretty sloppy anyhow), then you ought to be able to solve for Sd and ask yourself if that result makes sense. I hope this helps. -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] Request for input
Sorry, I was going off your post that read This leads me to believe that bus contention was causing the lack of scalability. I was just trying to outline a way to validate that suspicion. If you've already ruled out bus contention, then disregard my post. -Paul On 1/27/2012 11:40 AM, Jason Daly wrote: Hi, Paul, As Tim pointed out earlier, the more limiting resource is likely to be lock contention in the NVidia driver instead of bus contention. Note that Bb is going to be 4000 MB/sec (500 MB/sec * 8), per Quadroplex (PCI-e 2.0 8x) on the NIST machine. On my system I have an X58 chipset, so it's even wider (500 MB/sec * 16) per card. Also, the NIST machine's FSB is limited to 1.6 GT/sec, which is less than the 5 GT/sec that PCI-e provides. Given that the data is static (we're not transferring any vertex data over the bus, just making glDrawElements calls to VBOs in STATIC_DRAW mode), I doubt that the OpenGL command stream is going to be getting anywhere near the actual bus bandwidth. On 01/27/2012 09:17 AM, Paul Martz wrote: Hi Jason -- I agree that the system bus is a likely source of the scaling issue. It is certainly a single resource that has to be shared by all the GPUs in the system. To make a case for bus bandwidth limitation, you might work through the math. Bb FPS = Nw * Nd * Sd + O Where Bb is the bus bandwidth in bytes, Nw is the number of windows you're rendering to, Nd is the number of drawing commands, Sd is the size of the drawing commands in bytes, and O is the per frame OpenGL command overhead in bytes. The knowns: Bb = 500 MB/sec (PCIe 2.0) Nw = 4 Nd = 5500 Sd is a little harder to compute. It'll depend on the draw technology you're using (buffer objects or display lists) and the underlying OpenGL implementation. You could make a very rough guess here by figuring a fullword per OpenGL command, and a fullword per OpenGL command parameter. Just for the same of example, let's says Sd = 64 (16 fullwords to draw a single osg::Geometry). O encompasses all the per-frame OpenGL commands that OSG emits: glClear, glClearColor, glClearMask, dlDepthMask, matrices, light sources, swap, etc. You could plug in a rough guess like you would for Sd. Again, just as an example, let's use O = 2048. Plugging all that into a calculator, I get FPS = 371. But if Nw dropped to a single window, then FPS would jump to over 1400 -- or, more likely, you'd become limited by some other single resource in the system. The nice thing about algebra is that you can solve for the unknown, so of course you have the FPS, and if you have a pretty good guess for O (which can actually be pretty sloppy anyhow), then you ought to be able to solve for Sd and ask yourself if that result makes sense. I hope this helps. -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 -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Need help fixing my atmospheric transmission shader, it's so close to working!
My scene contains virtualplanetbuilder-generated terrain that has a texture
wrapped on it along with surface objects such as trees that I generated by
creating osg primitives and coloring them PER_VERTEX without using any
textures.
I have written an atmospheric transmission shader that decreases the r,g and b
values as a function of distance from the viewer to the object. However, I
can't seem to get the shader to work properly on both the terrain and trees at
the same time. Here is the code:
Vertex Shader:
Code:
varying float eyeDistance;
void main(void)
{
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_FrontColor = gl_Color;
eyeDistance = length(gl_ModelViewMatrix * gl_Vertex);
gl_Position = ftransform();
}
Fragment Shader:
Code:
uniform float ExtinctionCoefficient;
uniform sampler2D baseTexture;
varying float eyeDistance;
void main(void)
{
vec4 color = texture2D(baseTexture, gl_TexCoord[0].st);
color.r = color.r * exp( -1.0 * ExtinctionCoefficient * eyeDistance );
color.g = color.r;
color.b = color.r;
gl_FragColor = color;
}
The above shader pair will successfully make the terrain darker in color as I
zoom out, but the trees all look completely black no matter what, even if they
originally had varying colors without the shader.
If instead of setting color in the frag shader to texture2D() I instead set
it equal to gl_Color, the shader then works on all the objects in the scene
but I no longer see any remnants of the underlying terrain texture. Based on
this page
http://stackoverflow.com/questions/2552676/change-the-color-of-a-vertex-in-a-vertex-shader
I would have expected that setting color = texture2D(baseTexture,
gl_TexCoord[0].st) * gl_Color would have produced the result I was looking for,
but instead the result is identical to if I leave out * gl_Color.
I think my shader code is very close to being correct and just needs a nudge in
the right direction. Anyone?
Thanks very much in advance.
-Ethan
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=45086#45086
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/27/2012 02:12 PM, Paul Martz wrote: Sorry, I was going off your post that read This leads me to believe that bus contention was causing the lack of scalability. I was just trying to outline a way to validate that suspicion. If you've already ruled out bus contention, then disregard my post. Hi, Paul, I'm not dismissing your post at all. It's certainly worth thinking about the overall bandwidth, and how much of it might be consumed by the GL command stream. I like your equation as a general guideline. One just has to keep in mind that 500MB/sec is the bandwidth for a single PCI-e 2.0 lane. Most graphics cards get 8 lanes, if not 16, and that's per card. You also have to account for the CPU interconnect bandwidth, which may put an upper limit on how much data you can transfer with multiple cards (theoretically 12.8GB/s on this hardware). In this particular case, I think Tim is right. There's not enough data in the command stream to get near the bus bandwidth. In this case, there are two 8x PCI-e cards (total of 8GB/s bandwidth) feeding 4 GPU's (two QuadroPlex D2 units). Using your figures: 2 * 8 * 500 MB/s - = 5648 Hz 4 * ( (5500 * 64 B) + 2048 B) So, unless I'm missing something, the problem must be elsewhere :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindowCocoa::WindowData dynamic_cast returns 0
Sean,
Don't know conclusively, but I have had problems like this in the past when
using dynamic_cast on a polymorphic object and it failed to give a non-NULL
value even when I knew it should. As you said, using a static_cast or C-style
cast works. In my case it had to do with how objects were defined in different
compilation units. What worked for me was specifying the following linker flag
to ensure that everybody had the same RTTI data.
set(CMAKE_SHARED_LINKER_FLAGS ${CMAKE_SHARED_LINKER_FLAGS}
-Wl,-flat_namespace)
This link gives a more detailed description of the problem.
http://lists.apple.com/archives/xcode-users/2006/Feb/msg00234.html
The link only talks about passing the RTLD_GLOBAL flag to dlopen, but in my
case I needed to use the -flat_namespace flag. My particular case happened
from linking certain libraries statically causing multiple (different) copies
of the same object to be generated. Putting them all in a flat namespace made
them resolve the same, fixing my dynamic_cast problem.
So, not a conclusive answer, but at least it gives you something to investigate.
Hope that helps,
Chuck
On Jan 27, 2012, at 10:11 AM, Sean Sullivan wrote:
Hey guys,
I'm trying to pass an osgViewer::GraphicsWindowCocoa::WindowData to my traits
object with CreateOnlyView specified. For some reason whenever my WindowData
is dynamic_cast in GraphicsWindowCocoa.mm it just returns 0. If I switch them
to static_cast they work.
Here's my code:
Code:
// OSGWindow.h
osgViewer::GraphicsWindowCocoa::WindowData* windowData;
// OSGWindow.cpp
windowData = new osgViewer::GraphicsWindowCocoa::WindowData
(osgViewer::GraphicsWindowCocoa::WindowData::CreateOnlyView);
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits();
traits-x = 100;
traits-y = 100;
traits-width = 1280;
traits-height = 720;
traits-red = 8;
traits-blue = 8;
traits-green = 8;
traits-alpha = 8;
traits-depth = 24;
traits-windowDecoration = false;
traits-doubleBuffer = true;
traits-vsync = false;
traits-stencil = 1;
traits-samples = 8;
traits-sampleBuffers = 1;
traits-inheritedWindowData = windowData;
osg::ref_ptrosg::GraphicsContext context =
osg::GraphicsContext::createGraphicsContext (traits.get());
This is what's in GraphicsWindowCocoa.mm that returns 0:
Code:
GraphicsWindowCocoa::WindowData* windowData = traits-inheritedWindowData ?
dynamic_castGraphicsWindowCocoa::WindowData*(traits-inheritedWindowData.get())
: NULL;
I tried expanding it into if statements and the traits-inheritedWindowData
returns true. I also tried copying and pasting this line into my file where I
create my traits object and it returns properly.
Any ideas?
Cheers,
Sean
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=45082#45082
___
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] Request for input
Hi All, I haven't chipped in so far as I haven't really too much to add to the investigation. My sense from own tests and looking at others over the years is that looks to be contention in the drivers that leads to poor scaling. Reducing the amount of data and commands being pushed in each context's OpenGL fifio does seem to help avoid the contention, but doesn't seem to be able to remove it entirely. Curiously running separate contexts via separate applications has in the past shown good scalability so I suspect the driver contention is something per application specific. Along these lines I do wonder if running separate processes for each context rather than separate threads might help avoid the contention. Unfortunately the OSG's osgViewer design is based around the lightweight data sharing that threading provides over use of separate processes, and OpenThreads is geared up for creation and management of threads rather than processes. Perhaps one test one could do is create multiple processes at a very high level in the application and then run a separate scene graph and viewer within each of these processes. It wouldn't scale well in terms of CPU performance as the cache coherency would be rather shot to shreds, but it might just get around the driver contention. If we can confirm a driver contention that rapping at NVidia and AMD's door would be the appropriate thing to do. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hello Jason, On Jan 27, 2012, at 1:37 PM, Jason Daly wrote: On 01/27/2012 02:12 PM, Paul Martz wrote: Sorry, I was going off your post that read This leads me to believe that bus contention was causing the lack of scalability. I was just trying to outline a way to validate that suspicion. If you've already ruled out bus contention, then disregard my post. Hi, Paul, I'm not dismissing your post at all. It's certainly worth thinking about the overall bandwidth, and how much of it might be consumed by the GL command stream. I like your equation as a general guideline. One just has to keep in mind that 500MB/sec is the bandwidth for a single PCI-e 2.0 lane. Most graphics cards get 8 lanes, if not 16, and that's per card. You also have to account for the CPU interconnect bandwidth, which may put an upper limit on how much data you can transfer with multiple cards (theoretically 12.8GB/s on this hardware). In this particular case, I think Tim is right. There's not enough data in the command stream to get near the bus bandwidth. In this case, there are two 8x PCI-e cards (total of 8GB/s bandwidth) feeding 4 GPU's (two QuadroPlex D2 units). Using your figures: 2 * 8 * 500 MB/s - = 5648 Hz 4 * ( (5500 * 64 B) + 2048 B) So, unless I'm missing something, the problem must be elsewhere :-) We run a very similar system with 5 quadro cards and do not run into these problems with very large models. We are using VR Juggler though. I mention this because it would be very straight forward to use one of the sample OGL VR Juggler examples as a test application that would load an OBJ file or something to provide a raw OGL benchmark for the hardware. You could also use one of the sample OSG applications to do a comparison to at least provide a place to start working from in terms of figuring out your core issues. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/27/2012 04:17 PM, Doug McCorkle wrote: We run a very similar system with 5 quadro cards and do not run into these problems with very large models. We are using VR Juggler though. I mention this because it would be very straight forward to use one of the sample OGL VR Juggler examples as a test application that would load an OBJ file or something to provide a raw OGL benchmark for the hardware. You could also use one of the sample OSG applications to do a comparison to at least provide a place to start working from in terms of figuring out your core issues. Hi, Doug, It may not have been easy to find in the mountain of text from the original post, but I did end up writing a multithreaded pure OpenGL program in an effort to eliminate OSG as the culprit. Since we ultimately ended up getting a similar frame rate drop in both OSG and OpenGL, we pretty much have eliminated OSG as the culprit. One of the issues that I ran into in my investigation was that the problem was closely tied to the structure of the data itself. My original OpenGL program only loaded .obj files at first. However, the process of converting the original .ive file to .obj disturbed the structure of the data, and caused the OpenGL program to behave differently. Unless I can load the exact data structure that OSG is loading into the VR Juggler example, I'm afraid I'd run into the same problem. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On Jan 27, 2012, at 4:12 PM, Jason Daly wrote: On 01/27/2012 04:17 PM, Doug McCorkle wrote: We run a very similar system with 5 quadro cards and do not run into these problems with very large models. We are using VR Juggler though. I mention this because it would be very straight forward to use one of the sample OGL VR Juggler examples as a test application that would load an OBJ file or something to provide a raw OGL benchmark for the hardware. You could also use one of the sample OSG applications to do a comparison to at least provide a place to start working from in terms of figuring out your core issues. Hi, Doug, It may not have been easy to find in the mountain of text from the original post, but I did end up writing a multithreaded pure OpenGL program in an effort to eliminate OSG as the culprit. Since we ultimately ended up getting a similar frame rate drop in both OSG and OpenGL, Interesting. I did not catch that comment in your earlier posts. I will need to go back and read those posts more carefully to look at the data structure issues you are referring to. we pretty much have eliminated OSG as the culprit. This is an interesting problem. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
