Re: [osg-users] [osg-submissions] API configurations in a separate Config include file
Hi Paul, Paul Martz wrote: I was surprised to see a change with such widespread ramifications discussed only on osg-submissions, so I'm cross-posting. I think I've now waded through enough of the posts in this thread to understand why this was done, and how to cope with the fact that OSG header files are now in the build directory. Mathias, could you take the time to enter a FAQ on the wiki regarding this? This should primarily go into the release notes. The FAQ isn't the best place to store items that only apply to certain OSG versions. Paul I foresee many posts when people upgrade to the latest OSG of the form: why can't my application find the Config header?. Users will need to know the following: * OSG now generates headers in the build tree. If your app links with OSG from a source/build tree, your app will now need to look for headers in multiple locations. * You can get around this by installing OSG. You can customize the install location with an OSG cmake variable. * Any other info you think is relevant. A FAQ on the wiki would be better than having people search the osg-submissions archives. Thanks, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] MRT
Hello, I've a question regarding MRT, both in OSG and in general OpenGL. When I render to MRT, does the manipulations that occur after the rasterization, like alpha blending, ZBuffer test atc, apply to all the Rendering Targets? Is it possible to set different parameters for those stages, to each Rendering Target? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi threaded with slave camera and fbo
Hi Cedric, If someone has some clue or advise to dig it Sorry I had no time to look at the repro you created. I looked at your earlier modified prerender example though. I got curious and started to debug it I think I found some additional important circumstances and workaround that my help you. But topic is quite mixed nad complex and I may have problems explaining it. But here it goes: Both DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext modes use osgViewer::Renderer thread with double buffered SceneViews. SingleThreaded and CullDrawThreadPerContext use single SceneView for rendering. (CullDrawThreadPerContext also uses Renderer but only with one SceneView see osgViewer::Rendered::cull_draw method in comparison to osgViewer::Renderer::draw osgViewer::Renderer::cull) Double buffered SceneViews mean that there are two interleaved SceneViews performing cull and draw operations for subsequent odd/even frames. These two scene views share some resources but may also create some separate resources. For example, if texture is attached to RTT camera, each of these SceneViews will create two separate FBOs for this camera but these FBOs will share camera texture. But when you attach the image to RTT camera, each of these FBOs will create spearate render buffer and will read pixels to the camera image from the buffer. What seems to be the case in your modified osgprerender looks like there is either some problems with refreshing the image in one of these SceneViews. I ran your example through gliIntercept and found something really weird. First SceneView FBO creates Renderbuffer with RGBA_32F format but second SceneView creates RenderBuffer with RGBA format. So you end up with situation when odd RTT camera frames are rendered into float framebuffer but even frames are rendered into ubyte framebuffer. Apparently readPixels from float buffer fails somehow and only read pixels from ubyte work as intended. I got curious why first SceneView FBO uses float buffer but second uses ubyte buffer. I think the answer is following: Apparently first frame drawn by prerender RTT camera proceeds before rendered texture is initialized and aplied to draw final scene. When first FBO is created its render buffer is based on initial image internal format (RGBA_32F). FBO is build and used to render first frame and then its contents are read to the image. Then main camera draws scene using texture initilized from updated image. When this texture gets applied for the first time, image internal image format gets changed to texture format (RGBA) and thus second FBO is created using this different format So we end up with odd prerender frames rendered into RGBA_32F buffer and even frames rendered into RGBA byte buffer. But this does not explain why readPixels produce so visually different results. It looks like there might be additional bug in OSG or OpenGL in reading pixels from RGBA_32F framebuffer. Now time for the conclusion. I don't have much time to dig this further, and see why readPixels fail, maybe will investigate this some other day. So I don't have a real fix, but you may try a simple workaround. Set initial internal image format to RGBA instead of RGBA_32F. I did that and it seemed to remove the discrepancy. Alternatively make sure that texture build from image has its internal format set to RGBA_32F. But I did not try this option. Cheers, Wojtek J.P. Delport wrote: Hi, for our current app we use singlethreaded. FBO is a requirement because of multiple render targets. Best would be to fix multithreaded and FBO. For this we will need small test apps that reliably trigger errors. Problem is that I think most people are unsure whether they are abusing OSG (not using the library correctly, not setting dynamic correctly, not blocking correctly...) or whether it is a bug. jp Cedric Pinson wrote: What do you use to have a robust solution ? maybe i should just use something different than fbo ? Cedric J.P. Delport wrote: Hi, Cedric Pinson wrote: Hi, I would like to know if other found some strange issue with multi threaded, and render slave camera to fbo. Yes, there have been quite a few discussions about multithreaded and fbo in the recent months, but AFAIK nobody has put a finger on the exact problem yet. Attached is a simple modded version of osgprerender that also displays something strange in multithreaded. I'm not sure if it is related though. run with: ./osgprerender --image The image flashes every second frame for some reason. (Turn sync to vblank on so it does not flash too fast.) If, at the bottom of the .cpp, one enables the single threaded option, the flashing disappears. I have tried setting properties to dynamic on scene nodes, but it does not seem to help, or I am missing a critical one. jp ___ osg-users
Re: [osg-users] multi threaded with slave camera and fbo
Well thank you for helping, You give me a lot of imformation, i will dig it Cedric Wojciech Lewandowski wrote: Hi Cedric, If someone has some clue or advise to dig it Sorry I had no time to look at the repro you created. I looked at your earlier modified prerender example though. I got curious and started to debug it I think I found some additional important circumstances and workaround that my help you. But topic is quite mixed nad complex and I may have problems explaining it. But here it goes: Both DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext modes use osgViewer::Renderer thread with double buffered SceneViews. SingleThreaded and CullDrawThreadPerContext use single SceneView for rendering. (CullDrawThreadPerContext also uses Renderer but only with one SceneView see osgViewer::Rendered::cull_draw method in comparison to osgViewer::Renderer::draw osgViewer::Renderer::cull) Double buffered SceneViews mean that there are two interleaved SceneViews performing cull and draw operations for subsequent odd/even frames. These two scene views share some resources but may also create some separate resources. For example, if texture is attached to RTT camera, each of these SceneViews will create two separate FBOs for this camera but these FBOs will share camera texture. But when you attach the image to RTT camera, each of these FBOs will create spearate render buffer and will read pixels to the camera image from the buffer. What seems to be the case in your modified osgprerender looks like there is either some problems with refreshing the image in one of these SceneViews. I ran your example through gliIntercept and found something really weird. First SceneView FBO creates Renderbuffer with RGBA_32F format but second SceneView creates RenderBuffer with RGBA format. So you end up with situation when odd RTT camera frames are rendered into float framebuffer but even frames are rendered into ubyte framebuffer. Apparently readPixels from float buffer fails somehow and only read pixels from ubyte work as intended. I got curious why first SceneView FBO uses float buffer but second uses ubyte buffer. I think the answer is following: Apparently first frame drawn by prerender RTT camera proceeds before rendered texture is initialized and aplied to draw final scene. When first FBO is created its render buffer is based on initial image internal format (RGBA_32F). FBO is build and used to render first frame and then its contents are read to the image. Then main camera draws scene using texture initilized from updated image. When this texture gets applied for the first time, image internal image format gets changed to texture format (RGBA) and thus second FBO is created using this different format So we end up with odd prerender frames rendered into RGBA_32F buffer and even frames rendered into RGBA byte buffer. But this does not explain why readPixels produce so visually different results. It looks like there might be additional bug in OSG or OpenGL in reading pixels from RGBA_32F framebuffer. Now time for the conclusion. I don't have much time to dig this further, and see why readPixels fail, maybe will investigate this some other day. So I don't have a real fix, but you may try a simple workaround. Set initial internal image format to RGBA instead of RGBA_32F. I did that and it seemed to remove the discrepancy. Alternatively make sure that texture build from image has its internal format set to RGBA_32F. But I did not try this option. Cheers, Wojtek J.P. Delport wrote: Hi, for our current app we use singlethreaded. FBO is a requirement because of multiple render targets. Best would be to fix multithreaded and FBO. For this we will need small test apps that reliably trigger errors. Problem is that I think most people are unsure whether they are abusing OSG (not using the library correctly, not setting dynamic correctly, not blocking correctly...) or whether it is a bug. jp Cedric Pinson wrote: What do you use to have a robust solution ? maybe i should just use something different than fbo ? Cedric J.P. Delport wrote: Hi, Cedric Pinson wrote: Hi, I would like to know if other found some strange issue with multi threaded, and render slave camera to fbo. Yes, there have been quite a few discussions about multithreaded and fbo in the recent months, but AFAIK nobody has put a finger on the exact problem yet. Attached is a simple modded version of osgprerender that also displays something strange in multithreaded. I'm not sure if it is related though. run with: ./osgprerender --image The image flashes every second frame for some reason. (Turn sync to vblank on so it does not flash too fast.) If, at the bottom of the .cpp, one enables the single threaded option, the flashing disappears. I have tried setting properties to dynamic on scene nodes, but it does not seem to help, or I am missing a critical one. jp
Re: [osg-users] [osg-submissions] API configurations in a separate Config include file
Hi Bob, Bob Kuehne wrote: Paul Melis wrote: This should primarily go into the release notes. The FAQ isn't the best place to store items that only apply to certain OSG versions. Paul i disagree - this change affects not just this specific version, but this version and *all* future versions, at least until this mechanism is changed again. and the reason for documenting it is that without some attention to how this new change operates, it appears as though the build is broken. Exactly. And the first place to document this is in the release notes that accompany 2.6 when it comes out. We can then place an entry in the FAQ that links to these notes. so, i'd second the motion that this be written in both the relnotes and the FAQ. the relnotes/changes happen automatically from commit messages, but the FAQ should be the place people look, instead of posting to the list. Yes, the list is used too much as a general knowledge base for things that (mostly) Robert keeps explaining over and over again. The number of posts on osgViewer and multiple views/cameras/contexts/windows/monitors/scenes/rendering targets is just staggering. I know osgViewer is a relatively new component, but the lack of some high-level overview doesn't really help. It seems there _are_ some pages on the wiki that try to explain aspects of the node-kit, but these appear a slight bit messy. Nor have I seen many people refer posters to these pages (perhaps for that reason). What I suspect (I might be wrong, of course) is that the accumulated time spent on answering mails on this part of OSG could have been better used to write a single overview piece that was published at the time OSG 2.0 came out roughly a year ago. This would have people given something to start with and get their minds around the concepts used and it would be possible to refer to that piece as the introductory document for osgViewer. I guess this is also a bit of personal preference, as I much prefer to read a good explanation than having to use the list. Regards, Paul b On Wed, Jun 25, 2008 at 3:26 AM, Paul Melis [EMAIL PROTECTED] wrote: Hi Paul, Paul Martz wrote: I was surprised to see a change with such widespread ramifications discussed only on osg-submissions, so I'm cross-posting. I think I've now waded through enough of the posts in this thread to understand why this was done, and how to cope with the fact that OSG header files are now in the build directory. Mathias, could you take the time to enter a FAQ on the wiki regarding this? I foresee many posts when people upgrade to the latest OSG of the form: why can't my application find the Config header?. Users will need to know the following: * OSG now generates headers in the build tree. If your app links with OSG from a source/build tree, your app will now need to look for headers in multiple locations. * You can get around this by installing OSG. You can customize the install location with an OSG cmake variable. * Any other info you think is relevant. A FAQ on the wiki would be better than having people search the osg-submissions archives. Thanks, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
This is most definitely not a transparent change. It is not backwards compatible with application projects designed to build against an OSG source/build tree. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Killian Sent: Tuesday, June 24, 2008 10:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file What was suppose to happen is that all of the changes were to be transparent in such a way where he need not write additional info. The problem of course is that when the code was checked in it was not tested for the windows platform, and now that I finally understand how it is suppose to work there are two known issues: 1. On my setup using 2.4.8 and VS 7.1 platform the cmake fails to identify that I can use interlocked and threaded environment, and so the config files written are for single threaded, and some of my bounding variables were defined as float. 2. I suspect that cmake scripts included the *build* include for only OpenThreads and OSG (and these could build fine)... problem is that all projects dependent on either of these will also need to add the build path to search, and this triggered the why can't my application find the Config header? issues. It should be easy to fix #2 if in fact that is the intended direction (and to the best of my knowledge) it was. If these things are working properly, it should be a transparent workflow. I will certainly test this and provide feedback once the windows.h issues are resolved. James Killian - Original Message - From: Paul Martz [EMAIL PROTECTED] To: 'OpenSceneGraph Submissions' [EMAIL PROTECTED] Cc: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Sent: Tuesday, June 24, 2008 4:56 PM Subject: Re: [osg-users] [osg-submissions] API configurations in a separateConfig include file I was surprised to see a change with such widespread ramifications discussed only on osg-submissions, so I'm cross-posting. I think I've now waded through enough of the posts in this thread to understand why this was done, and how to cope with the fact that OSG header files are now in the build directory. Mathias, could you take the time to enter a FAQ on the wiki regarding this? I foresee many posts when people upgrade to the latest OSG of the form: why can't my application find the Config header?. Users will need to know the following: * OSG now generates headers in the build tree. If your app links with OSG from a source/build tree, your app will now need to look for headers in multiple locations. * You can get around this by installing OSG. You can customize the install location with an OSG cmake variable. * Any other info you think is relevant. A FAQ on the wiki would be better than having people search the osg-submissions archives. Thanks, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
I second Paul's statement - it breaks every other project that uses osg. Brian [EMAIL PROTECTED] wrote: - To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org From: Paul Martz [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 06/25/2008 08:47AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file This is most definitely not a transparent change. It is not backwards compatible with application projects designed to build against an OSG source/build tree. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Killian Sent: Tuesday, June 24, 2008 10:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file What was suppose to happen is that all of the changes were to be transparent in such a way where he need not write additional info. The problem of course is that when the code was checked in it was not tested for the windows platform, and now that I finally understand how it is suppose to work there are two known issues: 1. On my setup using 2.4.8 and VS 7.1 platform the cmake fails to identify that I can use interlocked and threaded environment, and so the config files written are for single threaded, and some of my bounding variables were defined as float. 2. I suspect that cmake scripts included the *build* include for only OpenThreads and OSG (and these could build fine)... problem is that all projects dependent on either of these will also need to add the build path to search, and this triggered the why can't my application find the Config header? issues. It should be easy to fix #2 if in fact that is the intended direction (and to the best of my knowledge) it was. If these things are working properly, it should be a transparent workflow. I will certainly test this and provide feedback once the windows.h issues are resolved. James Killian - Original Message - From: Paul Martz [EMAIL PROTECTED] To: 'OpenSceneGraph Submissions' [EMAIL PROTECTED] Cc: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Sent: Tuesday, June 24, 2008 4:56 PM Subject: Re: [osg-users] [osg-submissions] API configurations in a separateConfig include file I was surprised to see a change with such widespread ramifications discussed only on osg-submissions, so I'm cross-posting. I think I've now waded through enough of the posts in this thread to understand why this was done, and how to cope with the fact that OSG header files are now in the build directory. Mathias, could you take the time to enter a FAQ on the wiki regarding this? I foresee many posts when people upgrade to the latest OSG of the form: why can't my application find the Config header?. Users will need to know the following: * OSG now generates headers in the build tree. If your app links with OSG from a source/build tree, your app will now need to look for headers in multiple locations. * You can get around this by installing OSG. You can customize the install location with an OSG cmake variable. * Any other info you think is relevant. A FAQ on the wiki would be better than having people search the osg-submissions archives. Thanks, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
quite the interesting change, eh? gets back to a point of problem i have with this project - that it isn't designed, but mostly just implemented. and even that is done without a lot of thought as to the larger consequences... sigh. anyway, how's your new thing going? well? b -- Forwarded message -- From: Brian R Hill [EMAIL PROTECTED] Date: Wed, Jun 25, 2008 at 9:10 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file To: OpenSceneGraph Users osg-users@lists.openscenegraph.org I second Paul's statement - it breaks every other project that uses osg. Brian [EMAIL PROTECTED] wrote: - To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org From: Paul Martz [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 06/25/2008 08:47AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file This is most definitely not a transparent change. It is not backwards compatible with application projects designed to build against an OSG source/build tree. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Killian Sent: Tuesday, June 24, 2008 10:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file What was suppose to happen is that all of the changes were to be transparent in such a way where he need not write additional info. The problem of course is that when the code was checked in it was not tested for the windows platform, and now that I finally understand how it is suppose to work there are two known issues: 1. On my setup using 2.4.8 and VS 7.1 platform the cmake fails to identify that I can use interlocked and threaded environment, and so the config files written are for single threaded, and some of my bounding variables were defined as float. 2. I suspect that cmake scripts included the *build* include for only OpenThreads and OSG (and these could build fine)... problem is that all projects dependent on either of these will also need to add the build path to search, and this triggered the why can't my application find the Config header? issues. It should be easy to fix #2 if in fact that is the intended direction (and to the best of my knowledge) it was. If these things are working properly, it should be a transparent workflow. I will certainly test this and provide feedback once the windows.h issues are resolved. James Killian - Original Message - From: Paul Martz [EMAIL PROTECTED] To: 'OpenSceneGraph Submissions' [EMAIL PROTECTED] Cc: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Sent: Tuesday, June 24, 2008 4:56 PM Subject: Re: [osg-users] [osg-submissions] API configurations in a separateConfig include file I was surprised to see a change with such widespread ramifications discussed only on osg-submissions, so I'm cross-posting. I think I've now waded through enough of the posts in this thread to understand why this was done, and how to cope with the fact that OSG header files are now in the build directory. Mathias, could you take the time to enter a FAQ on the wiki regarding this? I foresee many posts when people upgrade to the latest OSG of the form: why can't my application find the Config header?. Users will need to know the following: * OSG now generates headers in the build tree. If your app links with OSG from a source/build tree, your app will now need to look for headers in multiple locations. * You can get around this by installing OSG. You can customize the install location with an OSG cmake variable. * Any other info you think is relevant. A FAQ on the wiki would be better than having people search the osg-submissions archives. Thanks, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
Hi Bob, I will have to disagree with you on that point. I have worked in the computer industry for 15 years now (hitman, freedom fighters just to name a couple).. To this extent I have worked with 4 different gaming companies that all have made there own scenegraph/engine .. and I have to say that OpenSceneGraph is the best designed project I have ever worked with! and yes everything is well :) my two cents, Peter On Wed, Jun 25, 2008 at 3:40 PM, Bob Kuehne [EMAIL PROTECTED] wrote: quite the interesting change, eh? gets back to a point of problem i have with this project - that it isn't designed, but mostly just implemented. and even that is done without a lot of thought as to the larger consequences... sigh. anyway, how's your new thing going? well? b -- Forwarded message -- From: Brian R Hill [EMAIL PROTECTED] Date: Wed, Jun 25, 2008 at 9:10 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file To: OpenSceneGraph Users osg-users@lists.openscenegraph.org I second Paul's statement - it breaks every other project that uses osg. Brian [EMAIL PROTECTED] wrote: - To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org From: Paul Martz [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 06/25/2008 08:47AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file This is most definitely not a transparent change. It is not backwards compatible with application projects designed to build against an OSG source/build tree. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Killian Sent: Tuesday, June 24, 2008 10:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file What was suppose to happen is that all of the changes were to be transparent in such a way where he need not write additional info. The problem of course is that when the code was checked in it was not tested for the windows platform, and now that I finally understand how it is suppose to work there are two known issues: 1. On my setup using 2.4.8 and VS 7.1 platform the cmake fails to identify that I can use interlocked and threaded environment, and so the config files written are for single threaded, and some of my bounding variables were defined as float. 2. I suspect that cmake scripts included the *build* include for only OpenThreads and OSG (and these could build fine)... problem is that all projects dependent on either of these will also need to add the build path to search, and this triggered the why can't my application find the Config header? issues. It should be easy to fix #2 if in fact that is the intended direction (and to the best of my knowledge) it was. If these things are working properly, it should be a transparent workflow. I will certainly test this and provide feedback once the windows.h issues are resolved. James Killian - Original Message - From: Paul Martz [EMAIL PROTECTED] To: 'OpenSceneGraph Submissions' [EMAIL PROTECTED] Cc: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Sent: Tuesday, June 24, 2008 4:56 PM Subject: Re: [osg-users] [osg-submissions] API configurations in a separateConfig include file I was surprised to see a change with such widespread ramifications discussed only on osg-submissions, so I'm cross-posting. I think I've now waded through enough of the posts in this thread to understand why this was done, and how to cope with the fact that OSG header files are now in the build directory. Mathias, could you take the time to enter a FAQ on the wiki regarding this? I foresee many posts when people upgrade to the latest OSG of the form: why can't my application find the Config header?. Users will need to know the following: * OSG now generates headers in the build tree. If your app links with OSG from a source/build tree, your app will now need to look for headers in multiple locations. * You can get around this by installing OSG. You can customize the install location with an OSG cmake variable. * Any other info you think is relevant. A FAQ on the wiki would be better than having people search the osg-submissions archives. Thanks, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list
[osg-users] Different line types
Hi For all. Does anyone had such problem ? I'm using a system that merges calls between pure openscenegraph updates and opengl updates. And I also have a component (PositionAttitudeTransform) with a couple of child drawing objects that must be connected each other by a simple line But when I try to add a new line as a common glBegin( GL_LINES ) under openscenegraph, the drawing is rendered as LINE_STIPPLE, even if I change it from LINES to LINE_LOOP or other stuff... A don't know if StateSet could resolve the problem. Because I've already tried to use it but I guess that I did not make the correct code struct for its calling, and the results were the same. Also, if I use standalone openscenegraph application based on osgViewer, the following code (applied to the compound GL-OSG system) works with no problem: /*/ Symbol *s1 = getSymbol( str_symbol1 ); Symbol *s2 = getSymbol( str_symbol2 ); osg::Vec3 p1 = s1-getPosition(); osg::Vec3 p2 = s2-getPosition(); osg::Vec4 color = s1-getTextColor(); osg::ref_ptr osg::Geometry line = new osg::Geometry; osg::ref_ptr osg::Vec3Array vertex = new osg::Vec3Array; vertex-push_back( p1 ); vertex-push_back( p2 ); line-setVertexArray( vertex.get() ); /// the problem should be resolved here with osg::DrawArrays::LINES declaration osg::ref_ptr osg::DrawArrays vindex = new osg::DrawArrays( osg::DrawArrays::LINES, 0, 2 ); line-addPrimitiveSet( vindex.get() ); /*/ Thanks anyway if anyone spend a time reading the message I'm new to openscenegraph with just a couple of tests as experience and a complex system that already use osg to be studied in my hands Kindly Andre ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
hi gang, sorry about the widespread expression of frustration with this particular change - it's come at an inconvenient time for a few projects i'm working on. i continue to be osg's #1 fan, and user, though i might be considered a wee bit critical at times. it's because i'm very intersested in seeing osg evolve well. :) apologies! bob On Jun 25, 2008, at 9:40 AM, Bob Kuehne wrote: quite the interesting change, eh? gets back to a point of problem i have with this project - that it isn't designed, but mostly just implemented. and even that is done without a lot of thought as to the larger consequences... sigh. anyway, how's your new thing going? well? b -- Forwarded message -- From: Brian R Hill [EMAIL PROTECTED] Date: Wed, Jun 25, 2008 at 9:10 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file To: OpenSceneGraph Users osg-users@lists.openscenegraph.org I second Paul's statement - it breaks every other project that uses osg. Brian [EMAIL PROTECTED] wrote: - To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org From: Paul Martz [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] Date: 06/25/2008 08:47AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file This is most definitely not a transparent change. It is not backwards compatible with application projects designed to build against an OSG source/build tree. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Killian Sent: Tuesday, June 24, 2008 10:18 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file What was suppose to happen is that all of the changes were to be transparent in such a way where he need not write additional info. The problem of course is that when the code was checked in it was not tested for the windows platform, and now that I finally understand how it is suppose to work there are two known issues: 1. On my setup using 2.4.8 and VS 7.1 platform the cmake fails to identify that I can use interlocked and threaded environment, and so the config files written are for single threaded, and some of my bounding variables were defined as float. 2. I suspect that cmake scripts included the *build* include for only OpenThreads and OSG (and these could build fine)... problem is that all projects dependent on either of these will also need to add the build path to search, and this triggered the why can't my application find the Config header? issues. It should be easy to fix #2 if in fact that is the intended direction (and to the best of my knowledge) it was. If these things are working properly, it should be a transparent workflow. I will certainly test this and provide feedback once the windows.h issues are resolved. James Killian - Original Message - From: Paul Martz [EMAIL PROTECTED] To: 'OpenSceneGraph Submissions' [EMAIL PROTECTED] Cc: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Sent: Tuesday, June 24, 2008 4:56 PM Subject: Re: [osg-users] [osg-submissions] API configurations in a separateConfig include file I was surprised to see a change with such widespread ramifications discussed only on osg-submissions, so I'm cross-posting. I think I've now waded through enough of the posts in this thread to understand why this was done, and how to cope with the fact that OSG header files are now in the build directory. Mathias, could you take the time to enter a FAQ on the wiki regarding this? I foresee many posts when people upgrade to the latest OSG of the form: why can't my application find the Config header?. Users will need to know the following: * OSG now generates headers in the build tree. If your app links with OSG from a source/build tree, your app will now need to look for headers in multiple locations. * You can get around this by installing OSG. You can customize the install location with an OSG cmake variable. * Any other info you think is relevant. A FAQ on the wiki would be better than having people search the osg-submissions archives. Thanks, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org This is a PRIVATE message. If you are not the intended
Re: [osg-users] multi threaded with slave camera and fbo
Hi Cedric, I just have found one more bit of info. Image internalTextureFormat gets reset by Image::allocateImage called from Image::readPixels when RTT camera buffer contents are read into image after first draw. So this does not happen when texture is applied for final scene draw. I am not sure if resseting internal format from GL_RGBA32F_ARB to GL_RGBA should not be considered as a bug ? However, it still does not explain what happens with image during and after readPixels got called when render buffer was GL_RGBA32F_ARB. Cheers, Wojtek Well thank you for helping, You give me a lot of imformation, i will dig it Cedric Wojciech Lewandowski wrote: Hi Cedric, If someone has some clue or advise to dig it Sorry I had no time to look at the repro you created. I looked at your earlier modified prerender example though. I got curious and started to debug it I think I found some additional important circumstances and workaround that my help you. But topic is quite mixed nad complex and I may have problems explaining it. But here it goes: Both DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext modes use osgViewer::Renderer thread with double buffered SceneViews. SingleThreaded and CullDrawThreadPerContext use single SceneView for rendering. (CullDrawThreadPerContext also uses Renderer but only with one SceneView see osgViewer::Rendered::cull_draw method in comparison to osgViewer::Renderer::draw osgViewer::Renderer::cull) Double buffered SceneViews mean that there are two interleaved SceneViews performing cull and draw operations for subsequent odd/even frames. These two scene views share some resources but may also create some separate resources. For example, if texture is attached to RTT camera, each of these SceneViews will create two separate FBOs for this camera but these FBOs will share camera texture. But when you attach the image to RTT camera, each of these FBOs will create spearate render buffer and will read pixels to the camera image from the buffer. What seems to be the case in your modified osgprerender looks like there is either some problems with refreshing the image in one of these SceneViews. I ran your example through gliIntercept and found something really weird. First SceneView FBO creates Renderbuffer with RGBA_32F format but second SceneView creates RenderBuffer with RGBA format. So you end up with situation when odd RTT camera frames are rendered into float framebuffer but even frames are rendered into ubyte framebuffer. Apparently readPixels from float buffer fails somehow and only read pixels from ubyte work as intended. I got curious why first SceneView FBO uses float buffer but second uses ubyte buffer. I think the answer is following: Apparently first frame drawn by prerender RTT camera proceeds before rendered texture is initialized and aplied to draw final scene. When first FBO is created its render buffer is based on initial image internal format (RGBA_32F). FBO is build and used to render first frame and then its contents are read to the image. Then main camera draws scene using texture initilized from updated image. When this texture gets applied for the first time, image internal image format gets changed to texture format (RGBA) and thus second FBO is created using this different format So we end up with odd prerender frames rendered into RGBA_32F buffer and even frames rendered into RGBA byte buffer. But this does not explain why readPixels produce so visually different results. It looks like there might be additional bug in OSG or OpenGL in reading pixels from RGBA_32F framebuffer. Now time for the conclusion. I don't have much time to dig this further, and see why readPixels fail, maybe will investigate this some other day. So I don't have a real fix, but you may try a simple workaround. Set initial internal image format to RGBA instead of RGBA_32F. I did that and it seemed to remove the discrepancy. Alternatively make sure that texture build from image has its internal format set to RGBA_32F. But I did not try this option. Cheers, Wojtek J.P. Delport wrote: Hi, for our current app we use singlethreaded. FBO is a requirement because of multiple render targets. Best would be to fix multithreaded and FBO. For this we will need small test apps that reliably trigger errors. Problem is that I think most people are unsure whether they are abusing OSG (not using the library correctly, not setting dynamic correctly, not blocking correctly...) or whether it is a bug. jp Cedric Pinson wrote: What do you use to have a robust solution ? maybe i should just use something different than fbo ? Cedric J.P. Delport wrote: Hi, Cedric Pinson wrote: Hi, I would like to know if other found some strange issue with multi threaded, and render slave camera to fbo. Yes, there have been quite a few discussions about multithreaded and fbo in the recent months, but AFAIK nobody has put a finger
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
osg-users, what fun would this list be if someone (lucky me) didn't get to stick their foot in their mouth from time to time. :) don't get me wrong: i think osg is by _far_ the best designed and implemented scenegraph out there. and robert does the best job at balancing an admittedly difficult task - incorporating changes from users, his own ideas and designs, and criticism from all fronts (mine included). i use osg for 100% of the projects i do work on and would have it no other way. having been involved with osg since it's inception, i'm both very satisfied and very critical of it, out of concern that it continues to evolve in a way that takes care of it's users yet adapts to the ever-changing graphics landscape. and i do try to contribute to make it better in little ways here and there. and so, as an act of contrition (yes, i was raised a catholic child), i submit my updated 'FindOSG.cmake' which i use to create builds of apps with osg on windows, linux, and the mac. this cmake FIND_PACKAGE tool will setup the variable OSG_INCLUDE_DIRS to point to both the generated and installed source of osg, as well as the OSG_LIBRARY_DIR for the discovered osg libraries. i'll post an entire standalone example to submissions later, because i think having a way for users to build a standalone app would be a useful addition, especially with the changing build landscape. sheepishly, (not a scotland joke) bob Findosg.cmake Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [Not OSG related question] Virtual memory management on Windows
Hi all, I have a question not related to OSG but I can't find any answer, and this is something that some of you probably knows. That's why I try here to find some help. Here is my problem : I have a big image database with some images larger than 1.5Go uncompressed, and I fail to load them (Win XP SP2 32bits with Visual Studio 8). My computer has 3Go of virtual memory and the option /3GB is activated on the system. In this document (page 13) : http://actes.sstic.org/SSTIC05/Vulnerabilites_et_gestion_des_limites_memoire/SSTIC05-article-Delalleau-Vulnerabilites_et_gestion_des_limites_memoire.pdf It says it's not possible to allocate more than 1.3Go in one call, and it's actually the limit where it crashs. If I do 2 allocations of 1Go each, it works, but 1 allocation of 1.4Go crashs... Has someone any idea if it's possible to change this limit ? My only hope will be to make smaller images, or even to develop under Linux ? :) Thanks in advance ! -- 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
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
Hi Bob, what fun would this list be if someone (lucky me) didn't get to stick their foot in their mouth from time to time. :) I assume you got some personal replies to your message, as I haven't seen anything on osg-users that reacted to it in any way, so your own reaction is a bit surprising to me. For the record, I agree with your sentiment, even if I can see reasons why OSG evolves as it does (open source software often imposes its own pace and demands that developers be more fluid and open to change...) So I personally didn't find your comment offensive. and so, as an act of contrition (yes, i was raised a catholic child), i submit my updated 'FindOSG.cmake' which i use to create builds of apps with osg on windows, linux, and the mac. this cmake FIND_PACKAGE tool will setup the variable OSG_INCLUDE_DIRS to point to both the generated and installed source of osg, as well as the OSG_LIBRARY_DIR for the discovered osg libraries. I agree that a template for a standalone project using OSG is a good addition. In the past, I have cannibalized the VPB CMake/project files for my own projects, and that worked for me (though of course, with the recent changes, even those will have to be reworked slightly). And it should be made clear that if you do 'make install' or build the INSTALL target in Visual Studio, you don't need anything different than before, since the Config headers are installed with your other OSG headers. It's only if you build and then use the files straight from your build tree (or copy them manually from there to somewhere else, omitting the Config headers) that you need to add the build/include/OpenThreads and build/include/osg directories in your include path. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] callback
Dear All,
i attached a callback to a geode node.
CallBack operator:
void GeodeCallBack::operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::Geode* geode =
dynamic_castosg::Geode*( node );
geode-removeDrawables(0,geode-getNumDrawables ());
// get different drawable.
osg::Drawable *d = drawableBuilder-getDrawable(dataPoint-shape);
geode-addDrawable( d );
traverse( node, nv );
}
1- is it Ok to change the geode's contains in the callback?
2- some times the geode-addDrawable( d ); terminate the program. any
ideas?
Thanks,
Ahmed Nawar
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] callback
Hi,
Is it an update callback or a cull calback ?
On Wed, Jun 25, 2008 at 5:11 PM, Ahmed Nawar [EMAIL PROTECTED]
wrote:
Dear All,
i attached a callback to a geode node.
CallBack operator:
void GeodeCallBack::operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::Geode* geode =
dynamic_castosg::Geode*( node );
geode-removeDrawables(0,geode-getNumDrawables ());
// get different drawable.
osg::Drawable *d = drawableBuilder-getDrawable(dataPoint-shape);
geode-addDrawable( d );
traverse( node, nv );
}
1- is it Ok to change the geode's contains in the callback?
2- some times the geode-addDrawable( d ); terminate the program. any
ideas?
Thanks,
Ahmed Nawar
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
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
Re: [osg-users] multi threaded with slave camera and fbo
Hi again Cedric, I think I have last piece of the puzzle. It looks like readPixels work perfectly correct with float Renderbuffer. I was blaming it because scene background was properly darkened by postRender camera callback but rendered cessna model seemed unafected by image darkennig process. Image darkenning was done by simple color scaling by 0.5. It turned out that cessna interior was also properly scaled. But when Renderbuffer was float, render buffer color compononts were not clamped to 0..1 range (which is obvious for float buffers, but I always forget about it;-). Shaders were substituting colors with vertices and multiplying them by 2 (Sine uniform) so even after scaling by 0.5 we were still having color components much larger than 1.0. Thats why cessna interior seemed not darkened at all. Jeez, I learned a lot today ;-) Thanks for interesting example ;-) Cheers, Wojtek Hi Cedric, I just have found one more bit of info. Image internalTextureFormat gets reset by Image::allocateImage called from Image::readPixels when RTT camera buffer contents are read into image after first draw. So this does not happen when texture is applied for final scene draw. I am not sure if resseting internal format from GL_RGBA32F_ARB to GL_RGBA should not be considered as a bug ? However, it still does not explain what happens with image during and after readPixels got called when render buffer was GL_RGBA32F_ARB. Cheers, Wojtek Well thank you for helping, You give me a lot of imformation, i will dig it Cedric Wojciech Lewandowski wrote: Hi Cedric, If someone has some clue or advise to dig it Sorry I had no time to look at the repro you created. I looked at your earlier modified prerender example though. I got curious and started to debug it I think I found some additional important circumstances and workaround that my help you. But topic is quite mixed nad complex and I may have problems explaining it. But here it goes: Both DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext modes use osgViewer::Renderer thread with double buffered SceneViews. SingleThreaded and CullDrawThreadPerContext use single SceneView for rendering. (CullDrawThreadPerContext also uses Renderer but only with one SceneView see osgViewer::Rendered::cull_draw method in comparison to osgViewer::Renderer::draw osgViewer::Renderer::cull) Double buffered SceneViews mean that there are two interleaved SceneViews performing cull and draw operations for subsequent odd/even frames. These two scene views share some resources but may also create some separate resources. For example, if texture is attached to RTT camera, each of these SceneViews will create two separate FBOs for this camera but these FBOs will share camera texture. But when you attach the image to RTT camera, each of these FBOs will create spearate render buffer and will read pixels to the camera image from the buffer. What seems to be the case in your modified osgprerender looks like there is either some problems with refreshing the image in one of these SceneViews. I ran your example through gliIntercept and found something really weird. First SceneView FBO creates Renderbuffer with RGBA_32F format but second SceneView creates RenderBuffer with RGBA format. So you end up with situation when odd RTT camera frames are rendered into float framebuffer but even frames are rendered into ubyte framebuffer. Apparently readPixels from float buffer fails somehow and only read pixels from ubyte work as intended. I got curious why first SceneView FBO uses float buffer but second uses ubyte buffer. I think the answer is following: Apparently first frame drawn by prerender RTT camera proceeds before rendered texture is initialized and aplied to draw final scene. When first FBO is created its render buffer is based on initial image internal format (RGBA_32F). FBO is build and used to render first frame and then its contents are read to the image. Then main camera draws scene using texture initilized from updated image. When this texture gets applied for the first time, image internal image format gets changed to texture format (RGBA) and thus second FBO is created using this different format So we end up with odd prerender frames rendered into RGBA_32F buffer and even frames rendered into RGBA byte buffer. But this does not explain why readPixels produce so visually different results. It looks like there might be additional bug in OSG or OpenGL in reading pixels from RGBA_32F framebuffer. Now time for the conclusion. I don't have much time to dig this further, and see why readPixels fail, maybe will investigate this some other day. So I don't have a real fix, but you may try a simple workaround. Set initial internal image format to RGBA instead of RGBA_32F. I did that and it seemed to remove the discrepancy. Alternatively make sure that texture build from image has its internal format set to
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
What was the last version you were able to successfully build? you don't need anything different than before, since the Config headers are installed with your other OSG headers. Do you have an out-of-source configuration or in source? I use the out-of-source configuration and so the config headers are installed in the build directory. If anyone has had a successful time in building on the VS platform, I am interested in how they are doing it. Right now I'm doing the wrong thing which is to copy the config files into the source tree yuck and then manually turning on the correct configuration (i.e. interlocked and enforce threading). This is as of build 8483. (FYI this is in plain text so you should be able to see it) :) - Original Message - From: Jean-Sébastien Guay To: OpenSceneGraph Users Sent: Wednesday, June 25, 2008 10:08 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file Hi Bob, what fun would this list be if someone (lucky me) didn't get to stick their foot in their mouth from time to time. :) I assume you got some personal replies to your message, as I haven't seen anything on osg-users that reacted to it in any way, so your own reaction is a bit surprising to me. For the record, I agree with your sentiment, even if I can see reasons why OSG evolves as it does (open source software often imposes its own pace and demands that developers be more fluid and open to change...) So I personally didn't find your comment offensive. and so, as an act of contrition (yes, i was raised a catholic child), i submit my updated 'FindOSG.cmake' which i use to create builds of apps with osg on windows, linux, and the mac. this cmake FIND_PACKAGE tool will setup the variable OSG_INCLUDE_DIRS to point to both the generated and installed source of osg, as well as the OSG_LIBRARY_DIR for the discovered osg libraries. I agree that a template for a standalone project using OSG is a good addition. In the past, I have cannibalized the VPB CMake/project files for my own projects, and that worked for me (though of course, with the recent changes, even those will have to be reworked slightly). And it should be made clear that if you do 'make install' or build the INSTALL target in Visual Studio, you don't need anything different than before, since the Config headers are installed with your other OSG headers. It's only if you build and then use the files straight from your build tree (or copy them manually from there to somewhere else, omitting the Config headers) that you need to add the build/include/OpenThreads and build/include/osg directories in your include path. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
Hello James, I think you're mixing things up. There are three different issues here: 1. The choice to use Config headers. 2. The fact that the Atomic header includes windows.h. 3. The fact that your version of CMake chooses the wrong configuration and does not generate the Config header. Number 1 is a design choice. The choice is basically between having a file that defines options that affect the build, and needing to specify those options as defines in *each* project that uses OSG. I can see why the choice to have a Config file was taken. Otherwise, you would have to support people configuring their OSG build one way and then linking to it in a project where the incorrect define was being used, which would happen more often than you'd think. Having a Config header ensures that both the built version of OSG and your project use the same options (as long as the same Config header is included for both). Number 2 was a mistake (by the person who made the change, but still unrelated to the choice in number 1), and is being rectified as we speak. Check the messages from yesterday. *That* is what's breaking the build on Windows right now. As for Number 3, I believe that is caused by CMake 2.4.x. This can be investigated and fixed *after* the windows.h issue is fixed, which is much more major (as it affects *everyone* building on Windows, independently of the version of CMake they use). A workaround for you would be to get CMake 2.6 from cmake.org. Then you would get the right configuration (interlocked), the Config header would be generated and used, and you would see the windows.h include problem... At least that's what I think. :-) you don't need anything different than before, since the Config headers are installed with your other OSG headers. Do you have an out-of-source configuration or in source? I use the out-of-source configuration and so the config headers are installed in the build directory. I use an out-of-source build with CMake 2.6, and the Config header is being generated just fine. But what I was talking about in the line you quoted above is that OSG headers are including the Config headers. If you don't do an INSTALL (or make install), then the Config headers are not together with your other OSG headers. Config headers: OpenSceneGraph/build/include/OpenThreads/Config OpenSceneGraph/build/include/osg/Config Other headers: OpenSceneGraph/include/OpenThreads/* OpenSceneGraph/include/osg/* So the other headers won't find #include OpenThreads/Config or #include osg/Config unless you add the directories above (in build) to your include file search path. Which was not required before. But if you do an INSTALL, you don't have that problem, because the INSTALL target copies the Config headers to the same place as the other headers, and so #include OpenThreads/Config will work without any change to your project files. I hope that clears things up. (FYI this is in plain text so you should be able to see it) :) Thanks :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multi threaded with slave camera and fbo
Cool :) Then thinking back on my problem i think i have an issue about synchronization (because i have rtt works it looks like it's not the good frame renderer). It seems that the projection matrix i set (in ortho) is not yet updated for the current frame i want to grab. In fact for my two camera rtt, only one seems synchronized with the projection matrix. And because it does not work for the cull draw on a different tread, it could makes sense. I have to dig it, but i have not the time yet, (i changed the threading model as a work around). Thank you to answer to this thread it was interesting to read you answers Cedric Wojciech Lewandowski wrote: Hi again Cedric, I think I have last piece of the puzzle. It looks like readPixels work perfectly correct with float Renderbuffer. I was blaming it because scene background was properly darkened by postRender camera callback but rendered cessna model seemed unafected by image darkennig process. Image darkenning was done by simple color scaling by 0.5. It turned out that cessna interior was also properly scaled. But when Renderbuffer was float, render buffer color compononts were not clamped to 0..1 range (which is obvious for float buffers, but I always forget about it;-). Shaders were substituting colors with vertices and multiplying them by 2 (Sine uniform) so even after scaling by 0.5 we were still having color components much larger than 1.0. Thats why cessna interior seemed not darkened at all. Jeez, I learned a lot today ;-) Thanks for interesting example ;-) Cheers, Wojtek Hi Cedric, I just have found one more bit of info. Image internalTextureFormat gets reset by Image::allocateImage called from Image::readPixels when RTT camera buffer contents are read into image after first draw. So this does not happen when texture is applied for final scene draw. I am not sure if resseting internal format from GL_RGBA32F_ARB to GL_RGBA should not be considered as a bug ? However, it still does not explain what happens with image during and after readPixels got called when render buffer was GL_RGBA32F_ARB. Cheers, Wojtek Well thank you for helping, You give me a lot of imformation, i will dig it Cedric Wojciech Lewandowski wrote: Hi Cedric, If someone has some clue or advise to dig it Sorry I had no time to look at the repro you created. I looked at your earlier modified prerender example though. I got curious and started to debug it I think I found some additional important circumstances and workaround that my help you. But topic is quite mixed nad complex and I may have problems explaining it. But here it goes: Both DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext modes use osgViewer::Renderer thread with double buffered SceneViews. SingleThreaded and CullDrawThreadPerContext use single SceneView for rendering. (CullDrawThreadPerContext also uses Renderer but only with one SceneView see osgViewer::Rendered::cull_draw method in comparison to osgViewer::Renderer::draw osgViewer::Renderer::cull) Double buffered SceneViews mean that there are two interleaved SceneViews performing cull and draw operations for subsequent odd/even frames. These two scene views share some resources but may also create some separate resources. For example, if texture is attached to RTT camera, each of these SceneViews will create two separate FBOs for this camera but these FBOs will share camera texture. But when you attach the image to RTT camera, each of these FBOs will create spearate render buffer and will read pixels to the camera image from the buffer. What seems to be the case in your modified osgprerender looks like there is either some problems with refreshing the image in one of these SceneViews. I ran your example through gliIntercept and found something really weird. First SceneView FBO creates Renderbuffer with RGBA_32F format but second SceneView creates RenderBuffer with RGBA format. So you end up with situation when odd RTT camera frames are rendered into float framebuffer but even frames are rendered into ubyte framebuffer. Apparently readPixels from float buffer fails somehow and only read pixels from ubyte work as intended. I got curious why first SceneView FBO uses float buffer but second uses ubyte buffer. I think the answer is following: Apparently first frame drawn by prerender RTT camera proceeds before rendered texture is initialized and aplied to draw final scene. When first FBO is created its render buffer is based on initial image internal format (RGBA_32F). FBO is build and used to render first frame and then its contents are read to the image. Then main camera draws scene using texture initilized from updated image. When this texture gets applied for the first time, image internal image format gets changed to texture format (RGBA) and thus second FBO is created using this different format So we end up with odd prerender frames rendered into RGBA_32F
Re: [osg-users] [osg-submissions] API configurations inaseparateConfig include file
I've heard there are alternatives :) http://www.sgi.com/products/software/performer/ osg-users, what fun would this list be if someone (lucky me) didn't get to stick their foot in their mouth from time to time. :) don't get me wrong: i think osg is by _far_ the best designed and implemented scenegraph out there. and robert does the best job at balancing an admittedly difficult task - incorporating changes from users, his own ideas and designs, and criticism from all fronts (mine included). i use osg for 100% of the projects i do work on and would have it no other way. having been involved with osg since it's inception, i'm both very satisfied and very critical of it, out of concern that it continues to evolve in a way that takes care of it's users yet adapts to the ever-changing graphics landscape. and i do try to contribute to make it better in little ways here and there. and so, as an act of contrition (yes, i was raised a catholic child), i submit my updated 'FindOSG.cmake' which i use to create builds of apps with osg on windows, linux, and the mac. this cmake FIND_PACKAGE tool will setup the variable OSG_INCLUDE_DIRS to point to both the generated and installed source of osg, as well as the OSG_LIBRARY_DIR for the discovered osg libraries. i'll post an entire standalone example to submissions later, because i think having a way for users to build a standalone app would be a useful addition, especially with the changing build landscape. sheepishly, (not a scotland joke) bob ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert/use GIS coordinates
Hi Glenn, Bottom line: if you use VPB to build a terrain in UTM zone 32 (or whatever), you will need to do no coordinate conversion. I'm currently doing some tests with some data I got from http://www.ngdc.noaa.gov/mgg/image/2minrelief.html (pretty low res, but I'm just testing). The problem I have is that the data's positions seem to be in latitude/longitude in degrees, and I'd like to convert it to what I'm expecting (meters). I'm not very familiar with the tools (I assume GDAL and/or PROJ can do this), so I'd appreciate a hand :-) gdalinfo gives me this for the file I have: Driver: EHdr/ESRI .hdr Labelled Files: Hellobob_5209.bin Hellobob_5209.hdr Size is 271, 241 Coordinate System is `' Origin = (2.9833500,64.01666586493) Pixel Size = (0.0333000,-0.0333000) Corner Coordinates: Upper Left ( 2.983, 64.0166659) Lower Left ( 2.983, 55.983) Upper Right ( 12.0166658, 64.0166659) Lower Right ( 12.0166658, 55.983) Center ( 7.496, 59.996) Band 1 Block=271x1 Type=Byte, ColorInterp=Undefined NoData Value=99 So as you can see, ~(3, 56) to ~(12,64) in degrees. I'd like to have that in meters in the right place on the Earth... How would I do that? On the gdal_translate man page I see the option a_srs overrides the projection of the output file, but I have no idea what the argument should be. Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GL_NV_depth_clamp
I'm currently trying to render infinite shadow volumes in OSG using the GL_NV_depth_clamp extension. This extension disables the near and far clipping planes on nVidia graphics cards. I've tried both using setMode() on the stateset associated with my shadow volume geode and calling glEnable() in the shadow volume's drawImplementation, and neither case works. Checking glIsEnabled(DEPTH_CLAMP_NV) is returning true. Is there some interaction between OpenSceneGraph and extensions I'm not aware of that is preventing this from working? Has anyone used depth clamping succesfully in OSG? I've tested this against OpenSceneGraph 2.2 and 2.4 on both a Quadro FX 3500 and a GeForce FX 7900, and in both cases the geometry is being clipped by the far clipping plane... The only alternative I can see is to use an infinite view frustum instead, but that comes with its own brand of problems... -Chris B ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Warning on 64bits: cast to pointer from integer of different size
On x86_64 (Suse 10.3) the following warning appears at lines 431 and 600 of BufferObject.cpp : warning: cast to pointer from integer of different size In both places (few lines over), if I change the line: unsigned int offset = 0; to: unsigned long offset = 0; The warning goes away. Can anyone more knowledgeable than me confirm that the change is correct before I submit the change? Thanks! mario -- Ing. Mario Valle Data Analysis and Visualization Services | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 /div ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert/use GIS coordinates
On Wed, Jun 25, 2008 at 12:41 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Glenn, Bottom line: if you use VPB to build a terrain in UTM zone 32 (or whatever), you will need to do no coordinate conversion. I'm currently doing some tests with some data I got from http://www.ngdc.noaa.gov/mgg/image/2minrelief.html (pretty low res, but I'm just testing). The problem I have is that the data's positions seem to be in latitude/longitude in degrees, and I'd like to convert it to what I'm expecting (meters). I'm not very familiar with the tools (I assume GDAL and/or PROJ can do this), so I'd appreciate a hand :-) gdalinfo gives me this for the file I have: Driver: EHdr/ESRI .hdr Labelled Files: Hellobob_5209.bin Hellobob_5209.hdr Size is 271, 241 Coordinate System is `' Origin = (2.9833500,64.01666586493) Pixel Size = (0.0333000,-0.0333000) Corner Coordinates: Upper Left ( 2.983, 64.0166659) Lower Left ( 2.983, 55.983) Upper Right ( 12.0166658, 64.0166659) Lower Right ( 12.0166658, 55.983) Center ( 7.496, 59.996) Band 1 Block=271x1 Type=Byte, ColorInterp=Undefined NoData Value=99 So as you can see, ~(3, 56) to ~(12,64) in degrees. I'd like to have that in meters in the right place on the Earth... How would I do that? On the gdal_translate man page I see the option a_srs overrides the projection of the output file, but I have no idea what the argument should be. Thanks in advance, J-S J-S, From the looks of your coordinates, UTM Zone 40N would be a good choice for a projected SRS. The -a_srs argument will accept many things including PROJ4, WKT, or a file containing a WKT. Try this: gdal_translate -a_srs +proj=utm +zone=40 +datum=WGS84 infile outfile Let me know if that works. -gw -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CmakeSetup problems...
In order to compile and run osgviewerWX example, I'm trying to build the VC++ project file using CMakeSetup. I've configured all the wxWidgets paths to configure, generate, and build but it still won't build the project file. In fact, CMakeSetup won't build any of the project files for any of the FLTK, GLUT, MFC, QT, etc., osgviewer examples. All other examples build and configure just fine. Is there another dependency that I need in CMakeSetup in order to build the project file for osgviewerWX? Any help or input would be appreciated. -Shayne smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Camera PostDraw Callback w/ OpenGL calls.
Guys, I have a camera postdraw callback on a View's camera. I want to do some OpenGL drawing via glBegin()/glEnd() and then take a screen capture. The screen capture works but the custom drawing isn't in there. It's on the screen though. I try to do glDrawBuffer( GL_BACK ) to force it into the same buffer as the camera, but no good. Any ideas? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert/use GIS coordinates
Hi Glenn, From the looks of your coordinates, UTM Zone 40N would be a good choice for a projected SRS. It should actually be UTM zone 32V, unless I made a mistake somewhere. It's the tip of the Norwegian peninsula. The -a_srs argument will accept many things including PROJ4, WKT, or a file containing a WKT. Try this: gdal_translate -a_srs +proj=utm +zone=40 +datum=WGS84 infile outfile I tried that, using 32 instead of 40. gdal_translate -a_srs +proj=utm +zone=32 +datum=WGS84 32V.tif 32V_wgs84.tif It doesn't seem to change much, the model generated by vpb and then loaded still seems to be using the latitude/longitude in degrees as units (it's about 9 units by 8 units in size). I'm using this command to generate the model: osgdem -d 32V_wgs84.tif --POLYGONAL --LOD -v 0.0001 -l 8 -o database/32V_wgs84.osg gdalinfo on the new file gives: Driver: GTiff/GeoTIFF Files: 32V_wgs84.tif Size is 271, 241 Coordinate System is: PROJCS[unnamed, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.2572235630016, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,9], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,32632]] Origin = (2.9833500,64.01666586493) Pixel Size = (0.0333000,-0.0333000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 2.983, 64.0166659) ( 4d30'40.62E, 0d 0'2.08N) Lower Left ( 2.983, 55.983) ( 4d30'40.62E, 0d 0'1.82N) Upper Right ( 12.0166658, 64.0166659) ( 4d30'40.91E, 0d 0'2.08N) Lower Right ( 12.0166658, 55.983) ( 4d30'40.91E, 0d 0'1.82N) Center ( 7.496, 59.996) ( 4d30'40.76E, 0d 0'1.95N) Band 1 Block=271x15 Type=Int16, ColorInterp=Gray NoData Value=-32768 Help? :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera PostDraw Callback w/ OpenGL calls.
Hi John, I have a camera postdraw callback on a View's camera. I want to do some OpenGL drawing via glBegin()/glEnd() and then take a screen capture. The screen capture works but the custom drawing isn't in there. It's on the screen though. I try to do glDrawBuffer( GL_BACK ) to force it into the same buffer as the camera, but no good. Any ideas? Wow, you're really putting osgViewer through its paces aren't you :-) I've never tried doing what you're doing, so I can only suggest that you try some other way of doing your OpenGL drawing. There are a few different ways of doing OpenGL inside OSG, some may not work in given usage models... Have you tried a custom drawable? Possibly putting the custom drawable on a geode that is child of a postdraw camera, and then using the finaldraw callback on your main camera instead of the postdraw callback to take your screen capture... Sorry I can't be of more help. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert/use GIS coordinates
On Wed, Jun 25, 2008 at 2:09 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Glenn, From the looks of your coordinates, UTM Zone 40N would be a good choice for a projected SRS. It should actually be UTM zone 32V, unless I made a mistake somewhere. It's the tip of the Norwegian peninsula. The -a_srs argument will accept many things including PROJ4, WKT, or a file containing a WKT. Try this: gdal_translate -a_srs +proj=utm +zone=40 +datum=WGS84 infile outfile I tried that, using 32 instead of 40. gdal_translate -a_srs +proj=utm +zone=32 +datum=WGS84 32V.tif 32V_wgs84.tif It doesn't seem to change much, the model generated by vpb and then loaded still seems to be using the latitude/longitude in degrees as units (it's about 9 units by 8 units in size). I'm using this command to generate the model: osgdem -d 32V_wgs84.tif --POLYGONAL --LOD -v 0.0001 -l 8 -o database/32V_wgs84.osg gdalinfo on the new file gives: Driver: GTiff/GeoTIFF Files: 32V_wgs84.tif Size is 271, 241 Coordinate System is: PROJCS[unnamed, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.2572235630016, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,9], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,32632]] Origin = (2.9833500,64.01666586493) Pixel Size = (0.0333000,-0.0333000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 2.983, 64.0166659) ( 4d30'40.62E, 0d 0'2.08N) Lower Left ( 2.983, 55.983) ( 4d30'40.62E, 0d 0'1.82N) Upper Right ( 12.0166658, 64.0166659) ( 4d30'40.91E, 0d 0'2.08N) Lower Right ( 12.0166658, 55.983) ( 4d30'40.91E, 0d 0'1.82N) Center ( 7.496, 59.996) ( 4d30'40.76E, 0d 0'1.95N) Band 1 Block=271x15 Type=Int16, ColorInterp=Gray NoData Value=-32768 Help? :-) Sorry I had my lat and long reversed ;) Anyway, the new SRS looks right, what does the .osg file say? The CoordinateSystemNode WKT? Sounds like a tiny file, can you attach it? -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert/use GIS coordinates
J-S, Also, I am an idiot, because I meant to say gdalwarp, not gdal_translate. gdal_translate -a_srs will just assign an SRS, not reproject the data. Anyway I will take it offline with you. Glenn On Wed, Jun 25, 2008 at 2:26 PM, Glenn Waldron [EMAIL PROTECTED] wrote: On Wed, Jun 25, 2008 at 2:09 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Glenn, From the looks of your coordinates, UTM Zone 40N would be a good choice for a projected SRS. It should actually be UTM zone 32V, unless I made a mistake somewhere. It's the tip of the Norwegian peninsula. The -a_srs argument will accept many things including PROJ4, WKT, or a file containing a WKT. Try this: gdal_translate -a_srs +proj=utm +zone=40 +datum=WGS84 infile outfile I tried that, using 32 instead of 40. gdal_translate -a_srs +proj=utm +zone=32 +datum=WGS84 32V.tif 32V_wgs84.tif It doesn't seem to change much, the model generated by vpb and then loaded still seems to be using the latitude/longitude in degrees as units (it's about 9 units by 8 units in size). I'm using this command to generate the model: osgdem -d 32V_wgs84.tif --POLYGONAL --LOD -v 0.0001 -l 8 -o database/32V_wgs84.osg gdalinfo on the new file gives: Driver: GTiff/GeoTIFF Files: 32V_wgs84.tif Size is 271, 241 Coordinate System is: PROJCS[unnamed, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.2572235630016, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,9], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,32632]] Origin = (2.9833500,64.01666586493) Pixel Size = (0.0333000,-0.0333000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 2.983, 64.0166659) ( 4d30'40.62E, 0d 0'2.08N) Lower Left ( 2.983, 55.983) ( 4d30'40.62E, 0d 0'1.82N) Upper Right ( 12.0166658, 64.0166659) ( 4d30'40.91E, 0d 0'2.08N) Lower Right ( 12.0166658, 55.983) ( 4d30'40.91E, 0d 0'1.82N) Center ( 7.496, 59.996) ( 4d30'40.76E, 0d 0'1.95N) Band 1 Block=271x15 Type=Int16, ColorInterp=Gray NoData Value=-32768 Help? :-) Sorry I had my lat and long reversed ;) Anyway, the new SRS looks right, what does the .osg file say? The CoordinateSystemNode WKT? Sounds like a tiny file, can you attach it? -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Not OSG related question] Virtual memory management on Windows
power linux Serge ;-). Regards David Callu 2008/6/25 Serge Lages [EMAIL PROTECTED]: Hi all, I have a question not related to OSG but I can't find any answer, and this is something that some of you probably knows. That's why I try here to find some help. Here is my problem : I have a big image database with some images larger than 1.5Go uncompressed, and I fail to load them (Win XP SP2 32bits with Visual Studio 8). My computer has 3Go of virtual memory and the option /3GB is activated on the system. In this document (page 13) : http://actes.sstic.org/SSTIC05/Vulnerabilites_et_gestion_des_limites_memoire/SSTIC05-article-Delalleau-Vulnerabilites_et_gestion_des_limites_memoire.pdf It says it's not possible to allocate more than 1.3Go in one call, and it's actually the limit where it crashs. If I do 2 allocations of 1Go each, it works, but 1 allocation of 1.4Go crashs... Has someone any idea if it's possible to change this limit ? My only hope will be to make smaller images, or even to develop under Linux ? :) Thanks in advance ! -- 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
Re: [osg-users] Build from svn in Cygwin still tries to build osgviewerWX but no WX
Robert Osfield wrote: On Tue, Jun 17, 2008 at 9:24 PM, Brian Keener [EMAIL PROTECTED] wrote: So perhaps the problem in build is down to a different WxWidgets version than the OSG can compile against, or not all the lib/includes matching up for some reason. Disabling WxWdiget should be possible by just setting the associated via ccmake . But I am building in Cygwin - which means it should be finding /usr/something or /something or /cygdrive/something and the D: drive on my system is the CD and has music in - not WxWdgets - there is not WxWidgets on my system that I can find. How do you disable in ccmake - I tried setting all the WxWidgets entries equal to their key and -NOTFOUND. This is really a CMake find issue - Cmake may be not just checking /usr paths, perhaps its the CMakeModules/Find3rdPartyDependencies.cmake that is introducing oddities. I have amit to not being CMake expert, let alone a Windows/Cygwin user so the best I can I think I have found it and it is a CMake issue with the FindWxWidgets.cmake script. Either osgviewerWX is new or this didn't start until Cmake 2.6 but I cannot be sure. At any rate in FindWxWidgets.cmake they use this code: #= #= IF(WIN32) SET(WIN32_STYLE_FIND 1) ENDIF(WIN32) IF(MINGW) SET(WIN32_STYLE_FIND 0) SET(UNIX_STYLE_FIND 1) ENDIF(MINGW) IF(UNIX) SET(UNIX_STYLE_FIND 1) ENDIF(UNIX) but in Cygwin WIN32 and UNIX are both set and the variables being set determine how it find wxWidgets so if WIN32 is set it is using the wrong logic. I added this: IF(CYGWIN) SET(WIN32_STYLE_FIND 0) SET(UNIX_STYLE_FIND 1) ENDIF(CYGWIN) right after the MINGW routine and that stopped it from find wxWidget or defaulting which it does in the Windows find even though I do not have it which it weird. Anyways just thought I would pass it on as it does appear (to me) to be in Cmake and not OSG. bk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera PostDraw Callback w/ OpenGL calls.
Hi John, I thought some of this sounded a little familiar. I found a discussion not too long relative to this. See the thread entitled Rendering to a image file. Here's a link to the specific post: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/28011/focus=28014 What Robert suggests (and as Jean-Sebastien suggests) is using the final draw callback to make sure that the extra OpenGL rendering is done before taking the screen capture. chuck -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, June 25, 2008 2:14 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Camera PostDraw Callback w/ OpenGL calls. Hi John, I have a camera postdraw callback on a View's camera. I want to do some OpenGL drawing via glBegin()/glEnd() and then take a screen capture. The screen capture works but the custom drawing isn't in there. It's on the screen though. I try to do glDrawBuffer( GL_BACK ) to force it into the same buffer as the camera, but no good. Any ideas? Wow, you're really putting osgViewer through its paces aren't you :-) I've never tried doing what you're doing, so I can only suggest that you try some other way of doing your OpenGL drawing. There are a few different ways of doing OpenGL inside OSG, some may not work in given usage models... Have you tried a custom drawable? Possibly putting the custom drawable on a geode that is child of a postdraw camera, and then using the finaldraw callback on your main camera instead of the postdraw callback to take your screen capture... Sorry I can't be of more help. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert/use GIS coordinates
Hi Glenn, Also, I am an idiot, because I meant to say gdalwarp, not gdal_translate. gdal_translate -a_srs will just assign an SRS, not reproject the data. gdalwarp asks me for -s_srs and -t_srs, if I just specify -t_srs +proj=utm +zone=32 +datum=WGS84 it says that there is no source coordinate system and aborts... What should I specify as the source coordinate system? Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert/use GIS coordinates
Jean-Sébastien Guay writes: gdalwarp asks me for -s_srs and -t_srs, if I just specify -t_srs +proj=utm +zone=32 +datum=WGS84 it says that there is no source coordinate system and aborts... What should I specify as the source coordinate system? -s_srs EPSG:4326 Or the convenient shorthand -s_srs WGS84 See -a_srs discussion here http://gdal.org/gdal_utilities.html A handy site http://www.spatialreference.org/ref/epsg/4326/ Norman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert/use GIS coordinates
Hi Norman, What should I specify as the source coordinate system? -s_srs EPSG:4326 Or the convenient shorthand -s_srs WGS84 Hmm, that doesn't seem to work either: gdalwarp -s_srs WGS84 -t_srs +proj=utm +zone=32 +datum=WGS84 32V.tif 32V_warped.tif Then I generate a terrain from that: osgdem -d 32V_warped.tif --TERRAIN -v 0.0001 -l 8 -o database_osg/32V.osg And if I load it, it's still the same as it was (i.e. too small relative to other models modeled in meters). gdalinfo output looks the same as before: Driver: GTiff/GeoTIFF Files: 32V_warped.tif Size is 271, 241 Coordinate System is: PROJCS[unnamed, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.2572235630016, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,9], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,32632]] Origin = (2.9833500,64.01666586493) Pixel Size = (0.0333000,-0.0333000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 2.983, 64.0166659) ( 4d30'40.62E, 0d 0'2.08N) Lower Left ( 2.983, 55.983) ( 4d30'40.62E, 0d 0'1.82N) Upper Right ( 12.0166658, 64.0166659) ( 4d30'40.91E, 0d 0'2.08N) Lower Right ( 12.0166658, 55.983) ( 4d30'40.91E, 0d 0'1.82N) Center ( 7.496, 59.996) ( 4d30'40.76E, 0d 0'1.95N) Band 1 Block=271x15 Type=Int16, ColorInterp=Gray Thanks for the links, BTW. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convert/use GIS coordinates
J-S, Send me the TIFF and I will figure out what the deal is. Just email it direct. -gw On Wed, Jun 25, 2008 at 4:36 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Norman, What should I specify as the source coordinate system? -s_srs EPSG:4326 Or the convenient shorthand -s_srs WGS84 Hmm, that doesn't seem to work either: gdalwarp -s_srs WGS84 -t_srs +proj=utm +zone=32 +datum=WGS84 32V.tif 32V_warped.tif Then I generate a terrain from that: osgdem -d 32V_warped.tif --TERRAIN -v 0.0001 -l 8 -o database_osg/32V.osg And if I load it, it's still the same as it was (i.e. too small relative to other models modeled in meters). gdalinfo output looks the same as before: Driver: GTiff/GeoTIFF Files: 32V_warped.tif Size is 271, 241 Coordinate System is: PROJCS[unnamed, GEOGCS[WGS 84, DATUM[WGS_1984, SPHEROID[WGS 84,6378137,298.2572235630016, AUTHORITY[EPSG,7030]], AUTHORITY[EPSG,6326]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4326]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,9], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,32632]] Origin = (2.9833500,64.01666586493) Pixel Size = (0.0333000,-0.0333000) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 2.983, 64.0166659) ( 4d30'40.62E, 0d 0'2.08N) Lower Left ( 2.983, 55.983) ( 4d30'40.62E, 0d 0'1.82N) Upper Right ( 12.0166658, 64.0166659) ( 4d30'40.91E, 0d 0'2.08N) Lower Right ( 12.0166658, 55.983) ( 4d30'40.91E, 0d 0'1.82N) Center ( 7.496, 59.996) ( 4d30'40.76E, 0d 0'1.95N) Band 1 Block=271x15 Type=Int16, ColorInterp=Gray Thanks for the links, BTW. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on Rendering Streaming video
The format the image data I'll be using is a proprietary format that basically just has the raw bayer data below a header. I do have an additional question about how to load the data into the texture. I've already set up an orthographic2D view that will look at a quad which will display the texture. The shader will then convert the texture into RGB and do the whitebalance. I am also able to swap the texture back and forth and maintain decent frame rates but the textures I'm using to test are only 64x64 pixels (tank.rgba and water.rgba) and I'm wondering if it would be too slow (30fps) to use the same method for 1000x1000 pixel images. Is there another method that I should be trying out? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulrich Hertlein Sent: Monday, June 23, 2008 9:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Advice on Rendering Streaming video [EMAIL PROTECTED] wrote: The video stream will be in Bayer format and will need to be converted to RGB before being displayed on the screen. I will also need to zoom the image and pan the image back and forth. There will be other filters that I'll need to apply but I think they will just end up being shaders. ... I was contemplating dumping the raw data into a texture and doing all the decoding on the graphics card within a series of shaders. Is this a viable approach? Use of a shader for the debayer process is definitively the way to go if you want to be realtime. For any kind of reasonable result the debayer algorithms will be too slow when done on the CPU. Hopefully you'll have a grayscale image (and not something more convoluted like YCbCr) so just upload that to a texture and knock yourself out with a debayer shader! ;-) Zoom/pan can also be done in the shader by modifying the texture coordinates. Just out of curiosity, what kind of image data are you using? RED? ARRI? Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Not OSG related question] Virtual memory management on Windows
Hi There's many issues why you will struggle with this and no it's not just a windows issues it effects other OS's some do a better job off moving the issues forward but they will still crop up Simplest solution is to go to a 64bit OS with a good 8gb or more. There is another limitation you will hit on 32bit windows is you can only have an address space per process of 1.8gb , other OS's such as Unix's and Linux's do a much better job and get you near the true 32bit limit Another problem is that you need a contiguous memory area for malloc/new on windows this is a big problem , Some of the reasons why this is an issue is that Windows has already eaten up a chunk of the available memory, not only with programs , services , dll's being loaded they sadly simply don't get then next serial memory address, they may be load smack bang in the middle of the address space, so straight away that can l half the size of the max malloc/new you can do. As you load more programs more dll's the longer windows is running the more fragmented the memory will get and the smaller the max malloc/new can create will get lower, the MAC's OS's are the best at handling this sort of thing and Linux is typically better than window's What you can try is all the normal traditional tips, only run [processes, services that absolutely need to etc see http://www.vis-sim.com/vega/vegafaq1.htm#f39 ( needs modernizing but the gist is valid) This use be a big problem back in the heyday of IRIX, it would load is system SO's(dll's) smack bang in the middle of memory the same for programs. What had to be do there was to force the system to load its libs either high or low and you has to rebase the loading address of all the SO's your program used. You can do a similar thing in Windows and for all your dll's to re-base and control were they load. If you do that the final trick is that as some as your application starts you need to create the large memory stuff straight away, otherwise your address space will get fragmented and your back to square one At my company we have to handle multi-terra byte imagery and have to use processes like I have described, so it can be done. you just need an engineer that knows this hard stuff, thankfully we have an engineer that does ;) and no you cannot have him ;) __ Gordon Tomlinson Email : mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] YIM/AIM : gordon3dBrit MSN IM : mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] Website : http://www.vis-sim.com www.vis-sim.com http://www.gordontomlinson.com www.gordontomlinson.com __ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Callu Sent: Wednesday, June 25, 2008 3:05 PM To: OpenSceneGraph Users Subject: Re: [osg-users] [Not OSG related question] Virtual memory management on Windows power linux Serge ;-). Regards David Callu 2008/6/25 Serge Lages [EMAIL PROTECTED]: Hi all, I have a question not related to OSG but I can't find any answer, and this is something that some of you probably knows. That's why I try here to find some help. Here is my problem : I have a big image database with some images larger than 1.5Go uncompressed, and I fail to load them (Win XP SP2 32bits with Visual Studio 8). My computer has 3Go of virtual memory and the option /3GB is activated on the system. In this document (page 13) : http://actes.sstic.org/SSTIC05/Vulnerabilites_et_gestion_des_limites_memoire /SSTIC05-article-Delalleau-Vulnerabilites_et_gestion_des_limites_memoire.pdf It says it's not possible to allocate more than 1.3Go in one call, and it's actually the limit where it crashs. If I do 2 allocations of 1Go each, it works, but 1 allocation of 1.4Go crashs... Has someone any idea if it's possible to change this limit ? My only hope will be to make smaller images, or even to develop under Linux ? :) Thanks in advance ! -- 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
Re: [osg-users] Warning on 64bits: cast to pointer from integer ofdifferent size
I am not sure about the osg coding protocol, but for what we do at my work place we use size_t as the generic unsigned int... this will be unsigned long for win32 and __int64 for the x64 platform. It is good to use as a generic container for local variables since it chooses the native size that fits best per platform. size_t is great for pointer offsets too. The part that is unclear to me is the osg protocol in regards to using things like size_t fpos_t etc... osg has to be more generic to comply to all platforms, and this is something I have not needed to worry about (yet). James Killian - Original Message - From: Mario Valle [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Wednesday, June 25, 2008 12:02 PM Subject: [osg-users] Warning on 64bits: cast to pointer from integer ofdifferent size On x86_64 (Suse 10.3) the following warning appears at lines 431 and 600 of BufferObject.cpp : warning: cast to pointer from integer of different size In both places (few lines over), if I change the line: unsigned int offset = 0; to: unsigned long offset = 0; The warning goes away. Can anyone more knowledgeable than me confirm that the change is correct before I submit the change? Thanks! mario -- Ing. Mario Valle Data Analysis and Visualization Services | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 /div ___ 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] Advice on Rendering Streaming video
[EMAIL PROTECTED] wrote: I've already set up an orthographic2D view that will look at a quad which will display the texture. The shader will then convert the texture into RGB and do the whitebalance. I am also able to swap the texture back and forth and maintain decent frame rates but the textures I'm using to test are only 64x64 pixels (tank.rgba and water.rgba) and I'm wondering if it would be too slow (30fps) to use the same method for 1000x1000 pixel images. The texture bandwidth isn't likely to be a problem, keep in mind that bayer images are only 1/3 of an RGB image of the same size. Things to look out for is to use non-power-of-two textures or texture rectangles to avoid CPU scaling of the image. You'll also want to attach a osg::PixelBufferObject to the osg::Image. Unfortunately getting a nice image from that is a b??ch and the shaders can get complex pretty fast, the number of texture lookups is probably the most expensive op. What de-bayer algorithms are you looking at? Cheers, /uli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file
Thanks for explaining things: For the first point about using config files, that's cool... I am in no position to judge whether or not to do that since I do not have experience building on other platforms, but at the same time I do know the perception this has for those who build with VS and my first impression of this was the same especially before I knew how it was suppose to work. As for the second point I'll be looking forward to hearing back from you and/or Mathias when this is resolved, then I'll try to build again. The third point: Well I'll give Cmake 2.6 another shot. I tried it too early before and it had some strange behavior. Hopefully now since a lot of people are using it I'll feel a bit more confident that it will work. I may get back with you on the Install workflow, but I'll need to see how 2.6 looks first. James Killian - Original Message - From: Jean-Sébastien Guay [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, June 25, 2008 10:59 AM Subject: Re: [osg-users] [osg-submissions] API configurations in aseparateConfig include file Hello James, I think you're mixing things up. There are three different issues here: 1. The choice to use Config headers. 2. The fact that the Atomic header includes windows.h. 3. The fact that your version of CMake chooses the wrong configuration and does not generate the Config header. Number 1 is a design choice. The choice is basically between having a file that defines options that affect the build, and needing to specify those options as defines in *each* project that uses OSG. I can see why the choice to have a Config file was taken. Otherwise, you would have to support people configuring their OSG build one way and then linking to it in a project where the incorrect define was being used, which would happen more often than you'd think. Having a Config header ensures that both the built version of OSG and your project use the same options (as long as the same Config header is included for both). Number 2 was a mistake (by the person who made the change, but still unrelated to the choice in number 1), and is being rectified as we speak. Check the messages from yesterday. *That* is what's breaking the build on Windows right now. As for Number 3, I believe that is caused by CMake 2.4.x. This can be investigated and fixed *after* the windows.h issue is fixed, which is much more major (as it affects *everyone* building on Windows, independently of the version of CMake they use). A workaround for you would be to get CMake 2.6 from cmake.org. Then you would get the right configuration (interlocked), the Config header would be generated and used, and you would see the windows.h include problem... At least that's what I think. :-) you don't need anything different than before, since the Config headers are installed with your other OSG headers. Do you have an out-of-source configuration or in source? I use the out-of-source configuration and so the config headers are installed in the build directory. I use an out-of-source build with CMake 2.6, and the Config header is being generated just fine. But what I was talking about in the line you quoted above is that OSG headers are including the Config headers. If you don't do an INSTALL (or make install), then the Config headers are not together with your other OSG headers. Config headers: OpenSceneGraph/build/include/OpenThreads/Config OpenSceneGraph/build/include/osg/Config Other headers: OpenSceneGraph/include/OpenThreads/* OpenSceneGraph/include/osg/* So the other headers won't find #include OpenThreads/Config or #include osg/Config unless you add the directories above (in build) to your include file search path. Which was not required before. But if you do an INSTALL, you don't have that problem, because the INSTALL target copies the Config headers to the same place as the other headers, and so #include OpenThreads/Config will work without any change to your project files. I hope that clears things up. (FYI this is in plain text so you should be able to see it) :) Thanks :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in pre for 2.5.3 dev release
Robert Osfield wrote: So pretty please, could you do svn update and build across as many platforms that you can so we can get a clear picture of how the OSG code base is holding up. Once things look fine across platforms I'll tag 2.5.3. With the fix I found for wxWidget the build for 8492 in Cygwin builds fine unless I select to build the wrappers and then I get an error building osgIntrospection. Bk [ 57%] Built target osgdb_tgz [ 59%] Built target osgdb_txp [ 60%] Built target osgdb_shp [ 60%] Built target osgdb_txf [ 60%] Built target osgdb_freetype [ 60%] Built target osgdb_zip Scanning dependencies of target osgIntrospection [ 60%] Building CXX object src/osgIntrospection/CMakeFiles/osgIntrospection.dir/ ConstructorInfo.o In file included from /usr/src/OpenSceneGraph/include/osgIntrospection/Type:19, from /usr/src/OpenSceneGraph/include/osgIntrospection/Construct orInfo:19, from /usr/src/OpenSceneGraph/src/osgIntrospection/ConstructorIn fo.cpp:15: /usr/src/OpenSceneGraph/include/osgIntrospection/Value:150: error: using-declara tion for non-member at class scope /usr/src/OpenSceneGraph/include/osgIntrospection/Value:150: error: expected `;' before toWString make[2]: *** [src/osgIntrospection/CMakeFiles/osgIntrospection.dir/ConstructorIn fo.o] Error 1 make[1]: *** [src/osgIntrospection/CMakeFiles/osgIntrospection.dir/all] Error 2 make: *** [all] Error 2 [EMAIL PROTECTED] /usr/develop/obj/osg $ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Particles being culled
Hi all,I'm trying to simulate a smoke trail emitting from a moving tank by using Joseph's codes but some particles are being culled (see attached picture). Any ideas what are the causes?Thanks,Cg _ NEW! Get Windows Live FREE. http://www.get.live.com/wl/allattachment: particle_cull.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
I think the default for particle systems is that particles are little billboards which always face the viewer's eye point. It looks like you've undone that setting somehow, and that the billboards are facing different directions. On Wed, Jun 25, 2008 at 11:07 PM, CG [EMAIL PROTECTED] wrote: Hi all, I'm trying to simulate a smoke trail emitting from a moving tank by using Joseph's codes but some particles are being culled (see attached picture). Any ideas what are the causes? Thanks, Cg Make the most of what you can do on your PC and the Web, just the way you want. Windows Live ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- AsymptopiaSoftware | [EMAIL PROTECTED] www.asymptopia.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
Hi Charles, Thanks for the reply, what are the settings for the eye point facing?Regards, Cg Date: Wed, 25 Jun 2008 23:18:07 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled I think the default for particle systems is that particles are little billboards which always face the viewer's eye point. It looks like you've undone that setting somehow, and that the billboards are facing different directions. On Wed, Jun 25, 2008 at 11:07 PM, CG [EMAIL PROTECTED] wrote: Hi all, I'm trying to simulate a smoke trail emitting from a moving tank by using Joseph's codes but some particles are being culled (see attached picture). Any ideas what are the causes? Thanks, Cg Make the most of what you can do on your PC and the Web, just the way you want. Windows Live ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org -- AsymptopiaSoftware | [EMAIL PROTECTED] www.asymptopia.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Manage multiple email accounts with Windows Live Mail effortlessly. http://www.get.live.com/wl/all___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particles being culled
try: ps-setParticleAlignment(osgParticle::ParticleSystem::BILLBOARD); On Wed, Jun 25, 2008 at 11:23 PM, CG [EMAIL PROTECTED] wrote: Hi Charles, Thanks for the reply, what are the settings for the eye point facing? Regards, Cg Date: Wed, 25 Jun 2008 23:18:07 -0600 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particles being culled I think the default for particle systems is that particles are little billboards which always face the viewer's eye point. It looks like you've undone that setting somehow, and that the billboards are facing different directions. On Wed, Jun 25, 2008 at 11:07 PM, CG [EMAIL PROTECTED] wrote: Hi all, I'm trying to simulate a smoke trail emitting from a moving tank by using Joseph's codes but some particles are being culled (see attached picture). Any ideas what are the causes? Thanks, Cg Make the most of what you can do on your PC and the Web, just the way you want. Windows Live ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- AsymptopiaSoftware | [EMAIL PROTECTED] www.asymptopia.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Share your beautiful moments with Photo Gallery. Windows Live Photo Gallery ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- AsymptopiaSoftware | [EMAIL PROTECTED] www.asymptopia.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] callback
Sorry for late.
It is an update callback.
Thanks,
Ahmed Nawar
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Serge Lages [EMAIL
PROTECTED]
Sent: Wednesday, June 25, 2008 6:14 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] callback
Hi,
Is it an update callback or a cull calback ?
On Wed, Jun 25, 2008 at 5:11 PM, Ahmed Nawar [EMAIL PROTECTED]mailto:[EMAIL
PROTECTED] wrote:
Dear All,
i attached a callback to a geode node.
CallBack operator:
void GeodeCallBack::operator()( osg::Node* node, osg::NodeVisitor* nv )
{
osg::Geode* geode =
dynamic_castosg::Geode*( node );
geode-removeDrawables(0,geode-getNumDrawables ());
// get different drawable.
osg::Drawable *d = drawableBuilder-getDrawable(dataPoint-shape);
geode-addDrawable( d );
traverse( node, nv );
}
1- is it Ok to change the geode's contains in the callback?
2- some times the geode-addDrawable( d ); terminate the program. any
ideas?
Thanks,
Ahmed Nawar
___
osg-users mailing list
osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
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
