Re: [osg-users] osgShadow 3.6.3
Hi Catalin, None of the osgShadow technique support shadows that surround a point light source as you have in your scene. This limitation is due the way that projective texturing is used for the shadow map, essentially you are limited to FOV from the light source to less than 180. The only way to remove this limitation is to use multiple shadow maps, such as using a cube map for the shadow map. None of the osgShadow techniques support this though so you'd need to implement this yourself. The osgShadow shadow techniques are also limited to a single light source, to enable support for a number of light sources you have to built a separate shadow map for each light source. For you application I would suggest handling spot lights with a single shadow map, and point lights that are within the volume as a cubemap, if you have directional lights then potentially you could use a single shadow map, though it's likely you'd want to make the the shadow map view dependent to avoid under sampling when you zoom into local areas. I'm afraid general purpose shadowing is hard, it's a huge topic, it won't be just a case of tweaking bits of an existing implementation. Cheers, Robert. -- You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/85c74239-037c-497b-9fe2-cb1285f1bf18%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and gl3
HI Werner, In the stable releases rhere isn't any built in support for remapping built in types like osg::TexGen that set the gl_EyePlane etc. attributes to osg_EyePlane uniforms. I have an experimental branch, shader_pipeline, that has the beginnings of a mapping to do this but it's not yet ready for general testing. For yourself, if you can build the OSG without specifically limiting yourself to GL core profile then you'll get a better experience. The exception right now is OSX because Apple have taken the approach of not implementation any modern GL features, and even GL3 they've limited to a subset of only the GL3 core profile, no backwards compatibility is provided. OSX doesn't support GL4 yet, and no signs of Vulkan support so it kinda looks like Apple are happy to relegate OSX boxes to graphics backwater. Robert. Robert. On 24 February 2017 at 14:52, Werner Modenbachwrote: > Hi all, > > my project needs gl3 features and so I use the following methods: > > camera->getGraphicsContext()->getState()->setUseModelViewAndProjectionUniforms(useGL3); > camera->getGraphicsContext()->getState()->setUseVertexAttributeAliasing(useGL3); > > Of course I need my own shaders then. > I'm trying to make osgShadow working with my project. > So far I have found the shader codes in StandardShadowMap and I try merging > the functionality with my own shaders. > Where I'm struggling is the gl_EyePlane[STRQ] stuff. It seems that is not > made available as osg_EyePlane[STRQ] like other > gl_ variables. Am I right? Is there any known way to get this working? > > Also there are cameras used inside shadowmaps. Those cameras have their own > shaders (?) which are not gl3 conformant. > Can this be influenced from my application? > > Thanks for any hints. > > - Werner - > > ___ > 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 with GLES
Hi Pierre-Jean, I was also doing some research in that. I think the shader you adopted is not the only place where shaders have to be given. I found some place with comments like "I don't use my shader because the fixed function shaders have better performance". This is just how I remember the comment - so not exactly reproduced. To be honest the research was consuming to much of my time. But it would be really great if share your solution if you manage to solve this. - Werner - Am 04.07.2016 um 17:48 schrieb Pierre-Jean Petitprez: Hi, I would like to use the osgShadow soft shadow map on an Android device (with GLES 2). I have already written my own Phong shader for my objects which works very well. Now I would like to add the shadow map. I have taken the shader code from the SoftShadowMap.cpp file and I have adapted it to add it in my own shader. But this does not seem to work, the applied shadow map is always fully white. Maybe this has to do with the texture coordinates that are used. Can someone enlighten me on using osgShadow with GLES 2 ? Thank you! Cheers, Pierre-Jean -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67987#67987 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- *TEXION Software Solutions, Rotter Bruch 26a, D-52068 Aachen* Phone: +49 241 475757-0 Fax: +49 241 475757-29 Web: http://texion.eu eMail: i...@texion.eu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow::MinimalShadowMap::ViewData::computeScenePolytopeBounds ... causes crash on Mac, fix proposed
Hi Robert, tested on OS X and works fine. Thanks ! Nick On Tue, Apr 28, 2015 at 6:01 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Nick, The code looks pretty dodgy so I'm not surprised it crashes, just that surprised we hadn't spotted it sooner. A better solution is to have two methods, one that takes a matrix and one takes no parameters. I have implemented this and checked it into svn/trunk. Could you test it out under OSX for me? Cheers, Robert On 28 April 2015 at 16:25, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Robert, as is defined like: osg::BoundingBox computeScenePolytopeBounds( const osg::Matrix m = *(osg::Matrix*)(NULL)); when using it without passing a matrix it causes crash with g++ on OS X (Windows and Linux are fine). Here is the proposed fix osg::BoundingBox computeScenePolytopeBounds( const osg::Matrix m = osg::Matrix::identity() ); In the implementation it wont matter since when the matrix reference is not NULL reference is multiplying vertices with it What do you think? Nick -- trajce nikolov nick ___ 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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow::MinimalShadowMap::ViewData::computeScenePolytopeBounds ... causes crash on Mac, fix proposed
On 29 April 2015 at 07:04, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Robert, tested on OS X and works fine. Thanks ! Good to hear, thanks for the testing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow::MinimalShadowMap::ViewData::computeScenePolytopeBounds ... causes crash on Mac, fix proposed
Hi Nick, The code looks pretty dodgy so I'm not surprised it crashes, just that surprised we hadn't spotted it sooner. A better solution is to have two methods, one that takes a matrix and one takes no parameters. I have implemented this and checked it into svn/trunk. Could you test it out under OSX for me? Cheers, Robert On 28 April 2015 at 16:25, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi Robert, as is defined like: osg::BoundingBox computeScenePolytopeBounds( const osg::Matrix m = *(osg::Matrix*)(NULL)); when using it without passing a matrix it causes crash with g++ on OS X (Windows and Linux are fine). Here is the proposed fix osg::BoundingBox computeScenePolytopeBounds( const osg::Matrix m = osg::Matrix::identity() ); In the implementation it wont matter since when the matrix reference is not NULL reference is multiplying vertices with it What do you think? Nick -- trajce nikolov nick ___ 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 multitexturing
Hi, all How i can apply shadow texture for object's native state? I don't want modify osg's sources (native shaders). I implement shader for multitexture terrain + grass and other objects, and i want get shadow map and bind it to my shaders. Now i implement like this: Code: class TestDrawCallback: public osg::Drawable::DrawCallback { public: TestDrawCallback() { isFirst = true; } virtual void drawImplementation(osg::RenderInfo renderInfo,const osg::Drawable* drawable) const { osg::State* state = renderInfo.getState(); const osg::StateSet* stateset = state-getStateSetStack().back(); osg::StateSet* ownStateSet = const_castosg::StateSet*(drawable-getStateSet()); osg::Texture2D* tex = const_castosg::Texture2D*(dynamic_castconst osg::Texture2D*(stateset-getTextureAttribute(1, osg::StateAttribute::TEXTURE))); if(tex) { if(isFirst) { ownStateSet-setTextureAttributeAndModes(2, tex, osg::StateAttribute::ON); isFirst = false; } state-pushStateSet(ownStateSet); state-applyTextureAttribute(2, tex); drawable-drawImplementation(renderInfo); state-popStateSet(); }else { drawable-drawImplementation(renderInfo); } } private: mutable bool isFirst; }; I tested this texture map as base texture. The object which I rendered was white, that is, texture is not passed on or something like that. I Thank you! e Cheers, Sedov[/code] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47881#47881 ___ 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] osgShadow PSSM light source issue
I noticed this problem as well. To fix this I modified PSSM to use the same code as the selectLight() method in StandardShadowMap. However osgShadow's PSSM implementation has a lot of other quirks as well... On 3/23/2012 5:47 AM, Daniel Schmid wrote: I have an issue with PSSM. The light source in my scene is not taken into account properly (sun). It calculates shadows like if sun as in perfect orbit. All other shadow implementations work correctly, and changes in light position are calculated correctly, but PSSM is stuck somehow. Does anybody know this problem ? Regards Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow private members of PSSM
Hi Daniel, I would recommend using over ViewDependentShadowMap over ParallelSplitShadowMap, this does mean use a recent dev release rather than a stable release but the new shadow technique can do parallel splits shadow maps as well as perspective shadow maps and make it easy to switch/between or combine them. It also performs much better. Robert. On 28 March 2012 14:26, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: Hi there Is there a reason why in ParallelSplitShadowMap, lots of the interesting members are private? I would like to derive my own PSSM, and implement multitexturing, but for this I do not have access to _textureUnitOffset, which is a private member and does’t even have a setter method… Regards Daniel ___ 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 PSSM
Hi Daniel, Currently I'm working on the ViewDependentShadowMap and has already added an initial implementation of PSSM and VSM. I'm using it with my digital city project which must have huge scenes and multi-threaded rendering features. I'd like to submit the changes some time later. :-) Wang Rui 2012/3/23 Daniel Schmid daniel.sch...@swiss-simtec.ch Hi there ** ** Obviously PSSM is good for huge scenes (my case), but the wrong choice for multi threaded rendering. Is there a attempt to make PSSM multithreaded, does anybody have modified it, or what would be the way to go ? ** ** Regards Daniel ** ** ** ** ___ 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 PSSM
So you are mixing PSSM and VSM? Sounds interesting. If you have any sample code I could have a look at, I would appreciate... Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Wang Rui Gesendet: Freitag, 23. März 2012 09:29 An: OpenSceneGraph Users Betreff: Re: [osg-users] osgShadow PSSM Hi Daniel, Currently I'm working on the ViewDependentShadowMap and has already added an initial implementation of PSSM and VSM. I'm using it with my digital city project which must have huge scenes and multi-threaded rendering features. I'd like to submit the changes some time later. :-) Wang Rui 2012/3/23 Daniel Schmid daniel.sch...@swiss-simtec.chmailto:daniel.sch...@swiss-simtec.ch Hi there Obviously PSSM is good for huge scenes (my case), but the wrong choice for multi threaded rendering. Is there a attempt to make PSSM multithreaded, does anybody have modified it, or what would be the way to go ? Regards Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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 PSSM
I would submit the code this weekend and everyone can have a look at it and make changes to make it better (at present I'm still not satisfied with my own implementation). Wang Rui 2012/3/23 Daniel Schmid daniel.sch...@swiss-simtec.ch So you are mixing PSSM and VSM? Sounds interesting. If you have any sample code I could have a look at, I would appreciate… ** ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow PSSM
Looking forward! Thanks! Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Wang Rui Gesendet: Freitag, 23. März 2012 09:41 An: OpenSceneGraph Users Betreff: Re: [osg-users] osgShadow PSSM I would submit the code this weekend and everyone can have a look at it and make changes to make it better (at present I'm still not satisfied with my own implementation). Wang Rui 2012/3/23 Daniel Schmid daniel.sch...@swiss-simtec.chmailto:daniel.sch...@swiss-simtec.ch So you are mixing PSSM and VSM? Sounds interesting. If you have any sample code I could have a look at, I would appreciate... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow culling faces
Hi, Danielyou can set correct osg::CullFace attribute to stateset of graph branches where you need it Cheers, Sergey23.03.2012, 17:10, "Daniel Schmid" daniel.sch...@swiss-simtec.ch:Hi there I have some objects whose shadow looks ugly when the front faces are culled. For those objects, I would like to have front and back faces taken into account for shadow rendering, for others I can go with backfaces. Unfortunately, the face fulling is a property of the camera. How can I handle it on a per node basis ? RegardsDaniel ___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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 multitexture
Hi Daneil, All the shadow mapping techniques AFAIR support multitexturing. You will have to provide you custom vertex and fragment shader however. Also you should set the texture unit/texture coordinates for the shadow to texture-count + 1. Just look into the sources, there are the vertex/fragment shaders you'll need to modify. I can agree that there currently is no homogeneous way to setup shaders for all the techniques, but it can be done. For the vertex shader, you will have to assign something the eye-space coordinates to the texture unit. For shadow mapping it more or less boils down to: gl_MultiTexCoord[n].s = dot(gl_EyePlaneS[n] * gl_Vertex); gl_MultiTexCoord[n].t = dot(gl_EyePlaneT[n] * gl_Vertex); gl_MultiTexCoord[n].p = dot(gl_EyePlaneP[n] * gl_Vertex); gl_MultiTexCoord[n].q = dot(gl_EyePlaneQ[n] * gl_Vertex); The fragment shader you can get from the sources. cheers Sebastian Hi Robert Thanks for your answer. I was hoping all osgShadow techniques support multi-texturing... but in my application, i tried every single one, and I only have strange effects. What happens basically is the following: I can manage to have a shadow with standardshadowmap, and all the view based techniques, by selecting the base texture unit as 0 and the shadow texture unit between 1 and 4. What happens then is that the according texture level of my model is replaced with my shadow texture and the texture coordinates of this level get mixed up, like i have other textures moving when rotating my viewport. So I thought, probably these levels are already occupied by my scene model, so I have to use a value above 4, but then I have no more shadow displayed at all. I'm sure I'm missing somehow an important point about the way base texture and shadow texture units must have been supposed to use. But after some days of try and error, I cannot figure how I can have osg create a shadow without removing my textures or messing with a textures layer coordinate... I'm really stuck... help appreciated. There are not really any tutorials out there explaining the use of osgShadow... Regards Daniel ___ 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 multitexture
I have a hard time understanding that the osgShadow implementations should support multitexturing when they never mix the colors oft he different texture units... Ok, I'm not yet that settled in glsl maybe there is some magic working behind, which I do not understand. I'm having a closer look right now into StandardShadowMap. There is only the base texture rendered (which I can define by setter method), plus the shadow texture. The other textures are ignored. When I want to use multiple texture layers, I ALWAYS have to write my own shaders. Is this correct ? Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Sebastian Messerschmidt Gesendet: Dienstag, 20. März 2012 08:18 An: OpenSceneGraph Users Betreff: Re: [osg-users] osgShadow and multitexture Hi Daneil, All the shadow mapping techniques AFAIR support multitexturing. You will have to provide you custom vertex and fragment shader however. Also you should set the texture unit/texture coordinates for the shadow to texture-count + 1. Just look into the sources, there are the vertex/fragment shaders you'll need to modify. I can agree that there currently is no homogeneous way to setup shaders for all the techniques, but it can be done. For the vertex shader, you will have to assign something the eye-space coordinates to the texture unit. For shadow mapping it more or less boils down to: gl_MultiTexCoord[n].s = dot(gl_EyePlaneS[n] * gl_Vertex); gl_MultiTexCoord[n].t = dot(gl_EyePlaneT[n] * gl_Vertex); gl_MultiTexCoord[n].p = dot(gl_EyePlaneP[n] * gl_Vertex); gl_MultiTexCoord[n].q = dot(gl_EyePlaneQ[n] * gl_Vertex); The fragment shader you can get from the sources. cheers Sebastian Hi Robert Thanks for your answer. I was hoping all osgShadow techniques support multi-texturing... but in my application, i tried every single one, and I only have strange effects. What happens basically is the following: I can manage to have a shadow with standardshadowmap, and all the view based techniques, by selecting the base texture unit as 0 and the shadow texture unit between 1 and 4. What happens then is that the according texture level of my model is replaced with my shadow texture and the texture coordinates of this level get mixed up, like i have other textures moving when rotating my viewport. So I thought, probably these levels are already occupied by my scene model, so I have to use a value above 4, but then I have no more shadow displayed at all. I'm sure I'm missing somehow an important point about the way base texture and shadow texture units must have been supposed to use. But after some days of try and error, I cannot figure how I can have osg create a shadow without removing my textures or messing with a textures layer coordinate... I'm really stuck... help appreciated. There are not really any tutorials out there explaining the use of osgShadow... Regards Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto: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 multitexture
Am 20.03.2012 09:26, schrieb Daniel Schmid: I have a hard time understanding that the osgShadow implementations should support multitexturing when they never mix the colors oft he different texture units... Ok, I'm not yet that settled in glsl maybe there is some magic working behind, which I do not understand. I'm having a closer look right now into StandardShadowMap. There is only the base texture rendered (which I can define by setter method), plus the shadow texture. The other textures are ignored. When I want to use multiple texture layers, I ALWAYS have to write my own shaders. Is this correct ? This is correct, also the current implementation doesn't support fog, as you requested in your first posting. *Von:*osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] *Im Auftrag von *Sebastian Messerschmidt *Gesendet:* Dienstag, 20. März 2012 08:18 *An:* OpenSceneGraph Users *Betreff:* Re: [osg-users] osgShadow and multitexture Hi Daneil, All the shadow mapping techniques AFAIR support multitexturing. You will have to provide you custom vertex and fragment shader however. Also you should set the texture unit/texture coordinates for the shadow to texture-count + 1. Just look into the sources, there are the vertex/fragment shaders you'll need to modify. I can agree that there currently is no homogeneous way to setup shaders for all the techniques, but it can be done. For the vertex shader, you will have to assign something the eye-space coordinates to the texture unit. For shadow mapping it more or less boils down to: gl_MultiTexCoord[n].s = dot(gl_EyePlaneS[n] * gl_Vertex); gl_MultiTexCoord[n].t = dot(gl_EyePlaneT[n] * gl_Vertex); gl_MultiTexCoord[n].p = dot(gl_EyePlaneP[n] * gl_Vertex); gl_MultiTexCoord[n].q = dot(gl_EyePlaneQ[n] * gl_Vertex); The fragment shader you can get from the sources. cheers Sebastian Hi Robert Thanks for your answer. I was hoping all osgShadow techniques support multi-texturing... but in my application, i tried every single one, and I only have strange effects. What happens basically is the following: I can manage to have a shadow with standardshadowmap, and all the view based techniques, by selecting the base texture unit as 0 and the shadow texture unit between 1 and 4. What happens then is that the according texture level of my model is replaced with my shadow texture and the texture coordinates of this level get mixed up, like i have other textures moving when rotating my viewport. So I thought, probably these levels are already occupied by my scene model, so I have to use a value above 4, but then I have no more shadow displayed at all. I'm sure I'm missing somehow an important point about the way base texture and shadow texture units must have been supposed to use. But after some days of try and error, I cannot figure how I can have osg create a shadow without removing my textures or messing with a textures layer coordinate... I'm really stuck... help appreciated. There are not really any tutorials out there explaining the use of osgShadow... Regards Daniel ___ 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 ___ 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 multitexture
Hi Daniel, On 20 March 2012 08:26, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: I have a hard time understanding that the osgShadow implementations should support multitexturing when they never mix the colors oft he different texture units… Ok, I’m not yet that settled in glsl maybe there is some magic working behind, which I do not understand. I’m having a closer look right now into StandardShadowMap. There is only the base texture rendered (which I can define by setter method), plus the shadow texture. The other textures are ignored. When I want to use multiple texture layers, I ALWAYS have to write my own shaders. Is this correct ? Since the fixed function pipeline can't do shadows natively you have to write your own shaders. I have plans to get shader composition for the OSG which would be able to replace the fixed function pipeline with shaders, but it'll be a while before I get the time to return to tackling this particular task. Once we have shader composition should be easier to support dropping provided more flexible shadow support, but shader composition is far from trivial, very much at the cutting edge of scene graphs. Until then you'll need to write your own shaders, but this is pretty standard practice these days, often developers will do everything with shaders. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and multitexture
There is a remaining question. In StandardShadowMap.cpp Lines 632 - 639 (osg 3.0.1) I find lines setting the texture mode for stage 1-4. Why is there a limitation to these 4 stages, and what are they doing? If my model uses 4 textures and the shadow should go on layer 5, could this be a problem? -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Dienstag, 20. März 2012 09:48 An: OpenSceneGraph Users Betreff: Re: [osg-users] osgShadow and multitexture Hi Daniel, On 20 March 2012 08:26, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: I have a hard time understanding that the osgShadow implementations should support multitexturing when they never mix the colors oft he different texture units. Ok, I'm not yet that settled in glsl maybe there is some magic working behind, which I do not understand. I'm having a closer look right now into StandardShadowMap. There is only the base texture rendered (which I can define by setter method), plus the shadow texture. The other textures are ignored. When I want to use multiple texture layers, I ALWAYS have to write my own shaders. Is this correct ? Since the fixed function pipeline can't do shadows natively you have to write your own shaders. I have plans to get shader composition for the OSG which would be able to replace the fixed function pipeline with shaders, but it'll be a while before I get the time to return to tackling this particular task. Once we have shader composition should be easier to support dropping provided more flexible shadow support, but shader composition is far from trivial, very much at the cutting edge of scene graphs. Until then you'll need to write your own shaders, but this is pretty standard practice these days, often developers will do everything with shaders. 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] osgShadow and multitexture
Hi, These lines limit the textures used for rendering shadow map. Basically there is no need to render the models with textures when we only render depth in shadow map. The only exception are textures which can contain alpha and then models will not render the parts with full transparency. So the lines there turn of all textures (maybe it should be exceeded to max number of stages available) except stage 0 where base texture with alpha is assumed to be. This should be no problem for models with more texture stages as long as you substitute shadow technique shaders with your own set which can process your multiple textures correctly. Cheers, Wojtek Lewandowski 2012/3/20 Daniel Schmid daniel.sch...@swiss-simtec.ch There is a remaining question. In StandardShadowMap.cpp Lines 632 - 639 (osg 3.0.1) I find lines setting the texture mode for stage 1-4. Why is there a limitation to these 4 stages, and what are they doing? If my model uses 4 textures and the shadow should go on layer 5, could this be a problem? -Ursprüngliche Nachricht- Von: osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert Osfield Gesendet: Dienstag, 20. März 2012 09:48 An: OpenSceneGraph Users Betreff: Re: [osg-users] osgShadow and multitexture Hi Daniel, On 20 March 2012 08:26, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: I have a hard time understanding that the osgShadow implementations should support multitexturing when they never mix the colors oft he different texture units. Ok, I'm not yet that settled in glsl maybe there is some magic working behind, which I do not understand. I'm having a closer look right now into StandardShadowMap. There is only the base texture rendered (which I can define by setter method), plus the shadow texture. The other textures are ignored. When I want to use multiple texture layers, I ALWAYS have to write my own shaders. Is this correct ? Since the fixed function pipeline can't do shadows natively you have to write your own shaders. I have plans to get shader composition for the OSG which would be able to replace the fixed function pipeline with shaders, but it'll be a while before I get the time to return to tackling this particular task. Once we have shader composition should be easier to support dropping provided more flexible shadow support, but shader composition is far from trivial, very much at the cutting edge of scene graphs. Until then you'll need to write your own shaders, but this is pretty standard practice these days, often developers will do everything with shaders. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and multitexture
Hi Wojtek, This should be no problem for models with more texture stages as long as you substitute shadow technique shaders with your own set which can process your multiple textures correctly. Almost correct - the problem is that the shadow technique also disable all shaders for the shadow pass. So even if the models / scene provide shaders which do multitexturing, the shadow pass will only alpha blend / alpha test with the texture in unit 0 when rendering the shadow pass. A shader could be set with OVERRIDE mode in the graph, and then (IIRC) it will be used during the shadow pass. I'd have to check the code again to confirm that the disabling is not done with PROTECTED mode... J-S -- __ Jean-Sebastien Guay jean_...@videotron.ca http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and multitexturing
Hi Daniel, All the osgShadow techniques can work with multi-texturing and it's certainly how I'd expect most users to use it. However, the built in shaders they provide can't handle all the types of effects you might want to use so you'll need to replace these with your own custom shaders. Robert. On 19 March 2012 14:40, Daniel Schmid daniel.sch...@swiss-simtec.ch wrote: Hi y’all I’m trying to implement shadow in my scene. My scene makes use of up to 4 texture levels in its models. I read in some comments that the lipsm and other shader based shadow techniques are not really made for multi texturing. Ist here anybody out there that made a custom shader that implements multitexturing and aswell fog functionality? Regards Daniel *** Daniel Schmid Swiss SIMTEC AG Frutigenstrasse 4 CH-3600 Thun Tel: +41 33 533 02 10 Fax: +41 33 533 02 01 Mail: daniel.sch...@swiss-simtec.ch URL: http://www.swiss-simtec.ch *** ___ 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 multitexture
Hi Robert Thanks for your answer. I was hoping all osgShadow techniques support multi-texturing... but in my application, i tried every single one, and I only have strange effects. What happens basically is the following: I can manage to have a shadow with standardshadowmap, and all the view based techniques, by selecting the base texture unit as 0 and the shadow texture unit between 1 and 4. What happens then is that the according texture level of my model is replaced with my shadow texture and the texture coordinates of this level get mixed up, like i have other textures moving when rotating my viewport. So I thought, probably these levels are already occupied by my scene model, so I have to use a value above 4, but then I have no more shadow displayed at all. I'm sure I'm missing somehow an important point about the way base texture and shadow texture units must have been supposed to use. But after some days of try and error, I cannot figure how I can have osg create a shadow without removing my textures or messing with a textures layer coordinate... I'm really stuck... help appreciated. There are not really any tutorials out there explaining the use of osgShadow... Regards Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow compile problem with OSG 2.7.8
On Tue, Sep 6, 2011 at 12:48 AM, Patrick J Neary patrick.ne...@ngc.com wrote: Do you have an issue with adding the friend declaration to support the older compilers? It all depends upon whether there is any risk of such a change breaking the build on other compilers. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow compile problem with OSG 2.7.8
On Sun, Sep 4, 2011 at 12:48 PM, Patrick J Neary patrick.ne...@ngc.com wrote: Paul, This problem still exists in 3.0.0 too. I was able to fix the problem under GCC 3.4.4 by adding the following friend to ViewDependentShadowTechnique: template class, class friend class ProjectionShadowMap; Robert, do you see any problem with this? Do I see any compile problem, or a problem with adding something extra to ViewDependentShadowTechnique to get it compile on old compilers? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow compile problem with OSG 2.7.8
robertosfield wrote: Do I see any compile problem, or a problem with adding something extra to ViewDependentShadowTechnique to get it compile on old compilers? Robert. Robert, Do you have an issue with adding the friend declaration to support the older compilers? --Patrick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42434#42434 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow compile problem with OSG 2.7.8
Paul, This problem still exists in 3.0.0 too. I was able to fix the problem under GCC 3.4.4 by adding the following friend to ViewDependentShadowTechnique: template class, class friend class ProjectionShadowMap; Robert, do you see any problem with this? Thanks, --Patrick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42405#42405 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
On 5/16/2011 12:55 PM, Paul Martz wrote: So I always recommended using Slaves cameras instead of Nested cams because they have their own CullVisitors. If I would design this today, instead of CullVisitor I would probably use RenderStage to index view resources. Understood. This is ViewerBase::RenderingTraversals, where it calls renderer-cull(). That's implemented internally with SceneView::cull(). Wojtek, in your experience, have you found that using multiple slave Cameras in this way causes StandardShadowMap (for example) to do a shadow map creation pass once for each slave Camera? There are multiple shadow map creation render passes done per frame, in other words. It seems like slave Cameras are really designed more for multiple displays, in which case you *do* want a shadow map created for each slave camera (so that it's generated and resident on the per-display GPU). But if the application uses slave Cameras rendering to a single window, the shadow map would still get generated multiple times per frame -- once per slave Camera -- which is undesirable. It seems like what we really want for shadow map creation is something that creates the shadow map once per frame#/GC pair. As far as I can tell, merely using slave Cameras doesn't achieve this. If I'm wrong about how StandardShadowMap works in the presence of multiple slave Cameras, please correct me. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
Hi, On 5/16/2011 12:55 PM, Paul Martz wrote: So I always recommended using Slaves cameras instead of Nested cams because they have their own CullVisitors. If I would design this today, instead of CullVisitor I would probably use RenderStage to index view resources. Understood. This is ViewerBase::RenderingTraversals, where it calls renderer-cull(). That's implemented internally with SceneView::cull(). Wojtek, in your experience, have you found that using multiple slave Cameras in this way causes StandardShadowMap (for example) to do a shadow map creation pass once for each slave Camera? There are multiple shadow map creation render passes done per frame, in other words. Yes. It does. However StandardShadowMap is not intended for wide use in practice. This class is a direct equivalent of ShadowMap. It is fully functional, so can be used as a replacement of ShadowMap, but its main role is to lay foundation for View Dependent Shadow Techniques derived from it. It seems like slave Cameras are really designed more for multiple displays, in which case you *do* want a shadow map created for each slave camera (so that it's generated and resident on the per-display GPU). But if the application uses slave Cameras rendering to a single window, the shadow map would still get generated multiple times per frame -- once per slave Camera -- which is undesirable. And thats the goal for View Dependent techniques which optimize shadow map resolution by adjusting shadow projection to part of the scene visible per view. So each view will need a different shadow map. These classes were designed to work in multi screen / multi threaded configurations. But they would also work for RTT Slave cameras. It seems like what we really want for shadow map creation is something that creates the shadow map once per frame#/GC pair. As far as I can tell, merely using slave Cameras doesn't achieve this. If I'm wrong about how StandardShadowMap works in the presence of multiple slave Cameras, please correct me. In case of MinimalShadowMap or LispSM techniques even if views share GC there is an assumption they use different view/projection matrices so Shadow maps for each of them should be created anyway. Cheers, Wojtek ___ 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 nested RTT-cams
Hi Paul, What I know for certain is this: all shadow techniques stemming from ViewDependentShadowTechnique (StandardShadowMap, MinimalShadowMap, LispSM) are not compatible with nested cameras. And its a design flaw. Basically all these techniques allocate resources per View and views are recognized and indexed by cull visitor pointer. Unfortunately cull visitor of the view main camera also traverses nested cameras, so this means these nested cameras will use the same resources as main view camera. Since the shadow map depends on the camera view/projection, obiously shadowmaps, projection and texgen settings will not work correctly for nested cams. So I always recommended using Slaves cameras instead of Nested cams because they have their own CullVisitors. If I would design this today, instead of CullVisitor I would probably use RenderStage to index view resources. I am however, not sure if I agree with your diagnosis on basic ShadowMap problem. Even if shadow map was rendered only once it should work well for both main and nested camera. Thats because ShadowMap projection does not depend on parent camera view or projection. Instead I suspect that shadow tex coord Texgen may be the problem. This is the only view dependent resouce here. Shadow texgen produces EYE_LINEAR coords. These coords depend on current model view matrix. I guess in Felix case main camera view matrix differs from nested camera view matrix. So texgen working for the main cam, does not produce correct coords for nested camera. These however are only theoretical deliberations. I have never tested or debuged such problem in practice, and I may be wrong. Cheers, Wojtek -Oryginalna wiadomość- From: Paul Martz Sent: Friday, May 13, 2011 11:55 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgShadow and nested RTT-cams Hi all -- While digging into an issue with multiple nested Camera nodes in 2.8.x, I came across this old thread in the archives and wanted to follow up, as it appears no one ever solved the mystery. I imagine there is more up-to-date information, or possibly even fixes on trunk? If so, please let me know. Camera nodes have a 1-to-1 mapping with RenderStage objects, and the first thing that happens in RenderStage::draw() is a check to ensure that the RenderStage only draws once per frame. (This is necessary because the RenderStage is inserted twice into the render graph: Once as a pre-render RenderStage, then once again as a regular child of the top-level Camera.) See RenderStage.cpp line 1109 on trunk. That's almost always what you want, except in Felix's case (see quoted text). In his situation, he has a scene that uses osgShadow (which uses a child Camera to implement the pre-render pass). Because a RenderStage can only draw once per frame, there is no way to render an osgShadow scene twice per frame: once to a texture (using an RTT Camera) and once again to some other framebuffer. Thoughts? -Paul On Aug 6 2009, 8:32 am, Felix Heide felix.he...@student.uni-siegen.de wrote: Hey folks, i have a problem with using theosgShadownodekit together with nestedRTT-Cams. A scenegraph as illustrated in the following image works fine: [Image:http://img7.imageshack.us/img7/5274/sgwithoutrttcam.png] But problems arise, when i use anRTT-Cam to render this scenegraph to an FBO. The FBO is used as a texture which is put on a simple quad-geode. The quad-geode is then rendered by the Viewers-Camera with orthogonal projection. In fact all this stuff is done to apply warping in the fragment shader pass. The resulting scenegraph is illustrated in the following figure: [Image:http://img9.imageshack.us/img9/8421/sgwithrttcam.png] The results are strange shadow artifacts. The shadows move with theRTT-Cameras viewpoint. In addition sometimes flickering in the shadows can be noticed. Except the shadows, the whole scene is rendered as it should be. At first, i thought it would have something to do with the shadowMap's cam. Line 192 in ShadowMap.cpp (osg 2.8.0) is Code: _camera-setReferenceFrame(osg::Camera::ABSOLUTE_RF_INHERIT_VIEWPOINT); If i understand the Reference Frame concept right, this line makes the shadowMaps cam inherit its viewpoint from the viewers cam and not the nestedrtt-cam, which would be the right one. So i tried to set the Referende Frame to ABSOLUTE_RF by accessing the current camera in a cull-callback attached to the ShadowScene node. That did not help. Hope someone has a tip for me. Cheers, Felix -- Read this topic online here:http://forum.openscenegraph.org/viewtopic.php?p=15921#15921 ___ osg-users mailing list osg-us...@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi
Re: [osg-users] osgShadow and nested RTT-cams
On 5/16/2011 6:07 AM, Wojciech Lewandowski wrote: Hi Paul, What I know for certain is this: all shadow techniques stemming from ViewDependentShadowTechnique (StandardShadowMap, MinimalShadowMap, LispSM) are not compatible with nested cameras. And its a design flaw. Basically all these techniques allocate resources per View and views are recognized and indexed by cull visitor pointer. Unfortunately cull visitor of the view main camera also traverses nested cameras, so this means these nested cameras will use the same resources as main view camera. I understand. I encountered the same issue in an early prototype version of what eventually became OcclusionQueryNode. Since the shadow map depends on the camera view/projection, obiously shadowmaps, projection and texgen settings will not work correctly for nested cams. Right, because (in the nested case), the CullVisitor address index looks up the wrong values. You get results, you just get the wrong results. So I always recommended using Slaves cameras instead of Nested cams because they have their own CullVisitors. If I would design this today, instead of CullVisitor I would probably use RenderStage to index view resources. Understood. This is ViewerBase::RenderingTraversals, where it calls renderer-cull(). That's implemented internally with SceneView::cull(). I am however, not sure if I agree with your diagnosis on basic ShadowMap problem. Even if shadow map was rendered only once it should work well for both main and nested camera. Thats because ShadowMap projection does not depend on parent camera view or projection. I came to the same conclusion after I slept on this Friday night. One pass to create the shadow map should be sufficient. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
On 5/16/2011 12:55 PM, Paul Martz wrote: Understood. This is ViewerBase::RenderingTraversals, where it calls renderer-cull(). That's implemented internally with SceneView::cull(). I meant the View, not the CullVisitor. Sorry for the mistake. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and osgearth
Hi, as far as I know, osgEarth ist shader based, so you have to integrate your shadow in the osgEarth shaders (look for shader Composition) Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=39269#39269 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and osgearth
Sumit, Please see my response to your post in the osgEarth forum for an answer. http://forum.osgearth.org/Shadow-in-osgearth-td6351086.html Glenn Waldron / Pelican Mapping / @glennwaldron On Wed, May 11, 2011 at 5:15 AM, Kumar Saurabh Arora saur...@vizexperts.com wrote: I am trying to implement the shadow of an object flying above the earth( rendered from osgEarth). It is not working . I tried every technique, none of them are working. But if I render simple sphere of same size in place of osgearth, then shadow works on the sphere. Is there anything else I am missing? Cheers Sumit Pandey ___ 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 texture problem
nothing? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=37290#37290 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow texture problem
In attachment osg file that doesn't work. When I activate osgShadow, I can't see texture. In osg file there's field textureUnit 0 {}. If I remove this and change, texture works. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36550#36550 PositionAttitudeTransform { name Collada visual scene group nodeMask 0x cullingActive TRUE StateSet { DataVariance STATIC rendering_hint DEFAULT_BIN renderBinMode INHERIT } referenceFrame RELATIVE position 0 0 0 attitude 0.707107 0 0 0.707107 scale 1 1 1 pivotPoint 0 0 0 num_children 1 MatrixTransform { name Strada_Dritta_01 nodeMask 0x cullingActive TRUE referenceFrame RELATIVE Matrix { 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 } num_children 1 Geode { nodeMask 0x cullingActive TRUE num_drawables 1 Geometry { DataVariance STATIC name lambert4SG StateSet { DataVariance STATIC rendering_hint DEFAULT_BIN renderBinMode INHERIT GL_CULL_FACE ON Material { ColorMode OFF ambientColor 0 0 0 1 diffuseColor 1 1 1 1 specularColor 0 0 0 1 emissionColor 0 0 0 1 shininess 0 } textureUnit 0 { } textureUnit 1 { GL_TEXTURE_2D ON Texture2D { file C:\\Documents and Settings\\All Users\\Documenti\\ARGame\\Texture_DEF\\Strada_Dritto.jpg wrap_s REPEAT wrap_t REPEAT wrap_r CLAMP min_filter LINEAR_MIPMAP_LINEAR mag_filter LINEAR maxAnisotropy 1 borderColor 0 0 0 0 borderWidth 0 useHardwareMipMapGeneration TRUE unRefImageDataAfterApply TRUE internalFormatMode USE_IMAGE_DATA_FORMAT resizeNonPowerOfTwo TRUE shadowComparison FALSE shadowCompareFunc GL_LEQUAL shadowTextureMode GL_LUMINANCE } TexEnv { mode MODULATE } } } useDisplayList TRUE useVertexBufferObjects FALSE PrimitiveSets 1 { DrawElementsUInt TRIANGLES 132 { 0 3 6 6 3 8 40 43 49 49 43 46 10 12 14 14 12 17 36 38 1 1 38 4 5 39 9 9 39 30 37 2 33 33 2 7 55 52 61 61 52 58 15 26 11 11 26 23 16 18 27 27 18 28 20 29 13 13 29 19 34 31 24 24 31 21 26 37 23 23 37 33 27 28 36 36 28 38 30 39 20 20 39 29 6 8 41 41 8 44 9 30 45 45 30 47 32 35 48 48 35 50 33 7 51 51 7 42 25 22 56 56 22 53 20 13 54 54 13 59 12 10 60 60 10 62 11 23 63 63 23 57 } } VertexArray Vec3Array 64 { 0.999613 0 0.999415 0.999613 0 0.999415 0.999613 0 0.999415 0.999613 0 -0.999398 0.999613 0 -0.999398 0.999613 0 -0.999398 0.999613 0.00739819 0.999415 0.999613 0.00739819 0.999415 0.999613 0.00739819 -0.999398 0.999613 0.00739819 -0.999398 -0.999199 0.00739819 0.999415 -0.999199 0.00739819 0.999415 -0.999199 0.00739819 -0.999398 -0.999199 0.00739819 -0.999398 -0.999199 0 0.999415 -0.999199 0 0.999415 -0.999199 0 0.999415 -0.999199 0 -0.999398 -0.999199 0 -0.999398 -0.999199 0 -0.999398 -0.807709 0.00739819 -0.999398 -0.807709 0.00739819 -0.999398 -0.807709 0.00739819 -0.999398 -0.807709 0.00739819 0.999415 -0.807709 0.00739819 0.999415 -0.807709 0.00739819 0.999415 -0.807709 0 0.999415 -0.807709 0 0.999415 -0.807709 0 -0.999398 -0.807709 0 -0.999398 0.807909 0.00739819 -0.999398 0.807909 0.00739819 -0.999398 0.807909 0.00739819 -0.999398 0.807909 0.00739819 0.999415 0.807909 0.00739819 0.999415 0.807909 0.00739819 0.999415 0.807909 0 0.999415 0.807909 0 0.999415 0.807909 0 -0.999398 0.807909 0 -0.999398 0.999613 0.0239958 0.999415 0.999613 0.0239958 0.999415 0.999613 0.0239958 0.999415 0.999613 0.0239958 -0.999398 0.999613 0.0239958 -0.999398 0.999613 0.0239958 -0.999398 0.807909 0.0239958 -0.999398 0.807909 0.0239958 -0.999398 0.807909 0.0239958 -0.999398 0.807909 0.0239958 0.999415 0.807909 0.0239958 0.999415 0.807909 0.0239958 0.999415 -0.807709 0.0239958 -0.999398 -0.807709 0.0239958 -0.999398 -0.807709 0.0239958
Re: [osg-users] osgShadow texture problem
I find the problem: some models (made in Maya and exported in Collada then in osg), in osg file have texture 0 empty. Perhaps in shadowed scene this is an important value. If I remove empty texture and I change other texture numbers it works. Have you got some ideas about this? thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36529#36529 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow texture problem
I notice that with some models textures works. What could be the problem? thanks!!! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36486#36486 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow texture problem
Hi, with some shadow techniques they take base texture unit value, try setting that value. Maybe that will help out. Are you rendering in Shaders or Fixed function pipeline? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36488#36488 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow texture problem
Hi, I put sm-setTextureUnit(1); but it doesn't change. I don't know if it's rendering in Shaders or Fixed, how do I check it? I can't understand why some models works and others not. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36496#36496 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow texture problem
Hi Daniele, It could be that some models are using multi-texturing or are the state in the models doesn't work well with the shaders used by osgShadow. The best way to work out what the different models are doing is to export then to .osg or .osgt (if you are using 2.9.x or svn/trunk) and then have a look at the resulting ascii file as it will list all the state that is being setup, and what texture units are active. Robert. On Wed, Feb 9, 2011 at 2:53 PM, daniele argiolas arj...@gmail.com wrote: Hi, I put sm-setTextureUnit(1); but it doesn't change. I don't know if it's rendering in Shaders or Fixed, how do I check it? I can't understand why some models works and others not. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36496#36496 ___ 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 texture problem
I'll add that (at least in version 2.8.3) changing the texture unit for the shadows does not update the shadow technique's shader code. You'll have to override the default shader code to align with whatever texture unit you choose to use for the shadows. Cheers, Steven -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=36509#36509 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow under OS/X
Hi, I know this is quite an old topic, anyway I'm experiencing exactly the same problems as Adrian BUT I'm using the latest svn/trunk code (downloaded just yesterday). I can also add that if I execute osgshadow with the --SingleThreaded switch then the artifacts are not there anymore. I use a MacBook Pro (i3) with a NVIDIA GeForce GT 330M and Mac OS X 10.6.5. Regards. Alessandro On Mon, Oct 1, 2007 at 10:46 PM, Adrian Egli 3dh...@gmail.com wrote: hi robert, i come from testing the osg under OS/X. all osgShadow doesn't work well, or it doesn't work at all on my mac book pro (ATI X1600, ... ) the whole scene is black, and only black. if i add --sv as parameter then it seems to work, but with hundereds of artefacts. did we change anything in the past, texturing, ... ... ... /regards adegli -- Adrian Egli ___ 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 clipping shadows cast from off-camera objects
That parameter is exactly what I was looking for, thanks! On 1/5/2011 3:36 PM, Wojciech Lewandowski wrote: Hi Peter, Try using MinLightMargin parameter. May help somtimes. Look at the attached picture for its meaning. Cheers, Wojtek Lewandowski -Oryginalna wiadomość- From: Peter Amstutz Sent: Wednesday, January 05, 2011 7:37 PM To: OpenSceneGraph Users Subject: [osg-users] osgShadow clipping shadows cast from off-camera objects Hello all, I am trying to add dynamic shadows to my scene and so far osgShadow::LightSpacePerspectiveShadowMapVB seems to produce the best results [*]. Unfortunately, one problem I am encountering is that shadows cast by geometry located to the side or behind the camera get clipped, leading to a number of artifacts. For example, standing outside a building with the sun to your back, the shadow map correctly projects the outline of a doorway onto the floor. However, once the camera enters the building, the wall is clipped and this causes the entire room to be illuminated. This is a very noticeable and undesirable effect. How can I mitigate this problem? [*] I had high hopes for PSSM based on reading about the technique but so far neither osg 2.8.3 nor 2.9.10 produce correct results for me. Thanks! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgshadow example completely black+ other visual problems
Hello Issam, can someone what can cause this please [Image: http://img94.imageshack.us/img94/4281/shadowlg.th.jpg ] (http://img94.imageshack.us/i/shadowlg.jpg/) What command line options are you using to run the osgshadow example? For me, these work well osgshadow --sm -3 osgshadow --ssm -3 osgshadow --lispsm -3 osgshadow --sm -4 osgshadow --lispsm -4 My config: AMD Athlon64 X2 4200+, NVidia GeForce GT 240 1GB, Windows 7 64bit Did it ever work on this machine / configuration? another issues i have [Image: http://img697.imageshack.us/img697/8601/screen2vks.th.jpg ] (http://img697.imageshack.us/i/screen2vks.jpg/) [Image: http://img88.imageshack.us/img88/204/screen1pzj.th.jpg ] (http://img88.imageshack.us/i/screen1pzj.jpg/) [Image: http://img443.imageshack.us/img443/6802/screen3owj.th.jpg ] (http://img443.imageshack.us/i/screen3owj.jpg/) ps : the last pics are from crysis and not from my app ;) That looks like your video card is overheating or something like that. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgshadow example completely black+ other visual problems
1- i did'nt try any of the command line options, just the exe but i will try your commands tonight, thanks for the suggestion 2 - h ... probably -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29728#29728 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OsgShadow
Hello Jose, I'm trying to use the library osgShadow but when I use it, I have the shadow effect in the sky too. I'd like to know how can I remove this effect. You might have seen that ShadowedScene has methods called {set|get}{Casts|Receives}ShadowTraversalMask. For shadowMap-based techniques, only the Casts mask works. You would need to use the Receives mask to control whether objects receive shadows, but it's not considered, so you can't do it that way But you have two other options: a) don't put your sky in the subgraph under the ShadowedScene. Make a root osg::Group, under which the ShadowedScene will be one child and other children can be added who will not have shadows. b) replace the osgShadow default shaders by your own, then you can control shadow application using a uniform variable or simply use a different shader that doesn't apply shadows for those objects you don't want shadows on. Also, is it possible to use osgShadow for files .ive? Yes of course, any model format OSG can load then becomes part of the scene graph and will work just as well for osgShadow. Moreover, .ive is (one of) OSG's native binary format, so you can even save some OSG-specific things in .ive files. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and osgearth
Hi Sumit, Have you tried LispSM ? I have not tested it with osgEarth but it works with osgDEM data. See osgShadow -4 --lispsm example. With large Dataset you will probably have to take advantage of two Lispsm methods inherited from MinimalShadowMap void setModellingSpaceToWorldTransform( const osg::Matrix modellingSpaceToWorld ); and void setMaxFarPlane( float maxShadowDistance ); to optimize shadow map resolution usage. Look how they are used in osgShadow example. Cheers, Wojtek Lewandowski From: sumit Sent: Saturday, April 10, 2010 9:14 AM To: 'OpenSceneGraph Users' Subject: [osg-users] osgShadow and osgearth Hi all, I m trying to get the shadows on earth(rendered by osgEarth). I have just inserted the earth node in osgShadow example. I could not get any shadow of mountains on terrain(self shadowing) by any shadowmap technique. I have tried to increase texture resolution but it's still not working. It was working for small terrain(created in osgShadow example model 2). Am I missing something? Cheers Sumit ___ 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 ECEF precision problems
HI Marius, When you're happy with your changes you could please post the whole modified files to osg-submissions so I can review them. Thanks, Robert. On Wed, Dec 30, 2009 at 1:49 PM, Marius Heise mhe...@heise-network.com wrote: Hi Wojtek, small difference big change :-). Shadow is rock solid now. I only thoroughly tested the directional lighting but it should work for the other cases too. Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21974#21974 Attachments: http://forum.openscenegraph.org//files/standardshadowmapcpppatch_180.txt ___ 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 ECEF precision problems
Hi Wojtek, I solved my directional light case. I changed all floats to doubles in * StandardShadowMap::ViewData::aimShadowCastingCamera The light camera position was calculated as float as was thus jumping around. Of course the change from yesterday using double bounding volumes also has to be activated. In the process I also upgraded the polytope class to double (I don't think this is necessary). I can fix the other light type cases (VB/CB/DB) but someone will have to give me a quick walk-through on posting updates to osg so I don't have to do my work twice. Thanks a lot for your support. Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21954#21954 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Hi Marius, My congratulations! I am glad you did it. I solved my directional light case. I changed all floats to doubles in * StandardShadowMap::ViewData::aimShadowCastingCamera The code in the above method was based on original ShadowMap code and indeed used floats (I must admit I neglected this method). In the process I also upgraded the polytope class to double (I don't think this is necessary). I can fix the other light type cases (VB/CB/DB) but someone will have to give me a quick walk-through on posting updates to osg so I don't have to do my work twice. osg::Polytope is double based by default as far as I know. Other classes stemming from ViewDependentShadowTechnique inherit and use StandardShadowMap::ViewData::aimShadowCastingCamera method so you have fixed them all in one shot ;-) Can you post your modified StandardShadowMap.cpp ? I am preparing few fixes and I would like to merge my changes with the change you have meade before sending my submissions. Cheers, Wojtek - Original Message - From: Marius Heise mhe...@heise-network.com To: osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 11:04 AM Subject: Re: [osg-users] osgShadow ECEF precision problems Hi Wojtek, The light camera position was calculated as float as was thus jumping around. Of course the change from yesterday using double bounding volumes also has to be activated. Thanks a lot for your support. Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21954#21954 ___ 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 ECEF precision problems
Hi Wojtek, :-) will do. Since I am currently on osg 2.9.5 I will switch to trunk and check if the double modifications only in StandardShadowMap.cpp are enough to solve the problem I had. If this is the case, I will send you the svn patch for osg trunk. My 2.9.5 is too dirty and old that I can send you that patch. Will let you know as soon as I've done it Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21969#21969 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Hi Marius, Current trunk version does not draw debug volumes, don't be surprised not seeing them. Its a problem outside of the osgShadow related to changes in COLOR_PER_PRIMITIVE handling. Cheers, Wojtek - Original Message - From: Marius Heise mhe...@heise-network.com To: osg-users@lists.openscenegraph.org Sent: Wednesday, December 30, 2009 1:37 PM Subject: Re: [osg-users] osgShadow ECEF precision problems Hi Wojtek, :-) will do. Since I am currently on osg 2.9.5 I will switch to trunk and check if the double modifications only in StandardShadowMap.cpp are enough to solve the problem I had. If this is the case, I will send you the svn patch for osg trunk. My 2.9.5 is too dirty and old that I can send you that patch. Will let you know as soon as I've done it Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21969#21969 ___ 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 ECEF precision problems
Hi Wojtek, small difference big change :-). Shadow is rock solid now. I only thoroughly tested the directional lighting but it should work for the other cases too. Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21974#21974 Attachments: http://forum.openscenegraph.org//files/standardshadowmapcpppatch_180.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Hi Marius, I am not sure what ECEF acronym means. I guess its WGS84 eliposoid coordinate system with origin in ellipsoid center. We are using LispSM with VPB generated terrain. Do you use setModellingSpaceToWorldTransform method ? It should be helpful in your work. See example of usage and setting it in osgshadow.cpp lines 832-851 (OSG trunk). However, I have not tested it with LispsmVB though, but LispsmCB and LispsmDB. And they seem to work precisely enough most of the time. When impleneting Lispsm/Minimal Shadow Map algorithms, I made the effort to make all computations using doubles. At the time when I was doing this, bounding boxes were based on floats so it may be the case that some issues could be related to inacurate bounding box precision. But my observations regarding shadow volume computations suggest different cause: even double precision is not enough for convex polytope math in WGS84 world coords when these convex polytopes are made from view frustums with very short near planes. For this case it would be better to make all shadow volume computations in view space. I wish I could do this someday but frankly I do not expect it to happen anytime soon. Cheers, Wojtek Lewandowski - Original Message - From: Marius Heise mhe...@heise-network.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, December 29, 2009 12:20 PM Subject: [osg-users] osgShadow ECEF precision problems Hi! I have been using osgShadow::LightSpacePerspectiveShadowMapVB very successfully in previous osg projects. I am currently making the transition from a local XYZ to a whole earth ECEF database. In general the shadow still works correctly, but jumps around by about a meter or two when my model moves. It looks like the underlying shadow bounding volume calculation architecture is not completely implemented with double precision. If so, could anybody give me a hint if the modifications are simple and where they are? Thanks a lot - any help is appreciated. Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21909#21909 ___ 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 ECEF precision problems
Hi Wojtek, thanks for your reply. Sorry for the ECEF (earth-centered-earth-fixed) acronym. Basically we are talking about the same thing. A quick update. I activated setDebugDraw() and both the geometry bounding volume and light volume were jumping. I just noticed and undefined the OSG_USE_FLOAT_BOUNDINGBOX in osg\config. Now the bounding volume is precise and the light volume bounces. I can up you a video link of the problem via PM if you like. Thanks a lot for the setModellingSpaceToWorldTransform tip. I will give this a try right away. I am open for any suggestions. Even if it means switching from LightSpacePerspectiveShadowMapVB to something else. I just remember testing all shadow mapping versions and VB worked the most reliable for my application with a lot of camera movement, wide spaced objects and keeping the resolution of the map high. Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21914#21914 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Hi Wojtek, I have done various tests with the osgShadow demo. All three versions of the LightSpacePerspectiveShadowMap (VB/CB/DB) have the same precision problem even if setModellingSpaceToWorldTransform() is used. I did the following to reproduce: Simulate a large database by changing osgShadow demo line 371 to: osg::Vec3 center(3000.0, 3000.0, 3000.0); Execute the demo with the following: osgshadow --directionalLight --lispsm --ViewBounds --debugHUD -2 osgshadow --directionalLight --lispsm --CullBounds --debugHUD -2 osgshadow --directionalLight --lispsm --DrawBounds --debugHUD -2 Any ideas? Thanks a lot for your effort! Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21919#21919 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Hi Marius, When I do this I see empty blue screen. No model displayed. Looks like camera is positioned far from the model. Perhaps you have done more modifications ? Wojtek - Original Message - From: Marius Heise mhe...@heise-network.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, December 29, 2009 4:17 PM Subject: Re: [osg-users] osgShadow ECEF precision problems Hi Wojtek, I have done various tests with the osgShadow demo. All three versions of the LightSpacePerspectiveShadowMap (VB/CB/DB) have the same precision problem even if setModellingSpaceToWorldTransform() is used. I did the following to reproduce: Simulate a large database by changing osgShadow demo line 371 to: osg::Vec3 center(3000.0, 3000.0, 3000.0); Execute the demo with the following: osgshadow --directionalLight --lispsm --ViewBounds --debugHUD -2 osgshadow --directionalLight --lispsm --CullBounds --debugHUD -2 osgshadow --directionalLight --lispsm --DrawBounds --debugHUD -2 Any ideas? Thanks a lot for your effort! Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21919#21919 ___ 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 ECEF precision problems
Hi Wojtek, sorry.. press '1' and then SPACE ... the camera home position is then calculated automatically to fit the model into the view. This is all caused because the model is so far away. Good luck :-) Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21922#21922 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow ECEF precision problems
Marius, We must have been using different OSG versions. 1 , SPACE seems to not work on my trunk code. I solved this by setting home postion manually. I was able replicate your problem but unfortunately have no more time to spare now and any aditional hints do not cross my mind at the moment. However, I am curious what can be wrong myself and will look into it in next or two days. Wojtek - Original Message - From: Marius Heise mhe...@heise-network.com To: osg-users@lists.openscenegraph.org Sent: Tuesday, December 29, 2009 5:05 PM Subject: Re: [osg-users] osgShadow ECEF precision problems Hi Wojtek, sorry.. press '1' and then SPACE ... the camera home position is then calculated automatically to fit the model into the view. This is all caused because the model is so far away. Good luck :-) Cheers, Marius -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21922#21922 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi Community, please appologize for asking again, since there was no feedback on this. Any ideas about this? Nick http://www.linkedin.com/in/tnikolov On Sat, Dec 5, 2009 at 2:30 PM, Trajce Nikolov nikolov.tra...@gmail.comwrote: Hi community. I am having some issues with shadowed scene. Imagine this scenario: - terrain as a shadow receiver - 1 moving model as shadow caster (the shadow looks good now) - adding additional moving models (now the shadow of the first one still looks great, but on all next models it is very blurry almost invisible) Any ideas, hints? Thanks a lot! Nick http://www.linkedin.com/in/tnikolov ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
On Tue, Dec 8, 2009 at 9:08 AM, Trajce Nikolov nikolov.tra...@gmail.com wrote: Hi Community, please appologize for asking again, since there was no feedback on this. Any ideas about this? It's hard to guess at what is up with so little details. Which ShadowTechniques have you tried? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi RObert, SoftShadowMap Nick http://www.linkedin.com/in/tnikolov On Tue, Dec 8, 2009 at 11:20 AM, Robert Osfield robert.osfi...@gmail.comwrote: On Tue, Dec 8, 2009 at 9:08 AM, Trajce Nikolov nikolov.tra...@gmail.com wrote: Hi Community, please appologize for asking again, since there was no feedback on this. Any ideas about this? It's hard to guess at what is up with so little details. Which ShadowTechniques have you tried? 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] osgShadow question
Hi Nick, On Tue, Dec 8, 2009 at 9:41 AM, Trajce Nikolov nikolov.tra...@gmail.com wrote: SoftShadowMap SoftShadowMap isn't view dependent to get good quality results you have to restrict the size of the shadow casting part of the scene. Try the view dependent techniques such as LightSpacePerspectiveShadowMap. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow - Application crash
Hi Jean Sebastien Guay , Thanks Jean Sebastien Guay for your help . ... Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21061#21061 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow - Application crash
Hi Manish, I have integrated Chipset and no additional 3d graphics card installed . Yes, I gathered as much from the error messages that you posted. Is Software rendering is possible ? For shadows, you really need Framebuffer Objects to get any acceptable performance. I have seen some integrated chipsets that will make OSG fall back from Framebuffer Objects to pbuffers (as yours does) and then work with pbuffer but more slowly. In your case, it seems that your driver doesn't even support pbuffers. You might try upgrading your integrated chipset's driver, perhaps that will make it support pbuffers, but I doubt the performance will be acceptable. So you'll probably have to disable shadows when running on that chipset. Note that it's the application's responsibility to detect the hardware or use config files or some other mechanism to disable features that aren't supported / are too slow on the current hardware. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow - Application crash
Hi Manish, It's not normal for osgShadow to crash so it's not something others in the community will be immediately be able to help you with as there are no clues to the cause of the crash. Does the osgshadow example work? What is the strack trace when the app crashes? Robert. On Thu, Dec 3, 2009 at 7:22 AM, manish Choudhary osgfo...@tevs.eu wrote: Hi, Im trying to add shadows to my scene, code taken from osgshadow example but my application crash If I dont set the setShadowTechnique then my application does not crash, but i obviously don't get shadows either. Ive tried each of the shadow techniques but only Shadow volumes technique . Why my application crash while using other shadow technique ? How can I solve this problem ? Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20790#20790 ___ 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 - Application crash
Hi, Hi, Osgshadow example does not work. While running osgshadow program application crash with the following stack trace -: ig4dev32.dll!037cd5b6() [Frames below may be incorrect and/or missing, no symbols loaded for ig4dev32.dll] ig4icd32.dll!0342a535() ig4icd32.dll!035e6d49() opengl32.dll!6103a2f5() opengl32.dll!6103a2a5() opengl32.dll!6103cccd() osg55-osgViewerd.dll!osgViewer::PixelBufferWin32::closeImplementation() Line 696 + 0x12 bytes C++ osg55-osgViewerd.dll!osgViewer::PixelBufferWin32::~PixelBufferWin32() Line 480 C++ osg55-osgViewerd.dll!osgViewer::PixelBufferWin32::`vector deleting destructor'() + 0x57 bytes C++ osg55-osgd.dll!osg::Referenced::unref() Line 176 + 0x23 bytes C++ osg55-osgUtild.dll!osg::ref_ptrosg::GraphicsContext::~ref_ptrosg::GraphicsContext() Line 33 + 0x24 bytes C++ osg55-osgUtild.dll!osgUtil::RenderStage::~RenderStage() Line 118 + 0x4e bytes C++ osg55-osgUtild.dll!osgUtil::RenderStage::`vector deleting destructor'() + 0x57 bytes C++ osg55-osgd.dll!osg::Referenced::unref() Line 176 + 0x23 bytes C++ osg55-osgUtild.dll!osg::ref_ptrosgUtil::RenderStage::~ref_ptrosgUtil::RenderStage() Line 33 + 0x24 bytes C++ osg55-osgUtild.dll!std::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ::~pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage () + 0x19 bytes C++ osg55-osgUtild.dll!std::_Tree_nodstd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Node::~_Node() + 0x19 bytesC++ osg55-osgUtild.dll!std::_Tree_nodstd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Node::`scalar deleting destructor'() + 0x16 bytes C++ osg55-osgUtild.dll!std::_Destroystd::_Tree_nodstd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Node(std::_Tree_nodstd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Node * _Ptr=0x01633d30) Line 60 C++ osg55-osgUtild.dll!std::allocatorstd::_Tree_nodstd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Node::destroy(std::_Tree_nodstd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Node * _Ptr=0x01633d30) Line 160 + 0x9 bytesC++ osg55-osgUtild.dll!std::_Treestd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Erase(std::_Tree_nodstd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Node * _Rootnode=0x01633d30) Line 1172 C++ osg55-osgUtild.dll!std::_Treestd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Erase(std::_Tree_nodstd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::_Node * _Rootnode=0x0162c798) Line 1170 C++ osg55-osgUtild.dll!std::_Treestd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::clear() Line 972 C++ osg55-osgUtild.dll!std::_Treestd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::erase(std::_Treestd::_Tmap_traitsosgUtil::CullVisitor *,osg::ref_ptrosgUtil::RenderStage,std::lessosgUtil::CullVisitor *,std::allocatorstd::pairosgUtil::CullVisitor * const,osg::ref_ptrosgUtil::RenderStage ,0 ::const_iterator
Re: [osg-users] osgShadow - Application crash
Hello Manish, After termination of the program , I got following message in the command window :- PixelBufferWin32::closeImplementation, wglReleasePbufferDCARB error: Invalid dev ice context (DC) handle. PixelBufferWin32::closeImplementation, wglDestroyPbufferARB error: Error code 32 21684230 How can I solve this problem ? Seems to me that your video card / drivers don't support Framebuffer Objects, and when osgShadow requests an FBO render-to-texture camera, OSG falls back to using pbuffers, and the messages above would suggest that your card doesn't support those either. What hardware are you running this on? We're using osgShadow on a wide range of video cards, from nVidia 7xxx line to the most recent GTX 2xx line. However we know that on most laptop integrated chipsets, we disable shadows (by trying to detect if the OpenGL driver supports Framebuffer Objects, as well as Fragment and Vertex shaders) because they will either run too slow or crash as they do for you. There is currently no such detection in osgShadow itself, it's up to the application developer to implement it. So the osgShadow example will try to run the same on any system, even if the system doesn't support the basic things it needs to do its work. This seems to be the case for you, but I'd need more information to know for sure. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow - Application crash
Hi, I have integrated Chipset and no additional 3d graphics card installed . Is Software rendering is possible ? If yes then what is that software name ? Thank you! Cheers, manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20857#20857 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Oops... If I use the debug hud, then I need to use the fragmentShaderSource_debugHUD and fragmentShaderSource_debugHUD_texcoord shaders? W -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Monday, November 09, 2009 1:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgShadow question Hi Wyatt, The fragmentShaderSource_debugHUD and fragmentShaderSource_debugHUD_texcoord shaders listed at the top of the cpp with the other two shaders Ah, no those are only used if you enable the debug HUD. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi Wyatt, Oops... If I use the debug hud, then I need to use the fragmentShaderSource_debugHUD and fragmentShaderSource_debugHUD_texcoord shaders? You're starting to go into the realm of questions you should be able to answer yourself, using the source and trying things out. I can't help you with every little detail. In this case, I think those shaders are only used by the debugHUD itself, and so you shouldn't need to modify them even if you enable the debugHUD since they should not affect your scene. But I'm not sure, check the source to see where they're applied. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi Debug hud shaders are only used by debug hud to display shadow map. These shaders should not bother you at all. They don't affect your scene, scene is drawn by mainVertex/mainFragment/shadowVertex/shadowFragment shaders. See osgshadow example with following options: -4 --lispsm --debugHUD and see what they do. Wojtek -- From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Sent: Wednesday, November 11, 2009 8:08 PM To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgShadow question Hi Wyatt, Oops... If I use the debug hud, then I need to use the fragmentShaderSource_debugHUD and fragmentShaderSource_debugHUD_texcoord shaders? You're starting to go into the realm of questions you should be able to answer yourself, using the source and trying things out. I can't help you with every little detail. In this case, I think those shaders are only used by the debugHUD itself, and so you shouldn't need to modify them even if you enable the debugHUD since they should not affect your scene. But I'm not sure, check the source to see where they're applied. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi Wojtek, I'm surprised the magic word to summon Wojtek (shadows) took so much time this time! We've been discussing this for a few days now :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi J-S, I have been bit swamped recently. I have restricted my policy to react only to LISPSM while being busy ;-). Besides, you are doing much better support than I could dream of. Thank You, btw. Wojtek -- From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com Sent: Wednesday, November 11, 2009 9:07 PM To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgShadow question Hi Wojtek, I'm surprised the magic word to summon Wojtek (shadows) took so much time this time! We've been discussing this for a few days now :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi Wyatt, Which shader is the basic shader, fragmentShaderSource_noBaseTexture or fragmentShaderSource_withBaseTexture? Depends on whether your object has a texture or not. Although now, since texture lookups are so cheap these days, I would suggest you save yourself some aggravation and just apply a white 1x1 texture to the top of your scene graph (which will thus apply to all untextured objects but won't change anything in their appearance) and use only one shader, the withBaseTexture one. See the code for osgShadow::ShadowMap for an example of such a texture set up. I assume it isn’t one for HUD. What do HUDs have to do with this? Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Is this what you are referring to? if (withBaseTexture) { scene-getOrCreateStateSet()-setTextureAttributeAndModes( 0, new osg::Texture2D(osgDB::readImageFile(Images/lz.rgb)), osg::StateAttribute::ON); } W -Original Message- See the code for osgShadow::ShadowMap for an example of such a texture set up. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi Wyatt, Is this what you are referring to? if (withBaseTexture) { scene-getOrCreateStateSet()-setTextureAttributeAndModes( 0, new osg::Texture2D(osgDB::readImageFile(Images/lz.rgb)), osg::StateAttribute::ON); } Nope, this: { // fake texture for baseTexture, add a fake texture // we support by default at least one texture layer // without this fake texture we can not support // textured and not textured scene // TODO: at the moment the PSSM supports just one texture layer in the GLSL shader, multitexture are // not yet supported ! osg::Image* image = new osg::Image; // allocate the image data, noPixels x 1 x 1 with 4 rgba floats - equivilant to a Vec4! int noPixels = 1; image-allocateImage(noPixels,1,1,GL_RGBA,GL_FLOAT); image-setInternalTextureFormat(GL_RGBA); // fill in the image data. osg::Vec4* dataPtr = (osg::Vec4*)image-data(); osg::Vec4 color(1,1,1,1); *dataPtr = color; // make fake texture osg::Texture2D* fakeTex = new osg::Texture2D; fakeTex-setWrap(osg::Texture2D::WRAP_S,osg::Texture2D::CLAMP_TO_EDGE); fakeTex-setWrap(osg::Texture2D::WRAP_T,osg::Texture2D::CLAMP_TO_EDGE); fakeTex-setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR); fakeTex-setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR); fakeTex-setImage(image); // add fake texture _stateset-setTextureAttribute(_baseTextureUnit,fakeTex,osg::StateAttribute::ON); _stateset-setTextureMode(_baseTextureUnit,GL_TEXTURE_2D,osg::StateAttribute::ON); _stateset-setTextureMode(_baseTextureUnit,GL_TEXTURE_3D,osg::StateAttribute::OFF); #if !defined(OSG_GLES1_AVAILABLE) !defined(OSG_GLES2_AVAILABLE) _stateset-setTextureMode(_baseTextureUnit,GL_TEXTURE_1D,osg::StateAttribute::OFF); #endif } (sorry for the formatting, search for fakeTex in your sources and you should see it) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
Hi Felix, Felix Heide wrote: no one has an idea ? Unfortunately, I don't have much to offer as I have no access to OSG source currently. But my intuition tells me that your case was not widely tested. I think you may have better chances when you setup your RTT rendering as separate slave camera instead of nested in the graph cam. See osg hud examples on how to setup RTT cam as osgViewer slave (I don't remeber exactly which one). Hope this helps Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
Hi Wojciech, Thank you very much ! I will try this ! Cheers, Felix -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16039#16039 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
no one has an idea ? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16009#16009 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow::ShadowedScene + multiple parental node paths
Hi Wojtek, thank you for the feedback, actually this problem arose from the fact that I am using the secondary path to my sceneNode (child of my mainRootNode, parent of all models in the scene), to RRT using the camera node (child of the mainRootNode as well), essentially creating a reflector for my scene. The mirror works great, but it can't coexist with shadowing using my current sg design, I can only have one or the other. Since I am kinda still new to OSG and the sg methodology, I might have overlooked other ways to create my mirror. I will be looking into your leads right away and keep you informed on how things are going. thanks again, Daniel Lazaroff -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15249#15249 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and osgdepthpartition
Hi D.J., (please use your name so we know how to address you) I am in the same business as you, solar system simulations and such. And I too use DPN happily, but not much experience with osgShadow. One advice is to make sure you're running single thread with OSG, I think it is a strong requirement of DPN so far, it might get better with future. As for the eclipses, it's hard to model them correctly with regular shadows, so I opted to just draw transparent cones (one for the penumbra, one for the umbra) see i.e.: http://orsa.sourceforge.net/screenshots/misc/eclipse.png Cheers, Pasquale On Tue, Jul 21, 2009 at 2:30 PM, D.J. Caldwelldlcaldwel...@gmail.com wrote: I am a developer for a program that visualizes large scale (solar system) and small scale (desktop) scenes. We would like to be able to visualize shadows in our scenes for things like solar/lunar eclipses, and ground vehicles with headlights traveling over terrain in and out of sun light. We started using OpenSceneGraph around version 2.2 or 2.4. We are now moving from version 2.6 to version 2.8. We have been using an adaptation of the DepthPartitionNode from the osgdepthpartition example to help with rendering since we often operate in a solar system scene, with orbits, trajectories and lines of sight displayed as lines. We also keep the camera positioned at the origin and move the scene (by way of a transform) to help cut down on jitter in the near view caused by floating point error. The problem is... While trying to make use of osgShadow, I have discovered apparent interference between shadowing and the depth partition node (see two images attached). It would seem that the depth partition node causes the shadow to move with the camera viewing direction, rather than staying with the light direction. In other words, moving the camera causes the shadow to move in an unexpected and undesired manner. My questions are... Is there a way to get osgShadow and a depth partition node to play nice together, or are they at odds by design? Is that, in fact, what I am seeing, or have I set my test case up incorrectly? Perhaps there is some other way to get the benefits of depth partitioning that will not interfere with shadows? I have searched the archives for discussion of using shadows with a depth partition node, but I seem to be missing it (or it just isn't there). I did find one reference http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg11218.html which says to follow the source code. I looked under the hood for ParallelSplitShadowMap, ShadowMap, and LightSpacePerspectiveShadowMap to try to get a feel for how best to proceed, but I'm not seeing a clear path to a solution which allows use of shadowing with a depth partition node. I was hoping to avoid a custom solution, either that combines the two, or maybe goes in a totally different direction, but my gut reaction is that it may be unavoidable. In addition to the images, I have also attached my test environment source code, so that you can interact with the test environment which produced the two attached images. The source code represents a simplified model of our use of OSG in our program. I have it set up so that, if --noUpdate is specified on the command line at run time, the home position of the camera manipulator is set to show the problem I am seeing. It may be easiest to see with --no-base-texture on the command line (which is what I used for the images). My development environment is currently: OpenSceneGraph 2.8.1 Visual Studio 2005 Professional Edition SP1 Microsoft .NET Framework Version 2.0 SP2 Microsoft Windows XP Professional Service Pack 3 (win32) NVIDIA GeForce Go 7950 GTX (nv4_disp.dll version 6.14.10.9422) Thanks in advance! D.J. Caldwell ___ 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 osgdepthpartition
Pasquale, Thanks for the quick reply. We are considering the use of cones as you describe for things like solar/lunar eclipses, but we were hoping to use osgShadow, especially when dealing with terrain and self-shadowing of complex geometry. I should have included the command line arguments I used to produce the images in my email (although I embedded them in the image names): --SingleThreaded --earth-centered --noUpdate --no-base-texture Please, address me as D.J., since I refer to myself as D.J. My given name is Darrell, but I reserve that name for formal situations. Since the list is trying for a more friendly atmosphere, I am giving you the name I use in *ALL* other situations: D.J. (which is an abbreviation of Darrell Junior). Thanks, again! D.J. On Tue, Jul 21, 2009 at 5:57 PM, Pasquale Tricaricotrica...@gmail.com wrote: Hi D.J., (please use your name so we know how to address you) I am in the same business as you, solar system simulations and such. And I too use DPN happily, but not much experience with osgShadow. One advice is to make sure you're running single thread with OSG, I think it is a strong requirement of DPN so far, it might get better with future. As for the eclipses, it's hard to model them correctly with regular shadows, so I opted to just draw transparent cones (one for the penumbra, one for the umbra) see i.e.: http://orsa.sourceforge.net/screenshots/misc/eclipse.png Cheers, Pasquale On Tue, Jul 21, 2009 at 2:30 PM, D.J. Caldwelldlcaldwel...@gmail.com wrote: I am a developer for a program that visualizes large scale (solar system) and small scale (desktop) scenes. We would like to be able to visualize shadows in our scenes for things like solar/lunar eclipses, and ground vehicles with headlights traveling over terrain in and out of sun light. We started using OpenSceneGraph around version 2.2 or 2.4. We are now moving from version 2.6 to version 2.8. We have been using an adaptation of the DepthPartitionNode from the osgdepthpartition example to help with rendering since we often operate in a solar system scene, with orbits, trajectories and lines of sight displayed as lines. We also keep the camera positioned at the origin and move the scene (by way of a transform) to help cut down on jitter in the near view caused by floating point error. The problem is... While trying to make use of osgShadow, I have discovered apparent interference between shadowing and the depth partition node (see two images attached). It would seem that the depth partition node causes the shadow to move with the camera viewing direction, rather than staying with the light direction. In other words, moving the camera causes the shadow to move in an unexpected and undesired manner. My questions are... Is there a way to get osgShadow and a depth partition node to play nice together, or are they at odds by design? Is that, in fact, what I am seeing, or have I set my test case up incorrectly? Perhaps there is some other way to get the benefits of depth partitioning that will not interfere with shadows? I have searched the archives for discussion of using shadows with a depth partition node, but I seem to be missing it (or it just isn't there). I did find one reference http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg11218.html which says to follow the source code. I looked under the hood for ParallelSplitShadowMap, ShadowMap, and LightSpacePerspectiveShadowMap to try to get a feel for how best to proceed, but I'm not seeing a clear path to a solution which allows use of shadowing with a depth partition node. I was hoping to avoid a custom solution, either that combines the two, or maybe goes in a totally different direction, but my gut reaction is that it may be unavoidable. In addition to the images, I have also attached my test environment source code, so that you can interact with the test environment which produced the two attached images. The source code represents a simplified model of our use of OSG in our program. I have it set up so that, if --noUpdate is specified on the command line at run time, the home position of the camera manipulator is set to show the problem I am seeing. It may be easiest to see with --no-base-texture on the command line (which is what I used for the images). My development environment is currently: OpenSceneGraph 2.8.1 Visual Studio 2005 Professional Edition SP1 Microsoft .NET Framework Version 2.0 SP2 Microsoft Windows XP Professional Service Pack 3 (win32) NVIDIA GeForce Go 7950 GTX (nv4_disp.dll version 6.14.10.9422) Thanks in advance! D.J. Caldwell ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] osgShadow::ShadowedScene + multiple parental node paths
Daniel, Frankly, I have never thought about such usage. I must admit that LispSM was not prepared for such scenario. All ViewDependentShadowTechniques (LispSM included) make assumption that there is one technique per View. I suppose that even if you use the same ShadowTechnique object but create two parental paths it will work like there were two independent instances rivalling for the same resources (shadow map /shadow cam view projection matrices/ texgen). So it will not work either. I am not sure if this is possible with your app but you may solve the problem by adding separate slave cameras (like HUD cams) for each extra ShadowedScene. But it will only work with extra slave or extra view. Nesting RTT camera in graph will not be enough. Each ViewDependentTechnique (and derived classes) use ptr to CullVisitor to identify View and create separate set of resources for this view. Graph nested cams use the same visitor as their parent View so it will be impossible to identify which cam is actually rendering and conflicts will be still present. Cheers, Wojtek Lewandowski -- From: Daniel Lazaroff lazaroff_dan...@yahoo.ca Sent: Tuesday, July 21, 2009 6:23 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] osgShadow::ShadowedScene + multiple parental node paths Hi guys, I have been using the LSPSM technique with great visual results so far, but I seem to be having an issue with the osgShadow::ShadowedScene node and multiple parental node paths. If the ShadowedScene node is deep into my scene graph and has a single getParentalNodePaths() there are no problems. But once I have more than one, the shadowing seems to be gone in the simplest of sg designs. Probably there is a simple explanation or I am missing an important point, thanks for any response ! Cheers, Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15184#15184 ___ 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 example
Hi Rabbi, I tried osgShadow example and it just turned out to be black, unlit geometries. Much less the shadow. I have run the exmaple on Mac, Windows and Linux and all the same. Anyone else has the same problems? You don't mention hardware, compiler, command line options used, nothing, so it's hard to say anything. On my NVidia 7900GTX and 9800GTX+, on Windows Vista and 7, using VC++ 2005, these work for me: osgshadow --sm -3 osgshadow --ssm -3 osgshadow --lispsm -3 and also with the -4 scene (though of course --sm and --ssm have trouble with large scenes, which is the point of lispsm). --sv never really worked (and in fact right now it crashes) and --pssm normally works but right now it has shadow flickering for some reason. If you give us more details we might be able to help more. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example
Hi, Thanks, never tried with those arguments. My video cards are mostly nvidia Quadro something. We are developing this game so it can run on most reasonably recent graphics cards. Thank you! Cheers, Rabbi -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14597#14597 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Thanks for your advices ! I've tested the uniform one by changing the shadow technique shader and it works great. Cheers, On Thu, Jun 25, 2009 at 4:28 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Serge, Anyone knows if there is a way to force an object to not receive the shadows ? Even with a dirty method (reseting it's tex coords on the drawable or something like that). Wojtek is right (of course, having implemented some of the ShadowMap techniques in OSG, he would know), ReceivesShadowTraversalMask is typically not used in ShadowMap techniques, as it would be a bit hard to implement generally. What we do is we have a uniform ShadowEnabled which if disabled skips the shadow map lookup in the shadow map shader. For this to work you have to replace your shadow technique's shader with one that will use whatever uniform you set, and you need to set a uniform to false (and make it default to true in your root ShadowedScene) instead of using the ReceivesShadowTraversalMask. So it's a bit inconvenient, you have two different ways of doing things - CastsShadowTraversal mask to make something not cast shadows, and a uniform to make it not receive shadows. Though it's kind of appropriate if you think about it, the former is do I use this object for shadows, and the latter is do I use the shadows on this object, so intuitively the former is a node mask and the latter is a shader parameter for the output. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Serge, I have no access to the code now. All techniques derived from osgShadow::ShadowMap share this limitation. If my memory serves me right they all ignore ReceivesShadowTraversalMask. But many tricks or graph rearangments were discussed earlier. For example look at this thread: http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16581.html If you look carefully you should be able to find more such posts. Unfortunately I cannot offer more help at this time. Cheers, Wojtek Lewandowski From: Serge Lages Sent: Wednesday, June 24, 2009 6:31 PM To: OpenSceneGraph Users Subject: [osg-users] osgShadow question Hi all, I am currently using osgShadow with the MinimalShadowMap technique. It works great but I have a question : - In my ShadowedScene, I set the children's nodemasks accordingly with the CastsShadowTraversalMask and ReceivesShadowTraversalMask properties, but it seems to not work, everything cast shadows on everything. Anyone knows if there is a way to force an object to not receive the shadows ? Even with a dirty method (reseting it's tex coords on the drawable or something like that). Thanks ! Best regards, -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow question
Hi Serge, Anyone knows if there is a way to force an object to not receive the shadows ? Even with a dirty method (reseting it's tex coords on the drawable or something like that). Wojtek is right (of course, having implemented some of the ShadowMap techniques in OSG, he would know), ReceivesShadowTraversalMask is typically not used in ShadowMap techniques, as it would be a bit hard to implement generally. What we do is we have a uniform ShadowEnabled which if disabled skips the shadow map lookup in the shadow map shader. For this to work you have to replace your shadow technique's shader with one that will use whatever uniform you set, and you need to set a uniform to false (and make it default to true in your root ShadowedScene) instead of using the ReceivesShadowTraversalMask. So it's a bit inconvenient, you have two different ways of doing things - CastsShadowTraversal mask to make something not cast shadows, and a uniform to make it not receive shadows. Though it's kind of appropriate if you think about it, the former is do I use this object for shadows, and the latter is do I use the shadows on this object, so intuitively the former is a node mask and the latter is a shader parameter for the output. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and model alpha textures
Hi Bob, Once you have finished implementing fog, and other features into the PSSM frag shader, may you could submitt it a s config file. regards adrian 2009/4/10 Bob Holcomb bob_holc...@hotmail.com Wojtek and Adrian, Hey guys, you were right on the money. I changed the PSSM frag shader to take the alpha channel from the current texture and it seemed to work well. I still need to wiggle my fog calculations into the shader and I think I'll be set. Thanks! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10048#10048 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and model alpha textures
Hi all The PSSM has a GLSL shader inside the implementation. And this makes the lighting stuff different from default one. Even coloring, .. , transparancy isn't a easy task. So to solve such unwished behaviour you can replace the pssm glsl shader our self. i would copy the org pssm shader from the current pssm implementation and rewrite those part you need to fix. then you can pass the new glsl shader thourgh the pssm's shader exchange interface. /** * you can overwrite the fragment shader if you like to modify it yourself, own fragment shader can be used */ class OSGSHADOW_EXPORT FragmentShaderGenerator : public osg::Referenced { public: /** * generate the GLSL fragement shader */ virtual std::string generateGLSL_FragmentShader_BaseTex(bool debug, unsigned int splitCount,double textureRes, bool filtered, unsigned int nbrSplits,unsigned int textureOffset); }; /** set fragment shader generator */ inline void setFragmentShaderGenerator(FragmentShaderGenerator* fsw) { _FragmentShaderGenerator = fsw;} i hope this solve your problems. important to know : (SingleThreaded is a must) osgshadow --pssm --SingleThreaded /adrian 2009/4/8 Wojciech Lewandowski lewandow...@ai.com.pl Bob, Its hard for me to imagine how one could get the effect of lightening instead of dimming. But maybe color material set in vertices (GL_COLOR_MATERIAL) may be involved somehow. This attribute is not handled by vertex shaders. But its handled by fixed pipeline.You may look at the shaders code ( stored inside osgShadow\src\StandardShadowMap.cpp ). All classed derived from StandardShadowMap (Lispsm included) may work bit differenet than other techniques because they define Vertex Shader. If your fixed pipeline lighting setup is different than what is assumed in SSM vertex shader we may see some issues not observable with other techniques (which only use Fragment Shaders). SSM vertex shader assumes that we have one light and separately compute and pass diffuse and ambient components to fragment shader. If ambient is passed separately, fragment shader may properly remove only diffuse component in shadowed areas keeping ambient untouched. Cheers, Wojtek Cheers, Wojtek - Original Message - From: Bob Holcomb bob_holc...@hotmail.com To: osg-users@lists.openscenegraph.org Sent: Wednesday, April 08, 2009 2:34 AM Subject: [osg-users] osgShadow and model alpha textures Hello, I'm adding osgShadow to an existing osg project and I'm getting some weird results with PSSM (Parallel Split Shadow Maps). They don't seem to be respecting the alpha channel of my model's texture. For example, I have helicopter model who's rotor system is represented by a quad and a texture of the blades which is mostly transparent. When rendering before adding osgShadow it looked fine. After adding osgShadow the translucent part is white (but the shadows projected on the ground look pretty good!). This only affects the items under the shadowedScene node, any geometry not under that node is rendered correctly. I've also tried the Light Space Perspective Map technique and found that the self shadowing looks great, but the projected texture on the ground actually makes the ground lighter instead of darker. If anybody has any info on either of these issues I would also appreciate the help. Thanks! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9871#9871 ___ 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 -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and model alpha textures
Wojtek and Adrian, Thanks for your help. I'll be working on the shaders to see what I can turn up. I'll let you know what I find. Thanks again! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9975#9975 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and model alpha textures
Wojtek and Adrian, Hey guys, you were right on the money. I changed the PSSM frag shader to take the alpha channel from the current texture and it seemed to work well. I still need to wiggle my fog calculations into the shader and I think I'll be set. Thanks! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10048#10048 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and model alpha textures
Bob, Its hard for me to imagine how one could get the effect of lightening instead of dimming. But maybe color material set in vertices (GL_COLOR_MATERIAL) may be involved somehow. This attribute is not handled by vertex shaders. But its handled by fixed pipeline.You may look at the shaders code ( stored inside osgShadow\src\StandardShadowMap.cpp ). All classed derived from StandardShadowMap (Lispsm included) may work bit differenet than other techniques because they define Vertex Shader. If your fixed pipeline lighting setup is different than what is assumed in SSM vertex shader we may see some issues not observable with other techniques (which only use Fragment Shaders). SSM vertex shader assumes that we have one light and separately compute and pass diffuse and ambient components to fragment shader. If ambient is passed separately, fragment shader may properly remove only diffuse component in shadowed areas keeping ambient untouched. Cheers, Wojtek Cheers, Wojtek - Original Message - From: Bob Holcomb bob_holc...@hotmail.com To: osg-users@lists.openscenegraph.org Sent: Wednesday, April 08, 2009 2:34 AM Subject: [osg-users] osgShadow and model alpha textures Hello, I'm adding osgShadow to an existing osg project and I'm getting some weird results with PSSM (Parallel Split Shadow Maps). They don't seem to be respecting the alpha channel of my model's texture. For example, I have helicopter model who's rotor system is represented by a quad and a texture of the blades which is mostly transparent. When rendering before adding osgShadow it looked fine. After adding osgShadow the translucent part is white (but the shadows projected on the ground look pretty good!). This only affects the items under the shadowedScene node, any geometry not under that node is rendered correctly. I've also tried the Light Space Perspective Map technique and found that the self shadowing looks great, but the projected texture on the ground actually makes the ground lighter instead of darker. If anybody has any info on either of these issues I would also appreciate the help. Thanks! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9871#9871 ___ 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 model alpha textures
I forgot to mention that I'm running an Nvidia 8600m and windows XP. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9872#9872 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgshadow not functional
HI Sajjad, Try updating your OpenGL drivers. If this doesn't work hassle ATI for developing drivers. Robert. 2009/3/28 ami guru dosto.wa...@gmail.com Hello forum, osgshadow is giving the following error: * Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) I am running on ubuntu with ATI X1600 that supports OpenGL 2.1. What are things i have to look into to get that working? Regards Sajjad ___ 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 not functional
One thing to get it working would be to buy a card they REALLY supports OpenGL like an Nvidia Card. __ Gordon Tomlinson gor...@gordontomlinson.com IM: gordon3db...@3dscenegraph.com www.vis-sim.com http://www.vis-sim.com/ www.gordontomlinson.com http://www.gordontomlinson.com/ __ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of ami guru Sent: Saturday, March 28, 2009 4:40 PM To: OpenSceneGraph Users Subject: [osg-users] osgshadow not functional Hello forum, osgshadow is giving the following error: * Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) I am running on ubuntu with ATI X1600 that supports OpenGL 2.1. What are things i have to look into to get that working? Regards Sajjad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow compile problem with OSG 2.7.8
I don't know if this is the long term solution but I replaced the protected: on line 48 of ProjectionShadowMap and line 230 of ViewDependentShadowTechnique and the compiler errors seem to have gone away. Paul - Original Message From: Wojciech Lewandowski lewandow...@ai.com.pl To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Wednesday, January 14, 2009 11:33:51 AM Subject: Re: [osg-users] osgShadow compile problem with OSG 2.7.8 Hi Paul, Can anybody tell me why I have this osgShadow compile problem using OSG 2.7.8 when compiled using GCC 3.2.3? I think I had the same problem when I attempted to compile 2.7.7 as well.. I am not sure what is recommended solution for your case. Issue is probably related to usage of heavy templates with member subclasses. Sorry I work under windows and cannot test this using GCC compiler. Maybe other Linux Gurus can help. After looking at your error description I would bet that replacing few protected: with public: keywords should help. But I am not sure where exactly those replacements should be made. But for a start I would change it in line 48 of ProjectionShadowMap. If you manage to fix the problem please send you changes to osg-submissions. Cheers, Wojtek [ 35%] Building CXX object src/osgShadow/CMakeFiles/osgShadow.dir/LightSpacePerspectiveShadowMap.o In file included from /net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8/include/osgShadow/LightSpacePerspectiveShadowMap:23, from /net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8/src/osgShadow/LightSpacePerspectiveShadowMap.cpp:18: /net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8/include/osgShadow/ViewDependentShadowTechnique: In member function `virtual osgShadow::ViewDependentShadowTechnique::ViewData* osgShadow::ProjectionShadowMapMinimalBoundsBaseClass, ShadowProjectionAlgorithmClass::initViewDependentData(osgUtil::CullVisitor*, osgShadow::ViewDependentShadowTechnique::ViewData*)': /net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8/include/osgShadow/ViewDependentShadowTechnique:152: ` struct osgShadow::ViewDependentShadowTechnique::ViewData' is protected /net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8/include/osgShadow/ProjectionShadowMap:77: within this context /net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8/include/osgShadow/ViewDependentShadowTechnique:152: ` struct osgShadow::ViewDependentShadowTechnique::ViewData' is protected /net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8/include/osgShadow/ProjectionShadowMap:77: within this context gmake[3]: *** [src/osgShadow/CMakeFiles/osgShadow.dir/LightSpacePerspectiveShadowMap.o] Error 1 gmake[3]: Leaving directory `/net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8' gmake[2]: *** [src/osgShadow/CMakeFiles/osgShadow.dir/all] Error 2 gmake[2]: Leaving directory `/net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/net/jekyll/raid/data/EngNet/share/sammy/OSG_2_7_8/OpenSceneGraph-2.7.8' gmake: *** [opt] Error 2 ___ 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