Re: [osg-users] Advice on interacting with osgShadow
Dear Wojciech, J-S, All classes belonging to ViewDependentShadow group derive shaders from StandardShadowMap. If you look at these shaders you will notice that they are split into main vertex and fragment shader and shadow vertex and fragment shader. I saw this. Maybe I'm being daft, but presumably this only helps when you have the SAME shader for the entire shadowed scene? I have a situation where the shadowed objects have a variety of different shaders. If I'm missing something obvious, my apologies. LODs should be properly handled by ViewDependentshadows. Shadow camera uses the same viewpoint as main camera. Shadow Camera ref frame is set to ABSOLUTE_RF_INHERIT_VIEWPOINT. Ah yes. Thanks for pointing that out. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
David, I saw this. Maybe I'm being daft, but presumably this only helps when you have the SAME shader for the entire shadowed scene? I have a situation where the shadowed objects have a variety of different shaders. If I'm missing something obvious, my apologies. Thats true. But opposite scenario is also possible. You can link your main shaders in your object statesets with shadow shaders from StandardShadowMap. Just grab them from StandardShadowMap via getShadowVertexShader() getShadowFragmentShader(). Make sure to call DynamicShadow functions in proper places of your main vertex shaders to compute shadow texture coords and call DynamicShadow in main fragment to get shadowing term. You may look at StandardShadow main shaders for reference. StandardShadowMap do not apply its shadow program with override attribute so if you actually have the shaders below ShadowedScene your shaders will be used. If you simply make sure call DynamicShadow function from your main you should be well and happy. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Wojtek, Just grab them from StandardShadowMap via getShadowVertexShader() getShadowFragmentShader(). Ah. I missed that. Perils of browsing source via the website, I guess... Thanks, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi David, Btw. Shadow shaders are extremaly simple. Vertex shader simply performs texgen operation on stage 1 to produce shadow tex coords. Fragment shader simply performs texture from shadow map. So generally you may even hardcode these operation into your main shaders. In my company we use some sort of poor man virtualization of OSG GLSL program. At the top of hierarchy we use dummy Shadow shaders which implement nullop DynamicShader (vertex does nothing, fragment returns 1.0 as shadow term) . When Shadowing kicks in these, Shadow shaders are substituted with StandardShadowMap shaders and programs are automatilly rebuilt. That way we can fairly easily activate/ deactivate Shadowing based on user request. Cheers, Wojtek - Original Message - From: David Spilling To: OpenSceneGraph Users Sent: Friday, October 24, 2008 2:59 PM Subject: Re: [osg-users] Advice on interacting with osgShadow Wojtek, Just grab them from StandardShadowMap via getShadowVertexShader() getShadowFragmentShader(). Ah. I missed that. Perils of browsing source via the website, I guess... Thanks, David -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi J-S, Wojciech, Thanks for the help. I've got shadow maps working (I'm on 2.6.1) and when I get round to it, I'll migrate up to the 2.7 ViewDependant stuff and see if I can get the other techniques working as well. Now, an add-on library could be written that would help unify the art pipeline. Things like models, textures, mapping of textures to texture units, shader management, shader generation from chunks of shader code, effect management, etc. could be made much simpler and more user-friendly. But as I said, I don't think it's OSG's job to do this. OSG provides a framework, and this is a bit too domain-specific IMHO. Regarding shader management, I think that it *would *be appropriate for OSG to provide something here. ( Obviously I realise that this is a large amount of code - I'm arguing about the appropriateness, not actually demanding that someone provide it ! ) The reason is basically that as fixed function falls away, shaders become more important, and the relationship between the scenegraph and the shader becomes much more like the relationship between the scenegraph and the state. For example, the 2.7 shadow library does a fantastic out-of-the-box job of providing a sort of uber-shader that tries to handle a variety of effects (various sorts of lights, multiple lights, diffuse texture etc.). However, throw that at a model that already has shaders on it, and you end up having to copy-and-paste the shadow shader into the models' shader. This gets more complicated if the various shadowed objects have different shaders, and this is the situation I have. I fear that bugfixes and so on to the complex shaders in osgShadow will end up with my object shaders being out-of-step, and therefore producing hard to pin-down errors in the result. (shader debugging is awful). Thinking aloud, I wonder if some sort of text-based accumulation of functions that are passed down the scenegraph, with assembly and binding at the level they are actually required, would be appropriate. For example, the shadow shader could just be a stub e.g. a float CalculateShadow() function that objects that are shadowed need to call if they want. A couple of specific things: 1) I admit I haven't looked properly at the 2.7 osgShadow, but does it handle LOD nodes within objects? 2) Although not relevant to me right now, in case the depth-only vertex shader gets implemented (at the moment it appears from the comments that fixed function has been found to be faster) it might be useful to be able to override osgShadow's depth-only vertex shader, - the object might in some cases be being dynamically transformed during shadowing (e.g. character animation). Anyway, just my 2p. Thanks (all involved) for all the work on the shadow libraries. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi David, Good to know you've got some progress. Regarding shader management, I think that it *would *be appropriate for OSG to provide something here. ( Obviously I realise that this is a large amount of code - I'm arguing about the appropriateness, not actually demanding that someone provide it ! ) The reason is basically that as fixed function falls away, shaders become more important, and the relationship between the scenegraph and the shader becomes much more like the relationship between the scenegraph and the state. Yes, of course, someday only OpenGL 3 will be supported in the graphic card drivers, in which case the fixed pipeline will be deprecated. So OSG will have to provide some high-level mechanism for managing shaders. Whether that is a fully fleshed out shader system or something close to what we already have (with a little more functionality) remains to be seen. Thinking aloud, I wonder if some sort of text-based accumulation of functions that are passed down the scenegraph, with assembly and binding at the level they are actually required, would be appropriate. For example, the shadow shader could just be a stub e.g. a float CalculateShadow() function that objects that are shadowed need to call if they want. Well, that is the crux of the problem really. There are a few ways to manage shaders in a scene: * One uber-shader at the root, with uniforms at nodes to control their appearance, a bit like what ViewDependentShadow does now and what I do in our framework here. (easy to maintain but on older cards you pay a penalty for conditionals and loops). * N different shaders for N different combinations of effects, and you choose the right shader on the node depending on its appearance (difficult to manage but you have more control and it can scale to older/newer cards) * Shader fragments on nodes which are linked together to make a complete shader (reduces the number of shaders to write manually, but need to make sure all combinations are linked at program load time or else dynamically linking a program at runtime will introduce a frame rate hit) There are possibly other strategies out there, but these are the main points. I've been researching this topic a lot, and there is still no clear winner out of these three options. It's a tradeoff and depends on your application and target market (for example: do you need to support old cards or do you have control over your hardware?). I haven't yet done any experimentation though, this is just from reading the literature. (also see Deferred Shading which might render all this obsolete - if the issue with transparency can be solved in an elegant way) So unless OSG intends on supporting all three and allowing the user to select which strategy to use, I think it's really up to the library user to select a strategy and adapt it to his own use, and then implement it. OSG should only supply the tools to make implementing these strategies possible (and it already does). As I said, that's just the way I feel about it, and you may disagree. We'll see what the future holds. I'm sure that if someone submits a system that implements one (or all) of these strategies, it will not be rejected, but it won't be a silver bullet solution so it will only be used by part of the applications using OSG. 1) I admit I haven't looked properly at the 2.7 osgShadow, but does it handle LOD nodes within objects? Yes. Specifically, the LOD used in shadow computation will be the same as seen from the camera's viewpoint, so the shadow will look like the geometry. On our side, we're looking into forcing the lowest-resolution (furthest) LOD for shadows, to lower the shadow RTT time in the cull traversal on large models. But this is not supported in the basic shadow technique(s). 2) Although not relevant to me right now, in case the depth-only vertex shader gets implemented (at the moment it appears from the comments that fixed function has been found to be faster) it might be useful to be able to override osgShadow's depth-only vertex shader, - the object might in some cases be being dynamically transformed during shadowing (e.g. character animation). Yes, of course you would need that in that case, and it's something that can be supported by subclassing the shadow technique once again. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
David, All classes belonging to ViewDependentShadow group derive shaders from StandardShadowMap. If you look at these shaders you will notice that they are split into main vertex and fragment shader and shadow vertex and fragment shader. Main shaders do nothing extraordinary they simply emulate fixed pipeline. Specific shadow tasks are performed in DynamicShadow functions defined in shadow.vert and shadow.frag shaders. So the code is prepared for such scenario where you simply substitute main shaders with yours and link your main shaders with default shadow technique shadow shaders. As to more general problem of shaders in OSG classes conflicting with user shaders I think we should start another thread devoted only to discussing this problem. I agree Its important topic but I really think its not only related to shadows. LODs should be properly handled by ViewDependentshadows. Shadow camera uses the same viewpoint as main camera. Shadow Camera ref frame is set to ABSOLUTE_RF_INHERIT_VIEWPOINT. The depth map rendering optimizations were the topic we discussed recently with J-S. For now we have decided we don't change this code. If neccessary - one should be able to everride proper shadow class and their internal ViewData class and adjust this fuctionality where needed. Cheers, Wojtek - Original Message - From: David Spilling To: OpenSceneGraph Users Sent: Thursday, October 23, 2008 2:04 PM Subject: Re: [osg-users] Advice on interacting with osgShadow Hi J-S, Wojciech, Thanks for the help. I've got shadow maps working (I'm on 2.6.1) and when I get round to it, I'll migrate up to the 2.7 ViewDependant stuff and see if I can get the other techniques working as well. Now, an add-on library could be written that would help unify the art pipeline. Things like models, textures, mapping of textures to texture units, shader management, shader generation from chunks of shader code, effect management, etc. could be made much simpler and more user-friendly. But as I said, I don't think it's OSG's job to do this. OSG provides a framework, and this is a bit too domain-specific IMHO. Regarding shader management, I think that it would be appropriate for OSG to provide something here. ( Obviously I realise that this is a large amount of code - I'm arguing about the appropriateness, not actually demanding that someone provide it ! ) The reason is basically that as fixed function falls away, shaders become more important, and the relationship between the scenegraph and the shader becomes much more like the relationship between the scenegraph and the state. For example, the 2.7 shadow library does a fantastic out-of-the-box job of providing a sort of uber-shader that tries to handle a variety of effects (various sorts of lights, multiple lights, diffuse texture etc.). However, throw that at a model that already has shaders on it, and you end up having to copy-and-paste the shadow shader into the models' shader. This gets more complicated if the various shadowed objects have different shaders, and this is the situation I have. I fear that bugfixes and so on to the complex shaders in osgShadow will end up with my object shaders being out-of-step, and therefore producing hard to pin-down errors in the result. (shader debugging is awful). Thinking aloud, I wonder if some sort of text-based accumulation of functions that are passed down the scenegraph, with assembly and binding at the level they are actually required, would be appropriate. For example, the shadow shader could just be a stub e.g. a float CalculateShadow() function that objects that are shadowed need to call if they want. A couple of specific things: 1) I admit I haven't looked properly at the 2.7 osgShadow, but does it handle LOD nodes within objects? 2) Although not relevant to me right now, in case the depth-only vertex shader gets implemented (at the moment it appears from the comments that fixed function has been found to be faster) it might be useful to be able to override osgShadow's depth-only vertex shader, - the object might in some cases be being dynamically transformed during shadowing (e.g. character animation). Anyway, just my 2p. Thanks (all involved) for all the work on the shadow libraries. David -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi J-S, Ok, then lets postpone any changes to the moment we hear additional requests from others. Once you managed to solve your blending issue this discussion seems purely academic. Lets wait for some practical problems to appear. I think this is actually best choice. With every piece we add, we make some fuctionality easier to use, but we also make already complex code even more complicated. However ;-) there is one little tweak I will submit. I will add default AlphaFunc/AlphaTest to shadow camera stateset. That way I will avoid transparency with typical models (which started discussion ;-). I should have done it in the first place to be consistent with render bin override policy. But I have neglected it beacuse our models had this attribute set. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi Wojtek, Ok, then lets postpone any changes to the moment we hear additional requests from others. Once you managed to solve your blending issue this discussion seems purely academic. Lets wait for some practical problems to appear. I think this is actually best choice. With every piece we add, we make some fuctionality easier to use, but we also make already complex code even more complicated. I totally agree. However ;-) there is one little tweak I will submit. I will add default AlphaFunc/AlphaTest to shadow camera stateset. That way I will avoid transparency with typical models (which started discussion ;-). I should have done it in the first place to be consistent with render bin override policy. But I have neglected it beacuse our models had this attribute set. What would be the parameters for this default AlphaFunc? I suggested before that we add an AlphaFunc with GREATER 0.0 as parameters, and I thought you had rejected the idea... Perhaps that was just a misunderstanding on my part. If that's what you intend to do, I'm all for it. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi J-S, Ok, then lets postpone any changes to the moment we hear additional requests from others. Once you managed to solve your blending issue this discussion seems purely academic. Lets wait for some practical problems to appear. I think this is actually best choice. With every piece we add, we make some fuctionality easier to use, but we also make already complex code even more complicated. I totally agree. Then we both agree ;-) However ;-) there is one little tweak I will submit. I will add default AlphaFunc/AlphaTest to shadow camera stateset. That way I will avoid transparency with typical models (which started discussion ;-). I should have done it in the first place to be consistent with render bin override policy. But I have neglected it beacuse our models had this attribute set. What would be the parameters for this default AlphaFunc? I suggested before that we add an AlphaFunc with GREATER 0.0 as parameters, and I thought you had rejected the idea... Perhaps that was just a misunderstanding on my part. If that's what you intend to do, I'm all for it. Yes. Pixels pass when alpha is GREATER than 0. Simplest ideas do not always come first ;-). Maybe it was me who got it wrong. I understood that we should have added this to osgShadow::ShadowedScene instance - which is beyond my realm. I will be happy to add this to StandardShadowMap shadow camera stateset, though ;-) Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
J-S and All, After a sleep I have taken another look at the subject and I would like to propose other approach: In general I doubt I will be able to foresee all types of problems and doubt I could add flags to suppress all responsible pieces of code. On the other hand all such problems could be solved by overriding proper shadow technique class. So as general recommedation I would suggest overriding one of the ViewDependentShadow classes and their associated ViewData class when defaults setttings not work. However, I understand that overridng proper Shadow class and their ViewData might be bit more complicated than overriding simpler things like node callback. So as a mid-solution for those lazy or those who don't know how to override a class, I would propose adding SetShadowMapCameraSettingsCallback. If added, this calback will be called whenever shadow camera stateset is filled, if not added default settings will be applied. This way if one needs to change some setings he may simply override calback and make it their way. Does it sound reasonable ? Wojtek -Original Message- From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2008 10:21 PM To: [EMAIL PROTECTED]; OpenSceneGraph Users Subject: Re: [osg-users] Advice on interacting with osgShadow Hi Wojtek, Turning on AlphaTest/AlphaFunc is not mutually exclusive with RenderBin override. I don't want to make decision that has to be its either this or that. I would like to leave RenderBin override as default. I would also add setShadowMapRenderingSettings/getShadowMapRenderingSettings methods to allow user turn it off if he decides. So my conclusion is I would like to add the submission as sent to the codebase. Excellent, I agree with this. I tested your code and it works for me, so you can send it to osg-submissions whenever you want. I could suggest that instead of using OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1, SET_COLOR_MASK_TO_FALSE = 2, you use the bit shift notation, which I find easier to read and maintain (and please align the values... :-) ): OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1 0, SET_COLOR_MASK_TO_FALSE = 1 1, SOME_OTHER_SETTING = 1 2, but that's just a style issue and subject to personal taste. Also you could add a doxygen comment for the ShadowMapRenderingSettings enum, which would explain what the values are useful for. Otherwise, it's pretty cryptic for users (unless they search the mailing lists and find this thread :-) ). J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi Wojtek, However, I understand that overridng proper Shadow class and their ViewData might be bit more complicated than overriding simpler things like node callback. So as a mid-solution for those lazy or those who don't know how to override a class, I would propose adding SetShadowMapCameraSettingsCallback. If added, this calback will be called whenever shadow camera stateset is filled, if not added default settings will be applied. This way if one needs to change some setings he may simply override calback and make it their way. I don't think it's being lazy to not want to override a shadow class. It's pretty specialized stuff, and if your overridden class does something wrong it's very easy to cause more problems than you fix. In essence, I think the number of users able to correctly derive from a shadow class to fix some behavior in the original class is pretty small. Not everyone is an experienced OpenGL / real-time graphics developer. Most just want to use OSG and want it to work without having to know the details. So I'm not sure if the callback mechanism is better than options as you suggested yesterday. One is very focused, the other is very general. Yes, the callback is more future-proof, but imagine someone who has the same problem as I do. They look at the shadow classes, and they see that they support a SetShadowMapCameraSettingsCallback. What do they do with that? What does the callback have to be? Plus, they will have to set all other settings (which they don't need to change) just to disable one setting... There's too much chance they might make a mistake. On the other hand, the options you suggested yesterday is much simpler for a user, and we can even document what each setting does, and when you might need to enable/disable it. I think this is more useful to a user who just has a problem and wants to solve it. I think it's important to keep in mind that OSG evolves with the needs of its users, so you don't have to predict all the settings that might need to be disabled. We can add others as they are needed. Finally, I'll also remind you that from my point of view, adding AlphaFunc into some statesets in my objects would be a good solution as well, so if you're not comfortable with the options and the callback mechanism, we can just drop the issue. I think my case was pretty specific to our models. If we ever get some other report of the same behavior, we can do something then... It's up to you. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi David, In the case where the objects that are casting shadows have expensive fragment shaders, I would prefer to turn these shaders off so that we just get a quick depth only pass. Fortunately my expensive shaders sit above the object's scenegraph, and so I can envisage an approach in which my unshaded object has two parent nodes (say A and B), which are both children of the shadow node. A would have the castsShadow mask and a cheap shader, and B would have the receivesShadow mask and the expensive shader. Does this sound like an acceptable approach? If you're using the ViewDependentShadow techniques, they already disable shaders while rendering the shadow pass. (note that they also disable blending, which is a problem if you have objects which are solid but whose textures give holes, like a chain link fence for example - the object's shadow will look completely solid instead of showing the holes as it should) I don't remember if the osgShadow::ShadowMap does the same, but it should. It makes sense to disable as much as possible for the shadow pass since all you want is depth information. If you find that your shaders are still being called, then yes, what you suggest above is reasonable. For good architectural reasons, I can not place one of my desired shadow receiving items underneath the shadow node. Hence I would like access to the shadow texture, so that it can bind it explicitly. Would allowing the ShadowTechnique classes to expose their RTT shadow texture so that something else can also bind it be a problem in general? At the moment its protected. Is this something worth submitting or should I just subclass/rewrite? I would subclass and just add a public getter for the texture since it's protected. Pretty simple. I wonder what the good architectural reasons are, but let's not get into that discussion :-) I realise that multitextured items aren't really supported by the out-of-the-box shadow techniques, but at the moment the handling of the shadow texture units and base texture units seems a little clumsy, and difficult to extend. Does anybody else have any experience of using shadows with objects that are already multitextured (e.g. diffuse and normal mapped)? It looks to me that if you have any other shaders knocking around your scenegraph, you need to subclass ShadowTechnique to support your usage model. Is that what people have done in the past? I don't really see why you can't just change the shaders, making sure your new shaders use the same uniform and sampler names and do the right calculations for shadows, while doing multitexturing. For osgShadow::ShadowMap, as long as the base texture is in unit 0 and the shadow map in unit 1, you're OK, so you can use units 2, 3, 4... for other textures. In the case of the ViewDependentShadow techniques, you can change the texture units used by the base texture and shadow texture, which does a search-and-replace in the shader code, so you could use units 0, 1, 2 as textures and 3 as shadow map as long as you set it that way in the ShadowTechnique. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi David, J-S As usual, Great thanks to J-S for doing my work ;-) But I would like to clarify the blending issue you mentioned. In the case where the objects that are casting shadows have expensive fragment shaders, I would prefer to turn these shaders off so that we just get a quick depth only pass. Fortunately my expensive shaders sit above the object's scenegraph, and so I can envisage an approach in which my unshaded object has two parent nodes (say A and B), which are both children of the shadow node. A would have the castsShadow mask and a cheap shader, and B would have the receivesShadow mask and the expensive shader. Does this sound like an acceptable approach? If you're using the ViewDependentShadow techniques, they already disable shaders while rendering the shadow pass. (note that they also disable blending, which is a problem if you have objects which are solid but whose textures give holes, like a chain link fence for example - the object's shadow will look completely solid instead of showing the holes as it should) No, they won't be solid. As they are not solid in for trees drawn in island scene. But you have to use alpha ref. On the other hand if your transparency does not use alpha ref and sets Z-values it will still be solid even if color buffer would end transparent. So I must admit I don't exactly understand why turning blending may change depth values in shadow map. Maybe its not blending but override on rendering bins ? I use only one bin to render shadow map - is this the reason of your problems ? Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Dear J-S, Thanks for the help. If you're using the ViewDependentShadow techniques, they already disable shaders while rendering the shadow pass. Ah - I hadn't spotted that in the code yet. So no problems there then. While I'm here, is there any reason why the shaded objects shouldn't do the TexGen in a vertex shader? I would subclass and just add a public getter for the texture since it's protected. Pretty simple. Sounds like a good idea. I wonder what the good architectural reasons are, but let's not get into that discussion :-) No, lets, as you might spot something I hadn't considered. Lets say I have a node representing a mirror, which uses an RTT technique to draw reflections. In a similar way to the shadows, the objects to be reflected are placed as children of the mirror, in addition to their normal position in the SG. The mirror puts various transforms and clips on the reflection, so that the reflected image is correct. Now, the mirror is itself a shadowCaster, as are the objects it is trying to reflect. If I put the objects and the mirror as children of the shadowTechnique node, then the non-mirror objects cast shadows twice - once in their normal orientation, and once in their reflected-child-of-mirror orientation, which is wrong. Thinking about it though, I suppose that setting shadowCast to false on an intermediate node between the mirror and the reflected objects prevents the cull traverse from ever finding them, so they don't cast shadows twice. Sounds right? Although I'm still a bit uneasy about what the mirror might make of the repeated cull traverse attempts... I suppose I had just better try it out rather than blather on and on. ...multitexturing Your comments agreed. soapbox mode I think that the issue is a little bit more far ranging to manage in a generic application way. For example, the set of incoming models I have to draw unfortunately comes in with texture units all over the place. (e.g. some have diffuse = 0, normal = 1, specular = 2, some have diffuse = 0, specular = 1, no normal). This is in part because file formats that do specify texture types (diffuse, normal, gloss etc.) like obj and 3ds, don't specify which texture unit they should occupy. Openflight, in contrast, specifies which textureUnit the incoming map actually is. Hence we end up with a bit of a mishmash, thanks to not having an art path that is historically well controlled, and receiving assets from various sources. Therefore it is tricky for me to say that texture unit 0 = shadows and 1 = diffuse, because it is hard to guarantee that in the general case. The solution I'm likely to resort to is to say shadow = 7, and then if the model comes in with anything in tex unit 7 then...well.. it has been warned. Can't say that's happened often though. [Although one might be using tangentspace generators to push normals into attributes 6,7,15, which could conceivably get mangled with shadows's texgen (in the case of shadow=7) which means that 7 is a bad choice... and so on.] Not ideal. I would prefer an OSG wide setting that would be user controlled that set up some sort of relationship between default texture types and units(e.g. 0=DIFFUSE, 1=SHADOW, 2=NORMAL, 3=SPECULAR etc.) , so that all the loaders that cared would be consistent (e.g. 3ds, obj), and that the shadow map could refer to, and that any shader set could read sampler2D values from, etc. No idea where this would go, though. /soapbox mode Thanks again for the pointers. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi Wojtek, No, they won't be solid. As they are not solid in for trees drawn in island scene. But you have to use alpha ref. On the other hand if your transparency does not use alpha ref and sets Z-values it will still be solid even if color buffer would end transparent. Alpha ref? What's that? (I'm showing my ignorance, but all I know is that our objects just have textures with alpha=0 for some texels - I don't know anything about alpha ref) So I must admit I don't exactly understand why turning blending may change depth values in shadow map. Maybe its not blending but override on rendering bins ? I use only one bin to render shadow map - is this the reason of your problems ? It's true that I was oversimplifying. I always put blending and renderbin settings in the same bucket as normally they're used together... You're absolutely right, it's the renderbin override that causes the shadows of my chain link fences (and other objects with textures having some texels alpha=0) to be totally opaque. So coming back to what you said above, what would be the right solution? Is there a way to fix our models so that I don't have to comment out the renderbin override in StandardShadowMap.cpp? Otherwise, I'd submit a setter/getter control for that particular setting. It's necessary in our situation. Thanks as always Wojtek, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi David, Thanks for the help. My pleasure. While I'm here, is there any reason why the shaded objects shouldn't do the TexGen in a vertex shader? They do... :-) Thinking about it though, I suppose that setting shadowCast to false on an intermediate node between the mirror and the reflected objects prevents the cull traverse from ever finding them, so they don't cast shadows twice. Sounds right? Although I'm still a bit uneasy about what the mirror might make of the repeated cull traverse attempts... I suppose I had just better try it out rather than blather on and on. About your mirror problem, I admit I haven't seen this case. Your solution (getting the shadow map texture and applying it to nodes not under the ShadowedScene) might be the best way, I don't know. I have the opinion that adding too many multiple traversal paths can make things hard to understand when debugging why something is not rendering correctly. That's up to you of course. But thanks for explaining, at least it shows me that I have to keep an open mind to situations that I haven't seen :-) I would prefer an OSG wide setting that would be user controlled that set up some sort of relationship between default texture types and units(e.g. 0=DIFFUSE, 1=SHADOW, 2=NORMAL, 3=SPECULAR etc.) , so that all the loaders that cared would be consistent (e.g. 3ds, obj), and that the shadow map could refer to, and that any shader set could read sampler2D values from, etc. No idea where this would go, though. I agree that all this is more complex than it should be. There are a few things OSG could do to simplify the art pipeline management, but I don't think it's really under its jurisdiction to do so. Applications will have different requirements, and even though some can be generalized, in many cases you want to try out different strategies in order to find the one that works best given your hardware and application-specific bottlenecks. Now, an add-on library could be written that would help unify the art pipeline. Things like models, textures, mapping of textures to texture units, shader management, shader generation from chunks of shader code, effect management, etc. could be made much simpler and more user-friendly. But as I said, I don't think it's OSG's job to do this. OSG provides a framework, and this is a bit too domain-specific IMHO. But it's a pretty large discussion that's bound to have widely different opinions from different people... I have no authority on OSG (other than sending submissions to suggest new directions) so I would be interested in Robert's opinion on the matter. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi J-S, No, they won't be solid. As they are not solid in for trees drawn in island scene. But you have to use alpha ref. On the other hand if your transparency does not use alpha ref and sets Z-values it will still be solid even if color buffer would end transparent. Alpha ref? What's that? (I'm showing my ignorance, but all I know is that our objects just have textures with alpha=0 for some texels - I don't know anything about alpha ref) Sorry for being imprecise. By alpha ref I meant using osg::AlphaFunc to discard pixels with alpha lower or equal to reference value. I think that OpenGL default is 0.0. So I must admit I don't exactly understand why turning blending may change depth values in shadow map. Maybe its not blending but override on rendering bins ? I use only one bin to render shadow map - is this the reason of your problems ? It's true that I was oversimplifying. I always put blending and renderbin settings in the same bucket as normally they're used together... You're absolutely right, it's the renderbin override that causes the shadows of my chain link fences (and other objects with textures having some texels alpha=0) to be totally opaque. So coming back to what you said above, what would be the right solution? Is there a way to fix our models so that I don't have to comment out the renderbin override in StandardShadowMap.cpp? Otherwise, I'd submit a setter/getter control for that particular setting. It's necessary in our situation. I see. Maybe AlphaFunc is selectively turned on by Transparent bins and turned off by Opaque bins and maybe thats why you see the difference when your StateSets do not have AlphaFunc set explicitly. I must admit that we usually set AlphaFunc in our datasbases thts probably the reason I have not noticed this problem yet. Ok, now I think I understand - I will submit fix for this case or if You prefer you may do it. Basically we would want to add setter and getter for the flag which will turn off render bin override, right ? Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi Wojtek, Ok, now I think I understand - I will submit fix for this case or if You prefer you may do it. Basically we would want to add setter and getter for the flag which will turn off render bin override, right ? Hmmm... I added an osg::AlphaFunc with comparison GL_GREATER 0.0 to the root of my scene graph, and it works well. So if this is the expected behavior, perhaps the ShadowedScene could have this osg::AlphaFunc by default? shadowedScene-getOrCreateStateSet()-setAttributeAndModes( new osg::AlphaFunc(osg::AlphaFunc::GREATER, 0.0), osg::StateAttribute::ON); Just hypothetically, for the same end result, what would be faster: A) overriding the renderbins and using an AlphaFunc B) disabling the override on the renderbin (I suspect A, but I'm not that familiar with AlphaFunc) I think it's expected that objects with textures which have texels at alpha=0.0 will have holes in their shadows. So we should either document this clearly, or set it by default, as it wasn't at all obvious to me, at least. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi Robert, J-S,
Attached are proposed fixes to supress overly aggressive optimizations in
StandardShadowMap rendering. I added ShadowMapRenderingSettings enum and
setShadowMapRenderingSettings / getShadowMapRenderingSettings methods to
provide mechanism for similar tweaks in the future.
J-S please look at this and add/adapt to your needs.
Cheers,
Wojtek
Hi J-S,
No, they won't be solid. As they are not solid in for trees drawn in
island scene. But you have to use alpha ref. On the other hand if your
transparency does not use alpha ref and sets Z-values it will still be
solid even if color buffer would end transparent.
Alpha ref? What's that? (I'm showing my ignorance, but all I know is that
our objects just have textures with alpha=0 for some texels - I don't
know anything about alpha ref)
Sorry for being imprecise. By alpha ref I meant using osg::AlphaFunc to
discard pixels with alpha lower or equal to reference value. I think that
OpenGL default is 0.0.
So I must admit I don't exactly understand why turning blending may
change depth values in shadow map. Maybe its not blending but override
on rendering bins ? I use only one bin to render shadow map - is this
the reason of your problems ?
It's true that I was oversimplifying. I always put blending and renderbin
settings in the same bucket as normally they're used together... You're
absolutely right, it's the renderbin override that causes the shadows of
my chain link fences (and other objects with textures having some texels
alpha=0) to be totally opaque.
So coming back to what you said above, what would be the right solution?
Is there a way to fix our models so that I don't have to comment out the
renderbin override in StandardShadowMap.cpp?
Otherwise, I'd submit a setter/getter control for that particular
setting. It's necessary in our situation.
I see. Maybe AlphaFunc is selectively turned on by Transparent bins and
turned off by Opaque bins and maybe thats why you see the difference when
your StateSets do not have AlphaFunc set explicitly. I must admit that we
usually set AlphaFunc in our datasbases thts probably the reason I have
not noticed this problem yet.
Ok, now I think I understand - I will submit fix for this case or if You
prefer you may do it. Basically we would want to add setter and getter for
the flag which will turn off render bin override, right ?
Cheers,
Wojtek
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
StandardShadowMap
Description: Binary data
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*
* ViewDependentShadow codes Copyright (C) 2008 Wojciech Lewandowski
* Thanks to to my company http://www.ai.com.pl for allowing me free this work.
*/
#include osgShadow/StandardShadowMap
#include osg/PolygonOffset
#include osg/ComputeBoundsVisitor
#include osgShadow/ShadowedScene
#include osg/Geode
#include osg/Geometry
#include osg/CullFace
#include osg/Point
#include osg/AlphaFunc
#include sstream
using namespace osgShadow;
#define DISPLAY_SHADOW_TEXEL_TO_PIXEL_ERROR 0
StandardShadowMap::StandardShadowMap():
BaseClass(),
_polygonOffsetFactor( 1.1f ),
_polygonOffsetUnits( 4.0f ),
_textureSize( 1024, 1024 ),
_baseTextureUnit( 0 ),
_shadowTextureUnit( 1 ),
_baseTextureCoordIndex( 0 ),
_shadowTextureCoordIndex( 1 ),
_shadowMapRenderingSettings( DEFAULT_SHADOW_MAP_RENDERING_SETTINGS )
{
_mainFragmentShader = new osg::Shader( osg::Shader::FRAGMENT,
// following expressions are auto modified - do not change them:
\n
// gl_TexCoord[0] 0 - can be subsituted with other index
\n
\n
float DynamicShadow( );
\n
\n
varying vec4 colorAmbientEmissive;
\n
\n
uniform sampler2D baseTexture;
\n
\n
void main(void)
Re: [osg-users] Advice on interacting with osgShadow
Hi J-S, I have sent proposed tweaks for submission. I think your observations prove that AlphaFunc is activated by Transparent bin. IMHO safest way with dealing with AlphaFunc/AlphaTest is to activate it explicitly as a node state attribute whenever BLEND is activated or TransparentBin is selected through RenderingBin hint. That way its always on when needed and we are not on mercy of default state sets ;-) I think that submission I have sent is still worth adding. I made my change slightly more general so that it may be easily extended to suppress other controversial optimizations when needed. Cheers, Wojtek Hi Wojtek, Ok, now I think I understand - I will submit fix for this case or if You prefer you may do it. Basically we would want to add setter and getter for the flag which will turn off render bin override, right ? Hmmm... I added an osg::AlphaFunc with comparison GL_GREATER 0.0 to the root of my scene graph, and it works well. So if this is the expected behavior, perhaps the ShadowedScene could have this osg::AlphaFunc by default? shadowedScene-getOrCreateStateSet()-setAttributeAndModes( new osg::AlphaFunc(osg::AlphaFunc::GREATER, 0.0), osg::StateAttribute::ON); Just hypothetically, for the same end result, what would be faster: A) overriding the renderbins and using an AlphaFunc B) disabling the override on the renderbin (I suspect A, but I'm not that familiar with AlphaFunc) I think it's expected that objects with textures which have texels at alpha=0.0 will have holes in their shadows. So we should either document this clearly, or set it by default, as it wasn't at all obvious to me, at least. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi Wojtek, J-S please look at this and add/adapt to your needs. Looks good and extensible too. Works fine as I expected. However, I've confirmed that disabling the renderbin override is not necessary if I put an AlphaFunc on my root node, so I'd also be happy with the status quo if no one needs this added configurability... See my other message in this thread. It might even be confusing to have two ways to accomplish the same thing, one of which may or may not be faster than the other... What do you think? J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi Wojtek, I think your observations prove that AlphaFunc is activated by Transparent bin. IMHO safest way with dealing with AlphaFunc/AlphaTest is to activate it explicitly as a node state attribute whenever BLEND is activated or TransparentBin is selected through RenderingBin hint. That way its always on when needed and we are not on mercy of default state sets ;-) Sure. I can always run a visitor on any loaded models, check if there's BLEND or TransparentBin settings anywhere, and then add AlphaFunc there too (since they aren't in our source models). I think that submission I have sent is still worth adding. I made my change slightly more general so that it may be easily extended to suppress other controversial optimizations when needed. I agree. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi J-S, It looks like we are in sort of counter-phase.You convinced me to your arguments in the same time as I convinced you to mine ;-) However, I've confirmed that disabling the renderbin override is not necessary if I put an AlphaFunc on my root node, so I'd also be happy with the status quo if no one needs this added configurability... See my other message in this thread. It might even be confusing to have two ways to accomplish the same thing, one of which may or may not be faster than the other... What do you think? I suppose that single overriden render bin with AlphaFunc/AlphaTest turned only when needed should be faster in theory. Other options turn AlphaFunce even when not needed. But in practice I doubt difference will be noticable. Even though you managed to activate AlphaFunc, I agree with you that forcing one render bin may possibly bring some unexpected trouble. Its hard to come up with exact scenario where it will fail, but I have the feeling that render bin various sorting modes and renderbin prototype extension mechanism may be at risk with such override. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hello Wojtek, I suppose that single overriden render bin with AlphaFunc/AlphaTest turned only when needed should be faster in theory. Other options turn AlphaFunce even when not needed. But in practice I doubt difference will be noticable. Even though you managed to activate AlphaFunc, I agree with you that forcing one render bin may possibly bring some unexpected trouble. Its hard to come up with exact scenario where it will fail, but I have the feeling that render bin various sorting modes and renderbin prototype extension mechanism may be at risk with such override. Err, ok, so what is the conclusion? What would you prefer to do? Remove the renderbin override (or set it to disabled by default in the options bitmask)? From my point of view, I'm just interested in the results. Both solutions give good results visually, and the performance difference seems to be very small (perhaps unmeasurable in my scene/application). So whatever you decide is fine by me. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
J-S, I suppose that single overriden render bin with AlphaFunc/AlphaTest turned only when needed should be faster in theory. Other options turn AlphaFunce even when not needed. But in practice I doubt difference will be noticable. Even though you managed to activate AlphaFunc, I agree with you that forcing one render bin may possibly bring some unexpected trouble. Its hard to come up with exact scenario where it will fail, but I have the feeling that render bin various sorting modes and renderbin prototype extension mechanism may be at risk with such override. Err, ok, so what is the conclusion? What would you prefer to do? Remove the renderbin override (or set it to disabled by default in the options bitmask)? Turning on AlphaTest/AlphaFunc is not mutually exclusive with RenderBin override. I don't want to make decision that has to be its either this or that. I would like to leave RenderBin override as default. I would also add setShadowMapRenderingSettings/getShadowMapRenderingSettings methods to allow user turn it off if he decides. So my conclusion is I would like to add the submission as sent to the codebase. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
Hi Wojtek, Turning on AlphaTest/AlphaFunc is not mutually exclusive with RenderBin override. I don't want to make decision that has to be its either this or that. I would like to leave RenderBin override as default. I would also add setShadowMapRenderingSettings/getShadowMapRenderingSettings methods to allow user turn it off if he decides. So my conclusion is I would like to add the submission as sent to the codebase. Excellent, I agree with this. I tested your code and it works for me, so you can send it to osg-submissions whenever you want. I could suggest that instead of using OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1, SET_COLOR_MASK_TO_FALSE = 2, you use the bit shift notation, which I find easier to read and maintain (and please align the values... :-) ): OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1 0, SET_COLOR_MASK_TO_FALSE = 1 1, SOME_OTHER_SETTING = 1 2, but that's just a style issue and subject to personal taste. Also you could add a doxygen comment for the ShadowMapRenderingSettings enum, which would explain what the values are useful for. Otherwise, it's pretty cryptic for users (unless they search the mailing lists and find this thread :-) ). J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Advice on interacting with osgShadow
J-S, I agree. I will make proposed changes and resubmit. I will do it tomorrow. Cheers, Wojtek -Original Message- From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2008 10:21 PM To: [EMAIL PROTECTED]; OpenSceneGraph Users Subject: Re: [osg-users] Advice on interacting with osgShadow Hi Wojtek, Turning on AlphaTest/AlphaFunc is not mutually exclusive with RenderBin override. I don't want to make decision that has to be its either this or that. I would like to leave RenderBin override as default. I would also add setShadowMapRenderingSettings/getShadowMapRenderingSettings methods to allow user turn it off if he decides. So my conclusion is I would like to add the submission as sent to the codebase. Excellent, I agree with this. I tested your code and it works for me, so you can send it to osg-submissions whenever you want. I could suggest that instead of using OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1, SET_COLOR_MASK_TO_FALSE = 2, you use the bit shift notation, which I find easier to read and maintain (and please align the values... :-) ): OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1 0, SET_COLOR_MASK_TO_FALSE = 1 1, SOME_OTHER_SETTING = 1 2, but that's just a style issue and subject to personal taste. Also you could add a doxygen comment for the ShadowMapRenderingSettings enum, which would explain what the values are useful for. Otherwise, it's pretty cryptic for users (unless they search the mailing lists and find this thread :-) ). J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
