Re: [osg-users] Texture is rendered strange
On 7/11/09 10:18 PM, Thorsten Werner wrote: osg::Vec2Array* texcoords = new osg::Vec2Array(4); (*texcoords)[0].set(0.0f, 0.0f); (*texcoords)[0].set(1.0f, 0.0f); (*texcoords)[0].set(1.0f, 1.0f); (*texcoords)[0].set(0.0f, 1.0f); Is this a cutpaste error? The image you're loading (.tga) isn't the one you've attached (.png), so we can't really say what's different. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Renderer and SceneView classes
Hi Dan, Renderer::cull() just does the cull traversal - i..e just collects a rendering graph of what drawables and state that visible to the Camera. The Renderer::draw() does the dispatch of the graph of what needs rendering. Robert. On Sun, Nov 8, 2009 at 12:09 PM, Dan R nice...@gmail.com wrote: OK thank you for the information. So whatever aspects of SceneView that Renderer is using now will eventually become part of the Renderer itself. I see that now. I'm not really interested in creating a separate library I just want to get OSG working for this project, but I can see that it would be a huge task porting it to a different language with different constraints. Anyway it's been a great learning experience going through the code. One further question, does actual rendering get invoked via the Renderer-cull() method? It looks like that then calls cull() and then draw() on the SceneView. Or is it the GraphicsContext-runOperations() that ends up rendering? Thanks, Dan On Sun, Nov 8, 2009 at 12:26 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Dan, SceneView is part of the original beginnings of the OSG, when it was single threaded, single context, and is now scheduled for deprecation. It will eventually be replaced entirely by functionality in osgViewer::Renderer, but for now I've simply reused SceneView. With any project that is a decade in the making you'll find a lot of history of it's evolution still in it, it's partly down to reusing code that does the job, and partly about maintaining backwards compatibility during transitions. So if you want to learn about the scene graph design and implementation keep this it mind that is living project, it's not only evolved alot through it's history, but it's still evolving a good old rate. As for creating a new scene graph in another language, I guess the OSG isn't too bad a place to start, but if you want to develop a really successful project you'll need under stand about wider project management as well as just the technical aspects of design and implementation. It also take a lot of work to write a full featured scene graph, hundreds of thousands of lines of code, and many man hours. Robert. On Sat, Nov 7, 2009 at 12:46 PM, Dan R nice...@gmail.com wrote: Hello, I'm new to OSG and am just looking over the code structure to better learn how a proper scene graph library is laid out. I'm interested in using (porting a stripped down version) of osg for a project I'm working on in another language. I pretty much understand the flow of the graph, however, when it comes down to the actual rendering traversal I get a bit lost. So I have these two questions, but maybe being directed to some older posts would be good answers... 1) The osgViewer::Renderer class appears frequently throughout the code, however, it seems to be based around the osgUtils::SceneView class. The SceneView class says that it's deprecated. Does this also mean that the Renderer class is deprecated, or simply that any calls to SceneView are no longer used in the normal work flow? 2) In a SingleThreaded case, where are the operations that result in rendering the Drawables get added? I see that in the renderingTraversals method, it first traverses the graph with a getBound() call, then goes through each camera and does a cull() (this uses a Renderer object from my first question), then goes through each GraphicsContext and calls runOperations. Where I get lost is, where are the operations for the GraphicsContext defined and added, that actually end up doing the work of rendering the drawables? Any direction in this case would clear a lot up for me, thanks, Dan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Renderer and SceneView classes
Hi Paul, On Sun, Nov 8, 2009 at 2:44 PM, Paul Martz pma...@skew-matrix.com wrote: Hi Robert -- There are large projects out there based on SceneView and getting along just fine without osgViewer. Removing SceneView would, at best, require them to migrate SceneView out of OSG and into their own app (where it would continue to work, barring future incompatible changes in OSG). And at worst, cost them an expensive port and re-verification of their product. I support marking SceneView as deprecated and replaced by Renderer, but think it would be wise to avoid changes to OSG that render SceneView inoperable. This has been my plan. To steadily move more functionality into osgViewer::Renderer and make SceneView redundant w.r.t modern OSG usage. SceneView needn't change too much, as CullVisitor/RenderStage/RenderBin etc. will still be in osgUtil. Once SceneView is redundant we'd need to make decision of when to move it out of the core OSG into the deprecated section of the subversion repository along with items like the old OpenFlight plugin. Prior to SceneView being moved out we'll need a period where we encourage OSG users still relying on SceneView to migrate to using osgViewer::Viewer in conjunction with osgViewer::GraphicsWindowEmbedded, as it offers the same easy ability to embed but offers a whole heap more flexibility and functionality. I would encourage this right now, as SceneView is well passed it's sell by date. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture is rendered strange
On Mon, Nov 9, 2009 at 09:50, Ulrich Hertlein u.hertl...@sandbox.de wrote: On 7/11/09 10:18 PM, Thorsten Werner wrote: osg::Vec2Array* texcoords = new osg::Vec2Array(4); (*texcoords)[0].set(0.0f, 0.0f); (*texcoords)[0].set(1.0f, 0.0f); (*texcoords)[0].set(1.0f, 1.0f); (*texcoords)[0].set(0.0f, 1.0f); Is this a cutpaste error? Hi Thorsten, You're assigning the texture coordinates only to the first element ([0]). Colin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Computing Normals for Drawables
Hi guys, Interesting conversation on solving this problem. I'm working with James on this and he's away this week, so I thought I'd reply to keep the conversation going, and also to thank you for your input. Just to throw another requirement into the mix, I don't think we can use vertex shaders, as we cannot guarantee what hardware the software will be run on. Basically integrated graphics is the lowest possible hardware, so what's that, DirectX 8? 9? Vertex shaders run on DX8 but you won't get many instructions. Can this not be done on the CPU side only? Interestingly we did float the idea of computing a shared normal array (a sphere coated with normals) for all objects in the scene, then provide indices between Geometry vertices and the shared normal array, however we really didn't know if this was possible in OSG, or if it would work. A quick look at osg::Geometry source code there is a function setNormalIndices, so perhaps if we were to create a NodeVisitor that did the following this could work? 1. On creation of the nodeVisitor, create an osg::Vec3Array for shared normals. Populate with normals in all directions. 2. As the NodeVisitor walks the tree, for each Geometry object use the code from SmoothingVisitor to calculate what the normal should be 3. Rather than store that normal in an array and pass to the Geometry, instead find the closest normal to it in the shared normal array, 4. Store the index to the shared normal, and finally set the indices on the Geometry using setNormalIndices This would be done once on load or creation of an object. It wouldn't matter to take the performance hit once per load, nor would it matter if this slowed down rendering. We already employ aggressive use of culling to achieve decent rendering framerate when the object count is high. The hard limit is memory. Thanks a lot for your input, Regards, Andrew On Sat, Nov 7, 2009 at 7:46 AM, yann le paih lepaih.y...@gmail.com wrote: Hi, Interresting links about compact normal and more : http://aras-p.info/blog/2009/08/04/compact-normal-storage-for-small-g-buffers/ http://aras-p.info/texts/CompactNormalStorage.html and http://c0de517e.blogspot.com/2008/10/normals-without-normals.html yann On Fri, Nov 6, 2009 at 10:51 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Simon, Ah I didn't know that, ty. Seems like an odd limitation though. Well, the video cards are implemented to take in only certain types of data. Vertices, normals and colors are in general aggregates of 32-bit floats (which is why no vertex type is ever a vector of 3 doubles). How does the angles thing work? Not sure I follow you. Your intuition is right that normals around a vertex will always be in a sphere. The thing is that you can encode that as spherical coordinates ( http://en.wikipedia.org/wiki/Spherical_coordinates), where r = 1 (since a normal is always unit-length). So the direction could be encoded as two angles, theta and phi, inclination and azimuth (see the Wikipedia article). Now, you already save one float that way over storing a 3-component vector. If you want to save more, since the angles are small numbers, you can store both of them into the lower and upper parts of a single 32-bit float (two 16 bit numbers) and re-extract them from the float in the shader. Another way is you could store only 2 of the 3 components of the normal - since a normal is unit-length you can calculate the third component easily. Those numbers will also be small (less than or equal to 1) so you could do the same transformation into two 16-bit values and store them into a single float. The spherical coordinates just came to mind first as I've used it before, but the result would be the same. If you did the normal lookup, wouldn't you save a whole load of shader processing time, or is memory bandwidth a bigger limitation with shaders? You'd save a little bit of processing time per vertex, but compared to a texture lookup to get the right normal from the lookup table, I don't know what would win. Seriously, what I've described above is child's play for a GPU, and very easily parallelizable, which is what GPUs do best. It's not really a matter of bandwidth since your lookup table would be pretty small too. I expect you'd get similar performance in both cases, for me it's just inconvenient to drag around an extra table when I don't have to - the angles / quantized vector method above would all fit nicely in the object itself without needing any extra data. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org --
Re: [osg-users] Computing Normals for Drawables
Hi Andrew, Vertex indices are just available for backwards compatibility, I would not recommend using them at all as they force the OSG down on to slow paths where it assemble the actual data to send to graphics card on each frame, as graphics cards do not support per primitive normals, or decoupled vertex indicies. The most efficient way to use OpenGL/graphcis hardware is with straight vertex arrays and osg::DrawElements to manage indices. Robert On Mon, Nov 9, 2009 at 10:21 AM, Andrew Burnett-Thompson aburnettthomp...@googlemail.com wrote: Hi guys, Interesting conversation on solving this problem. I'm working with James on this and he's away this week, so I thought I'd reply to keep the conversation going, and also to thank you for your input. Just to throw another requirement into the mix, I don't think we can use vertex shaders, as we cannot guarantee what hardware the software will be run on. Basically integrated graphics is the lowest possible hardware, so what's that, DirectX 8? 9? Vertex shaders run on DX8 but you won't get many instructions. Can this not be done on the CPU side only? Interestingly we did float the idea of computing a shared normal array (a sphere coated with normals) for all objects in the scene, then provide indices between Geometry vertices and the shared normal array, however we really didn't know if this was possible in OSG, or if it would work. A quick look at osg::Geometry source code there is a function setNormalIndices, so perhaps if we were to create a NodeVisitor that did the following this could work? 1. On creation of the nodeVisitor, create an osg::Vec3Array for shared normals. Populate with normals in all directions. 2. As the NodeVisitor walks the tree, for each Geometry object use the code from SmoothingVisitor to calculate what the normal should be 3. Rather than store that normal in an array and pass to the Geometry, instead find the closest normal to it in the shared normal array, 4. Store the index to the shared normal, and finally set the indices on the Geometry using setNormalIndices This would be done once on load or creation of an object. It wouldn't matter to take the performance hit once per load, nor would it matter if this slowed down rendering. We already employ aggressive use of culling to achieve decent rendering framerate when the object count is high. The hard limit is memory. Thanks a lot for your input, Regards, Andrew On Sat, Nov 7, 2009 at 7:46 AM, yann le paih lepaih.y...@gmail.com wrote: Hi, Interresting links about compact normal and more : http://aras-p.info/blog/2009/08/04/compact-normal-storage-for-small-g-buffers/ http://aras-p.info/texts/CompactNormalStorage.html and http://c0de517e.blogspot.com/2008/10/normals-without-normals.html yann On Fri, Nov 6, 2009 at 10:51 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Simon, Ah I didn't know that, ty. Seems like an odd limitation though. Well, the video cards are implemented to take in only certain types of data. Vertices, normals and colors are in general aggregates of 32-bit floats (which is why no vertex type is ever a vector of 3 doubles). How does the angles thing work? Not sure I follow you. Your intuition is right that normals around a vertex will always be in a sphere. The thing is that you can encode that as spherical coordinates (http://en.wikipedia.org/wiki/Spherical_coordinates), where r = 1 (since a normal is always unit-length). So the direction could be encoded as two angles, theta and phi, inclination and azimuth (see the Wikipedia article). Now, you already save one float that way over storing a 3-component vector. If you want to save more, since the angles are small numbers, you can store both of them into the lower and upper parts of a single 32-bit float (two 16 bit numbers) and re-extract them from the float in the shader. Another way is you could store only 2 of the 3 components of the normal - since a normal is unit-length you can calculate the third component easily. Those numbers will also be small (less than or equal to 1) so you could do the same transformation into two 16-bit values and store them into a single float. The spherical coordinates just came to mind first as I've used it before, but the result would be the same. If you did the normal lookup, wouldn't you save a whole load of shader processing time, or is memory bandwidth a bigger limitation with shaders? You'd save a little bit of processing time per vertex, but compared to a texture lookup to get the right normal from the lookup table, I don't know what would win. Seriously, what I've described above is child's play for a GPU, and very easily parallelizable, which is what GPUs do best. It's not really a matter of bandwidth since your lookup table would be pretty small too. I expect you'd get similar performance in both cases, for me it's just inconvenient to drag around an extra
Re: [osg-users] Renderer and SceneView classes
Hello Robert, On Nov 9, 2009, at 3:22 AM, Robert Osfield wrote: Hi Paul, On Sun, Nov 8, 2009 at 2:44 PM, Paul Martz pma...@skew-matrix.com wrote: Hi Robert -- There are large projects out there based on SceneView and getting along just fine without osgViewer. Removing SceneView would, at best, require them to migrate SceneView out of OSG and into their own app (where it would continue to work, barring future incompatible changes in OSG). And at worst, cost them an expensive port and re-verification of their product. I support marking SceneView as deprecated and replaced by Renderer, but think it would be wise to avoid changes to OSG that render SceneView inoperable. This has been my plan. To steadily move more functionality into osgViewer::Renderer and make SceneView redundant w.r.t modern OSG usage. SceneView needn't change too much, as CullVisitor/RenderStage/RenderBin etc. will still be in osgUtil. Once SceneView is redundant we'd need to make decision of when to move it out of the core OSG into the deprecated section of the subversion repository along with items like the old OpenFlight plugin. Prior to SceneView being moved out we'll need a period where we encourage OSG users still relying on SceneView to migrate to using osgViewer::Viewer in conjunction with osgViewer::GraphicsWindowEmbedded, as it offers the same easy ability to embed but offers a whole heap more flexibility and functionality. Do you have an example of how to use this class with an existing windowing toolkit? There was an FAQ on this subject related to SceneView that does not seem to be present anymore. If you have an example related to osgViewer that would be great. Just as a note, while osgViewer offers more features than SceneViewer for some apps needs those features are not needed and therefore the simple interface of SceneView is more than sufficient and provides easy integration with other windowing toolkits. Hopefully with osgViewer::GraphicsWindowEmbedded offers a similar interface with low computational overhead that does not bring along features that cause a performance hit. I would encourage this right now, as SceneView is well passed it's sell by date. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Computing Normals for Drawables
2009/11/9 Andrew Burnett-Thompson aburnettthomp...@googlemail.com: Hi guys, Interesting conversation on solving this problem. I'm working with James on this and he's away this week, so I thought I'd reply to keep the conversation going, and also to thank you for your input. Just to throw another requirement into the mix, I don't think we can use vertex shaders, as we cannot guarantee what hardware the software will be run on. Basically integrated graphics is the lowest possible hardware, so what's that, DirectX 8? 9? Vertex shaders run on DX8 but you won't get many instructions. Can this not be done on the CPU side only? Interestingly we did float the idea of computing a shared normal array (a sphere coated with normals) for all objects in the scene, then provide indices between Geometry vertices and the shared normal array, however we really didn't know if this was possible in OSG, or if it would work. A quick look at osg::Geometry source code there is a function setNormalIndices, so perhaps if we were to create a NodeVisitor that did the following this could work? 1. On creation of the nodeVisitor, create an osg::Vec3Array for shared normals. Populate with normals in all directions. 2. As the NodeVisitor walks the tree, for each Geometry object use the code from SmoothingVisitor to calculate what the normal should be 3. Rather than store that normal in an array and pass to the Geometry, instead find the closest normal to it in the shared normal array, 4. Store the index to the shared normal, and finally set the indices on the Geometry using setNormalIndices This would be done once on load or creation of an object. It wouldn't matter to take the performance hit once per load, nor would it matter if this slowed down rendering. We already employ aggressive use of culling to achieve decent rendering framerate when the object count is high. The hard limit is memory. Thanks a lot for your input, The only way to do it with the fixed pipeline I can think of, is basically just sort all your geometry into group's by the approximate normal, then you don't have to store the normal index at all so you'd save more memory. Doing it that way you're using BIND_OVERALL and vertex buffers so you're still using osgs fast path. Makes updating geometry a pain, but that doesn't sound like a problem from your description. Also with grouping the geometry this way you aren't restricted to a using a power of two number of normals, you can just try different numbers of normals till you get reasonable looking results. -- http://www.ssTk.co.uk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Renderer and SceneView classes
On Mon, Nov 9, 2009 at 1:28 PM, Doug McCorkle mc...@iastate.edu wrote: Do you have an example of how to use this class with an existing windowing toolkit? There was an FAQ on this subject related to SceneView that does not seem to be present anymore. If you have an example related to osgViewer that would be great. osgveviewerSDL and osgviewerGLUT both show how to use GraphicsWindowEmbedded. Just as a note, while osgViewer offers more features than SceneViewer for some apps needs those features are not needed and therefore the simple interface of SceneView is more than sufficient and provides easy integration with other windowing toolkits. Hopefully with osgViewer::GraphicsWindowEmbedded offers a similar interface with low computational overhead that does not bring along features that cause a performance hit. There is essentially no overhead in using osgViewer vs SceneView. As you'll see from the osgviewerSDL and osgviewerGLUT examples it's actually very straight forward to use. Another key benefit of using osgViewer over SceneView is that it means that you can move between using GraphicsWIndowEmbedded style app to one using the inbuilt GraphicsWindow functionality or GraphicsWindow window inheritance, you aren't locked into one style of viewer usage. Finally osgViewer usage is far more supportable by others in the community. Using SceneView directly means that you can use and abuse it in ways that we can't second guess. What makes it harder for us to support is a loss all round, both for you as you won't get the same quality of support as you'll get using mainstream classes, and for those attempting to support you as they just be wasting time trying to help you do stuff that osgViewer already solves. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Renderer and SceneView classes
Hello Robert, On Nov 9, 2009, at 7:54 AM, Robert Osfield wrote: On Mon, Nov 9, 2009 at 1:28 PM, Doug McCorkle mc...@iastate.edu wrote: Do you have an example of how to use this class with an existing windowing toolkit? There was an FAQ on this subject related to SceneView that does not seem to be present anymore. If you have an example related to osgViewer that would be great. osgveviewerSDL and osgviewerGLUT both show how to use GraphicsWindowEmbedded. Thanks for the info. I will take a look at these. Just as a note, while osgViewer offers more features than SceneViewer for some apps needs those features are not needed and therefore the simple interface of SceneView is more than sufficient and provides easy integration with other windowing toolkits. Hopefully with osgViewer::GraphicsWindowEmbedded offers a similar interface with low computational overhead that does not bring along features that cause a performance hit. There is essentially no overhead in using osgViewer vs SceneView. As you'll see from the osgviewerSDL and osgviewerGLUT examples it's actually very straight forward to use. Another key benefit of using osgViewer over SceneView is that it means that you can move between using GraphicsWIndowEmbedded style app to one using the inbuilt GraphicsWindow functionality or GraphicsWindow window inheritance, you aren't locked into one style of viewer usage. Finally osgViewer usage is far more supportable by others in the community. Using SceneView directly means that you can use and abuse it in ways that we can't second guess. What makes it harder for us to support is a loss all round, both for you as you won't get the same quality of support as you'll get using mainstream classes, and for those attempting to support you as they just be wasting time trying to help you do stuff that osgViewer already solves. I understand this point and for the most part we pay for support to address these issues (because of the points you raise above). As I pointed out before I really do not have a need for the features you mention above and therefore have not found it necessary to move to osgViewer. Anyway, thanks for the pointers to the examples. I will take a look at these and see what issues might arise in migrating our application to this interface. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Computing Normals for Drawables
Hi Andrew, Just to throw another requirement into the mix, I don't think we can use vertex shaders, as we cannot guarantee what hardware the software will be run on. Basically integrated graphics is the lowest possible hardware, so what's that, DirectX 8? 9? Vertex shaders run on DX8 but you won't get many instructions. Well you're kind of juggling conflicting requirements. You want the app to run on low-end graphics, but you want to reduce its CPU-side memory usage to a minimum by not storing normals. Generally you have a trade-off to make by using more memory and getting good performance, and getting lower performance but using less memory. That's just the way it goes, but you'll have to try to know for sure. No one has a situation exactly like yours, we can only offer guidance. We've given you a few different alternatives, now you have to weigh the pros and cons yourselves. Perhaps try a few of the alternatives in a little test program before making changes in your software itself, and test the alternatives in realistic settings (with lots of objects for example) looking at the stats each time. If you really want to use normal indices, try it out, but as Robert said (and I and others have said before in this thread) this will drop you down to slow paths. If that's good enough for you, then fine, but you won't know unless you try it. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Renderer and SceneView classes
Doug McCorkle schrieb: Hello Robert, On Nov 9, 2009, at 3:22 AM, Robert Osfield wrote: Hi Paul, On Sun, Nov 8, 2009 at 2:44 PM, Paul Martz pma...@skew-matrix.com wrote: Hi Robert -- There are large projects out there based on SceneView and getting along just fine without osgViewer. Removing SceneView would, at best, require them to migrate SceneView out of OSG and into their own app (where it would continue to work, barring future incompatible changes in OSG). And at worst, cost them an expensive port and re-verification of their product. I support marking SceneView as deprecated and replaced by Renderer, but think it would be wise to avoid changes to OSG that render SceneView inoperable. This has been my plan. To steadily move more functionality into osgViewer::Renderer and make SceneView redundant w.r.t modern OSG usage. SceneView needn't change too much, as CullVisitor/RenderStage/RenderBin etc. will still be in osgUtil. Once SceneView is redundant we'd need to make decision of when to move it out of the core OSG into the deprecated section of the subversion repository along with items like the old OpenFlight plugin. Prior to SceneView being moved out we'll need a period where we encourage OSG users still relying on SceneView to migrate to using osgViewer::Viewer in conjunction with osgViewer::GraphicsWindowEmbedded, as it offers the same easy ability to embed but offers a whole heap more flexibility and functionality. Do you have an example of how to use this class with an existing windowing toolkit? There was an FAQ on this subject related to SceneView that does not seem to be present anymore. If you have an example related to osgViewer that would be great. osgViewerGlut does this, for instance. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Renderer and SceneView classes
Hi Doug, On Mon, Nov 9, 2009 at 2:00 PM, Doug McCorkle mc...@iastate.edu wrote: I understand this point and for the most part we pay for support to address these issues (because of the points you raise above). We if you pay another party to maintain a branch of the OSG for you then this is fine, any part or version of the OSG can be maintained forever as it's all open source. This is the beauty of open source - you aren't locked into what I decide to do, or to come to me to support. That being said, my resposibility as project lead is to the main branch, and this will need to evolve within the needs of the wider community, with items being deprecated where they no longer server a purpose of cause potential support issues. This original post in this thread is an illustration of the fact of having SceneView around still can cause confusion. Other threads you'll still see user's trying to using osg::Geometry vertex indices even though the inline docs all say don't do it, and users get persistently told not to use it. In the end sometimes the only way to avoid misuse is to remove code keeping it around of backwards compatibility just causes more hassle. As I pointed out before I really do not have a need for the features you mention above and therefore have not found it necessary to move to osgViewer. Anyway, thanks for the pointers to the examples. I will take a look at these and see what issues might arise in migrating our application to this interface. I suspect you already have a need for osgViewer, but you've coded around the deficiencies of SceneView so don't notice it. I've certainly laboured lots of times trying to help users over the years integrate the DatabasePager with their SceneView apps, or how to handle multiple contexts etc. All problems neatly solved by osgViewer for you. It's worth mentioning that SceneView was officially marked for deprecation back when we were working on the dev work for OpenSceneGraph-2.0, over two and half years ago. From the doxygen comment for SceneView: /** * SceneView is deprecated, and is now just kept for backwards compatibility. * It is recommend that you use osgViewer::Viewer/Composite in combination * with osgViewer::GraphicsWindowEmbedded for embedded rendering support as * this provides a greater range of functionality and consistency of API. */ Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, After looking at both of the suggested examples (osgviewerSDL and osgviewerGLUT) I have a couple of questions. First, with SceneView we handed off the context ID to OSG, now it looks like we provide context information to osgViewer through the window's initial position? Is this correct? Is there anyway to hand off the context ID instead of using the setUpViewerAsEmbeddedInWindow interface? Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? Third, currently we do our update traversal and cull/draw on two separate threads, what is the appropriate way to handle this? I do not see a way to separate these two operations with the examples provided that use the frame call. Fourth, we currently make calls to SceneView like: sv-setViewport( ); sv-setProjectionMatrix( ); sv-setViewMatrix( ); are these same calls made on the osgViewer camera just like in SceneView? Fifth, we currently setup the OpenGL matrix stack with calls like: glPushAttrib( GL_ALL_ATTRIB_BITS ~GL_TEXTURE_BIT ); glPushAttrib( GL_TRANSFORM_BIT ); glPushAttrib( GL_VIEWPORT_BIT ); glMatrixMode( GL_MODELVIEW ); glPushMatrix(); glMatrixMode( GL_PROJECTION ); glPushMatrix(); //do cull/draw glMatrixMode( GL_PROJECTION ); glPopMatrix(); glMatrixMode( GL_MODELVIEW ); glPopMatrix(); glPopAttrib(); glPopAttrib(); glPopAttrib(); is this still required or is osgViewer hiding this somewhere? Thanks for the help. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture is rendered strange
Hi, Well the Fileformat isnt a copypaste error. I just have 2 versions of that file. The texcoords are indeed copypaste errors. Must have been too late :? Thank you! Cheers, Thorsten -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19363#19363 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] problems with transparency in the QOsgWidget for QT
Hi, I have problems with using the QOsgWidget under QT. I was load a Collada file *.dae The scene in the osgviewer.exe was correct (attachment pic good), but if i use the QOsgWidget Code: osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFile(collada.dae); root-addChild(loadedModel.get()); the scene was not as in the osgviewer.exe (attachment pic bad). How can i manipulate the QOsgWidget, so that the QOsgWidget show the same result as the osgviewer.exe Thank you! Cheers, Mike[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19364#19364 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture is rendered strange
Hi, Yes, I changed the 4 zeros to 0,1,2,3 in the array. Working fine now. Thank you! Cheers, Thorsten -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19366#19366 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Computing Normals for Drawables
Hi there, Jean Well you're kind of juggling conflicting requirements. You want the app to run on low-end graphics, but you want to reduce its CPU-side memory usage to a minimum by not storing normals. Well it's just a typical project really, everyone wants the moon on a stick and they don't understand the concept of engineering compromise! I think the overriding limit is memory usage. If the app cannot load the models it needs to, then its no good. Rendering performance is quite good (we aggressively cull and get 35 frames per second on an nVidia 9600. The most amount of time spent is cull) and so long as the frame rate remains above 5 FPS (ie: just about interactive) its ok ... *Simon Hammett* The only way to do it with the fixed pipeline I can think of, is basically just sort all your geometry into group's by the approximate normal, then you don't have to store the normal index at all so you'd save more memory. Simon I'm not sure I 100% follow what you're saying here. Could you clarify what you meant? Ok thanks all for your excellent suggestions. I think I will take a look at implementing an Index to shared Normal Array using setNormalIndices, even if this drops us down to slow paths, as I would be interested to see just how bad an effect it has on performance. If it's several orders of magnitude, well I will chalk that up to experience and move on. The other idea I like is to use the same method (Indices to normals) in a vertex shader. Not quite sure how I will do this but I believe the hardware we are operating on will be Shader Model 1.0 or 2.0 as a minimum. Thanks a lot, Andrew On Mon, Nov 9, 2009 at 2:14 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Andrew, Just to throw another requirement into the mix, I don't think we can use vertex shaders, as we cannot guarantee what hardware the software will be run on. Basically integrated graphics is the lowest possible hardware, so what's that, DirectX 8? 9? Vertex shaders run on DX8 but you won't get many instructions. Well you're kind of juggling conflicting requirements. You want the app to run on low-end graphics, but you want to reduce its CPU-side memory usage to a minimum by not storing normals. Generally you have a trade-off to make by using more memory and getting good performance, and getting lower performance but using less memory. That's just the way it goes, but you'll have to try to know for sure. No one has a situation exactly like yours, we can only offer guidance. We've given you a few different alternatives, now you have to weigh the pros and cons yourselves. Perhaps try a few of the alternatives in a little test program before making changes in your software itself, and test the alternatives in realistic settings (with lots of objects for example) looking at the stats each time. If you really want to use normal indices, try it out, but as Robert said (and I and others have said before in this thread) this will drop you down to slow paths. If that's good enough for you, then fine, but you won't know unless you try it. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Doug McCorkle wrote: Hello Robert, After looking at both of the suggested examples (osgviewerSDL and osgviewerGLUT) I have a couple of questions. First, with SceneView we handed off the context ID to OSG, now it looks like we provide context information to osgViewer through the window's initial position? Is this correct? Is there anyway to hand off the context ID instead of using the setUpViewerAsEmbeddedInWindow interface? My understanding is that you create your own window and context, and make them current, then call setUpViewerAsEmbeddedInWindow. (Honestly, I'm not cure why osgViewer needs the window size passed as params; it seems like osgViewer could just query them from the window system. Maybe Robert can elaborate?) Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? So, for example, your app opens multiple windows, each with their own context, say for a tiled display or CAVE... You only have one View (with multiple slave cameras) so it seems like this should work. Robert? Third, currently we do our update traversal and cull/draw on two separate threads, what is the appropriate way to handle this? This is a good question. Under the embedded model, you own context management, so the osgViewer threading models don't come in to play. I think the answer is that you use one thread to call Viewer::updateTraversal, and then you fire off concurrent threads to execute Viewer::renderingTraversals. Basically, you need to look at the internals of frame() to see what you need to do. (Keep in mind that Viewer derives from ViewerBase, so be sure to look at both classes for relevant code). I do not see a way to separate these two operations with the examples provided that use the frame call. Fourth, we currently make calls to SceneView like: sv-setViewport( ); sv-setProjectionMatrix( ); sv-setViewMatrix( ); are these same calls made on the osgViewer camera just like in SceneView? Pretty much, yes. Fifth, we currently setup the OpenGL matrix stack with calls like: glPushAttrib( GL_ALL_ATTRIB_BITS ~GL_TEXTURE_BIT ); glPushAttrib( GL_TRANSFORM_BIT ); glPushAttrib( GL_VIEWPORT_BIT ); glMatrixMode( GL_MODELVIEW ); glPushMatrix(); glMatrixMode( GL_PROJECTION ); glPushMatrix(); //do cull/draw glMatrixMode( GL_PROJECTION ); glPopMatrix(); glMatrixMode( GL_MODELVIEW ); glPopMatrix(); glPopAttrib(); glPopAttrib(); glPopAttrib(); is this still required or is osgViewer hiding this somewhere? Thanks for the help. I don't think osgViewer would be able to hide it; you can search the source code to see what it does. I don't think you have a need to push and pop the matrix stack around your draw, unless you have code outside of cull and draw that depends on the matrices being set a certain way. I hope this helps. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug and Paul, On Mon, Nov 9, 2009 at 5:09 PM, Paul Martz pma...@skew-matrix.com wrote: My understanding is that you create your own window and context, and make them current, then call setUpViewerAsEmbeddedInWindow. (Honestly, I'm not cure why osgViewer needs the window size passed as params; it seems like osgViewer could just query them from the window system. Maybe Robert can elaborate?) The whole point of GraphicsWindowEmbedded is to hide the windowing system support entirely from osgViewer, so it doesn't have any way what so ever to query anything about the windowing system. Just like SceneView you have to tell it the size of viewport/window etc. Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? So, for example, your app opens multiple windows, each with their own context, say for a tiled display or CAVE... You only have one View (with multiple slave cameras) so it seems like this should work. Robert? GraphicsWindowsEmbedded is suited for single context, single threaded apps. If you want to multi-context apps then the way to do is to use window inheritance feature of osgViewer::GraphicsWindow and inherit your applications generated window. The osgviewerMFC and osgviewerWx are examples that use GraphicsWindow inheritance. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hi Doug, On Mon, Nov 9, 2009 at 3:52 PM, Doug McCorkle mc...@iastate.edu wrote: After looking at both of the suggested examples (osgviewerSDL and osgviewerGLUT) I have a couple of questions. First, with SceneView we handed off the context ID to OSG, now it looks like we provide context information to osgViewer through the window's initial position? Is this correct? Is there anyway to hand off the context ID instead of using the setUpViewerAsEmbeddedInWindow interface? Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? One of the limits of GrapicsWindowEmbedded is that it can't automatically handle multi-threaded, multi-context usage. You potentially could have multipe osgViewer::Viewer each with it's own GraphicsWindowEmbedded, and set the ContextID for each GraphicsWindowEmbedded by getting the doing graphicswindow-getState()-setContextID(i);. However, for multi-context work you really are better off using osgViewer::GraphicsWindow window inheritance. Third, currently we do our update traversal and cull/draw on two separate threads, what is the appropriate way to handle this? I do not see a way to separate these two operations with the examples provided that use the frame call. You can break viewer.frame() down into it' update and rendering dispatch components. If you use GraphicsWindow inheritance, or native GraphicsWindow generation you'll actually get all the threading you are already doing for free. Fourth, we currently make calls to SceneView like: sv-setViewport( ); sv-setProjectionMatrix( ); sv-setViewMatrix( ); Not much different: viewer.getCamera()-setViewport(..); viewer.getCamera()-seProjectionMatrix(..); viewer.getCamera()-seViewMatrix(..); are these same calls made on the osgViewer camera just like in SceneView? Fifth, we currently setup the OpenGL matrix stack with calls like: glPushAttrib( GL_ALL_ATTRIB_BITS ~GL_TEXTURE_BIT ); glPushAttrib( GL_TRANSFORM_BIT ); glPushAttrib( GL_VIEWPORT_BIT ); glMatrixMode( GL_MODELVIEW ); glPushMatrix(); glMatrixMode( GL_PROJECTION ); glPushMatrix(); //do cull/draw glMatrixMode( GL_PROJECTION ); glPopMatrix(); glMatrixMode( GL_MODELVIEW ); glPopMatrix(); glPopAttrib(); glPopAttrib(); glPopAttrib(); is this still required or is osgViewer hiding this somewhere? Thanks for the You could wrap this all around the viewer.renderingTraversals(); call if you want. It's pretty hacky though doing all the push and pops. OpenGL 3.x and OpenGL ES 2.0 don't support such hacks so the days are numbered for this type of approach. -- I have to ask, what is the compelling reason to not to use osgViewer and role you own? It does multi-thread, multi-context natively - it can do caves, power-walls and much more (such as distortion correction), it just a matter of configuring the viewer with the appropriate slave Cameras. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
Hello Robert, On Nov 9, 2009, at 11:41 AM, Robert Osfield wrote: Hi Doug, On Mon, Nov 9, 2009 at 3:52 PM, Doug McCorkle mc...@iastate.edu wrote: After looking at both of the suggested examples (osgviewerSDL and osgviewerGLUT) I have a couple of questions. First, with SceneView we handed off the context ID to OSG, now it looks like we provide context information to osgViewer through the window's initial position? Is this correct? Is there anyway to hand off the context ID instead of using the setUpViewerAsEmbeddedInWindow interface? Second, what is the appropriate way to handle multiple contexts with the GraphicsWindowEmbedded interface? One of the limits of GrapicsWindowEmbedded is that it can't automatically handle multi-threaded, multi-context usage. You potentially could have multipe osgViewer::Viewer each with it's own GraphicsWindowEmbedded, and set the ContextID for each GraphicsWindowEmbedded by getting the doing graphicswindow-getState()-setContextID(i);. Slick. So this would be very similar to what we are doing now with SceneView. Thanks for the insight. However, for multi-context work you really are better off using osgViewer::GraphicsWindow window inheritance. Third, currently we do our update traversal and cull/draw on two separate threads, what is the appropriate way to handle this? I do not see a way to separate these two operations with the examples provided that use the frame call. You can break viewer.frame() down into it' update and rendering dispatch components. Thanks. I will look into this. If you use GraphicsWindow inheritance, or native GraphicsWindow generation you'll actually get all the threading you are already doing for free. Fourth, we currently make calls to SceneView like: sv-setViewport( ); sv-setProjectionMatrix( ); sv-setViewMatrix( ); Not much different: viewer.getCamera()-setViewport(..); viewer.getCamera()-seProjectionMatrix(..); viewer.getCamera()-seViewMatrix(..); are these same calls made on the osgViewer camera just like in SceneView? Fifth, we currently setup the OpenGL matrix stack with calls like: glPushAttrib( GL_ALL_ATTRIB_BITS ~GL_TEXTURE_BIT ); glPushAttrib( GL_TRANSFORM_BIT ); glPushAttrib( GL_VIEWPORT_BIT ); glMatrixMode( GL_MODELVIEW ); glPushMatrix(); glMatrixMode( GL_PROJECTION ); glPushMatrix(); //do cull/draw glMatrixMode( GL_PROJECTION ); glPopMatrix(); glMatrixMode( GL_MODELVIEW ); glPopMatrix(); glPopAttrib(); glPopAttrib(); glPopAttrib(); is this still required or is osgViewer hiding this somewhere? Thanks for the You could wrap this all around the viewer.renderingTraversals(); call if you want. It's pretty hacky though doing all the push and pops. OpenGL 3.x and OpenGL ES 2.0 don't support such hacks so the days are numbered for this type of approach. Yup. This will be disappearing in our app very soon with our OGL 3 migration this spring. -- I have to ask, what is the compelling reason to not to use osgViewer and role you own? It does multi-thread, multi-context natively - it can do caves, power-walls and much more (such as distortion correction), it just a matter of configuring the viewer with the appropriate slave Cameras. Candidly, I think that the VR Juggler configuration and device management is better than what is in OSG. I realize that is a personal preference but I like the VR Juggler windowing API and hardware management and configuration tools and implementation. I also like the leanness (it is a word amazingly) of the VR Juggler approach and implementation for windowing and device management. Most of what is supported in osgViewer I do not need or want. I really like the core OSG scenegraph and the file loaders but beyond that we do not need all of the event handling, manipulator tools, or other nodekit integration that osgViewer provides. We need a flexible scenegraph that we can control much of what is going on under-the-hood with windowing and events. Thanks again for the pointers above. Doug ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG v2.8.0
All, I'm currently trying to upgrade from OSG-1.2 to OSG-2.8.0 to upgrade a process currently in place. I'm trying to load this new version from scratch on a Windows XP machine with VS 2003 .NET. I'm following the instructions from: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio and have set up all of my environment variables, and I ran CMake to get my solution, and upon building the entire solution, I'm receiving over 250 link errors in the plugins ogr project similar to: Linking... Creating library C:\CMHP\OpenSceneGraph-2.8.0_orig\OpenSceneGraph\lib\Debug\osgdb_ogrd.lib and object C:\CMHP\OpenSceneGraph-2.8.0_orig\OpenSceneGraph\lib\Debug\osgdb_ogrd.exp ReaderWriterOGR.obj : error LNK2001: unresolved external symbol public: virtual enum CPLErr __thiscall GDALMajorObject::SetMetadataItem(char const *,char const *,char const *) (?setmetadatai...@gdalmajorobject@@UAE?AW4CPLErr@@pb...@z) Does anyone know what I'm missing here? Also, has the osgDem application gone away since OSG-1.2? Thanks! Jake _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgShadow question
From the Common Questions of the osgShadow node kit. What if my objects already have a shader applied to them? * That shader also needs to implement shadow mapping. See the http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src /osgShadow/ShadowMap.cpp top of src/osgShadow/ShadowMap.cpp for the basic shader, and use that in your shader (keep the same names for the variables too). Which shader is the basic shader, fragmentShaderSource_noBaseTexture or fragmentShaderSource_withBaseTexture? I assume it isn't one for HUD. Thanks, W ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG v2.8.0
Jacob Armstrong wrote: I'm currently trying to upgrade from OSG-1.2 to OSG-2.8.0 to upgrade a process currently in place. I'm trying to load this new version from scratch on a Windows XP machine with VS 2003 .NET. I'm following the instructions from: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio and have set up all of my environment variables, and I ran CMake to get my solution, and upon building the entire solution, I'm receiving over 250 link errors in the plugins ogr project similar to: Linking... Creating library C:\CMHP\OpenSceneGraph-2.8.0_orig\OpenSceneGraph\lib\Debug\osgdb_ogrd.lib and object C:\CMHP\OpenSceneGraph-2.8.0_orig\OpenSceneGraph\lib\Debug\osgdb_ogrd.exp ReaderWriterOGR.obj : error LNK2001: unresolved external symbol public: virtual enum CPLErr __thiscall GDALMajorObject::SetMetadataItem(char const *,char const *,char const *) (?setmetadatai...@gdalmajorobject@@UAE?AW4CPLErr@@pb...@z mailto:?setmetadatai...@gdalmajorobject@@UAE?AW4CPLErr@@pb...@z) Does anyone know what I'm missing here? It would sound like GDAL is not available during compilation. OGR is the GIS image loader that uses GDAL. Also, has the osgDem application gone away since OSG-1.2? It is broken out into VirtualPlanetBuilder, a separate SVN checkout and build: http://www.openscenegraph.org/projects/VirtualPlanetBuilder You will need to finish the OSG build itself first, then build VPB. Thanks! Jake -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi Wyatt, Which shader is the basic shader, fragmentShaderSource_noBaseTexture or fragmentShaderSource_withBaseTexture? Depends on whether your object has a texture or not. Although now, since texture lookups are so cheap these days, I would suggest you save yourself some aggravation and just apply a white 1x1 texture to the top of your scene graph (which will thus apply to all untextured objects but won't change anything in their appearance) and use only one shader, the withBaseTexture one. See the code for osgShadow::ShadowMap for an example of such a texture set up. I assume it isn’t one for HUD. What do HUDs have to do with this? Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG v2.8.0
Do you need the ogr plugin? If not, don't worry about it. If you do need ogr, then I suspect the link errors might be coming from an outdated version of the GDAL dependency. Lacking further information (like a map of OSG version to GDAL version), I'd try upgrading GDAL to see if the issue resolves itself. Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 Jacob Armstrong wrote: All, I'm currently trying to upgrade from OSG-1.2 to OSG-2.8.0 to upgrade a process currently in place. I'm trying to load this new version from scratch on a Windows XP machine with VS 2003 .NET. I'm following the instructions from: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio and have set up all of my environment variables, and I ran CMake to get my solution, and upon building the entire solution, I'm receiving over 250 link errors in the plugins ogr project similar to: Linking... Creating library C:\CMHP\OpenSceneGraph-2.8.0_orig\OpenSceneGraph\lib\Debug\osgdb_ogrd.lib and object C:\CMHP\OpenSceneGraph-2.8.0_orig\OpenSceneGraph\lib\Debug\osgdb_ogrd.exp ReaderWriterOGR.obj : error LNK2001: unresolved external symbol public: virtual enum CPLErr __thiscall GDALMajorObject::SetMetadataItem(char const *,char const *,char const *) (?setmetadatai...@gdalmajorobject@@UAE?AW4CPLErr@@pb...@z mailto:?setmetadatai...@gdalmajorobject@@UAE?AW4CPLErr@@pb...@z) Does anyone know what I'm missing here? Also, has the osgDem application gone away since OSG-1.2? Thanks! Jake Hotmail: Trusted email with powerful SPAM protection. Sign up now. http://clk.atdmt.com/GBL/go/177141665/direct/01/ ___ 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 v2.8.0
What other dependencies are there for OSG-2.8.0, and where can I get them? I downloaded all of the dependencies for VS 7.1 according to http://www.openscenegraph.org/projects/osg/wiki/Downloads/Dependencies. I placed them all in: ..\OpenSceneGraph-2.8.0\3rdParty\bin ..\OpenSceneGraph-2.8.0\3rdParty\include etc.. I've got environment variables for: OSG_ROOT OSG_BIN_PATH OSG_INCLUDE_PATH OSG_LIB_PATH I don't need the ogr project, so I'm not considered about it, and I'm looking to install VPBMaster as well, so what else am I missing here? I can't seem to set up a working load with the online documentation. Date: Mon, 9 Nov 2009 11:44:30 -0700 From: xe...@alphapixel.com To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] OSG v2.8.0 Jacob Armstrong wrote: I'm currently trying to upgrade from OSG-1.2 to OSG-2.8.0 to upgrade a process currently in place. I'm trying to load this new version from scratch on a Windows XP machine with VS 2003 .NET. I'm following the instructions from: http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio and have set up all of my environment variables, and I ran CMake to get my solution, and upon building the entire solution, I'm receiving over 250 link errors in the plugins ogr project similar to: Linking... Creating library C:\CMHP\OpenSceneGraph-2.8.0_orig\OpenSceneGraph\lib\Debug\osgdb_ogrd.lib and object C:\CMHP\OpenSceneGraph-2.8.0_orig\OpenSceneGraph\lib\Debug\osgdb_ogrd.exp ReaderWriterOGR.obj : error LNK2001: unresolved external symbol public: virtual enum CPLErr __thiscall GDALMajorObject::SetMetadataItem(char const *,char const *,char const *) (?setmetadatai...@gdalmajorobject@@UAE?AW4CPLErr@@pb...@z mailto:?setmetadatai...@gdalmajorobject@@UAE?AW4CPLErr@@pb...@z) Does anyone know what I'm missing here? It would sound like GDAL is not available during compilation. OGR is the GIS image loader that uses GDAL. Also, has the osgDem application gone away since OSG-1.2? It is broken out into VirtualPlanetBuilder, a separate SVN checkout and build: http://www.openscenegraph.org/projects/VirtualPlanetBuilder You will need to finish the OSG build itself first, then build VPB. Thanks! Jake -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Windows 7: Unclutter your desktop. http://go.microsoft.com/?linkid=9690331ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen:112009___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG v2.8.0
Hi Jacob, I don't need the ogr project, so I'm not considered about it, and I'm looking to install VPBMaster as well, so what else am I missing here? I can't seem to set up a working load with the online documentation. If you don't need the ogr loader, then you don't need all the dependencies... Most of the dependencies are optional, so you need to know if you need them yourself. The basic set of dependencies are jpeg, png, freetype, tiff, gif and zlib. You can always just build with a small set of dependencies and add others as needed later. If you already have gdal in your dependencies, but don't want to compile the ogr plugin, just delete whatever values you have in the GDAL* settings in the CMake window. They should get set to something_NOTFOUND afterwards, and the ogr plugin's project shouldn't be generated. Or just remove the gdal*.h header files in your dependencies include directory. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG v2.8.0
Jacob Armstrong wrote: What other dependencies are there for OSG-2.8.0, and where can I get them? I don't need the ogr project, so I'm not considered about it, and I'm looking to install VPBMaster as well, so what else am I missing here? I can't seem to set up a working load with the online documentation. You'll need GDAL to build VPB, so go get it. OGR isn't critical so many people skip it. GDAL probably should be listed on that Wiki page. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Databasepager + multiple views + different camera positions = memory leak?
BTW are aware of any publicly available Terra Page terrain? Off hand I'm not sure that there is any! Have you tried contacting Presagis? Thay have the rights for Terra Page and might have a sample. I'm about to challange Presagis to make a ive output for there TerraVista program. I haven't tryed to generate any TerraPage terrain using TerraVista, hince I don't have anything to give. All the terrain that I'm alowed to make at the moment is OpenFlight. FYI: TerraVista generated terrain (that is made to OpenFlight) works well in OSG (after it is converted to an ive file). D Glenn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19384#19384 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
Paul Martz pma...@skew-matrix.com wrote: osgBullet is a set of software tools for applications that use both OSG and the Bullet physics library. It features utilities to create Bullet collision shapes from OSG data and vice versa, run the physics simulation in a separate host thread, debug utilities to display Bullet collision shapes in an OSG scene, support for arbitrary scaling and center of mass, and support for COLLADA. For more information on osgBullet and to download the source, visit: http://osgbullet.vesuite.org Paul, you are my hero! I was working on integrating COLLADA and Bullet as we speak :) Going to check it out right away! Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Is this what you are referring to?
if (withBaseTexture)
{
scene-getOrCreateStateSet()-setTextureAttributeAndModes( 0,
new osg::Texture2D(osgDB::readImageFile(Images/lz.rgb)),
osg::StateAttribute::ON);
}
W
-Original Message-
See the code for osgShadow::ShadowMap for an example of such a texture set
up.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi Wyatt,
Is this what you are referring to?
if (withBaseTexture)
{
scene-getOrCreateStateSet()-setTextureAttributeAndModes( 0,
new osg::Texture2D(osgDB::readImageFile(Images/lz.rgb)),
osg::StateAttribute::ON);
}
Nope, this:
{
// fake texture for baseTexture, add a fake texture
// we support by default at least one texture layer
// without this fake texture we can not support
// textured and not textured scene
// TODO: at the moment the PSSM supports just one texture
layer in the GLSL shader, multitexture are
// not yet supported !
osg::Image* image = new osg::Image;
// allocate the image data, noPixels x 1 x 1 with 4 rgba
floats - equivilant to a Vec4!
int noPixels = 1;
image-allocateImage(noPixels,1,1,GL_RGBA,GL_FLOAT);
image-setInternalTextureFormat(GL_RGBA);
// fill in the image data.
osg::Vec4* dataPtr = (osg::Vec4*)image-data();
osg::Vec4 color(1,1,1,1);
*dataPtr = color;
// make fake texture
osg::Texture2D* fakeTex = new osg::Texture2D;
fakeTex-setWrap(osg::Texture2D::WRAP_S,osg::Texture2D::CLAMP_TO_EDGE);
fakeTex-setWrap(osg::Texture2D::WRAP_T,osg::Texture2D::CLAMP_TO_EDGE);
fakeTex-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR);
fakeTex-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
fakeTex-setImage(image);
// add fake texture
_stateset-setTextureAttribute(_baseTextureUnit,fakeTex,osg::StateAttribute::ON);
_stateset-setTextureMode(_baseTextureUnit,GL_TEXTURE_2D,osg::StateAttribute::ON);
_stateset-setTextureMode(_baseTextureUnit,GL_TEXTURE_3D,osg::StateAttribute::OFF);
#if !defined(OSG_GLES1_AVAILABLE)
!defined(OSG_GLES2_AVAILABLE)
_stateset-setTextureMode(_baseTextureUnit,GL_TEXTURE_1D,osg::StateAttribute::OFF);
#endif
}
(sorry for the formatting, search for fakeTex in your sources and you
should see it)
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
Ulrich Hertlein u.hertl...@sandbox.de wrote: But I was wondering: wasn't there some sort of osgPhysics effort that was aiming to provide an independent physics layer? Yes, there is osgPhysics, but it is using the PAL abstraction layer which doesn't work with gcc properly due to the way it is loading the physics engines on the fly. Even with static build I have never managed to get the examples to work. Regards, Jan signature.asc Description: This is a digitally signed message part. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
Jan Ciger wrote: Yes, there is osgPhysics, but it is using the PAL abstraction layer which doesn't work with gcc properly due to the way it is loading the physics engines on the fly. Even with static build I have never managed to get the examples to work. My client and I considered and dismissed PAL as unusable and decided to focus directly on Bullet instead. Rather than integrate Bullet into OSG (or vice versa), the design philosophy of osgBullet is to provide a lightweight utility library that enables the application to use both the Bullet and OSG APIs directly. As far as COLLADA goes, our original intent was to create large sets of collision shapes as an offline process, and selectively load them at runtime. However, midway through development, we discovered that the Bullet COLLADA loader was extremely inefficient, as much as 10 times slower than simply recreating the collision shapes at runtime. So osgBullet contains some support for COLLADA but it has really fallen into disuse at this point. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenGL error 'out of memory'
When I render my scene, I'm getting this in the log: Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) This is on a Windows XP machine with 4GB of RAM. I suspect it isn't complaining about running out of that memory though. Is it video RAM that I have run out of? Cory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how can i enable alpha test?
Ruben, thank your very much. :D i have enable it! Thanks again for your help! ren -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19393#19393 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
