Re: [osg-users] osgUtil::Optimizer and osgSim::DOFTransform with data variance STATIC
On Monday 27 Feb 2012 19:49:53 Jean-Sébastien Guay wrote: Hi Magnus, But maybe this question is more to the authors of osgmaxexporter. Why does osgmaxexporter unconditionally set the data variance to STATIC? What are the use cases where one would model a STATIC DOFTransform? DOFTransforms are a relic of Multigen (Presagis) Creator, and in that software they were the most widely used transform node. Modelers (as you probably know) are fond of putting lots of transforms (and groups) all over the scene graph, to keep things understandable to them, and to make it easier to modify the model later. Unfortunately, there are often many of these transforms that aren't really useful once the models are in the simulation software. So yes, there is a valid use case for static DOFTransforms - transforms that were just put there by the modeler for convenience, but which don't have any use in simulation. Now, I agree with you, the STATIC data variance should not be unconditionally applied. There can be rules to determine when it should be, for example if the DOFTransform does not have any limits. At my previous employer, we had made a custom osgconv which would massage the scene graph before calling the osgUtil::Optimizer on it (I think I mentioned this before on this list). This massage is highly dependent on what you'll be doing with your data, which is why I don't think it would be useful to submit such a thing - OSG provides the tools for you to do the right thing in your situation. But just as an example, our tool would: * Normalize state to expected values (we didn't require artists to set the right filtering or face culling manually, we enforced it in the tools, so that osgUtil::Optimizer's various merge operations could give good results) * Flag nodes as dynamic if we didn't want them optimized away (we had various rules, including if a comment contained Dynamic, if a DOF had limits, etc. * Remove most Group nodes since these just hinder the merge visitors and in most cases, better batching (less draw calls) is more important than better spatial culling. Again, I've talked about these things in the past, and others have shared similar or related advice too. Hope this helps, J-S Thanks, Jean-Sebastien, for your detailed explanation. You've effectively confirmed what I suspected. In our workflow, where DOFTransforms are only occasionally used for a very specific purpose they should never be marked STATIC in the first place. I believe that this is true for all workflows where DOFTransforms are being added through the osgmaxexporter. There they require a conscious decision of the modeller to add them to the scene through a special osgmaxexporter helper object. And as modellers don't really like to use functionality that is not native to their tool until they absolutely have no other choice an accidental use is rather improbable. I'll patch osgmaxexporter and take it from there. Thanks everyone for their contributions on this thread. Magnus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] A few questions on GraphicsWindowEmbedded
Hiya, I was able to display osg content on Qt's Declarative interface (QtQuick, QML, etc) using the osg::GraphicsWindowEmbedded class. I followed the examples for the FLTK and GLUT toolkits to get this (sort of) working. There are a few of things I don't understand, and would appreciate some clarification on. * What do the parameters passed to the osgViewer::GraphicsWindowEmbedded constructor (x,y,w,h) actually do? I played around with the values and it had no visible effect on my displayed result * What does GraphicsWindowEmbedded do behind the scenes? Since you don't explicitly specify a GraphicsContext for it, does that mean it uses the OpenGL context of the framework you're embedding it into? * I noticed that the viewport is rendered onto the window in absolute coordinates. With QtQuick, when you create an item to display on the screen, it has a child/parent relationship and coordinates are relative to the parent. Moving the parent will also move the child as you'd expect. This doesn't happen with GraphicsWindowEmbedded though, probably because with QtQuick, all the elements are painted onto one 'canvas' (I think), and GraphicsWindowEmbedded just paints straight onto that. * If, instead of having GraphicsWindowEmbedded draw on my screen whenever I call the viewer's frame() method, is it possible to render the viewer camera's output to a texture that I could manually draw onto a quad or something? This way I don't have to specify absolute coordinates for the viewport like I mentioned above. I already tried this by rendering to an osg::Image, then painting it on the screen with Qt, but I have a relatively old computer and osg::Image-readPixels() takes too much time. My results with the osgscreencapture example were also pretty terrible (15-16 fps @ 640x480). For anyone else who needs to do something similar, here's some scrap code you can use to define a QDeclarativeItem that'll show an osg view. http://pastie.org/3478592 (header) http://pastie.org/3478602 (source) Regards, Preet ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgCompute] Computation on a rendered texture quad
Hi, I got it working, thanks. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45821#45821 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A few questions on GraphicsWindowEmbedded
Hi Preet, On 28 February 2012 09:16, Preet prismatic.proj...@gmail.com wrote: * What do the parameters passed to the osgViewer::GraphicsWindowEmbedded constructor (x,y,w,h) actually do? I played around with the values and it had no visible effect on my displayed result They tell the GraphicsWidnowEmedded object where about the window it's representing is in desktop coordinates. * What does GraphicsWindowEmbedded do behind the scenes? Since you don't explicitly specify a GraphicsContext for it, does that mean it uses the OpenGL context of the framework you're embedding it into? GraphicsWindowEmbedded actually does nothing behind the scenes at all - it's a non op class designed to make it possible to reuse the osgViewer::Viewer and CompositeViewer classes in places that already provide the graphics context and are strictly single threaded and have a single window. It's really tricking these classes that a designed to work with multi-threading and multi-context capable systems where makeCurrent() and swapBuffers() implementations are accessible to work without doing this operations so when calls to makeCurrent() and swapBuffers() are made by the viewer classes nothing happens. Since nothing happens it's entirely up to the calling app to do it for the viewer because it can't do itself. Since GraphicsWindowEmbedded is design to avoid properly implementing the key context management functions on the OSG or a subclass side it does restrict how you can use the viewer classes. It's very much a crude approach to provide viewer functionality, easy to get working yes, fully capable no. You can't add the full capabilities back in when using GraphicsWindowEmbedded, if you don't need multi-threading or multi-context this will be fine, but if you do look elsewhere. Actually implementing a GraphicsWindow properly is the most powerful way to adapt 3rd party graphics contexts with the osgViewer, and this is done by the osgQt::GraphicsWindowQt class, as was as the GraphicsWindowX11, Win32, Cocoa and Carbon implementations found natively in osgViewer. * I noticed that the viewport is rendered onto the window in absolute coordinates. With QtQuick, when you create an item to display on the screen, it has a child/parent relationship and coordinates are relative to the parent. Moving the parent will also move the child as you'd expect. This doesn't happen with GraphicsWindowEmbedded though, probably because with QtQuick, all the elements are painted onto one 'canvas' (I think), and GraphicsWindowEmbedded just paints straight onto that. I know absolutely nothing about QtQuick or how you've implemented the integration with GraphicsWindowEmbedded so I can't say anything about this. * If, instead of having GraphicsWindowEmbedded draw on my screen whenever I call the viewer's frame() method, is it possible to render the viewer camera's output to a texture that I could manually draw onto a quad or something? This way I don't have to specify absolute coordinates for the viewport like I mentioned above. I already tried this by rendering to an osg::Image, then painting it on the screen with Qt, but I have a relatively old computer and osg::Image-readPixels() takes too much time. My results with the osgscreencapture example were also pretty terrible (15-16 fps @ 640x480). If you want to do off screen rendering then this is very different thing, GraphicsWindowEmedded is not the best thing to do this, what you'll want is a pbuffer, osgViewer provides this. I really don't have a clue what you are trying to achieve in the end with your application, or why you are attempting to use QtQuick. Might I suggest to explain to the community what type of application you are trying to develop, what platforms you are targeting and then let others suggest to you which route would be best rather than picking a non standard solution without actually saying why you've done this. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Slow rendering with displaylist.
Hello,
I am surprised about my little test program. I would like compare displaylists
with frame buffer objects. Because, I suppose that the displaylists have to be
faster than the vbo, because the displaylists are precompiled. But in my
example I get another result:
VBO: 225 FPS
DL: 88 FPS
Is that possible?
Following a part of my code:
// Geometry (Grid-Plane)
::osg::Geometry* geom = new osg::Geometry;
// Vertex Array (Grid with 1000 x 1000 quads)
::osg::ref_ptr ::osg::Vec3Array v = new ::osg::Vec3Array();
for(unsigned int x=0; x 1000; x++)
{
for(unsigned int y=0; y 1000; y++)
{
// create points
}
}
geom-setVertexArray(v);
#ifdef ENABLE_VBO
// Vertex Buffer Object
osg::VertexBufferObject* vbo = geom-getOrCreateVertexBufferObject();
vbo-setArray(0,v);
vbo-setUsage(GL_STATIC_DRAW);
geom-setUseVertexBufferObjects(true);
geom-setSupportsDisplayList(false);
geom-setUseDisplayList(false);
#else
geom-setSupportsDisplayList(true);
geom-setUseDisplayList(true);
#endif
// Primitive
::osg::DrawArrays* da = new
::osg::DrawArrays(::osg::PrimitiveSet::QUADS,0,v-size());
geom-addPrimitiveSet(da);
// Geometry Node
::osg::Geode* geode = new osg::Geode;
geode-addDrawable(geom);
Thanks
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
Re: [osg-users] Slow rendering with displaylist.
Hi Martin, I am surprised about my little test program. I would like compare displaylists with frame buffer objects. Because, I suppose that the displaylists have to be faster than the vbo, because the displaylists are precompiled. But in my example I get another result: I think what you're testing is the performance difference between vertex data on system memory and vertex data on graphics card memory. It doesn't makes that much sense to compare displaylists with fbos, because displaylists are about opengl commands and fbos about opengl data. Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin 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] Slow rendering with displaylist.
Hi, On Tuesday 28 February 2012, Martin Großer wrote: I am surprised about my little test program. I would like compare displaylists with frame buffer objects. Because, I suppose that the displaylists have to be faster than the vbo, because the displaylists are precompiled. But in my example I get another result: VBO: 225 FPS DL: 88 FPS Is that possible? Yes, that's possible. Plenty aspects of this: * GPUs just work in terms of vbos. That means when you program a gpu, you will set up some memory regions for different purposes. Including the vertex program inputs. You need a base pointer, some data types, stride etc... Then you set up some more memory for the fragment processors samplers tell the hardware the base pointer, the data types, strides, dimensions and whatnot. Then tell the setup unit that you want to draw some triangles using these arrays. This *is* basically what you do when you do buffer object draws. * DLists are implemented using vbos anyway. Thinking about how a gpu works in its own. Compiling just could mean to setup a set of vbo arrays and fire the draw on this. Dlist only provide a little more overhead in the sense that you can have degenerated display lists like dliststartglBegin(); glVertex()dlistend. This list could be combined with one just providing more vertices and containing a terminating glEnd. Which shows pretty fast that dlist handling can get pretty complicated in all its corner cases that are spect in old OpenGL standards valid and backward compatible up to today. * Dlists are deprecated. So driver writers assume since some time that the more optimized fast path should be the vbo/drawarray path. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin 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] Slow rendering with displaylist.
Hello Daniel, That is basically true. I want to get a feeling about DisplayLists and VBOs. I know that the display list is a precompiled sequence of OpenGL commands. That is the reason that I tought the display lists should be faster. But the question isn't the comparison, but the slow render performance when I want to use display lists. I think everything is wrong in my implementation. But I don't know what. Cheers Martin Original-Nachricht Datum: Tue, 28 Feb 2012 11:37:36 +0100 Von: Daniel Trstenjak daniel.trsten...@science-computing.de An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] Slow rendering with displaylist. Hi Martin, I am surprised about my little test program. I would like compare displaylists with frame buffer objects. Because, I suppose that the displaylists have to be faster than the vbo, because the displaylists are precompiled. But in my example I get another result: I think what you're testing is the performance difference between vertex data on system memory and vertex data on graphics card memory. It doesn't makes that much sense to compare displaylists with fbos, because displaylists are about opengl commands and fbos about opengl data. Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin 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 -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slow rendering with displaylist.
Hi Martin, That is basically true. I want to get a feeling about DisplayLists and VBOs. I know that the display list is a precompiled sequence of OpenGL commands. That is the reason that I tought the display lists should be faster. But the question isn't the comparison, but the slow render performance when I want to use display lists. I think everything is wrong in my implementation. But I don't know what. My point about system/graphics card memory is wrong. I thought about glVertexPointer, but this call isn't even compiled into a display list and shouldn't be used with one. So OSG will most likely use glBegin/glEnd to put the vertex data into the display list. It boils down to what Mathias ;) said, it's an implementation issue, dirty corner cases and driver developers don't optimize the display lists anymore, because they're deprecated and just not used that much anymore. Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin 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] Slow rendering with displaylist.
Hello, thanks to you, it was very helpful. Now I will only use VBOs. Greetings, Martin Original-Nachricht Datum: Tue, 28 Feb 2012 12:44:15 +0100 Von: Daniel Trstenjak daniel.trsten...@science-computing.de An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] Slow rendering with displaylist. Hi Martin, That is basically true. I want to get a feeling about DisplayLists and VBOs. I know that the display list is a precompiled sequence of OpenGL commands. That is the reason that I tought the display lists should be faster. But the question isn't the comparison, but the slow render performance when I want to use display lists. I think everything is wrong in my implementation. But I don't know what. My point about system/graphics card memory is wrong. I thought about glVertexPointer, but this call isn't even compiled into a display list and shouldn't be used with one. So OSG will most likely use glBegin/glEnd to put the vertex data into the display list. It boils down to what Mathias ;) said, it's an implementation issue, dirty corner cases and driver developers don't optimize the display lists anymore, because they're deprecated and just not used that much anymore. Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin 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 -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Scene as Texture
Hello Osg-Users, I want, at a specific time, capture the screen (of my osgViewer) and use it as a texture for a quad. What would be the best way to achieve this? Is there already an example for this? Thanks for the advice in advance. Hartmut -- frag nicht - du könntest eine antwort erhalten 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
Re: [osg-users] Slow rendering with displaylist.
Hi Martin, Be aware that for some combinaison of driver/hardware, VBO just don't work properly. I've encoutered the case on some Intel/ATI chipsets. A simple terrain created with VPB couldn't be loaded. With VBO OFF, everything was OK. Be also aware that if you use small geometries, there is a high overhead with VBO at initialization. It could be a good idea to make VBO you default implementation, but don't forget to have fallbacks when things will go wrong (especially if you have no control over target hardware) http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2011-July/052968.html http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-August/015543.html Luc De : Martin Großer grosser.mar...@gmx.de A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 28/02/2012 13:01 Objet : Re: [osg-users] Slow rendering with displaylist. Envoyé par : osg-users-boun...@lists.openscenegraph.org Hello, thanks to you, it was very helpful. Now I will only use VBOs. Greetings, Martin Original-Nachricht Datum: Tue, 28 Feb 2012 12:44:15 +0100 Von: Daniel Trstenjak daniel.trsten...@science-computing.de An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] Slow rendering with displaylist. Hi Martin, That is basically true. I want to get a feeling about DisplayLists and VBOs. I know that the display list is a precompiled sequence of OpenGL commands. That is the reason that I tought the display lists should be faster. But the question isn't the comparison, but the slow render performance when I want to use display lists. I think everything is wrong in my implementation. But I don't know what. My point about system/graphics card memory is wrong. I thought about glVertexPointer, but this call isn't even compiled into a display list and shouldn't be used with one. So OSG will most likely use glBegin/glEnd to put the vertex data into the display list. It boils down to what Mathias ;) said, it's an implementation issue, dirty corner cases and driver developers don't optimize the display lists anymore, because they're deprecated and just not used that much anymore. Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin 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 -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ 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] Slow rendering with displaylist.
Also be aware that on some architectures display lists are just plain faster for static geometry in many cases. I've certainly seen that on NVIDIA. Glenn Waldron / @glennwaldron On Tue, Feb 28, 2012 at 8:29 AM, Luc Frauciel luc.frauc...@star-apic.comwrote: Hi Martin, Be aware that for some combinaison of driver/hardware, VBO just don't work properly. I've encoutered the case on some Intel/ATI chipsets. A simple terrain created with VPB couldn't be loaded. With VBO OFF, everything was OK. Be also aware that if you use small geometries, there is a high overhead with VBO at initialization. It could be a good idea to make VBO you default implementation, but don't forget to have fallbacks when things will go wrong (especially if you have no control over target hardware) http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2011-July/052968.html http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-August/015543.html Luc De :Martin Großer grosser.mar...@gmx.deA :OpenSceneGraph Users osg-users@lists.openscenegraph.orgDate:28/02/2012 13:01Objet :Re: [osg-users] Slow rendering with displaylist.Envoyé par : osg-users-boun...@lists.openscenegraph.org -- Hello, thanks to you, it was very helpful. Now I will only use VBOs. Greetings, Martin Original-Nachricht Datum: Tue, 28 Feb 2012 12:44:15 +0100 Von: Daniel Trstenjak daniel.trsten...@science-computing.de An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] Slow rendering with displaylist. Hi Martin, That is basically true. I want to get a feeling about DisplayLists and VBOs. I know that the display list is a precompiled sequence of OpenGL commands. That is the reason that I tought the display lists should be faster. But the question isn't the comparison, but the slow render performance when I want to use display lists. I think everything is wrong in my implementation. But I don't know what. My point about system/graphics card memory is wrong. I thought about glVertexPointer, but this call isn't even compiled into a display list and shouldn't be used with one. So OSG will most likely use glBegin/glEnd to put the vertex data into the display list. It boils down to what Mathias ;) said, it's an implementation issue, dirty corner cases and driver developers don't optimize the display lists anymore, because they're deprecated and just not used that much anymore. Greetings, Daniel -- Daniel Trstenjak Tel : +49 (0)7071-9457-264 science + computing ag FAX : +49 (0)7071-9457-511 Hagellocher Weg 73 mailto: daniel.trsten...@science-computing.de D-72070 Tübingen WWW : http://www.science-computing.de/ -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin 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 -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a ___ 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] Testing of OpenSceneGraph svn/trunk in prep for 3.1 dev release
Hi All, I have now checked in the last build and runtime fixes that should be required for the 3.1.0 dev release, but will await for some more community testing before tagging the release. So please, svn update again and let me know how you get on. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Windows Touch Support
Hi *, I submitted a patch to enable MultiTouch Support for Windows 7 and above. A first patch featured a CMAKE Variable WIN32_MUTITOUCH controlling support for Multitouch on Windows. Furthermore: * It depends on a recent SDK (Which is part of Visual Studio 2010, but not by default part of VS 2008). * It updated the WIN_VER Variable to use the WIN7 API, iff WIN32_MUTITOUCH is enabled * It did call Win7 (Vista and upwards?) specific API's, breaking OSG on for instance Win XP. Robert rejected it because of these shortcomings and proposed to discuss other ways to use this API on osg-users. I now propose a different patch: * It should now work with all Visual Studio Versions. * WIN_VER is left as-is * I added the missing declarations from a recent SDK, if not supplied by the SDK * If someone chooses to update WIN_VER, the declarations should not break. * All API Calls are runtime detected. * No CMake Variable, Support is enabled automatically . What do you think? Please find attached a zip of the changed GraphicsWindowWin32.cpp as of SVN trunk of yesterday. Greetings, Olaf BTW: Maybe there is a transformation of coordinates of touchpoints missing... multitouch.tgz Description: application/compressed-tar ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPPU] Perfomance issues with PBO for input textures
Hi, I'm new to osgPPU and OSG in general, so please bear with me :) I'm trying to use the built-in mechanism in osgPPU::Unit for copying the rendered textures to the CPU. I'm using a simple tester based on one of the osgPPU, and my initialization code is structured like this: Code: // Somewhere in the middle of the Processor graph: osgPPU::Unit* pUnit = new osgPPU::UnitInOut(); pUnit-setUsePBOForInputTexture(0, true); parentUnit-addChild(pUnit); With this code the frame rate drops significantlly, from 60 to 10-30 (dependning on the viewport size). If I comment out the glGetTexImage call inside Unit.cpp, everything works as before (but nothing gets copied, of course). Considering I don't mind getting the texture with a delay of a few frames, is there any way to improve the performance of the current implementation? I must say I've read about PBO (http://www.songho.ca/opengl/gl_pbo.html), but I'm not sure whether this is the correct approach here, or how to integrate it with the existing code base. Thanks, Shahar -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45844#45844 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] more than 1 object in the same viewer
Hi, I am wondering if i can load 2 object files and have them share the same scene or viewer as a whole object? i was thinking the same way as the geode work when you add a Drawable (addDrawable()) if it is possible? can someone can give me an exemple? much appreciated. Thank you! Cheers, Renato -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45845#45845 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] more than 1 object in the same viewer
Is there a reason why you can't use a Group node with two children? -Paul On 2/28/2012 8:24 AM, Renato Oliveira wrote: Hi, I am wondering if i can load 2 object files and have them share the same scene or viewer as a whole object? i was thinking the same way as the geode work when you add a Drawable (addDrawable()) if it is possible? can someone can give me an exemple? much appreciated. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] more than 1 object in the same viewer
i guess i really dont know how to use it. i very new to openscenegraph and i was just able to learn how to load a single obj file for 1 viewer only. i also saw that that i can split the viewer into views so that the objects can have diffrent cameras but my real goal is just to have shapes loaded that will be 1 whole object att the end. do you have any exemples or hints in how to use the grope with childrens? i have a root node and i add the loaded objects to it, but only the last object add will display. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45847#45847 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Scene as Texture
The osgprerender example shows how to setup a scene to render to a texture for use on a quad. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_TRANSFORM_FEEDBACK_BUFFER_NV in OSG
Hello Paul, In OpenGL I have to define the varying variables for the transform feedback between the compiling and linking of the shader program. glTransformFeedbackVaryings(programHandle, 1, varyings, GL_SEPARATE_ATTRIBS); How can I do this in OSG? Additinally I use osg 2.8.4 from the Fedora repository. Cheers, Martin Original-Nachricht Datum: Mon, 27 Feb 2012 09:51:15 -0700 Von: Paul Martz pma...@skew-matrix.com An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] GL_TRANSFORM_FEEDBACK_BUFFER_NV in OSG Yes, it's possible, but there are no examples that I know of. You might try binding a buffer object in a Camera pre-draw callback, for an example of one strategy. -Paul On 2/27/2012 8:21 AM, Martin Großer wrote: Hello, Is it possible to use GL_TRANSFORM_FEEDBACK_BUFFER_NV extension in osg? I would like write back my vertex position data into a new Vertex Buffer Object. Is there any example about this? Cheers Martin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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] GraphicsWindowQt keyReleaseEvent key value is always 0
Hi osg users,
I recently found something strange with osgQT, when a key release event is
added to the event queue the key value is always 0.
It seems to be related to the void GLWidget::keyReleaseEvent( QKeyEvent*
event ) function in the osgQT/GraphicsWindowQt.cpp file.
On key press the QKeyEvent is remaped to get the proper key value but not
in the key release event.
The code is :
void GLWidget::keyReleaseEvent( QKeyEvent* event )
{
setKeyboardModifiers( event );
_gw-getEventQueue()-keyRelease( (osgGA::GUIEventAdapter::KeySymbol)
*(event-text().toAscii().data()) );
// this passes the event to the regular Qt key event processing,
// among others, it closes popup windows on ESC and forwards the event
to the parent widgets
if( _forwardKeyEvents )
inherited::keyReleaseEvent( event );
}
But it should be :
void GLWidget::keyReleaseEvent( QKeyEvent* event )
{
setKeyboardModifiers( event );
int value = s_QtKeyboardMap.remapKey( event );
_gw-getEventQueue()-keyRelease( value );
// this passes the event to the regular Qt key event processing,
// among others, it closes popup windows on ESC and forwards the event
to the parent widgets
if( _forwardKeyEvents )
inherited::keyReleaseEvent( event );
}
I made the fix on my version of the file and it works great.
I'm using OSG 3.0.1 and QT 4.8.0.
Kind regards,
--
Alexandre AMALRIC Ingénieur RD
===
PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
http://www.pixxim.fr
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] more than 1 object in the same viewer
Got it working after setting the scales. but possitioning and scalling properly will be a challenge. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45851#45851 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_TRANSFORM_FEEDBACK_BUFFER_NV in OSG
Hi, Martin afaik, there is no way, you should use opengl calls to get it working 28.02.2012, 20:10, Martin Groer grosser.mar...@gmx.de: Hello Paul, In OpenGL I have to define the varying variables for the transform feedback between the compiling and linking of the shader program. glTransformFeedbackVaryings(programHandle, 1, varyings, GL_SEPARATE_ATTRIBS); How can I do this in OSG? Additinally I use osg 2.8.4 from the Fedora repository. Cheers, Martin Original-Nachricht Datum: Mon, 27 Feb 2012 09:51:15 -0700 Von: Paul Martz pma...@skew-matrix.com An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] GL_TRANSFORM_FEEDBACK_BUFFER_NV in OSG Yes, it's possible, but there are no examples that I know of. You might try binding a buffer object in a Camera pre-draw callback, for an example of one strategy. -Paul On 2/27/2012 8:21 AM, Martin Großer wrote: Hello, Is it possible to use GL_TRANSFORM_FEEDBACK_BUFFER_NV extension in osg? I would like write back my vertex position data into a new Vertex Buffer Object. Is there any example about this? Cheers Martin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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] GL_TRANSFORM_FEEDBACK_BUFFER_NV in OSG
On 2/28/2012 9:10 AM, Martin Großer wrote: Hello Paul, In OpenGL I have to define the varying variables for the transform feedback between the compiling and linking of the shader program. glTransformFeedbackVaryings(programHandle, 1, varyings, GL_SEPARATE_ATTRIBS); How can I do this in OSG? The same way. You can issue an OpenGL call any time you have a current context (Camera pre draw callback, Drawable draw callback, etc). A quick glance at the Program header file reveals that you can get the program ID with a call to: osg::Program::getPCP(contextID)-getHandle(); Additinally I use osg 2.8.4 from the Fedora repository. Cheers, Martin Original-Nachricht Datum: Mon, 27 Feb 2012 09:51:15 -0700 Von: Paul Martzpma...@skew-matrix.com An: OpenSceneGraph Usersosg-users@lists.openscenegraph.org Betreff: Re: [osg-users] GL_TRANSFORM_FEEDBACK_BUFFER_NV in OSG Yes, it's possible, but there are no examples that I know of. You might try binding a buffer object in a Camera pre-draw callback, for an example of one strategy. -Paul On 2/27/2012 8:21 AM, Martin Großer wrote: Hello, Is it possible to use GL_TRANSFORM_FEEDBACK_BUFFER_NV extension in osg? I would like write back my vertex position data into a new Vertex Buffer Object. Is there any example about this? Cheers Martin ___ 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] [osgPPU] Perfomance issues with PBO for input textures
Hi Shahar, I would say that this is expected behaviour. This is due to the case, that the texture has to be copied from the GPU memory to the CPU memory. With PBOs this should be done through DMA or somehow directly without involving CPU for this, however the PCIe bus is the bottleneck here. I In general, consider if you need to have the resulting texture on the CPU at all ;) Maybe you can comeup with shaders which do exactly this, what you would do on the CPU. Actually with PBOs you can have asynchronous texture transfer. Not sure about download from GPU, but surely for uploading to the GPU. However, I can imagine that whenever you download the texture in every frame, which is automatically doen by osgPPU, the execution might stall, while the download isn't complete yet. Hence, what you might try is to write a callback which will just switch on the PBO use every nth frame, if you don't need the output of osgPPU in every frame. It might be that this could solve the problem, since the texture can be downloaded asynchronously during the rendering of the n frames. I am not sure if this will work out, but you might try this. Cheers, art kshahar wrote: Hi, I'm new to osgPPU and OSG in general, so please bear with me :) I'm trying to use the built-in mechanism in osgPPU::Unit for copying the rendered textures to the CPU. I'm using a simple tester based on one of the osgPPU examples, and my initialization code is structured like this: Code: // Somewhere in the middle of the Processor graph: osgPPU::Unit* pUnit = new osgPPU::UnitInOut(); pUnit-setUsePBOForInputTexture(0, true); parentUnit-addChild(pUnit); With this code the frame rate drops significantlly, from 60 to 10-30 (dependning on the viewport size). If I comment out the glGetTexImage call inside Unit.cpp, everything works as before (but nothing gets copied, of course). Considering I don't mind getting the texture with a delay of a few frames, is there any way to improve the performance of the current implementation? I must say I've read about PBO (http://www.songho.ca/opengl/gl_pbo.html), but I'm not sure whether this is the correct approach here, or how to integrate it with the existing code base. Thanks, Shahar -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45854#45854 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [forum] About the camera direction of the AnimationPathManipulator.
In fact, I want to set the camera direction by setting the setHomePosition() function but seems useless. Thanks in advance. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45667#45667 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Culling time is extremely long
Hi, I use compositeViewer, (osg 2.8.1) and each view contains no more than small amount of vertices. However the culling time, showed by the Statshelper, can be more than 30. The tricky thing is it is inconsistent between runs. Sometimes the culling time is 5 ~ 6. Then after I rerun the program, it shoots up to more than 30 I have attached the file for initializing views, Looking for help. Thank you! Cheers, Suyang -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45769#45769 Attachments: http://forum.openscenegraph.org//files/rediculous_culling_180.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Terrain texture brush implementation
Hi, As OSG newbie, I'm working on a terrain texture brush task. My goal: Use mouse controlled brush paint grass area on a prebuild terrain(has original texture) Progress: Now I successfully complete a demo, but the method I use seems unattractive. My implementation now: (Use OverlayNode method) 1. Load prebuild terrain(T1) and it to scene. 2. Duplicate the terrain node(Terrain T2). 3. Change the texture of T2, make is full of grass texture. 4. Use T2 as OverlaySubgraph, T1 as child to OverlayNode, so now, in the scene, I can see a single terrain full of grass. 5. Set color of each vertex in T2, make it complete transparent. 6. handle my mouse brush area, calculate effected vertices of T2 in brush area, and raise the transparent value of those vertices. 7. now the brush area will gradually show grass texture. I did some search about the question, seems multi-texture is another way, but I didn't figure out how. As I need control blend on individual vertex(brush area), I only found functions to change the blend of whole texture units. Any tip of a smart way will be grateful :-) Thank you! CaoWenjie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45773#45773 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Culling time is extremely long
1) Are you running on Linux or Windows? 2) Are you running OSG debug or release optimized? 3) Are you running with the default cull settings? If you want helpful feedback, providing more info will provoke a better response from the community. I just see a screenshot of your stats. I don't see any file with initializing code... -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Suyang Dong Sent: Saturday, February 25, 2012 4:07 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Culling time is extremely long Hi, I use compositeViewer, (osg 2.8.1) and each view contains no more than small amount of vertices. However the culling time, showed by the Statshelper, can be more than 30. The tricky thing is it is inconsistent between runs. Sometimes the culling time is 5 ~ 6. Then after I rerun the program, it shoots up to more than 30 I have attached the file for initializing views, Looking for help. Thank you! Cheers, Suyang -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45769#45769 Attachments: http://forum.openscenegraph.org//files/rediculous_culling_180.jpg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Terrain texture brush implementation
On 02/26/2012 06:58 AM, Cao Wenjie wrote: Hi, As OSG newbie, I'm working on a terrain texture brush task. My goal: Use mouse controlled brush paint grass area on a prebuild terrain(has original texture) Progress: Now I successfully complete a demo, but the method I use seems unattractive. My implementation now: (Use OverlayNode method) 1. Load prebuild terrain(T1) and it to scene. 2. Duplicate the terrain node(Terrain T2). 3. Change the texture of T2, make is full of grass texture. 4. Use T2 as OverlaySubgraph, T1 as child to OverlayNode, so now, in the scene, I can see a single terrain full of grass. 5. Set color of each vertex in T2, make it complete transparent. 6. handle my mouse brush area, calculate effected vertices of T2 in brush area, and raise the transparent value of those vertices. 7. now the brush area will gradually show grass texture. I did some search about the question, seems multi-texture is another way, but I didn't figure out how. As I need control blend on individual vertex(brush area), I only found functions to change the blend of whole texture units. Any tip of a smart way will be grateful :-) Hi, CaoWenjie The Source engine (used by Half Life 2) uses a multitexturing technique to achieve what you're trying to do. I implemented a viewer for Source engine .bsp files a while back. If you look in src/osgPlugins/bsp/VBSPReader.cpp, starting around line 803, you'll see a way to do this using TexEnvCombine operations on two texture units. The first combiner (on texture unit 0) does the interpolation between the two textures. The second combiner (on unit 1) just does the normal modulation between the combined color from the first unit and the vertex color. In this case, the first combiner uses the Alpha value from the vertex color (SRC_ALPHA) to decide how much to blend between the two textures (that's Operand2 in the INTERPOLATE operation). In your case, you'd want to set Operand2 based on your brush value. Note that your graphics card needs to support the ARB_tex_env_crossbar extension for this to work (most modern cards do). Hope this is useful... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Is the ZIP plugin thread-safe?
After experiencing problems, a quick review indicates to me that the ZIP plugin is not thread safe. Has anyone had any experience in using it in a multi-threaded environment? Evidence: ZipArchive holds an HZIP handle that corresponds to an open ZIP file. This handle contains internal file pointers that can be modifed concurrently by multiple threads attempting to read from the ZIP at the same time (e.g., from the DatabasePager). Any insights into this before I attempt to fix it? Glenn Waldron / @glennwaldron ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is the ZIP plugin thread-safe?
Is the problem in the public domain Zip Utils code? I would only suggest looking for a more current version. I bet the code in OSG is pretty dated by now, and maybe someone has addressed this. -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is the ZIP plugin thread-safe?
No, it's that the OSG ZipArchive uses a single control structure that ends up getting shared across threads (and not in a good way). It is a pretty simple fix, I think. Glenn Waldron / @glennwaldron On Tue, Feb 28, 2012 at 3:21 PM, Terry Welsh mogu...@gmail.com wrote: Is the problem in the public domain Zip Utils code? I would only suggest looking for a more current version. I bet the code in OSG is pretty dated by now, and maybe someone has addressed this. -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com ___ 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] Culling time is extremely long
Hi Culling time is more about amount of nodes\drawables in scene and how they organized into graph, and less about vertices itself. You can try to run your model through osg optimizer with SPATIALIZE_GROUPS option. Also check if you use any cull callbacks with heavy running time. And if you have some nodes on which culling is disabled ( setCullingActive(false) ) deeply in graph structure, this can kill your performance too. Cheers. 26.02.2012, 03:07, Suyang Dong dongsuyang.f...@yahoo.com.cn: Hi, I use compositeViewer, (osg 2.8.1) and each view contains no more than small amount of vertices. However the culling time, showed by the Statshelper, can be more than 30. The tricky thing is it is inconsistent between runs. Sometimes the culling time is 5 ~ 6. Then after I rerun the program, it shoots up to more than 30 I have attached the file for initializing views, Looking for help. Thank you! Cheers, Suyang -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45769#45769 Attachments: http://forum.openscenegraph.org//files/rediculous_culling_180.jpg ___ 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] Not Loading External References
I am using osgDB::readNodeFile to load in some .flt files. What I am wondering is if there is some type of option that can have it not load the external references in the files. Right now I just send a NodeVisitor through to round up a list of all the ProxyNodes and then I run through that list and remove them from their parents. While this works, it is not ideal as I have to go through and actually load in of the references. I do not need the references themselves. Unfortunately editing the actual .flt files is not an option. If this is the best solution, so be it. Thanks. Karl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slow rendering with displaylist.
Hi
From my own experience, display lists runs with good speed when:
1) vertex number is at most like 100k, with huge vertices count per drawable
vbos tends to be faster
2) display lists works best with triangle strips \ indexed list
both display lists and vbos performance can greatly vary with different data
types in vertex attributes (f.e. ushort indices is generally faster then ubyte
and uint, texcoords\ vertex colors works best with float or ushort etc) and
vertex attributes count, in some combinations vbos faster, in others dls.
As a side note, you'd better use triangles instead of quads, as they can work
quite a bit slower than triangles
Cheers.
28.02.2012, 14:20, Martin Groer grosser.mar...@gmx.de:
Hello,
I am surprised about my little test program. I would like compare
displaylists with frame buffer objects. Because, I suppose that the
displaylists have to be faster than the vbo, because the displaylists are
precompiled. But in my example I get another result:
VBO: 225 FPS
DL: 88 FPS
Is that possible?
Following a part of my code:
// Geometry (Grid-Plane)
::osg::Geometry* geom = new osg::Geometry;
// Vertex Array (Grid with 1000 x 1000 quads)
::osg::ref_ptr ::osg::Vec3Array v = new ::osg::Vec3Array();
for(unsigned int x=0; x 1000; x++)
{
for(unsigned int y=0; y 1000; y++)
{
// create points
}
}
geom-setVertexArray(v);
#ifdef ENABLE_VBO
// Vertex Buffer Object
osg::VertexBufferObject* vbo = geom-getOrCreateVertexBufferObject();
vbo-setArray(0,v);
vbo-setUsage(GL_STATIC_DRAW);
geom-setUseVertexBufferObjects(true);
geom-setSupportsDisplayList(false);
geom-setUseDisplayList(false);
#else
geom-setSupportsDisplayList(true);
geom-setUseDisplayList(true);
#endif
// Primitive
::osg::DrawArrays* da = new
::osg::DrawArrays(::osg::PrimitiveSet::QUADS,0,v-size());
geom-addPrimitiveSet(da);
// Geometry Node
::osg::Geode* geode = new osg::Geode;
geode-addDrawable(geom);
Thanks
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] A few questions on GraphicsWindowEmbedded
Hi Robert, Thanks for the thorough response. Simply put, QtQuick is a different way to build up GUIs. It uses a hybrid CSS/JS language called QML to design a UI instead of the widget / forms approach that GUI toolkits usually employ. It is geared specially towards mobile and tablet devices. I'm working on a couple of projects for systems which have a small touch display where typical UI design isn't appropriate. A very specific example is an in car infotainment system. I'd like to use OSG to render map data and display it in on my interface which I've built through QtQuick. Here's an example of what my interface looks like: http://prismaticproject.weebly.com/uploads/8/1/9/7/8197704/1660451_orig.png Unlike normal QGLWidgets, which the GraphicsWindowQt class uses, creating an item in QtQuick to display stuff is slightly different; there are no 'widgets'. You instead create an item, where you get access to a single paint() method where the only OpenGL functionality you have is making direct calls. All QtQuick items are rendered onto a single QGLWidget canvas. For example, I can do stuff like: //glBegin(GL_QUADS); //glColor3ub(0,0,255); //glVertex2d(boundingRect().left(), boundingRect().top()); //... And the item would render in its own assigned space on the screen, maintaining all of its positional parent child relationships. Regards, Preet On Tue, Feb 28, 2012 at 4:54 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Preet, On 28 February 2012 09:16, Preet prismatic.proj...@gmail.com wrote: * What do the parameters passed to the osgViewer::GraphicsWindowEmbedded constructor (x,y,w,h) actually do? I played around with the values and it had no visible effect on my displayed result They tell the GraphicsWidnowEmedded object where about the window it's representing is in desktop coordinates. * What does GraphicsWindowEmbedded do behind the scenes? Since you don't explicitly specify a GraphicsContext for it, does that mean it uses the OpenGL context of the framework you're embedding it into? GraphicsWindowEmbedded actually does nothing behind the scenes at all - it's a non op class designed to make it possible to reuse the osgViewer::Viewer and CompositeViewer classes in places that already provide the graphics context and are strictly single threaded and have a single window. It's really tricking these classes that a designed to work with multi-threading and multi-context capable systems where makeCurrent() and swapBuffers() implementations are accessible to work without doing this operations so when calls to makeCurrent() and swapBuffers() are made by the viewer classes nothing happens. Since nothing happens it's entirely up to the calling app to do it for the viewer because it can't do itself. Since GraphicsWindowEmbedded is design to avoid properly implementing the key context management functions on the OSG or a subclass side it does restrict how you can use the viewer classes. It's very much a crude approach to provide viewer functionality, easy to get working yes, fully capable no. You can't add the full capabilities back in when using GraphicsWindowEmbedded, if you don't need multi-threading or multi-context this will be fine, but if you do look elsewhere. Actually implementing a GraphicsWindow properly is the most powerful way to adapt 3rd party graphics contexts with the osgViewer, and this is done by the osgQt::GraphicsWindowQt class, as was as the GraphicsWindowX11, Win32, Cocoa and Carbon implementations found natively in osgViewer. * I noticed that the viewport is rendered onto the window in absolute coordinates. With QtQuick, when you create an item to display on the screen, it has a child/parent relationship and coordinates are relative to the parent. Moving the parent will also move the child as you'd expect. This doesn't happen with GraphicsWindowEmbedded though, probably because with QtQuick, all the elements are painted onto one 'canvas' (I think), and GraphicsWindowEmbedded just paints straight onto that. I know absolutely nothing about QtQuick or how you've implemented the integration with GraphicsWindowEmbedded so I can't say anything about this. * If, instead of having GraphicsWindowEmbedded draw on my screen whenever I call the viewer's frame() method, is it possible to render the viewer camera's output to a texture that I could manually draw onto a quad or something? This way I don't have to specify absolute coordinates for the viewport like I mentioned above. I already tried this by rendering to an osg::Image, then painting it on the screen with Qt, but I have a relatively old computer and osg::Image-readPixels() takes too much time. My results with the osgscreencapture example were also pretty terrible (15-16 fps @ 640x480). If you want to do off screen rendering then this is very different thing, GraphicsWindowEmedded is not the best thing to do this, what you'll want is a
Re: [osg-users] How to prevent resize of viewer window (WindowsandLinux)
I would be very interested in this as well. I have been having this issue for a long time. Our development systems all have one widescreen monitor at 1920x1080 and then one SD monitor at 1280x1024. If we want to run a 1280x1024 window on the widescreen as the left monitor, all is fine. However if you want it to run on the 1280x1024 monitor and it is the left most monitor, only 75% of the time it's fine. The other 25% go between showing up on the wrong screen and running at 1280x1024 inside of a 1920x1080 full screen window. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Daly Sent: Friday, February 24, 2012 12:05 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] How to prevent resize of viewer window (WindowsandLinux) On 02/24/2012 04:13 AM, Robert Osfield wrote: You should be able to do the cross platform route, but if there is a bug on the OSG side on one particular platform we as a community just need to fix it. I just have access to Linux, and have very little Windows experience so can't help out with debugging the Windows side, so have to rely on Windows dev to get things working perfectly under Windows - this normally works out pretty well. To resolve the issue the best route would be to create a small example that illustrates the problem so that others can reproduce, confirm the problem and then work to fix it. Modifying an existing osg example would probably be a good place to start. I found a little program I can test with. It looks like the MWM property for resizing is being set correctly, just the window manager (Metacity, in my case) is ignoring it. I'm putting together a submission that uses the ICCCM hints instead. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to prevent resize of viewer window (WindowsandLinux)
On 02/28/2012 04:04 PM, Cary, Karl A. wrote: I would be very interested in this as well. I have been having this issue for a long time. Our development systems all have one widescreen monitor at 1920x1080 and then one SD monitor at 1280x1024. If we want to run a 1280x1024 window on the widescreen as the left monitor, all is fine. However if you want it to run on the 1280x1024 monitor and it is the left most monitor, only 75% of the time it's fine. The other 25% go between showing up on the wrong screen and running at 1280x1024 inside of a 1920x1080 full screen window. Hi, Karl, Sounds like you've got a different problem to me. My patch is only for preventing the interactive resizing of the window (i.e: by clicking the mouse on the window's border and dragging it). I've seen problems like you mention before (I'm guessing you're on Linux). Usually, some combination of options to the xorg.conf file can be set to fix it, or at least make it behave consistently. If you're using the NVIDIA proprietary driver, check the driver's README.txt file for a list of options you can set. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rendering without calling osgViewer::frame
In my application I have a bunch of cameras that render to textures. Is there a way for me to trigger them to render without calling osgViewer::frame or going through the osgViewer class? Ideally I could simply call camera-renderView() or something similar. Is this possible? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45868#45868 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering without calling osgViewer::frame
On 02/28/2012 06:20 PM, Sean O'Connell wrote: In my application I have a bunch of cameras that render to textures. Is there a way for me to trigger them to render without calling osgViewer::frame or going through the osgViewer class? Ideally I could simply call camera-renderView() or something similar. Is this possible? Hi, Sean, Short answer: In theory, it's possible, but I wouldn't recommend it. What are you trying to accomplish, in more broad terms? There's probably a better way to do what you're trying to do (have you looked at osgPPU yet?) Long answer: The main problem with this is that the cull and draw traversals are normally spawned off into separate threads, with the exact configuration depending on the threading model in use. If you look at the implementation of the frame() method (in the base class implementation ViewerBase.cpp), you'll see that it's a pretty simple method that calls: advance(simulationTime); eventTraversal(); updateTraversal(); renderingTraversals(); If you then look at the renderingTraversals() method, you'll see it's a lot more complicated, since it has lots to do, and it needs to be able to deal with each of the different threading models that could be in use. You might be able to write your own version of renderingTraversals() to handle your specific use case and only render the cameras that you want, but you're likely to run into all kinds of problems. As I said earlier, there's probably a better way to do what you're trying to do. If you explain your task at a higher level, someone might be able to come up with a solution for you. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering without calling osgViewer::frame
Hi Sean, In the coming OpenSceneGraph 3.0 Cookbook (will be published in March), I provide such an example that renders OSG scene graph using osgUtil::SceneView directly in GLUT. You may find the source code at: https://github.com/xarray/osgRecipes/tree/master/cookbook/chapter9/ch09_06 The source code are completely in public domain so you may choose to buy the book or not. :-) But as Jason suggested, this is not recommended in most cases as you can't make use of a lot of OSG features anymore. Cheers, Wang Rui 2012/2/29 Sean O'Connell soconn...@zebraimaging.com In my application I have a bunch of cameras that render to textures. Is there a way for me to trigger them to render without calling osgViewer::frame or going through the osgViewer class? Ideally I could simply call camera-renderView() or something similar. Is this possible? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45868#45868 ___ 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
