Re: [osg-users] Viewport inheritance and RTT
Hi,
Christiansen, Brad wrote:
Hi,
Just 'resubmitting' my issue with a more simple question to see if
anyone has any ideas.
What are the rules with viewport inheritance?
- My understanding is:
If a camera has a viewport set, this is used when rendering the cameras
sub-graph. If it is not set, it uses the parent cameras viewport.
- What I am seeing:
My pre-render camera (rendering to a texture) has a viewport set but its
sub-graph is being rendered using its parent cameras viewport. I have
double checked that the viewport is set during the cull traversal. The
pre-render cameras viewport is placed on the stack, and set on the
RenderStage used to render the camera, yet it is still rendered using
the parents viewport.
- My question/s:
What could cause this to occur? i.e. when is a local viewport ignored
and 'overridden' by a parents viewport.
What should I look at to debug this? I am not sure what to check after
seeing the Renderstage apparently setup correctly.
sorry, I can't answer all your questions.
I don't think this goes as deep as renderstage. Have a look at View and
Viewer and check the handling of slaves. Check where addSlave adds the
View and then check where the list of views is used.
I am completely stumped now and this is proving a bit of a show-stopper
for me. Any suggestions on what to look at would be greatly appreciated.
I'm still not sure why you want to use a slave? I remember something you
said about shadows, but don't understand why shadows should differ
between slave/not slave. Pre-render should work fine with just an RTT
camera placed somewhere in the graph and in this case you can set
everything manually.
jp
Cheers,
Brad
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Christiansen, Brad
Sent: Tuesday, 12 January 2010 10:59 AM
To: OpenSceneGraph Users
Subject: [osg-users] Viewport inheritance and RTT
Hi,
I have a scene setup with a texture attached to a camera which is setup
for pre-rendering.
In my scene I set the viewport for the RTT camera to the dimensions of
the texture. Despite having done this, the viewport for the RTT camera
is being inherited from the main scenes camera, i.e. if the viewport of
the main camera is (0,0,8000,600) then only this section of the texture
is rendered, despite the viewport for the rtt camera being
(0,0,1024,1024).
I have stepped through the CullVistor with a debugger and have found
that the viewport does seem to be setup correctly by the cull visitor.
By the time I get to this section of the CullVisitor:
switch(camera.getRenderOrder())
{
case osg::Camera::PRE_RENDER:
//In the following line the viewport for the camera and the rtts is
correct
getCurrentRenderBin()-getStage()-addPreRenderStage(rtts.get(),camera.g
etRenderOrderNum());
break;
default:
getCurrentRenderBin()-getStage()-addPostRenderStage(rtts.get(),camera.
getRenderOrderNum());
break;
}
the viewport seems to have been setup correctly. Both the rtts's
viewport and the cameras viewport is (0,0,1024,1024), but when it is
rendered this is not the viewport that is used.
I am not quite sure where to go from here. Does anyone have any
suggestions on what I may have done wrong or what area I should debug
next?
I am using version 2.9.5 of OSG.
Cheers,
Brad
DISCLAIMER:-
--
This e-mail transmission and any documents, files and previous e-mail
messages
attached to it are private and confidential. They may contain
proprietary or copyright
material or information that is subject to legal professional privilege.
They are for
the use of the intended recipient only. Any unauthorised viewing, use,
disclosure,
copying, alteration, storage or distribution of, or reliance on, this
message is
strictly prohibited. No part may be reproduced, adapted or transmitted
without the
written permission of the owner. If you have received this transmission
in error, or
are not an authorised recipient, please immediately notify the sender by
return email,
delete this message and all copies from your e-mail system, and destroy
any printed
copies. Receipt by anyone other than the intended recipient should not
be deemed a
waiver of any privilege or protection. Thales Australia does not warrant
or represent
that this e-mail or any documents, files and previous e-mail messages
attached are
error or virus free.
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
DISCLAIMER:---
This e-mail transmission and any documents, files and previous e-mail
Re: [osg-users] [vpb] Geocentric Database, how to flattening area or cut out piece
zonk wrote: Hi, Is it possible to flatten the geocentric database at specific coordiantes, or cut out speciffic areas, so the gap can be refilled with a completely flat area? Maybe you could also directly alter your input data with the GDAL rasterizer tool : http://www.gdal.org/gdal_rasterize.html -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22593#22593 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Zoom effect
Hi, I use the setProjectionMatrixAsPerspective that performs what I need but the only problem is when I zoom out too much, my model streches until zoom in to the previous fovy values. How could I fix this? Thank you! Cheers, Gene -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22594#22594 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3d file formats supporting bump map
Hi David, and thanks for the great explanation! It has been very helpful I will try to modify or instruct the import plugins of the file formats I need forcing the association between the maps and the texture unit meaning then. Thanks again, Davide -- Forwarded message -- From: David Spilling david.spill...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: Tue, 12 Jan 2010 12:35:34 + Subject: Re: [osg-users] 3d file formats supporting bump map Hi Davide, Certainly the obj loader supports bump maps, but let me be clear about what it actually does. Apologies if this comes over as patronising; I have no idea of your level of expertise. In OSG/OpenGL land, textures (diffuse, bump map, specular map, etc.) are all attached to a particular geometry via a texture ID - this is an integer index ranging from 0 upwards. Shaders are then applied to this geometry that will colour the pixel based on a particular understanding of what each texture ID actually is. So for example, I can write a shader that assumes that texture unit 0 is the diffuse colour, texture unit 1 is some sort of specularity map, texture unit 2 is a bump map, etc. Or I can assume (for example as osgShadow tends to) that texture unit 0 is the diffuser colour, texture unit 1 is the shadow map. However - and this is the key - there is nothing that enforces this mapping between texture unit and meaning. 3DS, and the obj format, both explicitly include entries in the model for diffuse texture and specular map and bump map and so on. However the 3DS or obj format loader doesn't know what shader you are going to apply to this model, so has no idea which texture ID/unit to assign a loaded bump map texture to. Should it be 1? 2? etc. Some formats (e.g. .osg) allow you to save an objects shader within the object definition itself, thereby guaranteeing that the textures that the object loads are assigned to the right texture unit, and used in the right way. 3DS and .obj don't. AFAIK, there is currently no OSG-wide method for enforcing any consistency. All that being said, the OBJ loader allows you to specify what texture units you want which maps to go to when you load the model, via an options string. The options are all listed in the first few lines of ReaderWriterOBJ.cpp. The mapping between the flags in the .obj file and the name of the texture is in lines 434 onwards of obj.cpp. (It's useful to have a look at that, because the OBJ spec is not rigourously followed by all modelling tools - e.g. you see map_opacity in some obj files, even though it should be map_d according to the spec). I'm not amazingly familiar with osgFX, but reading the source for the BumpMapping technique, I notice that a) you can define which texture units should be used for diffuse and normal (note : not bump) textures, and b) by default these are 0=normal, 1=diffuse. I also don't know what Blender exports in terms of maps. When you say that the blender export isn't exporting the bump map, have you looked in the OBJ file to actually see whether there is a map_bump (or map_Bump, or just bump) in it? Has it been called something else by the exporter? Hope that helps, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FFmpeg and sound
Hi Serge, Robert is right, SDL only provides a very low-level sound API. If you have several sounds, you need to write your own software mixer. SDL advantage is that it's very easy to use. Because it's so low level, it does not have obscure side effects, which is what you want when you develop a movie plugin. But I wouldn't recommend to use it with the FFmpeg plugin for more than just testing. Libraries like OpenAL and FMOD are better suited. In fact we are using the FFmpeg plugin with FMOD in a commercial product, and playing several movies in parallel just fine. If you're interested by the FMOD audio sink, I'm sure I could provide you with a part of our implementation. T -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: 13 January 2010 6:38 PM To: OpenSceneGraph Users Subject: Re: [osg-users] FFmpeg and sound HI Serge, I believe the SDL interface only allows for one audio channel so implementating multiple videos would be problematic, or at least that was be reading of the API in my brief encounter with trying to get this working quickly. OpenAL and other dedicated audio libs would certainly be a better bet for handling multiple videos. We just need to code up such a solution. Robert. On Wed, Jan 13, 2010 at 6:25 PM, Serge Lages serge.la...@gmail.com wrote: Hi all, I've made some tests with the FFmpeg plugin and sound using the code from osgmovie (with the SDLAudioSink), it works but with limitations : - When there are multiple videos it produces random behaviors, sometimes only one sound from one video works, other times no sound is played. - When deleting my video objects, I've got a crash, I didn't had time to investigate where precisely it comes from yet. I'm under Windows 7 and VS9 Express, is anyone experiencing this kind of problem, or is having success playing multiple videos with sound ? I would also like to know if anyone knows how to control the sound volume with the SDL ? We should also modify the AudioSink class to allow it, currently there is a setVolume method on the ImageStream class but not on the AudioStream one. Thanks ! -- Serge Lages http://www.tharsis-software.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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 360 degree screen captures
Hi Darin, You can easily create 360 degree image captures in your app by just creating a series of slave cameras that each take around a 90 degree portion of the view, the viewports for the cameras can be side by side so you don't see the seem. Alternatively you can render the slave cameras to a cubemap than have final pass where you render this texture - this enables you to do full dome projection with distortion correction. It just so happens that the OSG already support full dome projection with distortion correction just do: viewer cow.osg --3d-sd This option calls the View::setUpViewFor3DSphericalDisplay(...), and if you have a look inside src/osgViewer/Viewer.cpp you'll find the implementation for it. It creates 7 slave cameras - 6 for the cube map and one for the final distortion correction pass. If you just want to do this all off screen then you you just use a pbuffer for graphics context rather than a conventional window. Also in your case you should be able to simplify the code from the 3DSphericalDisplay() example as you probably can get away with no distortion correction. Robert. On Wed, Jan 13, 2010 at 8:40 PM, Darin Kwasniewski dkwasniew...@prologic-inc.com wrote: Hi, Does there exist the capability utilizing the osg libraries to create the JPG/PNG without running the viewer, i.e. without displaying the viewer window. Is there an alternative to creating an image from the screen (and then writing it to the file), or is running the viewer a necessity to accomplish the rotation and image creation? Thank you! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22574#22574 ___ 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] User defined Manipulator in a thread
Hi, I found the problem it is not because of the code. I embed my viewer in a windows form and the form has buttons so when I press arrow keys thse buttos are being selected when I remove these buttons manipulator gets the keys but I need these buttons in the form. Thank you! Cheers, Tufan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22599#22599 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT slave views and multi-threading
Hi Robert, Wojciech my initial guess was that the lengthy draw dispatch of the master view and failing cull draw parallelism was the result of the same problem. However, they actually seem to be different problems and I'll focus first on the draw dispatch. The master camera draws only a screen aligned quad and nothing else (scene with shadows is rendered by the slave camera). Also no dynamic geometry. But, I indeed have a read buffer operation: a glGetTexImage call in the postdraw callback of the master camera. This call takes ~12 ms. I read back a small texture that is rendered by a camera in the current frame. The camera uses FRAME_BUFFER_OBJECT as render target implementation. It looks like using glReadPixels to read directly from the FBO is the advised method for getting data back to the system memory. How do I get the FBO that the camera is rendering to? Or, is there a better method to get the texture data back to the sysmem? cheers, tugkan Hi Tugkan, Robert mentioned lengthy read operation. It may be related to read buffer operation thats used to compute shadow volume in LightSpacePerpspectiveShadowMapDB. If your slave view uses osgShadow::LightSpacePerpspectiveShadowMapDB then you may check if osgShadow::LightSpacePerpspectiveShadowMapCB (cull bounds flavour) has the same problem. I am aware of LightSpacePerpspectiveShadowMapDB glReadBuffer limitation but I could not find quick and easy to implement workaround that would do this without scanning the image by CPU. I allocate small 64x64 texture and render the scene there, then read it into CPU memory and use CPU to scan pixels to optimzie shadow volume from depths and pixel locations strored in this prerender image. Wojtek - Original Message - From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, January 13, 2010 1:04 PM Subject: Re: [osg-users] RTT slave views and multi-threading Hi Tugkan, The osgdistortion example works a bit like what you are describing, could you try this to see what performance it's getting. As for general notes about threading, if you are working on the same graphics context as you are then all the draw dispatch and the draw GPU can only be done by a single graphics thread so there is little opportunity to make it more parallel without using another graphics card/graphics context and interleaving of frames. As for why the second camera is very expensive on draw dispatch, this suggest to me that it's blocking either due to the OpenGL fifo being full or that it contains a GL read back operation of some kind. Robert. On Wed, Jan 13, 2010 at 11:34 AM, Tugkan Calapoglu tug...@vires.com wrote: Hi All, I am using a slave view for rendering the scene to a texture. Initially I tried with a camera node, however, this did not work well due to a problem in LiSPSM shadows and I was suggested to use RTT slave views. My setup is as follows: There is a single main view and I attach a slave view to it. This slave view is attached with addSlave( slave , false ); so that it does *not* automatically use the master scene. I attach a texture to the slave view and make my scene child of this view. I attach a screen aligned quad to the main view. This quad visualizes the RTT texture from the slave view. Now I have a threading problem which can be seen on the snapshot I attached. There are two issues: 1- The main view (cam1) has a very large draw time even though it only renders the screen aligned quad. I double checked to see whether it also renders the actual scene but this is not the case. 2- Slave view does not run cull and draw in parallel. Cull and draw do run in parallel if they are not rendered with the slave view. Moreover, if I change the render order of the slave camera from PRE_RENDER to POST_RENDER it is ok. I could simply use POST_RENDER but I am afraid it introduces an extra one frame latency. If I render the screen aligned quad first and the scene later than what I see on the quad is the texture from previous frame (right?). Any ideas? cheers, tugkan ___ 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 -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463641 fax +49.8031.463645 emailtug...@vires.com internet www.vires.com
Re: [osg-users] RTT slave views and multi-threading
Hi Tugkan, Tugkan Calapoglu wrote: Hi Robert, Wojciech my initial guess was that the lengthy draw dispatch of the master view and failing cull draw parallelism was the result of the same problem. However, they actually seem to be different problems and I'll focus first on the draw dispatch. The master camera draws only a screen aligned quad and nothing else (scene with shadows is rendered by the slave camera). Also no dynamic geometry. But, I indeed have a read buffer operation: a glGetTexImage call in the postdraw callback of the master camera. This call takes ~12 ms. I read back a small texture that is rendered by a camera in the current frame. The camera uses FRAME_BUFFER_OBJECT as render target implementation. It looks like using glReadPixels to read directly from the FBO is the advised method for getting data back to the system memory. How do I get the FBO that the camera is rendering to? Or, is there a better method to get the texture data back to the sysmem? Simplest is to just attach an osg::Image to the RTT (to FBO) camera. See the attach method of osg::Camera. Think there is an example in osgprerender. Also see here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/52651 and http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/53432 rgds jp cheers, tugkan Hi Tugkan, Robert mentioned lengthy read operation. It may be related to read buffer operation thats used to compute shadow volume in LightSpacePerpspectiveShadowMapDB. If your slave view uses osgShadow::LightSpacePerpspectiveShadowMapDB then you may check if osgShadow::LightSpacePerpspectiveShadowMapCB (cull bounds flavour) has the same problem. I am aware of LightSpacePerpspectiveShadowMapDB glReadBuffer limitation but I could not find quick and easy to implement workaround that would do this without scanning the image by CPU. I allocate small 64x64 texture and render the scene there, then read it into CPU memory and use CPU to scan pixels to optimzie shadow volume from depths and pixel locations strored in this prerender image. Wojtek - Original Message - From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, January 13, 2010 1:04 PM Subject: Re: [osg-users] RTT slave views and multi-threading Hi Tugkan, The osgdistortion example works a bit like what you are describing, could you try this to see what performance it's getting. As for general notes about threading, if you are working on the same graphics context as you are then all the draw dispatch and the draw GPU can only be done by a single graphics thread so there is little opportunity to make it more parallel without using another graphics card/graphics context and interleaving of frames. As for why the second camera is very expensive on draw dispatch, this suggest to me that it's blocking either due to the OpenGL fifo being full or that it contains a GL read back operation of some kind. Robert. On Wed, Jan 13, 2010 at 11:34 AM, Tugkan Calapoglu tug...@vires.com wrote: Hi All, I am using a slave view for rendering the scene to a texture. Initially I tried with a camera node, however, this did not work well due to a problem in LiSPSM shadows and I was suggested to use RTT slave views. My setup is as follows: There is a single main view and I attach a slave view to it. This slave view is attached with addSlave( slave , false ); so that it does *not* automatically use the master scene. I attach a texture to the slave view and make my scene child of this view. I attach a screen aligned quad to the main view. This quad visualizes the RTT texture from the slave view. Now I have a threading problem which can be seen on the snapshot I attached. There are two issues: 1- The main view (cam1) has a very large draw time even though it only renders the screen aligned quad. I double checked to see whether it also renders the actual scene but this is not the case. 2- Slave view does not run cull and draw in parallel. Cull and draw do run in parallel if they are not rendered with the slave view. Moreover, if I change the render order of the slave camera from PRE_RENDER to POST_RENDER it is ok. I could simply use POST_RENDER but I am afraid it introduces an extra one frame latency. If I render the screen aligned quad first and the scene later than what I see on the quad is the texture from previous frame (right?). Any ideas? cheers, tugkan ___ 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
Re: [osg-users] RTT slave views and multi-threading
hi Jp, unfortunately that method is easy but very slow. I think it also uses glGetTexImage. cheers, tugkan Hi Tugkan, Tugkan Calapoglu wrote: Hi Robert, Wojciech my initial guess was that the lengthy draw dispatch of the master view and failing cull draw parallelism was the result of the same problem. However, they actually seem to be different problems and I'll focus first on the draw dispatch. The master camera draws only a screen aligned quad and nothing else (scene with shadows is rendered by the slave camera). Also no dynamic geometry. But, I indeed have a read buffer operation: a glGetTexImage call in the postdraw callback of the master camera. This call takes ~12 ms. I read back a small texture that is rendered by a camera in the current frame. The camera uses FRAME_BUFFER_OBJECT as render target implementation. It looks like using glReadPixels to read directly from the FBO is the advised method for getting data back to the system memory. How do I get the FBO that the camera is rendering to? Or, is there a better method to get the texture data back to the sysmem? Simplest is to just attach an osg::Image to the RTT (to FBO) camera. See the attach method of osg::Camera. Think there is an example in osgprerender. Also see here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/52651 and http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/53432 rgds jp cheers, tugkan Hi Tugkan, Robert mentioned lengthy read operation. It may be related to read buffer operation thats used to compute shadow volume in LightSpacePerpspectiveShadowMapDB. If your slave view uses osgShadow::LightSpacePerpspectiveShadowMapDB then you may check if osgShadow::LightSpacePerpspectiveShadowMapCB (cull bounds flavour) has the same problem. I am aware of LightSpacePerpspectiveShadowMapDB glReadBuffer limitation but I could not find quick and easy to implement workaround that would do this without scanning the image by CPU. I allocate small 64x64 texture and render the scene there, then read it into CPU memory and use CPU to scan pixels to optimzie shadow volume from depths and pixel locations strored in this prerender image. Wojtek - Original Message - From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, January 13, 2010 1:04 PM Subject: Re: [osg-users] RTT slave views and multi-threading Hi Tugkan, The osgdistortion example works a bit like what you are describing, could you try this to see what performance it's getting. As for general notes about threading, if you are working on the same graphics context as you are then all the draw dispatch and the draw GPU can only be done by a single graphics thread so there is little opportunity to make it more parallel without using another graphics card/graphics context and interleaving of frames. As for why the second camera is very expensive on draw dispatch, this suggest to me that it's blocking either due to the OpenGL fifo being full or that it contains a GL read back operation of some kind. Robert. On Wed, Jan 13, 2010 at 11:34 AM, Tugkan Calapoglu tug...@vires.com wrote: Hi All, I am using a slave view for rendering the scene to a texture. Initially I tried with a camera node, however, this did not work well due to a problem in LiSPSM shadows and I was suggested to use RTT slave views. My setup is as follows: There is a single main view and I attach a slave view to it. This slave view is attached with addSlave( slave , false ); so that it does *not* automatically use the master scene. I attach a texture to the slave view and make my scene child of this view. I attach a screen aligned quad to the main view. This quad visualizes the RTT texture from the slave view. Now I have a threading problem which can be seen on the snapshot I attached. There are two issues: 1- The main view (cam1) has a very large draw time even though it only renders the screen aligned quad. I double checked to see whether it also renders the actual scene but this is not the case. 2- Slave view does not run cull and draw in parallel. Cull and draw do run in parallel if they are not rendered with the slave view. Moreover, if I change the render order of the slave camera from PRE_RENDER to POST_RENDER it is ok. I could simply use POST_RENDER but I am afraid it introduces an extra one frame latency. If I render the screen aligned quad first and the scene later than what I see on the quad is the texture from previous frame (right?). Any ideas? cheers, tugkan ___ 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
Re: [osg-users] RTT slave views and multi-threading
Hi Tugkan, On Thu, Jan 14, 2010 at 12:00 PM, Tugkan Calapoglu tug...@vires.com wrote: unfortunately that method is easy but very slow. I think it also uses glGetTexImage. An operation like glReadPixels and glGetTexImage involves the fifo being flushed and the data copied back into main memory. These two things together make it slow and there isn't much you can do about it directly. The best way to deal with the high cost of these operations is to avoid them completely. Try to use algorithms that can use render to texture using FBO's and read this textures directly in other shaders. Never try to copy the results back to the CPU/main memory, this does force you to do more work on the GPU and rely on more complex shaders but in the end it means that you don't have to force a round trip to the GPU. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT slave views and multi-threading
Hi, Tugkan Calapoglu wrote: hi Jp, unfortunately that method is easy but very slow. I think it also uses glGetTexImage. You might be surprised. Have you read the threads I linked to? Attach uses glReadPixels (while doing the FBO rendering, so you don't have to bind anything yourself later) and in many cases this is the fastest. If you want something more elaborate, such as async PBO use, see the osgscreencapture example. Also, test whatever you use for your setup, all sorts of things can change the efficiency of reading data back to CPU. YMMV. Like Robert said tho, not reading anything back to CPU if you can help it is the best. rgds jp cheers, tugkan Hi Tugkan, Tugkan Calapoglu wrote: Hi Robert, Wojciech my initial guess was that the lengthy draw dispatch of the master view and failing cull draw parallelism was the result of the same problem. However, they actually seem to be different problems and I'll focus first on the draw dispatch. The master camera draws only a screen aligned quad and nothing else (scene with shadows is rendered by the slave camera). Also no dynamic geometry. But, I indeed have a read buffer operation: a glGetTexImage call in the postdraw callback of the master camera. This call takes ~12 ms. I read back a small texture that is rendered by a camera in the current frame. The camera uses FRAME_BUFFER_OBJECT as render target implementation. It looks like using glReadPixels to read directly from the FBO is the advised method for getting data back to the system memory. How do I get the FBO that the camera is rendering to? Or, is there a better method to get the texture data back to the sysmem? Simplest is to just attach an osg::Image to the RTT (to FBO) camera. See the attach method of osg::Camera. Think there is an example in osgprerender. Also see here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/52651 and http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/53432 rgds jp cheers, tugkan Hi Tugkan, Robert mentioned lengthy read operation. It may be related to read buffer operation thats used to compute shadow volume in LightSpacePerpspectiveShadowMapDB. If your slave view uses osgShadow::LightSpacePerpspectiveShadowMapDB then you may check if osgShadow::LightSpacePerpspectiveShadowMapCB (cull bounds flavour) has the same problem. I am aware of LightSpacePerpspectiveShadowMapDB glReadBuffer limitation but I could not find quick and easy to implement workaround that would do this without scanning the image by CPU. I allocate small 64x64 texture and render the scene there, then read it into CPU memory and use CPU to scan pixels to optimzie shadow volume from depths and pixel locations strored in this prerender image. Wojtek - Original Message - From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, January 13, 2010 1:04 PM Subject: Re: [osg-users] RTT slave views and multi-threading Hi Tugkan, The osgdistortion example works a bit like what you are describing, could you try this to see what performance it's getting. As for general notes about threading, if you are working on the same graphics context as you are then all the draw dispatch and the draw GPU can only be done by a single graphics thread so there is little opportunity to make it more parallel without using another graphics card/graphics context and interleaving of frames. As for why the second camera is very expensive on draw dispatch, this suggest to me that it's blocking either due to the OpenGL fifo being full or that it contains a GL read back operation of some kind. Robert. On Wed, Jan 13, 2010 at 11:34 AM, Tugkan Calapoglu tug...@vires.com wrote: Hi All, I am using a slave view for rendering the scene to a texture. Initially I tried with a camera node, however, this did not work well due to a problem in LiSPSM shadows and I was suggested to use RTT slave views. My setup is as follows: There is a single main view and I attach a slave view to it. This slave view is attached with addSlave( slave , false ); so that it does *not* automatically use the master scene. I attach a texture to the slave view and make my scene child of this view. I attach a screen aligned quad to the main view. This quad visualizes the RTT texture from the slave view. Now I have a threading problem which can be seen on the snapshot I attached. There are two issues: 1- The main view (cam1) has a very large draw time even though it only renders the screen aligned quad. I double checked to see whether it also renders the actual scene but this is not the case. 2- Slave view does not run cull and draw in parallel. Cull and draw do run in parallel if they are not rendered with the slave view. Moreover, if I change the render order of the slave camera from PRE_RENDER to POST_RENDER it is ok. I could simply use POST_RENDER but I am afraid it introduces an extra one frame latency. If I render the
Re: [osg-users] RTT slave views and multi-threading
Hi Robert, I am working on an HDR implementation which should work on multiple channels. The method I use requires average luminance of the scene. If I use different average luminances for different channels the colors will simply not match. E.g. in a tunnel front channel will see the tunnel exit and have a higher average luminance than the side channels which only see the dark tunnel walls. So, I do need a way to collect current average luminances of all channels and compute a single average that can be used for all (by channel I mean separate computers that are connected to separate projectors). I know that getting data back from GPU is slow but 12ms for a 4x4 texture seems extreme. glReadPixels seems to be faster, because we are able to make full screen grabs (800x600) and still keep 60hz (even w/o pbo). Some GPGPU people suggest using glReadPixels to read directly from a FBO rather than glGetTexImage, so I was wondering if there is a way to obtain the osg::FBO pointer from the camera? cheers, tugkan Hi Tugkan, On Thu, Jan 14, 2010 at 12:00 PM, Tugkan Calapoglu tug...@vires.com wrote: unfortunately that method is easy but very slow. I think it also uses glGetTexImage. An operation like glReadPixels and glGetTexImage involves the fifo being flushed and the data copied back into main memory. These two things together make it slow and there isn't much you can do about it directly. The best way to deal with the high cost of these operations is to avoid them completely. Try to use algorithms that can use render to texture using FBO's and read this textures directly in other shaders. Never try to copy the results back to the CPU/main memory, this does force you to do more work on the GPU and rely on more complex shaders but in the end it means that you don't have to force a round trip to the GPU. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463641 fax +49.8031.463645 emailtug...@vires.com internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT slave views and multi-threading
Hi Tugkan, On Thu, Jan 14, 2010 at 12:31 PM, Tugkan Calapoglu tug...@vires.com wrote: I know that getting data back from GPU is slow but 12ms for a 4x4 texture seems extreme. It's the flushing of the fifo that is the problem, that's why it's so slow, not the data transfer itself. Once you flush the fifo you loose the parallelism between the CPU and GPU. The only way to hide this is to use PBO's to do the read back and do the actual read back on the next frame rather than in the current frame. In your case you might be able to get away with this, a frames latency might not be a big issue if you can keep to a solid 60Hz and the values you are reading back aren't changing drastically between frames. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT slave views and multi-threading
Hi Jp, my initial implementation used osg:Image attached to a camera and it was just as slow. I will see what I can do with PBO's. regards, tugkan Hi, Tugkan Calapoglu wrote: hi Jp, unfortunately that method is easy but very slow. I think it also uses glGetTexImage. You might be surprised. Have you read the threads I linked to? Attach uses glReadPixels (while doing the FBO rendering, so you don't have to bind anything yourself later) and in many cases this is the fastest. If you want something more elaborate, such as async PBO use, see the osgscreencapture example. Also, test whatever you use for your setup, all sorts of things can change the efficiency of reading data back to CPU. YMMV. Like Robert said tho, not reading anything back to CPU if you can help it is the best. rgds jp cheers, tugkan Hi Tugkan, Tugkan Calapoglu wrote: Hi Robert, Wojciech my initial guess was that the lengthy draw dispatch of the master view and failing cull draw parallelism was the result of the same problem. However, they actually seem to be different problems and I'll focus first on the draw dispatch. The master camera draws only a screen aligned quad and nothing else (scene with shadows is rendered by the slave camera). Also no dynamic geometry. But, I indeed have a read buffer operation: a glGetTexImage call in the postdraw callback of the master camera. This call takes ~12 ms. I read back a small texture that is rendered by a camera in the current frame. The camera uses FRAME_BUFFER_OBJECT as render target implementation. It looks like using glReadPixels to read directly from the FBO is the advised method for getting data back to the system memory. How do I get the FBO that the camera is rendering to? Or, is there a better method to get the texture data back to the sysmem? Simplest is to just attach an osg::Image to the RTT (to FBO) camera. See the attach method of osg::Camera. Think there is an example in osgprerender. Also see here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/52651 and http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/53432 rgds jp cheers, tugkan Hi Tugkan, Robert mentioned lengthy read operation. It may be related to read buffer operation thats used to compute shadow volume in LightSpacePerpspectiveShadowMapDB. If your slave view uses osgShadow::LightSpacePerpspectiveShadowMapDB then you may check if osgShadow::LightSpacePerpspectiveShadowMapCB (cull bounds flavour) has the same problem. I am aware of LightSpacePerpspectiveShadowMapDB glReadBuffer limitation but I could not find quick and easy to implement workaround that would do this without scanning the image by CPU. I allocate small 64x64 texture and render the scene there, then read it into CPU memory and use CPU to scan pixels to optimzie shadow volume from depths and pixel locations strored in this prerender image. Wojtek - Original Message - From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, January 13, 2010 1:04 PM Subject: Re: [osg-users] RTT slave views and multi-threading Hi Tugkan, The osgdistortion example works a bit like what you are describing, could you try this to see what performance it's getting. As for general notes about threading, if you are working on the same graphics context as you are then all the draw dispatch and the draw GPU can only be done by a single graphics thread so there is little opportunity to make it more parallel without using another graphics card/graphics context and interleaving of frames. As for why the second camera is very expensive on draw dispatch, this suggest to me that it's blocking either due to the OpenGL fifo being full or that it contains a GL read back operation of some kind. Robert. On Wed, Jan 13, 2010 at 11:34 AM, Tugkan Calapoglu tug...@vires.com wrote: Hi All, I am using a slave view for rendering the scene to a texture. Initially I tried with a camera node, however, this did not work well due to a problem in LiSPSM shadows and I was suggested to use RTT slave views. My setup is as follows: There is a single main view and I attach a slave view to it. This slave view is attached with addSlave( slave , false ); so that it does *not* automatically use the master scene. I attach a texture to the slave view and make my scene child of this view. I attach a screen aligned quad to the main view. This quad visualizes the RTT texture from the slave view. Now I have a threading problem which can be seen on the snapshot I attached. There are two issues: 1- The main view (cam1) has a very large draw time even though it only renders the screen aligned quad. I double checked to see whether it also renders the actual scene but this is not the case. 2- Slave view does not run cull and draw in parallel. Cull and draw do run in parallel if they
Re: [osg-users] RTT slave views and multi-threading
Hi Robert, yes one frame latency is OK. Is there an example about the PBO usage? osgscreencapture seems to be about getting the data from frame buffer not from an RTT texture. tugkan Hi Tugkan, On Thu, Jan 14, 2010 at 12:31 PM, Tugkan Calapoglu tug...@vires.com wrote: I know that getting data back from GPU is slow but 12ms for a 4x4 texture seems extreme. It's the flushing of the fifo that is the problem, that's why it's so slow, not the data transfer itself. Once you flush the fifo you loose the parallelism between the CPU and GPU. The only way to hide this is to use PBO's to do the read back and do the actual read back on the next frame rather than in the current frame. In your case you might be able to get away with this, a frames latency might not be a big issue if you can keep to a solid 60Hz and the values you are reading back aren't changing drastically between frames. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Tugkan Calapoglu - VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone+49.8031.463641 fax +49.8031.463645 emailtug...@vires.com internet www.vires.com - Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT slave views and multi-threading
Hi, Tugkan Calapoglu wrote: Hi Jp, my initial implementation used osg:Image attached to a camera and it was just as slow. OK. I will see what I can do with PBO's. There is some code in the threads I linked to earlier that shows how to get data into a PBO using osg's PixelBufferDataObject. It does not do the async reading, but see here for more details: http://www.songho.ca/opengl/gl_pbo.html regards jp regards, tugkan Hi, Tugkan Calapoglu wrote: hi Jp, unfortunately that method is easy but very slow. I think it also uses glGetTexImage. You might be surprised. Have you read the threads I linked to? Attach uses glReadPixels (while doing the FBO rendering, so you don't have to bind anything yourself later) and in many cases this is the fastest. If you want something more elaborate, such as async PBO use, see the osgscreencapture example. Also, test whatever you use for your setup, all sorts of things can change the efficiency of reading data back to CPU. YMMV. Like Robert said tho, not reading anything back to CPU if you can help it is the best. rgds jp cheers, tugkan Hi Tugkan, Tugkan Calapoglu wrote: Hi Robert, Wojciech my initial guess was that the lengthy draw dispatch of the master view and failing cull draw parallelism was the result of the same problem. However, they actually seem to be different problems and I'll focus first on the draw dispatch. The master camera draws only a screen aligned quad and nothing else (scene with shadows is rendered by the slave camera). Also no dynamic geometry. But, I indeed have a read buffer operation: a glGetTexImage call in the postdraw callback of the master camera. This call takes ~12 ms. I read back a small texture that is rendered by a camera in the current frame. The camera uses FRAME_BUFFER_OBJECT as render target implementation. It looks like using glReadPixels to read directly from the FBO is the advised method for getting data back to the system memory. How do I get the FBO that the camera is rendering to? Or, is there a better method to get the texture data back to the sysmem? Simplest is to just attach an osg::Image to the RTT (to FBO) camera. See the attach method of osg::Camera. Think there is an example in osgprerender. Also see here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/52651 and http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/53432 rgds jp cheers, tugkan Hi Tugkan, Robert mentioned lengthy read operation. It may be related to read buffer operation thats used to compute shadow volume in LightSpacePerpspectiveShadowMapDB. If your slave view uses osgShadow::LightSpacePerpspectiveShadowMapDB then you may check if osgShadow::LightSpacePerpspectiveShadowMapCB (cull bounds flavour) has the same problem. I am aware of LightSpacePerpspectiveShadowMapDB glReadBuffer limitation but I could not find quick and easy to implement workaround that would do this without scanning the image by CPU. I allocate small 64x64 texture and render the scene there, then read it into CPU memory and use CPU to scan pixels to optimzie shadow volume from depths and pixel locations strored in this prerender image. Wojtek - Original Message - From: Robert Osfield robert.osfi...@gmail.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, January 13, 2010 1:04 PM Subject: Re: [osg-users] RTT slave views and multi-threading Hi Tugkan, The osgdistortion example works a bit like what you are describing, could you try this to see what performance it's getting. As for general notes about threading, if you are working on the same graphics context as you are then all the draw dispatch and the draw GPU can only be done by a single graphics thread so there is little opportunity to make it more parallel without using another graphics card/graphics context and interleaving of frames. As for why the second camera is very expensive on draw dispatch, this suggest to me that it's blocking either due to the OpenGL fifo being full or that it contains a GL read back operation of some kind. Robert. On Wed, Jan 13, 2010 at 11:34 AM, Tugkan Calapoglu tug...@vires.com wrote: Hi All, I am using a slave view for rendering the scene to a texture. Initially I tried with a camera node, however, this did not work well due to a problem in LiSPSM shadows and I was suggested to use RTT slave views. My setup is as follows: There is a single main view and I attach a slave view to it. This slave view is attached with addSlave( slave , false ); so that it does *not* automatically use the master scene. I attach a texture to the slave view and make my scene child of this view. I attach a screen aligned quad to the main view. This quad visualizes the RTT texture from the slave view. Now I have a threading problem which can be seen on the snapshot I attached. There are two issues: 1- The main view (cam1) has a very large draw time even though it only renders the screen aligned quad. I
Re: [osg-users] RTT slave views and multi-threading
Hi Tugkan, On Thu, Jan 14, 2010 at 12:51 PM, Tugkan Calapoglu tug...@vires.com wrote: yes one frame latency is OK. Is there an example about the PBO usage? osgscreencapture seems to be about getting the data from frame buffer not from an RTT texture. osgscreencapture uses a frame latency when it double buffers the PBO's. It doesn't matter whether it's frame buffer or FBO, the PBO is only related to memory management. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Faster build with precompiled headers (PCH)?
Interesting. I can't find it either if I search for that subject, but a search for precompiled headers does turn up a thread with that subject. I'm searching in the OSG-users Google Group. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 Sukender wrote: Hi Paul, I'm sorry, I did a search IN MY MAIL BOX and didn't find anything... but you're right, I should have searched the whole archives first! Well, to add a few details: - AFAIK, if you put only STL (and system headers?) in the PCH, you can avoid having to recompile the whole project each time you change osg/Node. The speedup is of course less, but it compensates a bit the slowness of MSVC. - The .h is automatically added to all .cpp files without having to change them (command line arg given in CMakeLists.txt). No special maintenance is to be made here. - However, you still got the thing I described in the previous mail: MSVC submitters must be warned to build without PCH before submitting. So maybe an OFF-by-default option would be fine? Anyway, I was just asking because I didn't find the thread... Silly me! And after all I guess it's far less important than other submissions ;) Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Paul Martz pma...@skew-matrix.com a écrit : The pros and cons of this was discussed not too long ago in the thread Drastic build time speed-up using precompiled headers. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ 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] osgOcean : GameDev have nice screenshot of ocean rendering.
Hi Adrian, Just FYI http://www.gamedev.net/community/forums/topic.asp?topic_id=558794 Yep, I saw the paper, here are a few more links: The paper itself: http://hal.archives-ouvertes.fr/inria-00443630 The author's page: http://evasion.inrialpes.fr/~Eric.Bruneton/ Looks great, something like that could be integrated as another OceanTechnique in osgOcean if someone wants to do it :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PagedLod and OpenGl Error : out of memory
Hi all, Using PagedLod in huge scene (about 30k nodes, 6M vertices with Low lods) I get a crash when I load a lot of PagedLods. After the datas loading, I move the camera into the scene to load High lod levels, and then I get a crash. In the logs the only error I saw is : Warning: detected OpenGL error 'mémoire insuffisante' after RenderBin::draw(,) CPU memory is not full when the crash occurs The stack strace is in nvoglnt.dll (Nvidia Opengl driver). My drivers are updated... Any idea of how to debug that crash or to get more informations ? Thanks a lot. Regards, Vincent. __ Information from ESET NOD32 Antivirus, version of virus signature database 4771 (20100114) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] general questions from a newbie
Hi, So here is my predicament. I am not really a graphics guy at all. The most I have done is taken a 1 week OpenGL class 10 yrs ago. Haven't looked at it since. I have been reading and reading and am overloaded with information. On top of that there is a lot that I just don't understand and am confused about. My specialty is GUI's and user friendliness, not graphics. I volunteered for this assignment to try to branch out some. The company I work for has an existing program from a project 4 yrs ago. It has a very simple 2D terrain map that shows points of interest with different icons. It was done on Windows with MFC. I have been tasked with doing the same thing for a current project that is done on Windows with QT. I have started looking at this. Currently on this project we have a QT GUI framework with many many possible windows that all can be opened, tiled, etc. in a common workspace. I need this map to be one of those windows. Ideally I want to be able to use Designer to make a GUI for the workspace. On that GUI will be a Frame, GroupBox, etc. widget or something that has nothing in it. I need to then pop this map into that area. Here are my current 2 big questions: 1) Is this type of integration even possible with QT? I really can't seem to find a definitive answer. Looking at the existing windows code there are functions that tie OSG with a Hwnd together. I guess I am looking for a similar way to tie the OSG and a QWidget together. 2) I am lost when they talk about Views, Viewports, Cameras, etc. The documentation doesn't really explain about all these, at least to where I can understand it and it sinks in. I have gone and looked at a few tutorials, but there isn't any comments, etc that delve into why this or that was done. I then wondered if this would be better covered as part of the underlying OpenGL stuff. Last night I was on the NeHe website and didn't see anything there either. Where is a good source to learn about this stuff? Thank you! Cheers, Justin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22618#22618 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] osgOcean bugs(?) and questions
This flickering black pixels seems to be related to back facing polygons and the water shader. Seems to related to the lookup into the environment map cube texture. Why does the osgOcean_EnvironmentMap cube texture get used for back facing polygons but not for the front facing? A comment in the shader seems to state that it used to be used for front facing polygons but was removed because of problems. Are these problems what I'm now seeing for back facing? Paul P. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22620#22620 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgDB::writeNodeFile() omits texture objects
I'm trying to dump the scene-graph. osgDB::writeNodeFile() writes geometry/colors ok, but (OSG 2.9.6) omits texture objects. Eg, when running osgviewer on the dumped .osg file, textures don't appear. Is this behavior of writeNodeFile() intentional? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLod and OpenGl Error : out of memory
Hi Vincent, I doubt there is a bug to debug, it's very much sounds like a pure issue of trying to rendering too much stuff at once that the graphics driver blows it's limits. Vista seems particular prone to not handling large amounts of graphics memory usage so one way to fix this would be try a different OS... The most robust fix will be to fix your databases so that don't bring in some much geometry and textures as it rather sounds like you are trying to put too much data in for capabilties of your system. Try scaling back the viewer master Camera's LODScale so that lower levels of details are chosen and thus lowering the system load. You could also try the new texture object and buffer object pools in svn/trunk to help limit the load. Robert. On Thu, Jan 14, 2010 at 3:31 PM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi all, Using PagedLod in huge scene (about 30k nodes, 6M vertices with Low lods) I get a crash when I load a lot of PagedLods. After the datas loading, I move the camera into the scene to load High lod levels, and then I get a crash. In the logs the only error I saw is : Warning: detected OpenGL error 'mémoire insuffisante' after RenderBin::draw(,) CPU memory is not full when the crash occurs The stack strace is in nvoglnt.dll (Nvidia Opengl driver). My drivers are updated... Any idea of how to debug that crash or to get more informations ? Thanks a lot. Regards, Vincent. __ Information from ESET NOD32 Antivirus, version of virus signature database 4771 (20100114) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.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] osgDB::writeNodeFile() omits texture objects
HI Jim, Are loading the scene, rendering and then writing out the scene graph? If so then it's likely that your scene graph as the Texture UnrefImageAfterApply enabled on them so that once the image data is downloaded to OpenGL the images get discarded so there's no handle to write them out to disk any more. By default this feature is off, but the osgUtil::Optimizer in it's default settings will enable it, so if you run the Optimzer this is probably the culprit. The DatabasePager also set up to enable this feature to help keep memory usage down. Robert. On Thu, Jan 14, 2010 at 3:46 PM, Jim Brooks jimbl...@gmail.com wrote: I'm trying to dump the scene-graph. osgDB::writeNodeFile() writes geometry/colors ok, but (OSG 2.9.6) omits texture objects. Eg, when running osgviewer on the dumped .osg file, textures don't appear. Is this behavior of writeNodeFile() intentional? ___ 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] Faster build with precompiled headers (PCH)?
Here is the original post you were referring to: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-August/015868.html Erik den Dekker On 14-01-2010, at 14:50, Paul Martz wrote: Interesting. I can't find it either if I search for that subject, but a search for precompiled headers does turn up a thread with that subject. I'm searching in the OSG-users Google Group. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 Sukender wrote: Hi Paul, I'm sorry, I did a search IN MY MAIL BOX and didn't find anything... but you're right, I should have searched the whole archives first! Well, to add a few details: - AFAIK, if you put only STL (and system headers?) in the PCH, you can avoid having to recompile the whole project each time you change osg/Node. The speedup is of course less, but it compensates a bit the slowness of MSVC. - The .h is automatically added to all .cpp files without having to change them (command line arg given in CMakeLists.txt). No special maintenance is to be made here. - However, you still got the thing I described in the previous mail: MSVC submitters must be warned to build without PCH before submitting. So maybe an OFF-by-default option would be fine? Anyway, I was just asking because I didn't find the thread... Silly me! And after all I guess it's far less important than other submissions ;) Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Paul Martz pma...@skew-matrix.com a écrit : The pros and cons of this was discussed not too long ago in the thread Drastic build time speed-up using precompiled headers. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Geocentric Database, how to flattening area or cut out piece
On 1/14/2010 1:43 AM, Luc Claustres wrote: Is it possible to flatten the geocentric database at specific coordiantes, or cut out speciffic areas, so the gap can be refilled with a completely flat area? Maybe you could also directly alter your input data with the GDAL rasterizer tool : http://www.gdal.org/gdal_rasterize.html I recently helped add support for GDAL rasterizing to the Z elevation of a polyline and polygon to the underlying GDAL rasterize code. I'm not sure this new functionality is accessible through the GDAL rasterize utility program yet, but this API is what my terrain deformation library uses internally. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ 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] PagedLOD DatabasePager crash
Greetings, Here's my steps: I'm creating a compositeViewer with one or more views. I'm loading a paged database. While the database is paging, I delete the compositeViewer (thus taking the context down with it as well as the database pager). I then create a new compositeViewer and attempt to render the sane database (same nodes). I'm getting a crash in the database pager, specifically it crash in the requestNodeFile function due to crashing on accessing invalid memory. The problem seems to step from the PagedLOD having a ref_ptr to a DatabasePager::DatabaseRequest. The databaseRequest has a raw pointer to a RequestQueue. The RequestQueue is invalid (as it is a referenced member of the original database pager, and thus is already deleted, but the DB request stayed alive). There appears to be no way of clearing the databaseRequest which is referenced in the PagedLOD node. This appears to be a problem with how OSG handles database paging, probably a bug. No obvious solution pops out, mainly due to the low level nature of the problem. This is an important issue since it affects one of our customers. I welcome any comments/suggestions/workarounds. Thank you and best regards, Colin Branch -- Colin Branch VT MAK work: (617) 876-8085 Ext. 159 email: cbra...@mak.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLOD DatabasePager crash
Hi Colin, You make no mention of which version of the OSG you are using. The DatabasePager and manage of GL objects when destroying contexts has improved significantly over the past year so the problems you are seeing may well be already resolved. Robert. On Thu, Jan 14, 2010 at 5:00 PM, Colin Branch cbra...@mak.com wrote: Greetings, Here's my steps: I'm creating a compositeViewer with one or more views. I'm loading a paged database. While the database is paging, I delete the compositeViewer (thus taking the context down with it as well as the database pager). I then create a new compositeViewer and attempt to render the sane database (same nodes). I'm getting a crash in the database pager, specifically it crash in the requestNodeFile function due to crashing on accessing invalid memory. The problem seems to step from the PagedLOD having a ref_ptr to a DatabasePager::DatabaseRequest. The databaseRequest has a raw pointer to a RequestQueue. The RequestQueue is invalid (as it is a referenced member of the original database pager, and thus is already deleted, but the DB request stayed alive). There appears to be no way of clearing the databaseRequest which is referenced in the PagedLOD node. This appears to be a problem with how OSG handles database paging, probably a bug. No obvious solution pops out, mainly due to the low level nature of the problem. This is an important issue since it affects one of our customers. I welcome any comments/suggestions/workarounds. Thank you and best regards, Colin Branch -- Colin Branch VT MAK work: (617) 876-8085 Ext. 159 email: cbra...@mak.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] [vpb] Geocentric Database, how to flattening area or cut out piece
Hi, is it possible to specifiy my polygon outline position and elevation, and GDAL rasterize code will interpolate correctly that this area is really flattend? or does it lift up/sink sown all coordinates inside the polygon to the specified value? How can I access the new API if now available via rasterize? Thank you, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22632#22632 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Geocentric Database, how to flattening area or cut out piece
On 1/14/2010 10:16 AM, Torben Dannhauer wrote: Hi, is it possible to specifiy my polygon outline position and elevation, and GDAL rasterize code will interpolate correctly that this area is really flattend? I'm not really sure what you're asking. or does it lift up/sink sown all coordinates inside the polygon to the specified value? This is what it does. You specify the BURN_VALUE_FROM_Z option and it no longer uses a constant value for a fill, rather it uses the Z value from the polyline/polygon. In the case of the polygon, it uses the value from the first vertex since interpolating non-constant values across a polygon interior is computationally messy. In the case of a polyline, it can use varying Z values from each vertex, interpolated linearly. It doesn't do any blending into the surrounding areas. That's the higher-level functionality that my library adds. How can I access the new API if now available via rasterize? Look at the GDAL rasterize API in the latest GDAL subversion checkout. I think GDAL 1.7 will have the new feature once it's released publicly. Thank you, Torben -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ 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] PagedLOD DatabasePager crash
Robert, I'm using 2.8.2 and I verified the problem exists in the trunk. -Colin On 1/14/2010 12:13 PM, Robert Osfield wrote: Hi Colin, You make no mention of which version of the OSG you are using. The DatabasePager and manage of GL objects when destroying contexts has improved significantly over the past year so the problems you are seeing may well be already resolved. Robert. On Thu, Jan 14, 2010 at 5:00 PM, Colin Branchcbra...@mak.com wrote: Greetings, Here's my steps: I'm creating a compositeViewer with one or more views. I'm loading a paged database. While the database is paging, I delete the compositeViewer (thus taking the context down with it as well as the database pager). I then create a new compositeViewer and attempt to render the sane database (same nodes). I'm getting a crash in the database pager, specifically it crash in the requestNodeFile function due to crashing on accessing invalid memory. The problem seems to step from the PagedLOD having a ref_ptr to a DatabasePager::DatabaseRequest. The databaseRequest has a raw pointer to a RequestQueue. The RequestQueue is invalid (as it is a referenced member of the original database pager, and thus is already deleted, but the DB request stayed alive). There appears to be no way of clearing the databaseRequest which is referenced in the PagedLOD node. This appears to be a problem with how OSG handles database paging, probably a bug. No obvious solution pops out, mainly due to the low level nature of the problem. This is an important issue since it affects one of our customers. I welcome any comments/suggestions/workarounds. Thank you and best regards, Colin Branch -- Colin Branch VT MAK work: (617) 876-8085 Ext. 159 email: cbra...@mak.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 -- Colin Branch VT MAK work: (617) 876-8085 Ext. 159 email: cbra...@mak.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PagedLod dataBasePager memory managment
Hi Robert, Robert Osfield a écrit : Hi Vincent, On Fri, Jan 8, 2010 at 2:30 PM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Is there a way to manage memory usage with the load of models ? In my case I have a lot of PagedLod to load, and my question is : is there a way to know is memory is sufficient for the next PageLod higher level node ? I just would like to stop the data loading when memory usage exceed some point. The DatabasePager in svn/trunk + 2.9.x has the ability to cap the number of PagedLOD to a maximum, and automatically recycles PagedLOD children that aren't in the current view when new PagedLOD are required by the current view. What this capping doesn't do is stop the loading of new PagedLOD, so if a single view requires a PagedLOD it will be loaded. To set the cap level programmatically via: viewer.getDatabasePager()-setTargetMaximumNumberOfPageLOD(targetNumOfPaged); Or using env var: set OSG_MAX_PAGEDLOD=200 I don't understand how this is working. If a pagedLod is required it will be loaded... but we can cap the number of lod... This sounds contradictory for me. The number of PagedLod you were speaking about is the PagedLod children or the number of PagedLod node in the scene ? Another feature of svn/trunk + 2.9.x is that texture and buffer object's pools that also provide a maximum cap on the number of texture objects and vbo/pbo/ebo's that can be allocated at any one time. You can set it programmatically via: osg::Texture::getTextureObjectManager(contextID)-setNumberActiveTextureObjects(targetNumBytes); Or using env var: set OSG_TEXTURE_POOL_SIZE=64000 Like the PagedLOD target, the texture pool size is only a target, and if a single frame requires more memory than this it will allocated more memory to prevent any thrashing of memory within a single frame. I did do tests with a strict limit on memory size but when a single frame requires more than this the memory thrashing cut performance down to a fraction of it's normal, for instance going from a solid 60Hz to 1 or 2Hz. There are no textures in my scene... but this is good to know. If you wanted the LOD control then you just implement this yourself using osgDB::Registry::ReadFileCallback that loads the tiles and then modifies PagedLOD that it loads that are higher than a certain resolution. Do you mean that using my own readFileCallback is not sufficient and I'll need to modify PagedLod sources too ? Thanks. Regards, Vincent. __ Information from ESET NOD32 Antivirus, version of virus signature database 4771 (20100114) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Adding DatabasePager to VRJuggler for PagedLOD Support
I am working on a VRJuggler project that uses OSG as its scenegraph. I need
to use a PagedLOD for the terrain because of its size. I used Virtual
Planet Builder to generate the PagedLOD and added that PagedLOD to the
scenegraph as a node. The application shows only the lowest resolution
model of the terrain.
I found a message in the osg-users and vpb archive titled LOD Problem from
26 May 2009 about the same problem. Simply, VRJuggler uses
osgUtil::SceneView and not osgViewer so support for database paging is not
present. Supposedly, if that support were added, it PagedLODs would operate
properly.
I have tried to build support for osgDB::DatabasePager into my application
as it is included in osgViewer but that has not solved my problem. The
modifications to the generic OSG Juggler sample app code are at the end of
this message. I would appreciate any advice on either what I have missed or
what I have not done correctly in this code. I can send the entire
Application.cpp file if needed.
Thank you for your help,
Levi
The code segments:
void Application::init()
{
// Initialize the head proxy - used for keeping time
_head.init(VJHead);
}
void Application::initScene()
{
_rootNode = getScene();
setDatabasePager(osgDB::
DatabasePager::create());
setImagePager(new osgDB::ImagePager);
_databasePager-registerPagedLODs(getScene()); // I assume this looks
for PagedLODs in the entire scenegraph?
}
osg::Group* Application::getScene()
{
// return the current scene graph
return theSceneGraph().rootGroupNode();
}
void Application::setDatabasePager(osgDB::DatabasePager* dp)
{
_databasePager = dp;
}
void Application::setImagePager(osgDB::ImagePager* ip)
{
_imagePager = ip;
}
void Application::preFrame()
{
// Get time from juggler head proxy
_headTime = _head-getTimeStamp().secd();
vrj::OsgApp::preFrame();
}
void Application::latePreFrame()
{
if(_frameStamp) {
_databasePager-registerPagedLODs(getScene()); // this should not be
necessary
// Update all the framestamp information
_frameStamp-setFrameNumber(_frameCount);
_frameStamp-setReferenceTime(_headTime);
_frameStamp-setSimulationTime(_headTime);
_frameCount++;
update();
}
vrj::OsgApp::latePreFrame();
}
void Application::configSceneView(osgUtil::SceneView* newSceneViewer)
{
_frameStamp = new osg::FrameStamp;
newSceneViewer-setFrameStamp(_frameStamp.get());
}
void Application::update()
{
_databasePager-updateSceneGraph(*_frameStamp);
_imagePager-updateSceneGraph(*_frameStamp);
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Adding DatabasePager to VRJuggler for PagedLOD Support
Levi Swartzentruber wrote: I am working on a VRJuggler project that uses OSG as its scenegraph. I need to use a PagedLOD for the terrain because of its size. I used Virtual Planet Builder to generate the PagedLOD and added that PagedLOD to the scenegraph as a node. The application shows only the lowest resolution model of the terrain. I found a message in the osg-users and vpb archive titled LOD Problem from 26 May 2009 about the same problem. Simply, VRJuggler uses osgUtil::SceneView and not osgViewer so support for database paging is not present. Supposedly, if that support were added, it PagedLODs would operate properly. I have tried to build support for osgDB::DatabasePager into my application as it is included in osgViewer but that has not solved my problem. The modifications to the generic OSG Juggler sample app code are at the end of this message. I would appreciate any advice on either what I have missed or what I have not done correctly in this code. I can send the entire Application.cpp file if needed. Hi, Levi, I had to do something similar for a different library (VESS). I haven't looked at VR Juggler in many years, but it seems like you're on the right track so far. Some things you appear to be missing... During configuration of the SceneView, you'll need these: * osgSceneView-getCullVisitor()-setDatabaseRequestHandler(osgDatabasePager) * osgDatabasePager-setCompileGLObjectsForContextID(osgSceneView-getState()-getContextID(), true) Before a frame render (perhaps in the update method) * osgDatabasePager-updateSceneGraph(*osgFrameStamp) * osgDatabasePager-signalBeginFrame() After a frame render, * osgDatabasePager-compileGLObjects(*(osgSceneView-getState()), availableTime) * osgSceneView-flushDeleteGLObjects(availableTime) * osgDatabasePager-signalEndFrame() I think that's all of them. Hopefully you can deduce what goes where from the above :-) This works for our library, at least in the case of one active DatabasePager and one active SceneView. I don't know that we've ever tested multiple pagers/views, although we did code for it (you need a separate DatabasePager for each distinct scene, but multiple SceneViews can share a DatabasePager if they also share the scene). Right now we're in the process of porting our stuff to use osgViewer, which does all of this and more for you. I'd recommend the same for you guys, if you can find the time :-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Disabling rendering
This might sound like an odd question, but is there a way to disable rendering (no culling and no draw) while still allowing intersections. The reason why I am asking is because I have a distributed system - i.e. some applications only performs intersections with the scene without rendering it. In addition, the osg update call must still occur since that's where some of my animation states gets uptate, which will change the outcome of intersection results (like sprites). Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22641#22641 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MinGW and OpenSceneGraph
Hi Jean-Sébastien Robert, thanks for the feedback! @Robert: I've actually written a tutorial that describes how to setup a c/c++ development environment which I'm using to compile OpenSceneGraph. It also includes the version numbers. http://www.multigesture.net/articles/how-to-install-mingw-msys-and-eclipse-on-windows/ @Jean-S (1) libjpeg That's strange, I don't know if mingw32 on ubuntu is using the same files as on windows. I'm currently not using the offical verison of MinGW (latest verison 5.1.6, http://sourceforge.net/projects/mingw/files/) because it is using a GCC compiler version 3.x. Instead I'm using a build from http://nuwen.net/mingw.html#download (currently using 4.3) which is bundled with a more recent GCC compiler (version 4.3.3). The package also includes libjpeg version 7. (2) freetype While this indeed solve the issue without modifying the code, it moves the problem to the shell. Since users still need to manually type this fix... (3) curl That should probably do the trick, I'll see if I can make it work. Hopefully I have some more time next week to investigate the possible fixes and submit a patch. Kind regards, - Laurence --- From: Jean-Sébastien Guay jean-sebastien.g...@---.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: Wed, 13 Jan 2010 01:57:04 -0500 Subject: Re: [osg-users] MinGW and OpenSceneGraph Hi Laurence, I investigated your issues a bit more. Here is what I found: (1) osgPlugin: jpeg Problem: boolean is not defined This comes from the fact that the version of the jpeg headers included in MinGW defines JPEG_boolean (and JPEG_FALSE/JPEG_TRUE) instead of boolean ( and FALSE/TRUE). I think this is a good idea as it avoids possible name clashes, but in this case it causes problems. What I find weird is that I looked at both the headers in the Win32 VC8 dependencies package (which is fairly old) and the headers on an up-to-date Ubuntu install, and both define straight boolean (not JPEG_boolean as the MinGW header defines). In both cases, the jmorecfg.h header states: Copyright (C) 1991-1997, Thomas G. Lane. The MinGW header states: Copyright (C) 1991-1997, Thomas G. Lane. Modified 1997-2009 by Guido Vollbeding. So it would seem the MinGW header is more recent, or just that it includes changes that were not integrated into the baseline? That seems a bit weird to me, that the MinGW header would be more recent than what's on an up-to-date Ubuntu install... Anyways, I'll see if I can code up a solution that will allow us to compile in both cases. (2) osgPlugin: freetype Problem: It can't find the freetype header files Actually, you could fix this without any code changes: 1. open an msys prompt 2. cd /mingw/include 3. ln -s freetype2 freetype That way the include files will be found. (3) osgPlugin: curl As I said, the required libraries are added at src/osgPlugins/curl/ CMakeLists.txt inside an IF(WIN32) which works for VC++ builds. Seems the Msys build doesn't go into that IF, so I'll look into adding the proper check (probably || MINGW or something like that. That should take care of it. Stay tuned... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] HUD - force refresh
Hi everyone,
I'm new around here, but I'll try to think the questions through, at least for
the first couple of days :)
So, to the point:
I have a scene with a small HUD, and in that HUD a text that is changing based
on some keypresses. What I'm trying to do is, in the event handler, set an
update callback for the text, and then, immediately after that, start an
algorithm on the scene. The callback is supposed to measure the total time of
that algorithm.
The images in the attachment illustrate the point.
The code of the keyboard press handler looks like this:
Code:
if ( ea.getKey()==osgGA::GUIEventAdapter::KEY_F5 )
{
if (fnn.getNode() != NULL)
{
osg::Object* obj =
dynamic_castosg::Object*(dynamic_castosg::Geode*(fnn.getNode())-getDrawable(0));
osgText::Text* hudText =
dynamic_castosgText::Text*(obj);
BruteForceCallback* bfCb = new
BruteForceCallback();
hudText-setUpdateCallback(bfCb);
/*
for (int i = 0; i 10; i++)
for (int j = 0; j 2; j++)
{
int x = 0;
x += 5;
}
std::cout Finished. std::endl;
*/
//hudText-setUpdateCallback(NULL);
//hudText-setText(Algorithm: +
bfCb-getAlgorithmName()
// + \nCamera positioned.\nTotal time:
+ bfCb-getTimeAsString());
}
return true;
}
The for loop is a placeholder, and I've tried adding to it commands such as
requestRedraw() and frame(), but then the program freezes. Without it, it of
course waits until the for loop is done, and then updates the text.
I probably should have asked this question before implementing the callbacks,
but better late than never :) , so how can I force the update of the HUD text
periodically during the calculations? Is this a good way to do it at all? I'd
really prefer a single-threaded program...
And one last question:
the program crashes on hudText-setUpdateCallback(NULL);
How do I remove the callback properly after the algorithm is done?
Thank you so much for any help!
Cheers,
Inos [/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=22643#22643
Attachments:
http://forum.openscenegraph.org//files/afterkeypress_163.png
http://forum.openscenegraph.org//files/beforekeypress_652.png
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MinGW and OpenSceneGraph
Hi Laurence, @Jean-S (1) libjpeg That's strange, I don't know if mingw32 on ubuntu is using the same files as on windows. I'm currently not using the offical verison of MinGW (latest verison 5.1.6, http://sourceforge.net/projects/mingw/files/) because it is using a GCC compiler version 3.x. Instead I'm using a build from http://nuwen.net/mingw.html#download (currently using 4.3) which is bundled with a more recent GCC compiler (version 4.3.3). The package also includes libjpeg version 7. Yes, and I'm using the same installer to test with. I actually started with your tutorial on installing MinGW and MSYS, and then customized a few things. :-) (2) freetype While this indeed solve the issue without modifying the code, it moves the problem to the shell. Since users still need to manually type this fix... But I think it's better to make the code general and let links handle the difference than the opposite. Else the code becomes a spaghetti of #if(MINGW) #elsif(...) ... A symlink is a simple and clean way to make your system's directory structure look more standard. Since thousands of developers actively use OSG on various flavors of Linux, and it uses freetype/..., I think making MinGW follow this (even if by default it puts the headers in freetype2/...) is a more general solution. (3) curl That should probably do the trick, I'll see if I can make it work. I've actually fixed the problem in my local checkout at home, but I had a few more tests to do yesterday and it was late so I opted to go sleep and send the fixes tomorrow (today). So I will hopefully send the fixes I needed to use to build OSG on MinGW/MSYS tonight. I had a few more fixes to make than what you said, but perhaps they're in things you didn't opt to compile, like osgmovie, osgviewerSDL, the TXP plugin, ... Stay tuned, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling rendering
Hi Guy, This might sound like an odd question, but is there a way to disable rendering (no culling and no draw) while still allowing intersections. The reason why I am asking is because I have a distributed system - i.e. some applications only performs intersections with the scene without rendering it. In addition, the osg update call must still occur since that's where some of my animation states gets uptate, which will change the outcome of intersection results (like sprites). Intersections are completely separate from cull and draw, so you can always do intersections even if no rendering is happening. But the hard part is getting the update visitor to run on your subgraph but not the cull visitor (the results of the cull visitor are used for rendering, so if the cull visitor doesn't run on a subgraph then that subgraph will not be rendered). There's a few ways to do it, I guess I would do that with a cull callback set on the root node of the subgraph you don't want to render, and which doesn't call traverse(node, nv);. That way the cull traversal will stop there for that subgraph, and won't visit the children. But since there's no similar update callback, the update traversal will traverse the whole thing. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling rendering
Guy Volckaert wrote: This might sound like an odd question, but is there a way to disable rendering (no culling and no draw) while still allowing intersections. The reason why I am asking is because I have a distributed system - i.e. some applications only performs intersections with the scene without rendering it. In addition, the osg update call must still occur since that's where some of my animation states gets uptate, which will change the outcome of intersection results (like sprites). If using osgViewer, don't call viewer.frame(). If you still want the update traversal, run the UpdateVisitor by hand. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Geocentric Database, how to flattening area or cut out piece
Chris 'Xenon' Hanson wrote: It doesn't do any blending into the surrounding areas. That's the higher-level functionality that my library adds. Something simple I tested and which helps producing a smooth blend is to upsample the elevation, rasterize your polygon, then downsample back to the original resolution. It is easy with the GDAL tools or API. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22647#22647 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] light lobes and shadow maps
Hi community, I have some shader that does some lighting in the scene. Now studying osgShadow and the techniques. I want to a shadow map technique to disable the lightening of the scene behind obstacles. I have some code done, but not working. I need some help, someone experienced with GLSL to spend a minute or to to have a look and if possible to spot the problem. Anyone? Thanks a lot Nick http://www.linkedin.com/in/tnick Sent from Izmit, 41, Turkey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling rendering
Paul. Thanks for the advice. What I ended-up doing is overriding the void ViewerBase::frame(double simulationTime) function. Depending on the state of a rendering flag, I either call or don't call the renderingTraversals() function. Hopefully, that won't cause any other issues. Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22648#22648 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Geocentric Database, how to flattening area or cut out piece
On 1/14/2010 12:52 PM, Luc Claustres wrote: It doesn't do any blending into the surrounding areas. That's the higher-level functionality that my library adds. Something simple I tested and which helps producing a smooth blend is to upsample the elevation, rasterize your polygon, then downsample back to the original resolution. It is easy with the GDAL tools or API. Not a bad idea. I needed a configurable blend curve, so your trick (effectively a linear blend) wouldn't work for me, but good suggestion. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ 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] general questions from a newbie
jterpstra wrote: 1) Is this type of integration even possible with QT? Yes, you can embed a OSG view into a Qt frame, dock window etc. There are two ways to do this shown in the osgViewerQt example. Adapterwindow is easiest, the oosgwidget needs a little fix on windows to stop a redrawing bug. (see http://forum.openscenegraph.org/viewtopic.php?t=4432) 2) I am lost when they talk about Views, Viewports, Cameras, etc. Where is a good source to learn about this stuff? These are roughly the same as in Opengl. The more important thing to learn is how osg:: Nodes, Geoeds, Geometries and Drawables go together The best place to start is Paul Marz's book http://www.osgbooks.com/books/osg_qs.html All this migth be overkill for a 2d map. The new Qt drawing canvas is very good, have you looked at the quartely newslatter on Qt's site? It's free as a download or you can buy a paper copy. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22651#22651 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light lobes and shadow maps
Hi Nick, This is not really an answer to your question, but for my application I used an attenuation factor (proportional to the squared distance) to avoid light behind obstacles (obstacles are generally far from my lights in my application). Maybe you can use one too. By the way, could you tell me how many lights you have? Josselin. This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] light lobes and shadow maps
Hi Nick, Post the troublesome code and elaborate a bit more about the problem. If its really a minute or two I am sure someone will be able to help. Wojtek Lewandowski From: Trajce Nikolov Sent: Thursday, January 14, 2010 8:58 PM To: OpenSceneGraph Users Subject: [osg-users] light lobes and shadow maps Hi community, I have some shader that does some lighting in the scene. Now studying osgShadow and the techniques. I want to a shadow map technique to disable the lightening of the scene behind obstacles. I have some code done, but not working. I need some help, someone experienced with GLSL to spend a minute or to to have a look and if possible to spot the problem. Anyone? Thanks a lot Nick http://www.linkedin.com/in/tnick Sent from Izmit, 41, Turkey ___ 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] general questions from a newbie
second post . -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22654#22654 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] general questions from a newbie
I found some posts later this morning: http://forum.openscenegraph.org/viewtopic.php?t=3004 http://lists.openscenegraph.org/htdig.cgi/osg-submissions-openscenegraph.org/2009-June/004578.html (kinda dumb it won't let my post URLs until I have 2 posts arg) It seams pretty informative and more attuned to what I am trying to do. I finally just got it all compiling and working. Tomorrow I will start examining the code, tweaking things, and really playing with it. I am fairly confident this will be good enough to get me going. Overall I am not too worried about understanding the nodes etc and how they go together right now. For the most part I won't need to change that part of the existing code. What I do have to do is take the existing drawing code as it works under a Windows project and shoe-horn it into a QT project. Most likely this is all overkill for our simple 2D map. I am just excited since the more I pick up in the graphics area, the more options I have for work here at my job. Thanks for the help guys. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22655#22655 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] general questions from a newbie
Just a follow up question on this, does QT allow a multi-threaded embedded osgViewer or is it knocked down to single threaded like what happens to osgViewer embedded in GLUT? -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Beckett Sent: Thursday, January 14, 2010 1:28 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] general questions from a newbie jterpstra wrote: 1) Is this type of integration even possible with QT? Yes, you can embed a OSG view into a Qt frame, dock window etc. There are two ways to do this shown in the osgViewerQt example. Adapterwindow is easiest, the oosgwidget needs a little fix on windows to stop a redrawing bug. (see http://forum.openscenegraph.org/viewtopic.php?t=4432) 2) I am lost when they talk about Views, Viewports, Cameras, etc. Where is a good source to learn about this stuff? These are roughly the same as in Opengl. The more important thing to learn is how osg:: Nodes, Geoeds, Geometries and Drawables go together The best place to start is Paul Marz's book http://www.osgbooks.com/books/osg_qs.html All this migth be overkill for a 2d map. The new Qt drawing canvas is very good, have you looked at the quartely newslatter on Qt's site? It's free as a download or you can buy a paper copy. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22651#22651 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Adding DatabasePager to VRJuggler for PagedLOD Support
Those comments were very helpful. I am able to get the VR Juggler application to display the PagedLOD properly but I still have one problem. I can only move a set distance around the terrain before the program seg faults. The line that causes the problem is osgSceneView-flushDeletedGLObjects(availableTime);. If I comment out that line, I do not get a segmentation fault, but the frame rate drops steadily while the application runs. Is this a threading or context issue? Any help would be greatly appreciated. Thank you, Levi On Thu, Jan 14, 2010 at 1:14 PM, Jason Daly jd...@ist.ucf.edu wrote: Levi Swartzentruber wrote: I am working on a VRJuggler project that uses OSG as its scenegraph. I need to use a PagedLOD for the terrain because of its size. I used Virtual Planet Builder to generate the PagedLOD and added that PagedLOD to the scenegraph as a node. The application shows only the lowest resolution model of the terrain. I found a message in the osg-users and vpb archive titled LOD Problem from 26 May 2009 about the same problem. Simply, VRJuggler uses osgUtil::SceneView and not osgViewer so support for database paging is not present. Supposedly, if that support were added, it PagedLODs would operate properly. I have tried to build support for osgDB::DatabasePager into my application as it is included in osgViewer but that has not solved my problem. The modifications to the generic OSG Juggler sample app code are at the end of this message. I would appreciate any advice on either what I have missed or what I have not done correctly in this code. I can send the entire Application.cpp file if needed. Hi, Levi, I had to do something similar for a different library (VESS). I haven't looked at VR Juggler in many years, but it seems like you're on the right track so far. Some things you appear to be missing... During configuration of the SceneView, you'll need these: - osgSceneView-getCullVisitor()-setDatabaseRequestHandler(osgDatabasePager) - osgDatabasePager-setCompileGLObjectsForContextID(osgSceneView-getState()-getContextID(), true) Before a frame render (perhaps in the update method) - osgDatabasePager-updateSceneGraph(*osgFrameStamp) - osgDatabasePager-signalBeginFrame() After a frame render, - osgDatabasePager-compileGLObjects(*(osgSceneView-getState()), availableTime) - osgSceneView-flushDeleteGLObjects(availableTime) - osgDatabasePager-signalEndFrame() I think that's all of them. Hopefully you can deduce what goes where from the above :-) This works for our library, at least in the case of one active DatabasePager and one active SceneView. I don't know that we've ever tested multiple pagers/views, although we did code for it (you need a separate DatabasePager for each distinct scene, but multiple SceneViews can share a DatabasePager if they also share the scene). Right now we're in the process of porting our stuff to use osgViewer, which does all of this and more for you. I'd recommend the same for you guys, if you can find the time :-) --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] Adding DatabasePager to VRJuggler for PagedLODSupport
Levi Swartzentruber wrote: Those comments were very helpful. I am able to get the VR Juggler application to display the PagedLOD properly but I still have one problem. I can only move a set distance around the terrain before the program seg faults. The line that causes the problem is osgSceneView-flushDeletedGLObjects(availableTime);. If I comment out that line, I do not get a segmentation fault, but the frame rate drops steadily while the application runs. Is this a threading or context issue? Any help would be greatly appreciated. Not sure. I don't recall having any issues with the DatabasePager in our code (I'm sure there was one or two, but they weren't memorable enough for me to recall right now). All of our rendering is currently single-threaded (although the DatabasePager does run in its own thread). We never had the need for any special thread protection. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Zoom effect
Hi Gene, On 14/01/10 8:11 PM, Gene Permel wrote: I use the setProjectionMatrixAsPerspective that performs what I need but the only problem is when I zoom out too much, my model streches until zoom in to the previous fovy values. How could I fix this? That is a common effect when you open the field-of-view of the camera. There's no way to 'fix' that because it's not broken. You can try to move the camera (dolly in/out while keeping fov const) or use a ortho projection and change the projection width. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewport inheritance and RTT
Hi,
Thanks for your answer.
In relation to your comment:
I'm still not sure why you want to use a slave? I remember something
you
said about shadows, but don't understand why shadows should differ
between slave/not slave. Pre-render should work fine with just an RTT
camera placed somewhere in the graph and in this case you can set
everything manually.
I am using an RTT camera placed somewhere in the graph and I am setting
everything manually. As far as I can tell I am using a very simple,
basic case for RTT (it doesn't actually involve shadows). This is why I
am so stuck on what can be going wrong.
I will modify one of the examples to match what I am doing so I can
examine the issue in a very simple setup and go from there. I am really
stuck on what to do to try and fix this. Thanks again for your help.
Cheers,
Brad
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P.
Delport
Sent: Thursday, 14 January 2010 4:11 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Viewport inheritance and RTT
Hi,
Christiansen, Brad wrote:
Hi,
Just 'resubmitting' my issue with a more simple question to see if
anyone has any ideas.
What are the rules with viewport inheritance?
- My understanding is:
If a camera has a viewport set, this is used when rendering the
cameras
sub-graph. If it is not set, it uses the parent cameras viewport.
- What I am seeing:
My pre-render camera (rendering to a texture) has a viewport set but
its
sub-graph is being rendered using its parent cameras viewport. I have
double checked that the viewport is set during the cull traversal. The
pre-render cameras viewport is placed on the stack, and set on the
RenderStage used to render the camera, yet it is still rendered using
the parents viewport.
- My question/s:
What could cause this to occur? i.e. when is a local viewport ignored
and 'overridden' by a parents viewport.
What should I look at to debug this? I am not sure what to check after
seeing the Renderstage apparently setup correctly.
sorry, I can't answer all your questions.
I don't think this goes as deep as renderstage. Have a look at View and
Viewer and check the handling of slaves. Check where addSlave adds the
View and then check where the list of views is used.
I am completely stumped now and this is proving a bit of a
show-stopper
for me. Any suggestions on what to look at would be greatly
appreciated.
I'm still not sure why you want to use a slave? I remember something you
said about shadows, but don't understand why shadows should differ
between slave/not slave. Pre-render should work fine with just an RTT
camera placed somewhere in the graph and in this case you can set
everything manually.
jp
Cheers,
Brad
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Christiansen, Brad
Sent: Tuesday, 12 January 2010 10:59 AM
To: OpenSceneGraph Users
Subject: [osg-users] Viewport inheritance and RTT
Hi,
I have a scene setup with a texture attached to a camera which is
setup
for pre-rendering.
In my scene I set the viewport for the RTT camera to the dimensions of
the texture. Despite having done this, the viewport for the RTT camera
is being inherited from the main scenes camera, i.e. if the viewport
of
the main camera is (0,0,8000,600) then only this section of the
texture
is rendered, despite the viewport for the rtt camera being
(0,0,1024,1024).
I have stepped through the CullVistor with a debugger and have found
that the viewport does seem to be setup correctly by the cull visitor.
By the time I get to this section of the CullVisitor:
switch(camera.getRenderOrder())
{
case osg::Camera::PRE_RENDER:
//In the following line the viewport for the camera and the rtts is
correct
getCurrentRenderBin()-getStage()-addPreRenderStage(rtts.get(),camera.g
etRenderOrderNum());
break;
default:
getCurrentRenderBin()-getStage()-addPostRenderStage(rtts.get(),camera.
getRenderOrderNum());
break;
}
the viewport seems to have been setup correctly. Both the rtts's
viewport and the cameras viewport is (0,0,1024,1024), but when it is
rendered this is not the viewport that is used.
I am not quite sure where to go from here. Does anyone have any
suggestions on what I may have done wrong or what area I should debug
next?
I am using version 2.9.5 of OSG.
Cheers,
Brad
DISCLAIMER:-
--
This e-mail transmission and any documents, files and previous e-mail
messages
attached to it are private and confidential. They may contain
proprietary or copyright
material or information that is subject to legal professional
privilege.
They are for
the use
[osg-users] [build] How do I compile an OSG app, so that it can be run without the OSG installed?
Hi there. How do I compile an OSG app, so that it can be run, on another computer, without the OSG installed (dlls and libs)? I just want to be able to send my app, for instance, via email, so that someone may run or test it on another pc, even without having OSG installed on it. I remember doing it, under unix, some 15 years ago, with C, with my own libraries, but I've never tried it under Windows. Thank you in advance. Agos -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22660#22660 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How do I compile an OSG app, so that it can be run without the OSG installed?
On 1/14/2010 6:03 PM, Agos Silva wrote: How do I compile an OSG app, so that it can be run, on another computer, without the OSG installed (dlls and libs)? Static linking. It's an option in CMake now, if I recall. I think there are some instructions on the OSG web site too, because plugins have special requirements for static linking. Beware, some plugins have LGPL code and therefore have license problems if you staticlly link them in non-(L)GPL code. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ 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] Is PolytopeIntersector a good choice for multiple selection?
Hi,
I've a scene with only a handful of Geodes (under 200).
If I wanted to detect which objects were selected within a 2D rectangle on
screen (think clicking, holding, dragging out a rectangle over the view) -
would a PolytopeIntersector be a good choice?
Code:
osgUtil::PolytopeIntersector *picker = new osgUtil::PolytopeIntersector(cf,
fmin(downX, lastX),
fmin(downY, lastY),
fmax(downX, lastX),
fmax(downY, lastY));
osgUtil::IntersectionVisitor iv(picker);
view-getCamera()-accept(iv);
if(picker-containsIntersections()) {
// do stuff
}
I ask because I've tried (using the above) - where downX/Y are filled in on
mouse down - and as soon as the selection encompasses a number of geodes it
really slows down, considerably (I'm doing this every time the mouse position
changes, e.g: ::DRAG). I suspect I'm doing something wrong / using the
polytope incorrectly perhaps?
Any pointers?
I'm considering using a nodemask to only examine the few things I need to test
for (ends up being about 12 quads). But wondering if I'm doing things
incorrectly from the outset...
Cheers,
Neil
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=22664#22664
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MinGW and OpenSceneGraph
Hi Laurence, While creating this tutorial I found some minor issues (In the tutorial I explain how to patch it): I have just sent the fixes I could come up with to osg-submissions. You can look at the message here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.cvs/6738 You can also download the zip with the modified source files. If you want to try, please download it and copy the unzipped directory structure over a fresh SVN checkout of the OSG source and see if you have less problems. For now though I have opted to keep the solution I gave for the freetype plugin, i.e. cd /mingw/include ln -s freetype2 freetype We'll see what Robert says about that, but I personally think it's better to have a standard path, and if one type of system has a different path then use symlinks to make it conform to the standard. Other than that, I had more issues than you apparently had, but I hope most if not all of them are fixed by my changes. I tested what I could and almost everything worked as it should (sound in osgmovie and the Qt examples being the only exceptions). Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Starting out
We have an existing visual simulation that is based on Performer. We know have to add collision detection with landmasses and the sea bottom. I was thinking of using OpenSceneGraph to place the vehicles in the world and use Bullet to do the actual collision detections. At this stage I don't need any rendering but since my vehicle models are all in OpenFlight format and I have access to some DTED Level 1 data I thought this was the way to go. What I am after is example programs which have the vehicles drawn at their latitude, longitude and altitude and shows the sort of collisions that I am after. To speed things up I am only interested certain vehicles. I intend to have my existing program talk to the collision detection program via shared memory so I either I need a separate thread which deals with reading and writing to this shared memory and updating the collision program with where the vehicles are in the world. Any help would be most appreciated. Tony Vasile CSC Australia ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Viewport inheritance and RTT
Hi,
For the record, I have found a workaround for the issue.
To fix the problem, I did the following the RTT Camera:
ss = rttCamera-getOrCreateStateSet();
osg::Viewport* vp = new osg::Viewport(0,0,textureSize,textureSize);
ss-setAttributeAndModes(vp, osg::StateAttribute::OVERRIDE
osg::StateAttribute::ON);
It was my understanding that this would have the same effect as just
setting on the viewport on the camera. However, this works, but just
setting the viewport doesn't.
Cheers,
Brad
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Christiansen, Brad
Sent: Friday, 15 January 2010 8:55 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Viewport inheritance and RTT
Hi,
Thanks for your answer.
In relation to your comment:
I'm still not sure why you want to use a slave? I remember something
you
said about shadows, but don't understand why shadows should differ
between slave/not slave. Pre-render should work fine with just an RTT
camera placed somewhere in the graph and in this case you can set
everything manually.
I am using an RTT camera placed somewhere in the graph and I am setting
everything manually. As far as I can tell I am using a very simple,
basic case for RTT (it doesn't actually involve shadows). This is why I
am so stuck on what can be going wrong.
I will modify one of the examples to match what I am doing so I can
examine the issue in a very simple setup and go from there. I am really
stuck on what to do to try and fix this. Thanks again for your help.
Cheers,
Brad
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P.
Delport
Sent: Thursday, 14 January 2010 4:11 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Viewport inheritance and RTT
Hi,
Christiansen, Brad wrote:
Hi,
Just 'resubmitting' my issue with a more simple question to see if
anyone has any ideas.
What are the rules with viewport inheritance?
- My understanding is:
If a camera has a viewport set, this is used when rendering the
cameras
sub-graph. If it is not set, it uses the parent cameras viewport.
- What I am seeing:
My pre-render camera (rendering to a texture) has a viewport set but
its
sub-graph is being rendered using its parent cameras viewport. I have
double checked that the viewport is set during the cull traversal. The
pre-render cameras viewport is placed on the stack, and set on the
RenderStage used to render the camera, yet it is still rendered using
the parents viewport.
- My question/s:
What could cause this to occur? i.e. when is a local viewport ignored
and 'overridden' by a parents viewport.
What should I look at to debug this? I am not sure what to check after
seeing the Renderstage apparently setup correctly.
sorry, I can't answer all your questions.
I don't think this goes as deep as renderstage. Have a look at View and
Viewer and check the handling of slaves. Check where addSlave adds the
View and then check where the list of views is used.
I am completely stumped now and this is proving a bit of a
show-stopper
for me. Any suggestions on what to look at would be greatly
appreciated.
I'm still not sure why you want to use a slave? I remember something you
said about shadows, but don't understand why shadows should differ
between slave/not slave. Pre-render should work fine with just an RTT
camera placed somewhere in the graph and in this case you can set
everything manually.
jp
Cheers,
Brad
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Christiansen, Brad
Sent: Tuesday, 12 January 2010 10:59 AM
To: OpenSceneGraph Users
Subject: [osg-users] Viewport inheritance and RTT
Hi,
I have a scene setup with a texture attached to a camera which is
setup
for pre-rendering.
In my scene I set the viewport for the RTT camera to the dimensions of
the texture. Despite having done this, the viewport for the RTT camera
is being inherited from the main scenes camera, i.e. if the viewport
of
the main camera is (0,0,8000,600) then only this section of the
texture
is rendered, despite the viewport for the rtt camera being
(0,0,1024,1024).
I have stepped through the CullVistor with a debugger and have found
that the viewport does seem to be setup correctly by the cull visitor.
By the time I get to this section of the CullVisitor:
switch(camera.getRenderOrder())
{
case osg::Camera::PRE_RENDER:
//In the following line the viewport for the camera and the rtts is
correct
getCurrentRenderBin()-getStage()-addPreRenderStage(rtts.get(),camera.g
etRenderOrderNum());
break;
default:
getCurrentRenderBin()-getStage()-addPostRenderStage(rtts.get(),camera.
getRenderOrderNum());
