Re: [osg-users] OSG and NVX_gpu_memory_info
Hi all, > - An osg::Camera::DrawHandler... > - An osg::Node::NodeHandler... I just noticed some mistakes in my original post: DrawHandler should be DrawCallback, and NodeHandler should be NodeCallback. Sorry about that. I'm writing the emails on one machine and reading from another, and these mistakes snuck through. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and NVX_gpu_memory_info
Hi Robert, On 30/09/15 19:50, Robert Osfield wrote:> HI Garth, > Sorry for the typo, the setRealizeOperation is what I was referring to. Not a problem, thanks for the clarification. > If you want to check periodically then just use a Camera::DrawCallback > attached to the main camera attached to the GraphicsContext/Window of > interest. This will be called every frame, but within this callback you > could have your own check to see if the GL calls are required for that > frame. Thanks. This was one of the configurations I had tried (with setInitialDrawCallback() and setFinalDrawCallback()), and the one I had the best hopes for. Unfortunately the calls failed. I'm not certain, but I seem to remember that other GL calls worked fine in this setup, and that it was only the calls related to NVX_gpu_memory_info that were failing. Perhaps this is all an oddity relating to NVX_gpu_memory_info specifically? I also want to try this the setup you describe here *exactly*, in case this changes the result. At this point I think I'm going to have to put something minimalistic together and have an further experiment with it. I'll post a follow-up when I've got some results. Cheers, Garth > On 30 September 2015 at 10:56, Garth D <garthy_...@entropicsoftware.com> > wrote: >> Thanks for having a look at things and for the suggestion. >> >> On 30/09/15 17:35, Robert Osfield wrote:> HI Garth, >>> I'd use a RealizerOperation. Have a look at the osgvolume example to an >>> example of using a RealizerOperation to get information from the graphics >>> context. >> >> I was unfortunately unable to solve the problem. Here is what I tried: >> >> I checked the osgvolume.cpp source for 3.2.1 and 3.4.0, but did not find a >> RealizerOperation in either. >> >> I did notice that osgvolume does also use viewer.setRealizeOperation() for >> TestSupportOperation, defined earlier. Is this what you are referring to? >> Assuming yes: This is the way I was able to successfully query the >> information once only at the start of the program. Unfortunately I need to >> query the information periodically, ie. over the course of the program, >> rather than just at initialisation. Unless I am mistaken, the target of >> setRealizeOperation is only called the one time, on viewer realization. Is >> this right? If so: Is there a corresponding call that I can use to attach >> an osg::Operation or similar to in order to make the required calls >> periodically? If not: Is there a way to indicate that the operation should >> be repeatedly called? >> >> Or is there another part of osgvolume.cpp that I should be looking at? The >> only glGet* call in the file is in TestSupportOperation, which is set using >> setRealizeOperation(), so I think I am looking in the right place? >> >> I'll continue to experiment. Thanks again for the suggestion. Is there >> anything else I should try? >> >>> On 30 September 2015 at 03:49, Garth D <garthy_...@entropicsoftware.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> I was wondering if anyone has been successful in using the >>>> NVX_gpu_memory_info extension with OpenSceneGraph, and the best place to >>>> call glGetIntegerv to get the associated values. >>>> >>>> Details on the extension here: >>>> https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt >>>> >>>> I'm using Linux, OSG 3.2.1, and a card that supports the >>>> NVX_gpu_memory_info extension. >>>> >>>> I have tried querying the current and total memory using >>>> GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX and >>>> GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, and in each case but one, >> the >>>> values reported back are zero. >>>> >>>> The only success I have had thus far has been querying the values via an >>>> osg::Operation set with ViewerBase::setRealizeOperation() on my viewer >>>> (osg::Viewer). The values returned appear to be correct. This allows me >> to >>>> get the correct values *once* at the start of the program. >> Unfortunately I >>>> need to query them periodically, and I have been unable to do this. >>>> >>>> So far, I have tried hooking the calls into: >>>> - An osg::Camera::DrawHandler, set via >>>> osg::Camera::setInitialDrawCallback(). >>>> - An osg::Node::NodeHandler, hooked into the root node via >>>> osg::Node::setUpdateCallback. >>>> - An osg::Drawable::DrawCallback,
Re: [osg-users] OSG and NVX_gpu_memory_info
Hi Robert, Thanks for having a look at things and for the suggestion. On 30/09/15 17:35, Robert Osfield wrote:> HI Garth, > I'd use a RealizerOperation. Have a look at the osgvolume example to an > example of using a RealizerOperation to get information from the graphics > context. I was unfortunately unable to solve the problem. Here is what I tried: I checked the osgvolume.cpp source for 3.2.1 and 3.4.0, but did not find a RealizerOperation in either. I did notice that osgvolume does also use viewer.setRealizeOperation() for TestSupportOperation, defined earlier. Is this what you are referring to? Assuming yes: This is the way I was able to successfully query the information once only at the start of the program. Unfortunately I need to query the information periodically, ie. over the course of the program, rather than just at initialisation. Unless I am mistaken, the target of setRealizeOperation is only called the one time, on viewer realization. Is this right? If so: Is there a corresponding call that I can use to attach an osg::Operation or similar to in order to make the required calls periodically? If not: Is there a way to indicate that the operation should be repeatedly called? Or is there another part of osgvolume.cpp that I should be looking at? The only glGet* call in the file is in TestSupportOperation, which is set using setRealizeOperation(), so I think I am looking in the right place? I'll continue to experiment. Thanks again for the suggestion. Is there anything else I should try? Cheers, Garth > > Robert. > > On 30 September 2015 at 03:49, Garth D <garthy_...@entropicsoftware.com> > wrote: > >> Hi all, >> >> I was wondering if anyone has been successful in using the >> NVX_gpu_memory_info extension with OpenSceneGraph, and the best place to >> call glGetIntegerv to get the associated values. >> >> Details on the extension here: >> https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt >> >> I'm using Linux, OSG 3.2.1, and a card that supports the >> NVX_gpu_memory_info extension. >> >> I have tried querying the current and total memory using >> GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX and >> GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, and in each case but one, the >> values reported back are zero. >> >> The only success I have had thus far has been querying the values via an >> osg::Operation set with ViewerBase::setRealizeOperation() on my viewer >> (osg::Viewer). The values returned appear to be correct. This allows me to >> get the correct values *once* at the start of the program. Unfortunately I >> need to query them periodically, and I have been unable to do this. >> >> So far, I have tried hooking the calls into: >> - An osg::Camera::DrawHandler, set via >> osg::Camera::setInitialDrawCallback(). >> - An osg::Node::NodeHandler, hooked into the root node via >> osg::Node::setUpdateCallback. >> - An osg::Drawable::DrawCallback, hooked into a dummy chain off the root >> of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via >> osg::Drawable::setDrawCallback. >> - An osg::Drawable::CullCallback , hooked into a dummy chain off the root >> of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via >> osg::Drawable::setCullCallback. >> - An osg::Camera::DrawHandler, set via >> osg::Camera::setFinalDrawCallback(). Only partly-tested due to a >> race-condition that occurs in my code, but appears to fail. >> >> I have experimented with osg::GraphicsContext::makeCurrent() with each. >> >> Can anyone suggest a better place to hook these calls into? Or >> alternatively confirm that they have the extension working with one of the >> above, so I can change or experiment with my existing setup to try to make >> it work? >> >> Cheers, >> Garth >> ___ >> 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 and NVX_gpu_memory_info
Hi all, On 01/10/15 10:12, Garth D wrote: If I had to guess, I am doing something in my project at some point after the setRealizeOperation operation is called that causes it to fail by the time it gets around to the first call to the callback set by setInitialDrawCallback() in the Camera. ... and solved. There was an unfortunate interaction between the threading system in my project and the one used in OSG. The particular interaction is something I have not seen before, and did not think was possible. The bug will be somewhere in my project code. As a test, I put a Camera::DrawCallback in a small piece of code fully isolated from the threading in the rest of my project doing nothing but dumping the reported values. I then attached it with setInitialDrawCallback() in a similar, isolated piece of code. It worked perfectly. Thanks again Robert for pointing me in the right direction. Being able to concentrate on just two established working approaches made finding the actual bug feasible. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG and NVX_gpu_memory_info
Hi Robert, On 30/09/15 19:50, Robert Osfield wrote:> If you want to check periodically then just use a Camera::DrawCallback > attached to the main camera attached to the GraphicsContext/Window of > interest. This will be called every frame, but within this callback you > could have your own check to see if the GL calls are required for that > frame. I've put together a test application that tries out a bunch of simple configurations based on the exact setup you describe. The calls worked correctly and consistently with either an Operation (or GraphicsOperation) attached with setRealizeOperation(), or a Camera::DrawCallback attached with setInitialDrawCallback(), or both. If I had to guess, I am doing something in my project at some point after the setRealizeOperation operation is called that causes it to fail by the time it gets around to the first call to the callback set by setInitialDrawCallback() in the Camera. Many thanks for pointing me in the right direction. Both techniques you mention work perfectly in the simple test application. The actual issue must be something I am doing differently between the minimal example and the full project. I'll have to experiment with the two to figure out what the difference is. Cheers, Garth > On 30 September 2015 at 10:56, Garth D <garthy_...@entropicsoftware.com> wrote: Hi Robert, Thanks for having a look at things and for the suggestion. On 30/09/15 17:35, Robert Osfield wrote:> HI Garth, I'd use a RealizerOperation. Have a look at the osgvolume example to an example of using a RealizerOperation to get information from the graphics context. I was unfortunately unable to solve the problem. Here is what I tried: I checked the osgvolume.cpp source for 3.2.1 and 3.4.0, but did not find a RealizerOperation in either. I did notice that osgvolume does also use viewer.setRealizeOperation() for TestSupportOperation, defined earlier. Is this what you are referring to? Assuming yes: This is the way I was able to successfully query the information once only at the start of the program. Unfortunately I need to query the information periodically, ie. over the course of the program, rather than just at initialisation. Unless I am mistaken, the target of setRealizeOperation is only called the one time, on viewer realization. Is this right? If so: Is there a corresponding call that I can use to attach an osg::Operation or similar to in order to make the required calls periodically? If not: Is there a way to indicate that the operation should be repeatedly called? Or is there another part of osgvolume.cpp that I should be looking at? The only glGet* call in the file is in TestSupportOperation, which is set using setRealizeOperation(), so I think I am looking in the right place? I'll continue to experiment. Thanks again for the suggestion. Is there anything else I should try? Cheers, Garth Robert. On 30 September 2015 at 03:49, Garth D <garthy_...@entropicsoftware.com> wrote: Hi all, I was wondering if anyone has been successful in using the NVX_gpu_memory_info extension with OpenSceneGraph, and the best place to call glGetIntegerv to get the associated values. Details on the extension here: https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt I'm using Linux, OSG 3.2.1, and a card that supports the NVX_gpu_memory_info extension. I have tried querying the current and total memory using GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX and GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, and in each case but one, the values reported back are zero. The only success I have had thus far has been querying the values via an osg::Operation set with ViewerBase::setRealizeOperation() on my viewer (osg::Viewer). The values returned appear to be correct. This allows me to get the correct values *once* at the start of the program. Unfortunately I need to query them periodically, and I have been unable to do this. So far, I have tried hooking the calls into: - An osg::Camera::DrawHandler, set via osg::Camera::setInitialDrawCallback(). - An osg::Node::NodeHandler, hooked into the root node via osg::Node::setUpdateCallback. - An osg::Drawable::DrawCallback, hooked into a dummy chain off the root of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via osg::Drawable::setDrawCallback. - An osg::Drawable::CullCallback , hooked into a dummy chain off the root of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via osg::Drawable::setCullCallback. - An osg::Camera::DrawHandler, set via osg::Camera::setFinalDrawCallback(). Only partly-tested due to a race-condition that occurs in my code, but appears to fail. I have experimented with osg::GraphicsContext::makeCurrent() with each. Can anyone suggest a better place to hook these calls into? Or alternatively confirm that they have the extension working with one of the above, so I can change or experiment with my existing s
Re: [osg-users] Modern GLSL and OSG
Hi Jan, On 28/09/15 17:36, Jan Ciger wrote: On Sun, Sep 27, 2015 at 9:28 PM, Garth D <garthy_...@entropicsoftware.com> wrote: As a side note, I have to say that I am really liking the ability to hang Uniforms off arbitrary parts of the scene graph- generally on Geometry or Groups depending on the scope that I need the Uniform to cover. It's really a very nice design. Uniforms are parts of the OpenGL state, same as e.g. bound textures, shaders or lighting settings. If I grossly simplify things, the "only" thing that OSG does is to manage this state for you - adds and removes bits from the state depending on which part of the scene graph is being drawn, all the while to make sure to minimize the amount of these state changes (changing state of the driver is relative expensive operation). It is one of the basic purposes of a scene graph. In the project I am working on the geometry is laid out in such a way that there are different levels of Groups under which certain Uniforms always hold the same value. It works really nicely with such a system. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG and NVX_gpu_memory_info
Hi all, I was wondering if anyone has been successful in using the NVX_gpu_memory_info extension with OpenSceneGraph, and the best place to call glGetIntegerv to get the associated values. Details on the extension here: https://www.opengl.org/registry/specs/NVX/gpu_memory_info.txt I'm using Linux, OSG 3.2.1, and a card that supports the NVX_gpu_memory_info extension. I have tried querying the current and total memory using GPU_MEMORY_INFO_TOTAL_AVAILABLE_MEMORY_NVX and GPU_MEMORY_INFO_CURRENT_AVAILABLE_VIDMEM_NVX, and in each case but one, the values reported back are zero. The only success I have had thus far has been querying the values via an osg::Operation set with ViewerBase::setRealizeOperation() on my viewer (osg::Viewer). The values returned appear to be correct. This allows me to get the correct values *once* at the start of the program. Unfortunately I need to query them periodically, and I have been unable to do this. So far, I have tried hooking the calls into: - An osg::Camera::DrawHandler, set via osg::Camera::setInitialDrawCallback(). - An osg::Node::NodeHandler, hooked into the root node via osg::Node::setUpdateCallback. - An osg::Drawable::DrawCallback, hooked into a dummy chain off the root of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via osg::Drawable::setDrawCallback. - An osg::Drawable::CullCallback , hooked into a dummy chain off the root of: osg::Node -> osg::Geode -> osg::Geometry (osg::Drawable), via osg::Drawable::setCullCallback. - An osg::Camera::DrawHandler, set via osg::Camera::setFinalDrawCallback(). Only partly-tested due to a race-condition that occurs in my code, but appears to fail. I have experimented with osg::GraphicsContext::makeCurrent() with each. Can anyone suggest a better place to hook these calls into? Or alternatively confirm that they have the extension working with one of the above, so I can change or experiment with my existing setup to try to make it work? Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modern GLSL and OSG
Hi Jan, Thanks again for sharing your thoughts on the subject. :) On 26/09/15 19:46, Jan Ciger wrote:> On Sat, Sep 26, 2015 at 5:02 AM, Garth D > <garthy_...@entropicsoftware.com> wrote: >> >> My original motivation was to move to using "modern" OpenGL (ie. avoiding >> anything deprecated) because I didn't want to be in the situation where I >> started relying on something that was likely to be removed in the future. > > Well, I don't think you need to worry about that too much. Yeah, I'm pretty-much past this one now. :) > Yes, the > "old school" OpenGL is marked as deprecated and removed from the Core > profiles (and OpenGL ES 2.0 doesn't support it at all). However, at > least Nvidia (AMD/Ati probably as well) has declared that they are > going to support the legacy profiles for indefinite future. > > The reason is that the code is already in the driver and costs them > essentially nothing (the old APIs don't change) and also the ton of > old code that uses it. That's also why the OpenGL 3 was felt to be > such a letdown and not a radical departure in a new direction - there > are simply too many CAD and visualization companies with decades old > codebases that would stop working overnight with a new driver and > there is no business willpower to rewrite that because it works well > enough. Moreover, I am pretty sure that even today you will find major > CAD systems doing atrocities such as using direct mode (glBegin/glEnd) > somewhere in their code ... That certainly makes sense. I had wondered at the time how successful the deprecation would be. I could see it being successful if a popular compatibility layer library emerged and gained widespread use, but I don't think this really happened. This seems to mean that the bulk of the compatibility support is instead retained at the driver level, which is as you note. >> Additionally, I have a need that I know is not going to be handled very well >> in the fixed-function pipeline. From experience I know that whilst the FFP >> is neat for simpler tasks, it feels like a massive burden as the needs get >> more complex. >> >> A last goal was as a learning exercise. The aim was to rely on shader >> functionality a bit more strictly than minimally necessary, as a means of >> taking care of the glaring (and increasingly hard-to-explain professionally) >> hole in my 3D knowledge. > > By all means, that is a good reason. Also if you decide to develop on > mobile, you won't have much choice there. Yes, this is much clearer to me know. As a side note, I have to say that I am really liking the ability to hang Uniforms off arbitrary parts of the scene graph- generally on Geometry or Groups depending on the scope that I need the Uniform to cover. It's really a very nice design. Thanks again! Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modern GLSL and OSG
Hi Jan, Many thanks for the additional information. :) On 25/09/15 17:48, Jan Ciger wrote: On Fri, Sep 25, 2015 at 2:01 AM, Garth D <garthy_...@entropicsoftware.com> wrote: Thankyou for the suggestion. :) I have to admit being unsure how to set the specific context at present. From what I've read, there'd need to be a glXCreateContextAttribsARB call somewhere to create the GL3 context under Linux- and there doesn't seem to be one. Skimming the source (I'm presently using OSG 3.2.1, but had a peek at 3.4.0) suggests that perhaps this support is only available on a Windows build. On the cmake side, OSG_GL3_AVAILABLE in my build is off. However, glVersion=4.4 appears in my log during a build. The cmake variables are meant to be set by the developer, see the instructions here: http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/72253 It is possible that GL3 support is still available on Windows only, but even if that is the case, it shouldn't be terribly difficult to make it work in Linux too. The drivers and OpenGL implementations certainly support it now. Thanks. I thought this might be the case. I'm beginning to suspect that aiming for strict OpenGL 3+ or 4+ might not be the best thing for me to concentrate at the moment. I might be better off just using it where it helps and leaving a jump to "pure" modern GL until a later date. Well, it depends on what you want to do. Moving to the "modern" OpenGL without the fixed pipeline functionality is a big jump, because basically you don't have anything pre-defined by the library anymore. No matrix stack (glPush/glPop), everything needs to be managed using shaders, etc. The older functionality is easier to make display something on the screen quickly, because there are fewer things to set up. The newer stuff gives you much more flexibility, though. Excellent, many thanks for the explanation and clarification. My original motivation was to move to using "modern" OpenGL (ie. avoiding anything deprecated) because I didn't want to be in the situation where I started relying on something that was likely to be removed in the future. Additionally, I have a need that I know is not going to be handled very well in the fixed-function pipeline. From experience I know that whilst the FFP is neat for simpler tasks, it feels like a massive burden as the needs get more complex. A last goal was as a learning exercise. The aim was to rely on shader functionality a bit more strictly than minimally necessary, as a means of taking care of the glaring (and increasingly hard-to-explain professionally) hole in my 3D knowledge. As I've been digging around the first goal seems less and less important, so my goals have been shifting somewhat. Going pure non-FFP is something I can handle down the track. > Using OSG > helps to hide this complexity, because OSG abstracts and manages many > of these things for you, regardless of which OpenGL profile are you > using. Excellent. I couldn't tell if this was the case, or if OpenGL 3+ was an experimental thing in OSG, or how complete the OSG support for it was. At this point I've made it over the initial hurdle of setting things up properly in OSG and getting the basics running, so I'm on to the meat of the task at this point- messing about with the shaders themselves. Thanks for taking the time to write that up, it has clarified things considerably. Much appreciated. :) Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modern GLSL and OSG
Hi Jan, On 25/09/15 05:18, Jan Ciger wrote:> -BEGIN PGP SIGNED MESSAGE- > On 24/09/15 00:19, Garth D wrote: >> Many thanks for the interesting suggestion. :) >> >> My main development environment is Linux-based, with a secondary >> virtualised Windows development environment. Due to the >> visualization (VirtualBox) I don't believe I can do much in the way >> of development with ANGLE due to its DX backend, at least with my >> current setup. > > Um, wouldn't it be far easier to simply ask OSG to create an OpenGL > 3.x/4.x core context instead? Then you don't have the legacy stuff > available and don't need to bother with hacks like Angle. Thankyou for the suggestion. :) I have to admit being unsure how to set the specific context at present. From what I've read, there'd need to be a glXCreateContextAttribsARB call somewhere to create the GL3 context under Linux- and there doesn't seem to be one. Skimming the source (I'm presently using OSG 3.2.1, but had a peek at 3.4.0) suggests that perhaps this support is only available on a Windows build. On the cmake side, OSG_GL3_AVAILABLE in my build is off. However, glVersion=4.4 appears in my log during a build. However, I am probably fine even if I am not grasping things entirely at this point. It is something I can experiment with later on, probably on my existing Windows build environment. Whether I experiment with ANGLE from there or not is something I can weigh up from that point. Thanks for the additional input. I also just noticed that my prior email used "visualization" rather than "virtualisation". Whoops. ;} I think I need to place a little less faith in spellcheck suggestions. I'm beginning to suspect that aiming for strict OpenGL 3+ or 4+ might not be the best thing for me to concentrate at the moment. I might be better off just using it where it helps and leaving a jump to "pure" modern GL until a later date. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Modern GLSL and OSG
Hi all, I was wondering if anyone can make some suggestions as to resources that are useful for learning GLSL in modern OpenGL (say, 3.0+) with a specific focus on use with OSG. My existing GLSL knowledge is weak compared to my general 3D knowledge, and mostly dates back to the early days of shaders. A lot of what I have personally done with OpenGL and OSG has involved the fixed-function pipeline, or things that map to it fairly closely. Thus far I've been digging around online for GLSL resources, but tend to frequently find myself doing it the wrong way as I'm using features that have since become deprecated. On the OSG side I tend to dig around in the OSG examples and search the source to try to find the OSG equivalents to OpenGL calls I see mentioned in the GLSL resources. I then put these together and if I'm lucky something useful comes out. :) I think I'll figure things out eventually if I continue to crash around blindly as I have been, but if anyone can suggest some better starting points for GLSL use in OSG specifically, it would be much appreciated. :) Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Modern GLSL and OSG
Hi Christian, Many thanks for the interesting suggestion. :) My main development environment is Linux-based, with a secondary virtualised Windows development environment. Due to the visualization (VirtualBox) I don't believe I can do much in the way of development with ANGLE due to its DX backend, at least with my current setup. Having said that, being able to limit a future port to the OpenGL ES 2.0 API subset could be very useful indeed. It is likely that I would be looking at the feasibility of moving the project I am working on to mobile devices in the future, and this sounds like something that could be very useful to use while I am doing so. Cheers, Garth On 23/09/15 22:19, Christian Buchner wrote:> If you're using Windows you could try building OSG against ANGLE > and limit yourself to the OpenGL ES 2.0 API feature set. Here you can't > accidentially fall back into using deprecated (fixed function) features > because these have been stripped from the API. > > There would also be plenty of books about OpenGL ES 2.0 available - and you > can immediately target mobile platforms (iOS, Android) > > Christian > > > 2015-09-23 14:44 GMT+02:00 Garth D <garthy_...@entropicsoftware.com>: > >> >> Hi all, >> >> I was wondering if anyone can make some suggestions as to resources that >> are useful for learning GLSL in modern OpenGL (say, 3.0+) with a specific >> focus on use with OSG. >> >> My existing GLSL knowledge is weak compared to my general 3D knowledge, >> and mostly dates back to the early days of shaders. A lot of what I have >> personally done with OpenGL and OSG has involved the fixed-function >> pipeline, or things that map to it fairly closely. >> >> Thus far I've been digging around online for GLSL resources, but tend to >> frequently find myself doing it the wrong way as I'm using features that >> have since become deprecated. On the OSG side I tend to dig around in the >> OSG examples and search the source to try to find the OSG equivalents to >> OpenGL calls I see mentioned in the GLSL resources. I then put these >> together and if I'm lucky something useful comes out. :) >> >> I think I'll figure things out eventually if I continue to crash around >> blindly as I have been, but if anyone can suggest some better starting >> points for GLSL use in OSG specifically, it would be much appreciated. :) >> >> Cheers, >> Garth >> ___ >> 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] Modern GLSL and OSG
Replying to myself with what I have managed to figure out so far to provide some information in case it comes up in a search. I can't vouch for the accuracy as this is still new to me. Anyway: - Compile messages end up being sent through the osg::NotifyHandler mechanism. - Shaders don't appear to be compiled immediately, but if you use them (by attaching an osg::Program to a osg::StateSet with setAttributeAndModes()), they end up being compiled and used at a later point. - osg::StateSet::addUniform() with a osg::Uniform argument seems to be the way to specify uniforms. - osg::Program::addBindAttribLocation() is a means of binding variables to a specific attribute index (output location), which you need for other calls. I believe location layout qualifiers in the shaders themselves can be used as well. - osg::Program::getAttribBindingList() seems to only return the variables set with addBindAttribLocation(), and not ones specified in the shader itself. This might be a timing issue, perhaps the results change after the shaders are actually compiled and linked? - osg::State::setUseModelViewAndProjectUniforms(true) can be used to automatically hook up variables such as "osg_ModelViewProjectionMatrix", which seems to be an OSG analogue to "gl_ModelViewProjectionMatrix". This seems to be a useful bridge while trying to figure things out. - The compile messages can be used to confirm the actual attribute indexes used. - Variables that aren't used may be optimised out, which makes them unavailable. - Using Geometry::setVertexAttribArray with the last argument set correctly (eg. BIND_PER_VERTEX) seems to be the way that you can pass texture coordinates to shaders. I'm guessing other information such as vertices and normals are handled similarly. Hopefully this helps someone in a similar situation to the one I was in. On 23/09/15 22:14, Garth D wrote: Hi all, I was wondering if anyone can make some suggestions as to resources that are useful for learning GLSL in modern OpenGL (say, 3.0+) with a specific focus on use with OSG. My existing GLSL knowledge is weak compared to my general 3D knowledge, and mostly dates back to the early days of shaders. A lot of what I have personally done with OpenGL and OSG has involved the fixed-function pipeline, or things that map to it fairly closely. Thus far I've been digging around online for GLSL resources, but tend to frequently find myself doing it the wrong way as I'm using features that have since become deprecated. On the OSG side I tend to dig around in the OSG examples and search the source to try to find the OSG equivalents to OpenGL calls I see mentioned in the GLSL resources. I then put these together and if I'm lucky something useful comes out. :) I think I'll figure things out eventually if I continue to crash around blindly as I have been, but if anyone can suggest some better starting points for GLSL use in OSG specifically, it would be much appreciated. :) Cheers, Garth ___ 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] OpenSceneGraph 3.2.1 release candidate 6 tagged
Hi Robert, Re OSG 3.2.1-rc6. Builds and installs fine on a Debian Linux 7 system, updates as of less than a few days ago. gcc 4.7.2. nVidia, multi-head Xinerama, 2x2head cards. cmake line was: cmake -D CMAKE_INSTALL_PREFIX=/opt/OpenSceneGraph-3.2.1-rc6 -D CMAKE_BUILD_TYPE=Release -D BUILD_OSG_EXAMPLES=yes .. Fired up a few random examples, no extensive testing. Also builds on a Debian 6.0.6 system, minimal but mixed updates. nVidia, multi-head Xinerama, 2x2head cards. Custom build script/environment with patches from current build env (3.2.1-rc1), which applied cleanly. gcc 4.4.5. Fired up a few random examples, no extensive testing. FBX plugin included (20141?). Was not in a position to run it through my full build env or integrate it into my app at this time. Also have a Windows XP, 32-bit virtual machine, with MSVC++ 2008 express set up, on which I've already got 3.2.1-rc6 running, but it takes a huge amount of time for a full build so it'd be an overnight thing. I can try this out if it is useful, ping me if wanted. Mostly just a simple build and install test on the two machines this time, but I hope it is still useful as a data point. All the best with the release! Cheers, Garth On 04/07/14 00:04, Robert Osfield wrote: Hi All, I made some minor warning fixes and bug fixes to support read/write of image to .osgb format, these are now wrapped up in a 3.2.1 release candidate 6: * Zip file containing source code : OpenSceneGraph-3.2.1-rc6.zip http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-3.2.1-rc6.zip * Subversion tag for 3.2.1-rc6 : svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.2. http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.2.1-rc61-rc6 OpenSceneGraph My plan is to tag the final 3.2.1 stable release tomorrow, so would appreciate testing on the platforms you have available and against your applications. Thanks in advance, Robert. -- ChangeLog since rc5: 2014-07-03 14:13 robert * NEWS.txt: Updated NEWS in prep for 3.2.1 release 2014-07-03 13:06 robert * src/osgPlugins/osc/OscSendingDevice.cpp, src/osgPresentation/PropertyManager.cpp: Added vertical destructors 2014-07-02 14:14 robert * src/osgPlugins/osg/ReaderWriterOSG2.cpp: Merged fix from svn/trunk to handlng of file type of nested files within a .osgx, .osgt and .osgb file. 2014-07-01 07:31 robert * applications/osgviewer/osgviewer.cpp: Added #include stdint.h to address compile issue on some Linux distro's. 2014-06-30 15:31 robert * examples/osgvolume/osgvolume.cpp: Add dds no flip on write option to prevent output of .dds volume from being flipped by the dds plugin. ___ 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] OpenSceneGraph 3.2.1 release candidate 6 tagged
Hi Robert, No problem at all, HTH. Cheers, Garth On 04/07/14 23:46, Robert Osfield wrote: Thanks for the testing and feedback Garth, much appreciated. No need to run the overnight build as I'll be tagging 3.2.1 this afternoon On 4 July 2014 15:05, Garth D garthy_...@entropicsoftware.com mailto:garthy_...@entropicsoftware.com wrote: Hi Robert, Re OSG 3.2.1-rc6. Builds and installs fine on a Debian Linux 7 system, updates as of less than a few days ago. gcc 4.7.2. nVidia, multi-head Xinerama, 2x2head cards. cmake line was: cmake -D CMAKE_INSTALL_PREFIX=/opt/__OpenSceneGraph-3.2.1-rc6 -D CMAKE_BUILD_TYPE=Release -D BUILD_OSG_EXAMPLES=yes .. Fired up a few random examples, no extensive testing. Also builds on a Debian 6.0.6 system, minimal but mixed updates. nVidia, multi-head Xinerama, 2x2head cards. Custom build script/environment with patches from current build env (3.2.1-rc1), which applied cleanly. gcc 4.4.5. Fired up a few random examples, no extensive testing. FBX plugin included (20141?). Was not in a position to run it through my full build env or integrate it into my app at this time. Also have a Windows XP, 32-bit virtual machine, with MSVC++ 2008 express set up, on which I've already got 3.2.1-rc6 running, but it takes a huge amount of time for a full build so it'd be an overnight thing. I can try this out if it is useful, ping me if wanted. Mostly just a simple build and install test on the two machines this time, but I hope it is still useful as a data point. All the best with the release! Cheers, Garth On 04/07/14 00:04, Robert Osfield wrote: Hi All, I made some minor warning fixes and bug fixes to support read/write of image to .osgb format, these are now wrapped up in a 3.2.1 release candidate 6: * Zip file containing source code : OpenSceneGraph-3.2.1-rc6.zip http://www.openscenegraph.__org/downloads/developer___releases/OpenSceneGraph-3.2.1-__rc6.zip http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-3.2.1-rc6.zip * Subversion tag for 3.2.1-rc6 : svn co http://svn.openscenegraph.org/__osg/OpenSceneGraph/tags/__OpenSceneGraph-3.2 http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.2. http://svn.openscenegraph.__org/osg/OpenSceneGraph/tags/__OpenSceneGraph-3.2.1-rc6 http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.2.1-rc61-rc6 OpenSceneGraph My plan is to tag the final 3.2.1 stable release tomorrow, so would appreciate testing on the platforms you have available and against your applications. Thanks in advance, Robert. -- ChangeLog since rc5: 2014-07-03 14:13 robert * NEWS.txt: Updated NEWS in prep for 3.2.1 release 2014-07-03 13:06 robert * src/osgPlugins/osc/__OscSendingDevice.cpp, src/osgPresentation/__PropertyManager.cpp: Added vertical destructors 2014-07-02 14:14 robert * src/osgPlugins/osg/__ReaderWriterOSG2.cpp: Merged fix from svn/trunk to handlng of file type of nested files within a .osgx, .osgt and .osgb file. 2014-07-01 07:31 robert * applications/osgviewer/__osgviewer.cpp: Added #include stdint.h to address compile issue on some Linux distro's. 2014-06-30 15:31 robert * examples/osgvolume/osgvolume.__cpp: Add dds no flip on write option to prevent output of .dds volume from being flipped by the dds plugin. _ osg-users mailing list osg-users@lists.__openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ osg-users mailing list osg-users@lists.__openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__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] Migration from 3.0.1 to 3.2.0 (CEGUI)
Hi all, I've just managed to solve the second main problem I had been encountering, and I wanted to share the solution in case it helps someone else out of the same fix. A bit of experimentation showed that with the updated camera code, the only overlay that was still vanishing when shadows were used was my CEGUI Drawable (CEGUI 0.7.5). The other overlays were actually fine. In the Drawable that I am using, during drawImplementation, the state is set up to lead into CEGUI's renderGUI call roughly as follows (please excuse transcription errors): osg::State *state = renderInfo.getState(); state-disableAllVertexArrays(); state-disableTexCoordPointer(0); glPushMatrix(); glPushAttrib(); ... CEGUI::System::getSingleton().renderGUI(); If I was using a ShadowedScene with any ShadowTechnique at all, the GUI would vanish. Up until that point it would render fine. The fix ended up being to reset a bit more state (after the disableTexCoordPointer call: state-setActiveTextureUnit(0); state-setClientActiveTextureUnit(0); I'm actually quite surprised that this worked, but it did. I wonder if there is a better way to do this, but it seems sufficient in my case. Cheers, Garth On 02/11/13 13:24, Garth D wrote: Another problem: If I use shadows, specifically ShadowTexture, the HUD I use (implemented with a Camera set with POST_RENDER rendering order) vanishes entirely. If I disable shadows, it returns. It worked fine in 3.0.1 (ie. shadows did not impact the HUD). It also works fine right up until the point I add the first geometry with shadows. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.2.1-rc1 tagged, please test
Hi Robert, Are you still after input on 3.2.1-rc1? If so: Successful build of 3.2.1-rc1 on Debian 6 Linux, 64-bit with gcc 4.4.5. FBX plugin (20141) enabled and works. Used in my app both in the model setup workflow (using osgconv with FBX models), which imports and reorients many fixed and animated models. Ran in my app, some light manual testing, and successfully went through its automatic test suite. No changes needed to the app or tools since the 3.2.0 upgrade. Not pristine- some small patches added for my project, additional functionality, but they were made against the 3.2.0 codebase and applied cleanly without changes to 3.2.1-rc1. Driver is the nVidia 64-bit 325.15 binary driver on a pair of GT630 cards using Xinerama. I also did a pristine build (ie. no patches) just to see how it went. Build was successful. Included the FBX plugin as above. No testing as my app needs the aforementioned patches to run. Successful build also on Windows XP, 32-bit, using using MSVC++ 2008, virtual machine under VirtualBox. Same patches as above. Light testing in my app. Worked well. Also, the 3.2.1 RC1 link is broken on these pages: http://www.openscenegraph.org/index.php/download-section/stable-releases http://www.openscenegraph.org/index.php/download-section/stable-releases/149-openscenegraph-3-2-1-release-candidate-1 but anyone looking to download a release candidate will probably be able to figure out the correct links (OpenSceneGraph-3.2.1-rc1.zip rather than OpenSceneGraph-3.2.1.zip). All the best with the 3.2.1 release. Cheers, Garth On 04/10/13 02:06, Robert Osfield wrote: Hi All, We are now preparing for the OpenSceneGraph-3.2.1 stable release that will be made in mid October, the release in binary compatible with 3.2.0 and includes bug and build fixes. Prior to this release we are making a series of release candidates and call on members of the community to test out these release candidates on their platforms and against their applications to make sure that that any remaining problems can be addressed prior to the 3.2.1 release. Please reports success and failures to the osg-users mailing list/forum. Source Code: * Zip file containing source code : OpenSceneGraph-3.2.1-rc1.zip http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-3.2.1.zip * Subversion tag for 3.2.1-rc1 : svn co http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.2. http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-3.2.1-rc11-rc1 OpenSceneGraph Thanks, Robert. ___ 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] Migration from 3.0.1 to 3.2.0
Hi all, On 02/11/13 13:24, Garth D wrote: ... It is almost as if the model is being drawn in the reverse order with depth buffering disabled. ... Looks like I stumbled onto the solution for this one, and my guess on what was happening wasn't too far off. Creating an explicit StateSet under each problematic model with GL_DEPTH_TEST turned on fixed this- it really *was* rendering without depth testing. I do turn GL_DEPTH_TEST off for parts of my scene tree, but only in sibling nodes, never direct ancestors for the models (as far as I know). I had assumed this would not impact things- but perhaps this is not right. It appears I could get away with this in 3.0.1, but not 3.2.0. It would also explain why osgviewer etc handle it correctly, but my app did not. I'm guessing that carefully checking that StateSets are explicitly set to what I need them to be, as close to the Geodes in question as possible, is going to be the way to clear up many of the problems I am encountering. Suggestions on better ways to track down potential problems of this type definitely appreciated if anyone has any thoughts or suggestions to share. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Migration from 3.0.1 to 3.2.0
Hi Mike, Thankyou! :) This is exactly the sort of post I was hoping someone would make- a good solid hint based on a similar experience, and enough information to let me dig into it further. In my case a call of setGlobalDefaults on the StateSet of each camera I create cleared up a few other glitches I hadn't yet figured out, plus I found that I can now remove the extra explicit StateSet creation I spoke of in my previous post, and things still work as they should. Perhaps my original understanding wasn't too far off the mark- I had just missed the subtlety of the change between 3.0.1 and 3.2.0 in the default StateSets used for a new Camera. Whilst it hasn't changed the vanishing overlay issue I'm having with shadowing enabled, I'm still pretty chuffed that this single change has cleared up the main issue I was facing, plus a whole bunch of smaller ones that I hadn't really made a start on solving. Thanks for taking the time to share your experience and for making my evening. :) Cheers, Garth On 02/11/13 22:46, Mike Connell wrote: I suspect you may need a: camera-getOrCreateStateSet()-setGlobalDefaults(); There is some previous discussion on the list about it if you search for setGlobalDefaults and 3.2. I had a very similar problem when we upgraded to 3.2, and this fixed it for us. best wishes Mike On 2 November 2013 11:07, Garth D garthy_...@entropicsoftware.com mailto:garthy_...@entropicsoftware.com wrote: Hi all, On 02/11/13 13:24, Garth D wrote: ... It is almost as if the model is being drawn in the reverse order with depth buffering disabled. ... Looks like I stumbled onto the solution for this one, and my guess on what was happening wasn't too far off. Creating an explicit StateSet under each problematic model with GL_DEPTH_TEST turned on fixed this- it really *was* rendering without depth testing. I do turn GL_DEPTH_TEST off for parts of my scene tree, but only in sibling nodes, never direct ancestors for the models (as far as I know). I had assumed this would not impact things- but perhaps this is not right. It appears I could get away with this in 3.0.1, but not 3.2.0. It would also explain why osgviewer etc handle it correctly, but my app did not. I'm guessing that carefully checking that StateSets are explicitly set to what I need them to be, as close to the Geodes in question as possible, is going to be the way to clear up many of the problems I am encountering. Suggestions on better ways to track down potential problems of this type definitely appreciated if anyone has any thoughts or suggestions to share. Cheers, Garth _ osg-users mailing list osg-users@lists.__openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__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] Migration from 3.0.1 to 3.2.0
Hi Robert, Thanks for that. With Mike's message above I was able to dig into things in a bit more detail, and one of the posts I went through was a post of yours where you went into detail on the reasons behind the change (if I may summarise, in short, it is a former bug in OSG that was fixed, whose presence inadvertently hid bugs in code that used OSG, code such as mine). The fix you and Mike have mentioned cleared up the original problem without the need for the fix I found, plus solved some additional problems besides. It is superior to the solution I used and outlined in the post you've directly replied to- in fact, after trying out the suggestion in Mike's code I went and reversed my change, and established that with this better fix, my fix is no longer needed. Thankyou also for the extra description, it has helped solidify my understanding of how OSG handles things in this respect. I do appreciate you taking the time to help out with your thoughts here, even though it is clearly something that you have taken the time to go through on previous occasions with others. Had I had sufficient understanding to identify the problem at the outset, or with the benefit of hindsight, I would have liked to have spared you the need to do it yet again. I hope others reading are similarly helped as I have been. I will be leaving the day with more knowledge than I began the day with. And on that note, it's now 1am locally, so it seems a sensible point to bring my day to a close. :) Cheers, Garth On 03/11/13 00:19, Robert Osfield wrote: Hi Garth, I've discussed this with the release of OSG-3.2 a number of times. A fix in 3.2 that addressed a bug of the internal rendering classes overriding the Viewer's Camera state causes this problem in client code. The problem is the OSG now does exactly what you ask it to do w.r.t State, so if your Viewer's Camera is empty then it doesn't apply any State. Normally OSG applications just use the default Camera StateSet set up by the osg::View class which calls the Camera::getOrCreateStateSet()-setGlobalDefaults() for you. For applictions that just apply settings to the View(er)'s Camera directly won't see any problems because all the defaults are in place. However, if you application is creating it's own Camera and then applying this to the View the GlobalDefaults are not set up so you just end up getting OpenGL defaults. It sounds like in your case this is exactly what is happening. The solution is to either just reuse the View(er) Camera rather than creating your own, or do as View does for it's default constructed Camera - call setGlobalDefaults(), or just decide what state you want in your application. In effect the bug in 3.0.0 was actually hiding a bug in the set up of the Camera state in your application, if you fix this in your application as suggested above the code will actually work fine with both 3.0.x and 3.2.x. Robert. On 2 November 2013 10:07, Garth D garthy_...@entropicsoftware.com mailto:garthy_...@entropicsoftware.com wrote: Hi all, On 02/11/13 13:24, Garth D wrote: ... It is almost as if the model is being drawn in the reverse order with depth buffering disabled. ... Looks like I stumbled onto the solution for this one, and my guess on what was happening wasn't too far off. Creating an explicit StateSet under each problematic model with GL_DEPTH_TEST turned on fixed this- it really *was* rendering without depth testing. I do turn GL_DEPTH_TEST off for parts of my scene tree, but only in sibling nodes, never direct ancestors for the models (as far as I know). I had assumed this would not impact things- but perhaps this is not right. It appears I could get away with this in 3.0.1, but not 3.2.0. It would also explain why osgviewer etc handle it correctly, but my app did not. I'm guessing that carefully checking that StateSets are explicitly set to what I need them to be, as close to the Geodes in question as possible, is going to be the way to clear up many of the problems I am encountering. Suggestions on better ways to track down potential problems of this type definitely appreciated if anyone has any thoughts or suggestions to share. Cheers, Garth _ osg-users mailing list osg-users@lists.__openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__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
[osg-users] Migration from 3.0.1 to 3.2.0
Hi all, I am attempting to migrate an existing codebase that uses OSG 3.0.1 to use 3.2.0 (as a precursor to 3.2.1), and I've run into a number of problems. I could really use some starting points and suggestions to assist in tracking these down. I am running on Debian Linux 6 with 2xGT630 nVidia cards, more information available if needed. The codebase runs *mostly* fine on 3.0.1, but issues arise in 3.2.0. Is there any resource on migrating to OSG 3.2.0 available? If there was such a thing, it would potentially give me a list of things to check against. I'm thinking I am likely relying on some default or behaviour that just isn't true any more in 3.2.0. One problem: I have a number of animated models (without textures for now) that load and display fine in osgviewer and osganimationviewer. However, in the app itself, they behave strangely. It seems that within the same model, geometry that should be further away frequently appears in front of closer geometry. For example, consider a model with a human wearing a backpack, with the human facing the camera. In this case, the backpack is drawn, in what appears the right position, in front of the human, overlapping it. It is almost as if the model is being drawn in the reverse order with depth buffering disabled. Regarding the models: Most were originally FBX models, but I convert them with osgconv into osgb format before use. I used the same process in 3.0.1 (with a 3.0.1 osgconv), and they seemingly worked fine with 3.0.1. It also appears that sometimes- but not always- that closer geometry in different models appears behind geometry that is further away. Another problem: If I use shadows, specifically ShadowTexture, the HUD I use (implemented with a Camera set with POST_RENDER rendering order) vanishes entirely. If I disable shadows, it returns. It worked fine in 3.0.1 (ie. shadows did not impact the HUD). It also works fine right up until the point I add the first geometry with shadows. Lastly, even with 3.0.1 I could never wrap my head fully around RenderBins, and the significance of their names and numbering. Is there any guide, anywhere, which is both accurate and up-to-date for 3.2.0 on RenderBins, and how they interact with render order and rendering hints? Is there a means to diagnosing which bins are in use and which geometry ends up in each? Any suggestions and starting points appreciated. My progress is very slow and my attempts to solve it haphazard. I could really use some outside input. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Pre-rotating a model
Hi Chris, There's also osgconv if you're happy to reorient and/or convert models before loading. http://trac.openscenegraph.org/projects/osg//wiki/Support/UserGuides/osgconv Cheers, Garth On 04/10/13 02:21, Chris Stankevitz wrote: On Thu, Oct 3, 2013 at 9:22 AM, Glenn Waldrongwald...@gmail.com wrote: https://github.com/openscenegraph/osg/blob/master/src/osgPlugins/rot/ReaderWriterROT.cpp Glenn, That is so cool, thank you. Also, I'm embarrassed to say I had no idea I could solve this problem by wrapping the model inside a MatrixTransform. Chris ___ 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] VBO fallback behavior and virtual machines
Hi Judson, You're welcome. Happy to help. Cheers, Garth On 22/03/13 00:26, Judson Weissert wrote: Garth, Thank you for the information. Knowing that you got it to work in an embedded (non-fullscreen) window w/ 3D acceleration enabled is helpful. I should have posted my environment information in my previous posts: - VirtualBox 4.2.10 - OSG 3.1.2 (dev release) - ATI RadeonHD 5700 series with atiumdag 9.2.0.0 (Catalyst 12.10) driver - Host Windows 7 64-bit - Guest Windows 7 Ultimate N 64-bit Thanks, Judson On 3/20/2013 10:36 PM, Garth D wrote: Hi Judson, On 20/03/13 09:57, Judson Weissert wrote: Has anyone had success viewing their models using VirtualBox? I can confirm textured static and animated models work fine in my app under VirtualBox. I use it as a test environment in my development setup semi-regularly. - Host: Debian Linux 6.0.6 - Guest: Windows XP - OpenSceneGraph 3.0.1 (with some small custom patches) - VirtualBox 4.2.4 r81684 with 3D acceleration enabled - Host hardware is nVidia-based. If more detail on the above would help, just let me know. I run my app windowed, in a small window. Never tried it fullscreen. It's not fast. My demands on it aren't too high. Be careful of shadows though- I've had issues. Sorry that I can't be more specific, but consider disabling shadows as a test if you're having problems. Personally, I don't bother with the non-3D-accelerated setup with VirtualBox any more, because almost everything 3D-related breaks or is unusably slow. If you're developing, you control the hardware. For users, I'd imagine the cases where someone expects to run VirtualBox as a user *and* wants to disable 3D acceleration for a 3D app are very rare. For this reason, I just stick with the enabled setup. Since the 3D acceleration mode works as a pass-through to the host of sorts, having well-behaved 3D hardware on the host is essential. I've mostly stuck with nVidia cards for this purpose. I don't know about ATI, but they'd probably be fine. It's been a while since I've used VMware for this purpose, but I *think* OSG was one of the few engines that could cope with it. I haven't used VMware for a few years now though. I hope this helps. Cheers, Garth ___ 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] VBO fallback behavior and virtual machines
Hi Judson,
On 20/03/13 09:57, Judson Weissert wrote:
Has anyone had success viewing their models using VirtualBox?
I can confirm textured static and animated models work fine in my app
under VirtualBox. I use it as a test environment in my development setup
semi-regularly.
- Host: Debian Linux 6.0.6
- Guest: Windows XP
- OpenSceneGraph 3.0.1 (with some small custom patches)
- VirtualBox 4.2.4 r81684 with 3D acceleration enabled
- Host hardware is nVidia-based.
If more detail on the above would help, just let me know.
I run my app windowed, in a small window. Never tried it fullscreen.
It's not fast. My demands on it aren't too high.
Be careful of shadows though- I've had issues. Sorry that I can't be
more specific, but consider disabling shadows as a test if you're having
problems.
Personally, I don't bother with the non-3D-accelerated setup with
VirtualBox any more, because almost everything 3D-related breaks or is
unusably slow. If you're developing, you control the hardware. For
users, I'd imagine the cases where someone expects to run VirtualBox as
a user *and* wants to disable 3D acceleration for a 3D app are very
rare. For this reason, I just stick with the enabled setup.
Since the 3D acceleration mode works as a pass-through to the host of
sorts, having well-behaved 3D hardware on the host is essential. I've
mostly stuck with nVidia cards for this purpose. I don't know about ATI,
but they'd probably be fine.
It's been a while since I've used VMware for this purpose, but I *think*
OSG was one of the few engines that could cope with it. I haven't used
VMware for a few years now though.
I hope this helps.
Cheers,
Garth
On 20/03/13 09:57, Judson Weissert wrote:
Hello,
I have been testing in VirtualBox recently, and encountered two problems
that I was hoping someone might recognize. Note: The problems do not
occur outside of a virtual environment.
1. I have geometry in my model where I call
osg::Geometry::setUseVertexBufferObjects(true), but the virtual
environment only supports OpenGL 1.1. An access violation occurs shortly
after calling glDrawElements() from DrawElementsUInt::draw().
The last portion of the call stack is as follows (access violation in
memcpy() trying to access 0x4fbc):
msvcrt.dll!memcpy() + 0x31 bytes
opengl32.dll!__gllc_ReducedElementsHandler() + 0x285 bytes
opengl32.dll!ReduceDrawElements() + 0x1cb bytes
opengl32.dll!__gllc_DrawElements() + 0x121 bytes
osg92-osg.dll!osg::DrawElementsUInt::draw(osg::State state={...}, bool
useVertexBufferObjects=false)
osg92-osg.dll!osg::Geometry::drawImplementation(osg::RenderInfo
renderInfo={...})
Taking out the call to setUseVertexBufferObjects() seems to fix the
problem. Do I have to detect the OpenGL version explicitly, or is the
OSG library supposed to fallback to a non-VBO mode of operation
automatically?
Also, prior to the crash, I get various Error: glBufferData not
supported by OpenGL driver notifications. Also a glGenBuffers() and
glBindBuffer() error notification, and a Windows error #127 that
mentions wglChoosePixelFormatARB ext not found.
2. If I enable 3D acceleration in VirtualBox, there is no crash, but the
scene ends up opening as a separate window and takes up the entire
screen. I am not sure how much this issue relates to OSG though.
Spy++ shows a window class of OSG Graphics Window for Win32 [{with
cursor}], that is not visible in Spy if the window opens as a child
window with a non-null parent as expected.
Has anyone had success viewing their models using VirtualBox? or VMWare?
Thanks,
Judson
___
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] Why no games with OSG?
Hi Michael, I don't believe you'll find too many games, but you'll find a respectable number of completed simulations and other projects, along with a good number of people working professionally with it. Coming from an OGRE background you'll probably appreciate the number of included examples, the speed in which you can get started, and the presence of the osgconv tool, which doesn't really have an OGRE equivalent. Of course, the best way to determine suitability for your own project is to experiment with it. There are plenty of included examples that will guide you in this; I went through a similar process myself. Cheers, Garth On 24/04/12 17:58, michael kapelko wrote: Hi. I'm new to OSG. I use OGRE for my game currently, but due to various issues I would like to switch to OSG. I coudn't find any info on games made with OSG, no pictures in OSG Forum - Album - Games, no Google results, only some simulations and other non-game stuff. The only game I found is FlightGear. I wonder why are there no games on OSG? Or am I missing something? Thanks. ___ 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 and node masks
Hi all, A quick update on this: I had speculated that attaching things to a separate tree that was not attached to a osgShadow::ShadowedScene would avoid the problem, and I can confirm now that this is the case. I am now effectively keeping two copies of the scene tree now: one that contains things that should cast or receive shadows; and one that contains things that should do neither. I don't expect much of a performance hit, and haven't seen one. It sounds messy, but in practice it isn't too bad. I have actors that manage their own nodes/drawables, and these are the only entities that need the shadow-less text, so I just create two sets of transforms and maintain two trees for each actor, rather than one. This solves the problem as such. One school of thought is that the solution that quickly solves the problem at hand is the correct solution, but I'm not entirely convinced. ;) I am curious as to what the correct solution should be. Perhaps it is to logically separate entities into a scene with shadows and a scene without, as I have mentioned above. Or perhaps my initial approach was right, and everything that appears together *should* logically be created together under a ShadowedScene, with some objects casting, some receiving, and some abstaining. In the latter case, the questions from my last email remain- essentially, is my understanding of node masks correct, is the vanishing text expected behaviour given my choice of masks, and am I approaching things in the right way? I would love to hear the thoughts of anyone who has touched on this area, and can correct or confirm my understanding on the issue. With this input, I will have a better placed to track down the actual problem in my case. Opinions on the best approach definitely welcomed. Any input appreciated. :) Cheers, Garth On 21/04/12 16:50, Garth D wrote: Hi all, I was wondering if someone could help me out with respect to correcting my understanding of shadows and node masks. I am using OpenSceneGraph 3.0.1. I have created a scene, including a osgShadow::ShadowedScene. I have set the node mask for receiving shadows (via setReceivesShadowTraversalMask) to 1, and the mask to cast shadows (via setCastsShadowTraversalMask) to 2. I am using ShadowTexture- I have not been able to get the other techniques to work properly. I have some text (osgText::Text) that I wish to attach to an animated model, screen-facing. I neither want to cast nor receive shadows from this text. The text is attached to a osg::Geode, which is attached to a osg::MatrixTransform, which the model is also attached to, indirectly. Up the tree a little bit, the osgShadow::ShadowedScene can be found. If I leave the Geode as-is, it takes the default all-bits-set node mask, and casts a shadow. If I set it to 2, it casts a shadow. If I set it to 1, it doesn't cast one, but receives shadows from objects in the scene. If I then set the Geode node mask to 0, or 4, both of which should indicate no shadow casting or receiving (as bits zero and one are not set), the text vanishes entirely. Now, obviously it shouldn't do that. I saw similar symptoms when playing with osgEphemeris, but didn't dig into it further when I shifted away from using it. If believe that if I reparent the scene so that it lies outside of the ShadowedScene, it appears correctly. This is because I have a scene fadeout using RTT, and I reparent the scene so that it does not touch a ShadowedScene in this case, and the text appears again during the transition. I am wondering if my understanding of node masks and how they interact with osgShadow is correct. If not, if someone could indicate where and how I am using them incorrectly, it would be appreciated. I was also wondering with respect to modern-day usage, which parts of osgShadow would be considered most reliable and mature. Cheers, Garth ___ 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] look for the example of Skeletal animation
Hi, The osganimation* examples (eg. osganimationviewer, osganimationhardware) included in the source distribution may be a good place to start. Cheers, Garth On 20/04/12 21:46, 炫界 wrote: I want to learn osg Skeletal animation,but I can't find the appropriate.Is anyone has several examples? Thank you 网易Lofter，专注兴趣，分享创作！ http://www.lofter.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgShadow and node masks
Hi all, I was wondering if someone could help me out with respect to correcting my understanding of shadows and node masks. I am using OpenSceneGraph 3.0.1. I have created a scene, including a osgShadow::ShadowedScene. I have set the node mask for receiving shadows (via setReceivesShadowTraversalMask) to 1, and the mask to cast shadows (via setCastsShadowTraversalMask) to 2. I am using ShadowTexture- I have not been able to get the other techniques to work properly. I have some text (osgText::Text) that I wish to attach to an animated model, screen-facing. I neither want to cast nor receive shadows from this text. The text is attached to a osg::Geode, which is attached to a osg::MatrixTransform, which the model is also attached to, indirectly. Up the tree a little bit, the osgShadow::ShadowedScene can be found. If I leave the Geode as-is, it takes the default all-bits-set node mask, and casts a shadow. If I set it to 2, it casts a shadow. If I set it to 1, it doesn't cast one, but receives shadows from objects in the scene. If I then set the Geode node mask to 0, or 4, both of which should indicate no shadow casting or receiving (as bits zero and one are not set), the text vanishes entirely. Now, obviously it shouldn't do that. I saw similar symptoms when playing with osgEphemeris, but didn't dig into it further when I shifted away from using it. If believe that if I reparent the scene so that it lies outside of the ShadowedScene, it appears correctly. This is because I have a scene fadeout using RTT, and I reparent the scene so that it does not touch a ShadowedScene in this case, and the text appears again during the transition. I am wondering if my understanding of node masks and how they interact with osgShadow is correct. If not, if someone could indicate where and how I am using them incorrectly, it would be appreciated. I was also wondering with respect to modern-day usage, which parts of osgShadow would be considered most reliable and mature. Cheers, Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using osgShadow with osgEphemeris (or alternatives)
Hi everyone, In OpenSceneGraph 3.0.1, is there a known fundamental incompatibility between osgShadow and osgEphemeris (circa 4/4/12)? I am using osgShadow (namely ShadowTexture), with both animated and static models, and started to work in osgEphemeris in order to provide a more interesting sky than a single static colour. One thing I noticed is that whenever osgEphemeris is working, the location of cast shadows shifted around significantly, and they are nowhere near the objects that are casting them (ie. the shadows were very clearly incorrect). Depending on the view angle, they also bounced around to different locations. I noticed that animated models no longer cast shadows, but that may have just been a symptom specific to my particular case. In case the node mask was causing a problem (for osgShadow I am using 1 to cast, and 2 to receive), I tried different values. Setting it to zero caused the EphemerisModel to vanish (is this normal?), and to four left it there, but didn't help the shadow situation. In any case, when the EphemerisModel was working, the shadows were shifted around and incorrect. I've tried disabling lighting on the model (via state sets and GL_LIGHTING), as well as attaching it to different nodes, but I don't seem to have struck upon the correct combination. Interestingly enough, if I use either on their own, they work fine. Shadows work fine, without ephemeris models; and ephemeris models seem to produce good results if I turn off shadows. Can anyone suggest any things to try, confirm there are known problems, or otherwise? On a side note, I began to investigate osgEphemeris in the first case as I needed a simple sky. My requirements are pretty low, as the sky is merely decorative, so I don't necessarily *have* to use osgEphemeris specifically. I am wondering what the best approach to sky creation in OSG 3.0.1 would be? The potential solutions I ran into were: - Use the sky code osghangglide as a base/inspiration. - Find a spare $1.5k and use SilverLining (a bit overkill for my application at present!) - Use skydome.osgt from the OpenSceneGraph data dir (I gave this a shot, but I wasn't able to successfully get it working correctly with the rest of my app) - Build up my own geometry, customising the texture coordinates as I need (the most flexible approach, but the most time consuming, and the most pointless if someone has done it already), and grab or buy some existing sky textures to match the expected texture. - Use osgEphemeris, which is what I'm looking at above. Are there other solutions that I should be exploring as well, or in preference? Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using osgShadow with osgEphemeris (or alternatives)
Hi Luc, Thanks for the fast reply on that one. I hadn't considered checking out interactions with the clip planes. I've had to manually override their calculation in a past project, so this could be worth checking out. Incidentally, I did shrink the ephemeris model via setSkyDemoRadius a fair bit before starting, but the presence of the geometry is likely going to move the clip planes around. May I ask re your usage of osgShadow and osgEphemeris, which shadow technique you were using? And yes, osgEphemeris is probably overkill ultimately. ;) Garth On 05/04/12 23:30, Luc Frauciel wrote: Hi Gath, I use osgShadow (VDSM) and osgEphemeris in conjunction, and they seem to work together. However, there are known problems related to osgEphemeris which are broader : - The Skydome in osgEphemeris can be very large, causing unwanted interaction with culling/ nearfar planes. see http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/026772.html long thread, but with useful hints towards solutions - I remember problems with clearing operation, but probably related to solutions to the previous problem. If the only thing that you want is a skydome, osgEphemeris is an overkill for that. You probably still have to consider the culling problems introduced by skydomes (a scene with a skydome is artificially big). Luc De :Garth D garthy_...@entropicsoftware.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 05/04/2012 15:34 Objet : [osg-users] Using osgShadow with osgEphemeris (or alternatives) Envoyé par :osg-users-boun...@lists.openscenegraph.org Hi everyone, In OpenSceneGraph 3.0.1, is there a known fundamental incompatibility between osgShadow and osgEphemeris (circa 4/4/12)? I am using osgShadow (namely ShadowTexture), with both animated and static models, and started to work in osgEphemeris in order to provide a more interesting sky than a single static colour. One thing I noticed is that whenever osgEphemeris is working, the location of cast shadows shifted around significantly, and they are nowhere near the objects that are casting them (ie. the shadows were very clearly incorrect). Depending on the view angle, they also bounced around to different locations. I noticed that animated models no longer cast shadows, but that may have just been a symptom specific to my particular case. In case the node mask was causing a problem (for osgShadow I am using 1 to cast, and 2 to receive), I tried different values. Setting it to zero caused the EphemerisModel to vanish (is this normal?), and to four left it there, but didn't help the shadow situation. In any case, when the EphemerisModel was working, the shadows were shifted around and incorrect. I've tried disabling lighting on the model (via state sets and GL_LIGHTING), as well as attaching it to different nodes, but I don't seem to have struck upon the correct combination. Interestingly enough, if I use either on their own, they work fine. Shadows work fine, without ephemeris models; and ephemeris models seem to produce good results if I turn off shadows. Can anyone suggest any things to try, confirm there are known problems, or otherwise? On a side note, I began to investigate osgEphemeris in the first case as I needed a simple sky. My requirements are pretty low, as the sky is merely decorative, so I don't necessarily *have* to use osgEphemeris specifically. I am wondering what the best approach to sky creation in OSG 3.0.1 would be? The potential solutions I ran into were: - Use the sky code osghangglide as a base/inspiration. - Find a spare $1.5k and use SilverLining (a bit overkill for my application at present!) - Use skydome.osgt from the OpenSceneGraph data dir (I gave this a shot, but I wasn't able to successfully get it working correctly with the rest of my app) - Build up my own geometry, customising the texture coordinates as I need (the most flexible approach, but the most time consuming, and the most pointless if someone has done it already), and grab or buy some existing sky textures to match the expected texture. - Use osgEphemeris, which is what I'm looking at above. Are there other solutions that I should be exploring as well, or in preference? Garth ___ 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] Using osgShadow with osgEphemeris (or alternatives)
Hi Luc, Excellent, thanks for that. Knowing a specific case where the two work well together should help considerably. Garth On 06/04/12 00:10, Luc Frauciel wrote: May I ask re your usage of osgShadow and osgEphemeris, which shadow technique you were using? VDSM (View Dependant Shadow Map), with custom shaders for multi-texturing, transparency, fog, etc... I exclude the skydome of osgephemeris from culling (cf thread) and disable depth test on it. VDSM works quite well for non human-like viewpoints (near the ground, looking towards horizon). Luc De :Garth D garthy_...@entropicsoftware.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 05/04/2012 16:15 Objet : Re: [osg-users] Using osgShadow with osgEphemeris (or alternatives) Envoyé par :osg-users-boun...@lists.openscenegraph.org Hi Luc, Thanks for the fast reply on that one. I hadn't considered checking out interactions with the clip planes. I've had to manually override their calculation in a past project, so this could be worth checking out. Incidentally, I did shrink the ephemeris model via setSkyDemoRadius a fair bit before starting, but the presence of the geometry is likely going to move the clip planes around. May I ask re your usage of osgShadow and osgEphemeris, which shadow technique you were using? And yes, osgEphemeris is probably overkill ultimately. ;) Garth On 05/04/12 23:30, Luc Frauciel wrote: Hi Gath, I use osgShadow (VDSM) and osgEphemeris in conjunction, and they seem to work together. However, there are known problems related to osgEphemeris which are broader : - The Skydome in osgEphemeris can be very large, causing unwanted interaction with culling/ nearfar planes. see http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/026772.html long thread, but with useful hints towards solutions - I remember problems with clearing operation, but probably related to solutions to the previous problem. If the only thing that you want is a skydome, osgEphemeris is an overkill for that. You probably still have to consider the culling problems introduced by skydomes (a scene with a skydome is artificially big). Luc De : Garth D garthy_...@entropicsoftware.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 05/04/2012 15:34 Objet : [osg-users] Using osgShadow with osgEphemeris (or alternatives) Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi everyone, In OpenSceneGraph 3.0.1, is there a known fundamental incompatibility between osgShadow and osgEphemeris (circa 4/4/12)? I am using osgShadow (namely ShadowTexture), with both animated and static models, and started to work in osgEphemeris in order to provide a more interesting sky than a single static colour. One thing I noticed is that whenever osgEphemeris is working, the location of cast shadows shifted around significantly, and they are nowhere near the objects that are casting them (ie. the shadows were very clearly incorrect). Depending on the view angle, they also bounced around to different locations. I noticed that animated models no longer cast shadows, but that may have just been a symptom specific to my particular case. In case the node mask was causing a problem (for osgShadow I am using 1 to cast, and 2 to receive), I tried different values. Setting it to zero caused the EphemerisModel to vanish (is this normal?), and to four left it there, but didn't help the shadow situation. In any case, when the EphemerisModel was working, the shadows were shifted around and incorrect. I've tried disabling lighting on the model (via state sets and GL_LIGHTING), as well as attaching it to different nodes, but I don't seem to have struck upon the correct combination. Interestingly enough, if I use either on their own, they work fine. Shadows work fine, without ephemeris models; and ephemeris models seem to produce good results if I turn off shadows. Can anyone suggest any things to try, confirm there are known problems, or otherwise? On a side note, I began to investigate osgEphemeris in the first case as I needed a simple sky. My requirements are pretty low, as the sky is merely decorative, so I don't necessarily *have* to use osgEphemeris specifically. I am wondering what the best approach to sky creation in OSG 3.0.1 would be? The potential solutions I ran into were: - Use the sky code osghangglide as a base/inspiration. - Find a spare $1.5k and use SilverLining (a bit overkill for my application at present!) - Use skydome.osgt from the OpenSceneGraph data dir (I gave this a shot, but I wasn't able to successfully get it working correctly with the rest of my app) - Build up my own
Re: [osg-users] Using osgShadow with osgEphemeris (or alternatives)
Hi Luc, Incidentally, thanks also for the thread link and the suggestions re potential culling issues. I disabled automatic calculation of near/far planes and fixed the code to work with manual settings, but the symptoms remained the same (ephemeris model enabled warps shadows), although I think my experimentation there might help out with some (unrelated) issues I had previously encountered and put on the backburner. Going through the thread you provided, the idea of using a dedicated prerender camera to contain the dome seems to have been successfully used by others, so that might give me something else to experiment with. I might also code up my own skysphere-building code as it would let me compare the results with the osgEphemeris implementation to narrow down where the problem is coming from (osgEphemeris, or the distant geometry). Thankyou again for your thoughts on this one. My attempts to solve this one have felt a bit aimless, and you've helped narrow down the focus somewhat. Much appreciated. :) Garth On 05/04/12 23:30, Luc Frauciel wrote: Hi Gath, I use osgShadow (VDSM) and osgEphemeris in conjunction, and they seem to work together. However, there are known problems related to osgEphemeris which are broader : - The Skydome in osgEphemeris can be very large, causing unwanted interaction with culling/ nearfar planes. see http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-April/026772.html long thread, but with useful hints towards solutions - I remember problems with clearing operation, but probably related to solutions to the previous problem. If the only thing that you want is a skydome, osgEphemeris is an overkill for that. You probably still have to consider the culling problems introduced by skydomes (a scene with a skydome is artificially big). Luc De :Garth D garthy_...@entropicsoftware.com A : OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: 05/04/2012 15:34 Objet : [osg-users] Using osgShadow with osgEphemeris (or alternatives) Envoyé par :osg-users-boun...@lists.openscenegraph.org Hi everyone, In OpenSceneGraph 3.0.1, is there a known fundamental incompatibility between osgShadow and osgEphemeris (circa 4/4/12)? I am using osgShadow (namely ShadowTexture), with both animated and static models, and started to work in osgEphemeris in order to provide a more interesting sky than a single static colour. One thing I noticed is that whenever osgEphemeris is working, the location of cast shadows shifted around significantly, and they are nowhere near the objects that are casting them (ie. the shadows were very clearly incorrect). Depending on the view angle, they also bounced around to different locations. I noticed that animated models no longer cast shadows, but that may have just been a symptom specific to my particular case. In case the node mask was causing a problem (for osgShadow I am using 1 to cast, and 2 to receive), I tried different values. Setting it to zero caused the EphemerisModel to vanish (is this normal?), and to four left it there, but didn't help the shadow situation. In any case, when the EphemerisModel was working, the shadows were shifted around and incorrect. I've tried disabling lighting on the model (via state sets and GL_LIGHTING), as well as attaching it to different nodes, but I don't seem to have struck upon the correct combination. Interestingly enough, if I use either on their own, they work fine. Shadows work fine, without ephemeris models; and ephemeris models seem to produce good results if I turn off shadows. Can anyone suggest any things to try, confirm there are known problems, or otherwise? On a side note, I began to investigate osgEphemeris in the first case as I needed a simple sky. My requirements are pretty low, as the sky is merely decorative, so I don't necessarily *have* to use osgEphemeris specifically. I am wondering what the best approach to sky creation in OSG 3.0.1 would be? The potential solutions I ran into were: - Use the sky code osghangglide as a base/inspiration. - Find a spare $1.5k and use SilverLining (a bit overkill for my application at present!) - Use skydome.osgt from the OpenSceneGraph data dir (I gave this a shot, but I wasn't able to successfully get it working correctly with the rest of my app) - Build up my own geometry, customising the texture coordinates as I need (the most flexible approach, but the most time consuming, and the most pointless if someone has done it already), and grab or buy some existing sky textures to match the expected texture. - Use osgEphemeris, which is what I'm looking at above. Are there other solutions that I should be exploring as well, or in preference? Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users
Re: [osg-users] Using osgShadow with osgEphemeris (or alternatives)
Hi all, I've coded up and integrated a custom-built sky sphere and integrated it into my project. I'm using manual near/far clip planes. The osgShadow ShadowTexture-based shadows are working fine and do not experience the same displacement issues as when using osgEphemeris. Obviously there is some subtlety in the interaction between osgEphemeris and osgShadow that comes up in my project, which isn't triggered when using simple geometry and triangle strips, even when the geometry is distant. Strange. I think I'll stick with custom geometry going forward in my project, as I don't really need the advanced features of osgEphemeris at this point. I haven't experimented with a separate camera yet, but this might be something I try out at a later stage, especially since it has worked for others. Garth On 06/04/12 11:20, Garth D wrote: I might also code up my own skysphere-building code as it would let me compare the results with the osgEphemeris implementation to narrow down where the problem is coming from (osgEphemeris, or the distant geometry). ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG FAQ native formats
Hi Chris, Thanks for the confirmation and information. :) Sorry for the delayed response- I just wanted to give it a few days in case someone with wiki access also saw the message and made the change directly (which happened). :) Garth On 06/01/12 16:19, Chris 'Xenon' Hanson wrote: On 1/5/2012 10:37 PM, Garth D wrote: lists osg and ive as the native OSG formats. Is this still accurate? Should this be listed as osgb for the binary format, and osgt for the text format? You're correct, those are the new native formats. The old should be noted as deprecated in 3.x. If the FAQ is incorrect, is there somebody I should let know? I think you can edit it yourself, but I forget who manages logins for the Wiki. Perhaps Jose Luis Hidalgo? Cheers. :) Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG FAQ native formats
Hi Robert, Not a problem at all, happy to help. Thankyou for making such a great library available. Incidentally, can I suggest a minor change in the new FAQ entry? Presently it is: The extensible of the new formats enables end user application ... How about, instead, one of: The extensible nature of the new formats enables end user applications ...; The extensibility of the new formats enables end user applications ...; or The new formats enable end user applications ... ? Garth On 06/01/12 20:27, Robert Osfield wrote: Hi Garth, Thanks for the notification. I have amended this FAQ entry to mention the new .osgt, osgx and .osgb formats and how .osg and .ive related to older versions of the OSG. Robert. On 6 January 2012 05:37, Garth Dgarthy_...@entropicsoftware.com wrote: Hi all, The OSG FAQ here: http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#DoestheOpenSceneGraphhaveanativefileformat lists osg and ive as the native OSG formats. Is this still accurate? Should this be listed as osgb for the binary format, and osgt for the text format? Or have I got this backward? Or is it a bit more complicated than that? If the FAQ is incorrect, is there somebody I should let know? Cheers. :) Garth ___ 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] Extending Geode or Geometry
Hi Philipp, This is just a personal preference, but when faced with a similar problem I tend to keep the data separate rather than extend the existing class. The benefits are: - You can use whatever class hierarchy suits your problem without being bound by the constraints of what works best for the target class (in this case, either Geode or Drawable). - If you need more than one Geode, or multiple types, or no Geode in some cases, it varies, or you want a geometry-free run, you're going to wish you went for a separate class. - If you want to perform geometry updates, you can always choose to either modify the existing geometry, or just create a whole new Geode and/or Drawable. If you extend instead, you're stuck working with that one as a base, and you'll need to modify. - If you want to add additional effects in some way to the geometry, it will likely be easier this way. Of course, there are cases where it would make more sense to extend the OSG classes themselves. For example, if your problem was somewhat close to a scene graph in design, and the geometry was always incrementally updated due to a full rebuild being prohibitively expensive, it might save some time to tie it in more directly through class extension. Just my thoughts on the issue. I hope they help. :) Garth PS. In my own project I am *effectively* using a single osg::Group per object that has a renderable component. That way I can include as much or as little of OSG as I need. In practice it's a little more complex than that, but it follows this basic idea. On 07/01/12 02:54, Philipp Moeller wrote: Hi list, my use-case is this: I have data structures that cannot be rendered directly but can be transformed to something that is renderable. All algorithms manipulating data work on my own data structures. After the algorithms are done, I would like to update the geometry to reflect the changed data. I'm unsure if I should extend a osg::Geode, add my datastructure as a member and a rebuild() member funtion or if it makes more sense to extend a osg::Drawable and go from there. Basically, the setUserData() function already does what I want but it lacks a way to issue an update. Alternatively, I can just store my data separately and use setUserData to have to keep pointers to the associated data and work from there. Cheers, Philipp ___ 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] OSG FAQ native formats
Hi all, The OSG FAQ here: http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#DoestheOpenSceneGraphhaveanativefileformat lists osg and ive as the native OSG formats. Is this still accurate? Should this be listed as osgb for the binary format, and osgt for the text format? Or have I got this backward? Or is it a bit more complicated than that? If the FAQ is incorrect, is there somebody I should let know? Cheers. :) Garth ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Skeletal Animation Advise
Hi Steven, I certainly can't speak for everyone (or with any authority whatsoever) ;), but for my own OSG 3.0.1 -based project, for what it's worth, things started working very nicely for me when I started using FBX as an intermediate format for skeletal animation (I subsequently convert animated models to osgb format, personally). I can't help at all with the main part of your question (ie. the best course of action starting with OSG 2.8.2), but I thought I'd share the above at least. Garth On 23/12/11 06:30, Steven Powers wrote: Hi, I am currently running with OSG v2.8.2 and I am required to add in skeletal animation support. I'm wondering what the best file formats will be best suited to do this and if it would be a good idea to upgrade OSG to a version that includes the FBX plugin. From reading the forums it seems FBX is the best approach, assuming I upgrade my OSG version, but is there a solution that would work well with OSG 2.8.2?? Thank you! Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44453#44453 ___ 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] Rotate point in 3d space?
Hi Paul, A good search term in Google that will give you a lot of useful info is: 3d rotation. You'll also have to give some thought as to which axis you are rotating around. Good luck. :) Garth On 17/12/11 22:52, Paul Griffiths wrote: Hi, Lets say i have a point: float x = 20; float y = 5; float z = 3; how do I rotate the point using point 0,0,0 as the pivot? Say I wish to rotate it by 45deg? It's for some math to set a clip plane's 3 points. ... Thank you! Cheers, Paul -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44408#44408 ___ 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
