[osg-users] Lighting
Hi, I applied lightning to a sphere it is working fine,but i am not able to do blink the light for every 30secs,can anybody help me?(sending my code) Thank you! Cheers, Latha -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70738#70738 Attachments: http://forum.openscenegraph.org//files/ligth_to_sphere_193.txt http://forum.openscenegraph.org//files/ligth_to_sphere_480.txt http://forum.openscenegraph.org//files/ligth_to_sphere_215.txt ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting flickering
Hello Trajce!!! LightSource may be traversed after some Drawables. This may be the problem! Try to move LightSource node upper to be traversed first. KOS 2014-02-25 0:44 GMT+04:00 Trajce Nikolov NICK trajce.nikolov.n...@gmail.com : Hi Community, I have a scene where I use light lobes (shader based) which seam to work well. The lights are attached through osg::LightSource and are moved by osg::MatrixTransforms. All works well. Part of the scene is rendered by a third party rendering engine and I see the lights flicker there, this part is litten when I zoom in or pan, when the eye is static it does not. The software allows me to inject my own shaders for the lighting so I use the same shader that is proven to work. It is somewhat as losing or changing the gl_LightSource (ehm, I know I could use uniforms for this, but it is bit of old code) positions on the fly. Any clue what this zoom in flicker could be? Any idea is welcome -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -- С уважением, Матвеев Константин Руководитель проекта +7 (917) 554 44 64 konstantin.matve...@eligovision.ru EligoVision. Интерактивные Технологии http://www.eligovision.ru ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting flickering
Thanks Kostantin! I will try to do that Nick On Wed, Mar 12, 2014 at 8:24 AM, Konstantin lalakos...@gmail.com wrote: Hello Trajce!!! LightSource may be traversed after some Drawables. This may be the problem! Try to move LightSource node upper to be traversed first. KOS 2014-02-25 0:44 GMT+04:00 Trajce Nikolov NICK trajce.nikolov.n...@gmail.com: Hi Community, I have a scene where I use light lobes (shader based) which seam to work well. The lights are attached through osg::LightSource and are moved by osg::MatrixTransforms. All works well. Part of the scene is rendered by a third party rendering engine and I see the lights flicker there, this part is litten when I zoom in or pan, when the eye is static it does not. The software allows me to inject my own shaders for the lighting so I use the same shader that is proven to work. It is somewhat as losing or changing the gl_LightSource (ehm, I know I could use uniforms for this, but it is bit of old code) positions on the fly. Any clue what this zoom in flicker could be? Any idea is welcome -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -- С уважением, Матвеев Константин Руководитель проекта +7 (917) 554 44 64 konstantin.matve...@eligovision.ru EligoVision. Интерактивные Технологии http://www.eligovision.ru ___ 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
[osg-users] lighting flickering
Hi Community, I have a scene where I use light lobes (shader based) which seam to work well. The lights are attached through osg::LightSource and are moved by osg::MatrixTransforms. All works well. Part of the scene is rendered by a third party rendering engine and I see the lights flicker there, this part is litten when I zoom in or pan, when the eye is static it does not. The software allows me to inject my own shaders for the lighting so I use the same shader that is proven to work. It is somewhat as losing or changing the gl_LightSource (ehm, I know I could use uniforms for this, but it is bit of old code) positions on the fly. Any clue what this zoom in flicker could be? Any idea is welcome -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] lighting of pointsprites
Hi all I implemented a particle system using pointsprites, using fixed function pipeline. Now I have the requirement that the particles must react to lighting. I tried everything, but somehow my points don't care. I know I can do my own thing by implementing a shader program, but first I wonder if there is a limitation for point sprites to not beeing able to be illuminated by default. Or maybe it is a bug in my application, but normally by setting _dstate-setMode(GL_LIGHTING, osg::StateAttribute::ON); everything is taken care of... Thank you! Cheers, Daniel -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51459#51459 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting of pointsprites
Hello Daniel, I know I can do my own thing by implementing a shader program, but first I wonder if there is a limitation for point sprites to not beeing able to be illuminated by default. Actually, the only way to get point sprites to be lit is to use a shader. Think about it, a point sprite is just a point which is expanded to a polygon in view space. So it has no normals, or at most it has a single normal which points in the wrong direction (the point's normal), duplicated for all vertices. In a shader, you can choose to make your point sprite have sphere normals, or any other shape you want. You can also use a normal map to get an even better shape. The fixed pipeline cannot do this. Fixed pipeline point sprites were designed for simple billboarded sprites. Hope this helps, 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] lighting not consistent across images in osgprerendercubemap
Dear Robert, Thanks for your suggestion, but that does not fix the issue. (Diff to osgprerendercubemap.cpp attached.) Any other ideas? -Andrew On 11/05/2012 10:37 AM, Robert Osfield wrote: HI Andrew, Try putting an osg::LightSource with a positional light into the scene. Robert. On 3 November 2012 13:01, Andrew Straw straw...@astraw.com mailto:straw...@astraw.com wrote: Hi, (I have a vague memory of this question being asked years ago but I cannot find the discussion.) In the example program osgprerendercubemap, if you study the reflections you can see, at the borders between the faces of the cubemap used to render the reflects, inconsistencies in the specular highlights. Upon further inspection in my own code (just rendering the cubemap itself), it appears that the lighting, and hence the specular reflections, are calculated for a light that is fixed relative to the per-cubemap-face camera rather than fixed in world coordinates. Consequently, when an object shifts from the right edge of one camera to the left edge of the next camera, the reflection is rendered from a totally different relative light position. The visual seams are quite obvious when you know what to look for, and even more so in my program based off this one. Any advice on how to eliminate this effect would be greatly appreciated. Thanks in advance, Andrew ___ 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 diff --git a/osgprerendercubemap.cpp b/osgprerendercubemap.cpp index 0cc5481..c902266 100644 --- a/osgprerendercubemap.cpp +++ b/osgprerendercubemap.cpp @@ -102,6 +102,21 @@ ref_ptrGroup _create_scene() matirial-setShininess(Material::FRONT_AND_BACK, 64.0f); scene-getOrCreateStateSet()-setAttributeAndModes(matirial.get(), StateAttribute::ON); + osg::LightSource* lightSource = new osg::LightSource; + scene-addChild(lightSource); + + osg::Light* light = lightSource-getLight(); + light-setLightNum(0); + light-setPosition(osg::Vec4(0.0f,5.0f,5.0f,1.0f)); + light-setAmbient(osg::Vec4(0.8f,0.8f,0.8f,1.0f)); + light-setDiffuse(osg::Vec4(0.2f,0.2f,0.2f,1.0f)); + light-setSpecular(osg::Vec4(0.9f,0.9f,0.9f,1.0f)); + + scene-getOrCreateStateSet()-setAssociatedModes(light,osg::StateAttribute::ON); + + // enable lighting by default. + scene-getOrCreateStateSet()-setMode(GL_LIGHTING, osg::StateAttribute::ON); + return scene; } @@ -352,6 +367,7 @@ int main(int argc, char** argv) scene-addChild(reflectedScene.get()); viewer.setSceneData(scene.get()); +viewer.setLightingMode(osg::View::NO_LIGHT); return viewer.run(); } ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting not consistent across images in osgprerendercubemap
Hi Andrew, Try applying an osg::LightModel state attribute to your scene graph with setLocalViewer set to true. I use this to get consistent specular highlights across walls in our CAVE setups. Hope this helps. Cheers, Farshid On Wed, Nov 7, 2012 at 5:22 AM, Andrew Straw straw...@astraw.com wrote: Dear Robert, Thanks for your suggestion, but that does not fix the issue. (Diff to osgprerendercubemap.cpp attached.) Any other ideas? -Andrew On 11/05/2012 10:37 AM, Robert Osfield wrote: HI Andrew, Try putting an osg::LightSource with a positional light into the scene. Robert. On 3 November 2012 13:01, Andrew Straw straw...@astraw.com wrote: Hi, (I have a vague memory of this question being asked years ago but I cannot find the discussion.) In the example program osgprerendercubemap, if you study the reflections you can see, at the borders between the faces of the cubemap used to render the reflects, inconsistencies in the specular highlights. Upon further inspection in my own code (just rendering the cubemap itself), it appears that the lighting, and hence the specular reflections, are calculated for a light that is fixed relative to the per-cubemap-face camera rather than fixed in world coordinates. Consequently, when an object shifts from the right edge of one camera to the left edge of the next camera, the reflection is rendered from a totally different relative light position. The visual seams are quite obvious when you know what to look for, and even more so in my program based off this one. Any advice on how to eliminate this effect would be greatly appreciated. Thanks in advance, Andrew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting not consistent across images in osgprerendercubemap
That's it! Many thanks! That had been a source of frustration for some time. -Andrew On 07-Nov-12 17:52, Farshid Lashkari wrote: Hi Andrew, Try applying an osg::LightModel state attribute to your scene graph with setLocalViewer set to true. I use this to get consistent specular highlights across walls in our CAVE setups. Hope this helps. Cheers, Farshid On Wed, Nov 7, 2012 at 5:22 AM, Andrew Straw straw...@astraw.com mailto:straw...@astraw.com wrote: Dear Robert, Thanks for your suggestion, but that does not fix the issue. (Diff to osgprerendercubemap.cpp attached.) Any other ideas? -Andrew On 11/05/2012 10:37 AM, Robert Osfield wrote: HI Andrew, Try putting an osg::LightSource with a positional light into the scene. Robert. On 3 November 2012 13:01, Andrew Straw straw...@astraw.com mailto:straw...@astraw.com wrote: Hi, (I have a vague memory of this question being asked years ago but I cannot find the discussion.) In the example program osgprerendercubemap, if you study the reflections you can see, at the borders between the faces of the cubemap used to render the reflects, inconsistencies in the specular highlights. Upon further inspection in my own code (just rendering the cubemap itself), it appears that the lighting, and hence the specular reflections, are calculated for a light that is fixed relative to the per-cubemap-face camera rather than fixed in world coordinates. Consequently, when an object shifts from the right edge of one camera to the left edge of the next camera, the reflection is rendered from a totally different relative light position. The visual seams are quite obvious when you know what to look for, and even more so in my program based off this one. Any advice on how to eliminate this effect would be greatly appreciated. Thanks in advance, Andrew ___ 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 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 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] lighting not consistent across images in osgprerendercubemap
HI Andrew, Try putting an osg::LightSource with a positional light into the scene. Robert. On 3 November 2012 13:01, Andrew Straw straw...@astraw.com wrote: Hi, (I have a vague memory of this question being asked years ago but I cannot find the discussion.) In the example program osgprerendercubemap, if you study the reflections you can see, at the borders between the faces of the cubemap used to render the reflects, inconsistencies in the specular highlights. Upon further inspection in my own code (just rendering the cubemap itself), it appears that the lighting, and hence the specular reflections, are calculated for a light that is fixed relative to the per-cubemap-face camera rather than fixed in world coordinates. Consequently, when an object shifts from the right edge of one camera to the left edge of the next camera, the reflection is rendered from a totally different relative light position. The visual seams are quite obvious when you know what to look for, and even more so in my program based off this one. Any advice on how to eliminate this effect would be greatly appreciated. Thanks in advance, Andrew __**_ osg-users mailing list osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** 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
[osg-users] lighting not consistent across images in osgprerendercubemap
Hi, (I have a vague memory of this question being asked years ago but I cannot find the discussion.) In the example program osgprerendercubemap, if you study the reflections you can see, at the borders between the faces of the cubemap used to render the reflects, inconsistencies in the specular highlights. Upon further inspection in my own code (just rendering the cubemap itself), it appears that the lighting, and hence the specular reflections, are calculated for a light that is fixed relative to the per-cubemap-face camera rather than fixed in world coordinates. Consequently, when an object shifts from the right edge of one camera to the left edge of the next camera, the reflection is rendered from a totally different relative light position. The visual seams are quite obvious when you know what to look for, and even more so in my program based off this one. Any advice on how to eliminate this effect would be greatly appreciated. Thanks in advance, Andrew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Lighting problem
Hello OSG users, I'm having a lighting problem in my osgviewerQt (derived from [1]) application with a self created drawable object. All my spheres are basically looking like this [2], with this weird spot on top of all spheres. Has anybody an idea, a) what could be causing this or (more important) b) how to stop it? Has anyone stumbled upon this himself before? Grateful for any advise Hartmut [1] http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/examples/osgviewerQT?rev=7995 [2] http://www-user.tu-chemnitz.de/~harl/mail_halde/osg/Sphere_dots.png -- frag nicht - du könntest eine antwort erhalten Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting problem
On 11/15/2011 6:58 AM, Hartmut Leister wrote: Hello OSG users, I'm having a lighting problem in my osgviewerQt (derived from [1]) application with a self created drawable object. All my spheres are basically looking like this [2], with this weird spot on top of all spheres. This is normal: http://en.wikipedia.org/wiki/Specular_highlight Has anybody an idea, a) what could be causing this or (more important) b) how to stop it? It happens on shiny smooth curved surfaces lit by a singe point light source. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting problem
Hi Hartmut, On 16/11/11 0:58 , Hartmut Leister wrote: I'm having a lighting problem in my osgviewerQt (derived from [1]) application with a self created drawable object. All my spheres are basically looking like this [2], with this weird spot on top of all spheres. Has anybody an idea, a) what could be causing this or (more important) b) how to stop it? Has anyone stumbled upon this himself before? I'm not quite sure what 'weird spot' you're talking about? The highlight? The black sphere behind the green one (that looks like another geometry to me)? Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting problem
Hi, What you're seeing is the specular highlights based on your light source and material properties. To turn this off, set your specular material rgb and shininess to 0.0. Since OSG uses OpenGL under the hood, it would be helpful to understand the OpenGL lighting model...:) Shayne -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43905#43905 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting problem when using help or stats handler
A colleague of mine has found a fix for this issue. I think that the question
now is, is it a bug in OSG
or us using OSG improperly (in that case should / could it be prevented).
The fix is as follow (modify EffectDecorator.h in provided code):
class CameraCullCallback : public osg::NodeCallback
{
public:
CameraCullCallback(osg::Group* fx) : m_fx(fx)
{ }
virtual void operator()(osg::Node*, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor* cv = dynamic_castosgUtil::CullVisitor*(nv);
if(cv (cv-getCurrentRenderStage() != cv-getRenderStage()))
{
cv-getCurrentRenderStage()-setInheritedPositionalStateContainer(cv-getRenderStage()-getPositionalStateContainer());
}
m_fx-osg::Group::traverse(*nv);
}
private:
osg::observer_ptrosg::Group m_fx; /// group which has the scene
under it
};
cheers,
guillaume
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier,
Guillaume
Sent: September-27-11 11:13 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Lighting problem when using help or stats handler
I have attached a simple example that reproduces the problem. I am not sure if
this is a OSG problem or if we are not using it properly.
The problem occurs when more than 2 pre-render stages are cascading (as
described in previous post of thread), as the inherited
PositionalStateContainer will stop at the 2nd stage and not be pushed on the
following cascading pre-rendering stages, which happens in our scene graph (and
reproduced in the attached example).
Run the example, see the cow with green specular light. Press 'h'. The cow does
not change. Now set MULTIPLE_PRERENDER_STAGES = true in prerenderbin.cpp line
26. Repeat the above procedure. The lighting changes when the help is
displayed...
cheers,
guillaume
PK
=?
prerenderbin/PK e|:?7 % ) prerenderbin/CMakeLists.txtTMoÚ0¾#ñ ,Æ!½PmvëÁI
ÍâÈvPw²Râ¶ÖHÂ
vCü÷½v@ÚÄ~÷ÛýNá¬+U©SÕ.ná`§?Ìu¡óM.+õk£+9 Âx@#ôeòmòÕçØcÔÍa=ÀËeK #_úî
µ 4¥`ïÞYé'4Þ í
ÏU3ÎxÛâ;T®ë?*C£ñä»ÊÔÓæåðw¼õæøH¸ÉLÆið¸Yë$òO À ô³*y
¸ààD-å3É(OI®ê:}QbCI£ 2¨á²)«ßè ¸ëËQVªeÔ»®k
ÚoÀèpP«Æ±Z?`¨/5Ôi ñÆXÜ·¤ òÂÄ'ÌQY¿Ü.TUë²@ÂÏô·ºX®6:'ä
â$Ö
8ü]ú2ÝØy4kS9°÷UþqÉÎôÇ~ØÌÏwÍ{Í¿¦YùfVB½7æ4ze¾ ÞTeVqZ5z¹R®U!^+fµe«M®Ìjz½Y¥ÐáàÄ·I6óAöÃÒ$òÑç#pGp40\JC4JjeèV; ,0yQ·;8ç ÞKeWÃNÙÿ£45
§Uv
Èl°çÊa!n÷Ob Zs2Ã-ÎN±9h}Ù8Ë íÃé_R3ÏîåzmAòü ÍW˲2m¼^C
»s}_Gâ%»!éùÈÎ]ïnlHruÀ5
¾°ÃÑþ¦!vIhfþ DxNv£Û£V}iÍfôÏkÍéï¤wGz׿PK ¹X;?éHbø1
á prerenderbin/EffectDecorator.cppµiÒ0ô»3þ¨3ZºúVQ
z:L¶
´ZLRp=þ»ï%½KÐÙ
É»¯¼½Dn{\ ,ÌU}ærAmÿòÅ /dç÷¹\Þ|Ìø)qþ°zðBðO ð¨vô*|uäUíüUý:É¥ õýO=
s©L(½+UK¤ò:
¼£%ÙH4½)`5sYÄÈ!7ðÈ
«ù]Öûß³!Ëpî°¯=Î
÷þÖGò 7Ç¡
ÒÝ[÷ÊÐ/¸ Ð ºP©òV+ú«{Z2/öÊ «IWëx Òhû`úl|
XÜ0÷lÈãÛYðiRï= r+öUÅôT8»bȶTáN]¦rjE 7É$VëXókx¨M®Èzé©SÖÊ×EÓÛ
òµ¿ÖvñB%]:ÊÕÚS 2ßò[-Ì},}ë¾Ã±Öe°í Eh,#æiôáj¾~
kÈ:ÌÛÈNGoÜ«ÜxH=¯/è
ÌÒ®`T1Ç(ë!dÂæü5sïX7nÛð åË÷Nì[[ö
ì´ZÀ9ò3¦®-ÆlF TDZ25=-F
lµ´ì)Ê©ç l= Íûι39vCWANÅu:ÓÓ ;^L'Î ç ú{¨8ÃñãÿAûÑh0îÿá4 NwÜd
MùÇK¬MIL 2/
¥I'X:~
å±ØTT«°¦ÎàÝP9Û.l@çä1· :í~2(+kb=¡\×®
Qw82Ê~ 28}LW̺\ؽð)\izsf
/É?E»$u9-mr ÉäD²ÒPÚG$5n(½Éj:lýF¼þ_ÎóÿÄX¤ýY,w#3AZÆbuÚä÷×.JEªÔ
Eå8¼Ü\)Bî\£ê:å\Ê2dé °¾1kX,^[A¤¾lKs)¯ÁV|Ãë¡ÕPIÏÎ)
Éó³8Õnn4è½*÷. Pl ¯2 V±é`JïH2uÓ,UP»tµXFD@=|5
ýù£wÎ@ïL ?êæ c³¿Ó
Çît÷në^¿½)à¡1^ð-
³åOÀÖÕÔ1-AU)ÃO°Å|ÄýóþCüò¬J|]Ò¢n7Ú0RLD4
h¤*¿{ç/c(ͨL¶ÔmáBý´æYøÞ£«¢=
xoT¡ÂFBñr«´aáu?[Hß.m+?=$BF
n³îå.D·þ÷;´çT~Fkö£ÉtþèÕéé ~
òd6ÎwwÓ9O:f°±ZíýÌ T Îf1^'}ØøǸ§eÊ Óe§p'-]6Iu:ÓÁ¨ë
_æÓÓfï'BßÁ¹K±òô,éï *@ó!VШIQû-}? ¤öz:èí1a½ ¼ ÐGíàJ¢®_¹
v±¸¥bôØÅÌÌÕÛ»¬)O gà[×o¨K
yÆ¢®ª1YLàüLëóLí³4*u§Òùü¤³ÿúW«u0IÌrj»°¿ai
lгú`P¡ab.UtcjMØ¿Ñ7Èò¹u(ß$k÷Ñl2zå`² h7hKôõlíãìP)3ÅMhë*}C2áUv÷yØ6ðM`FûØüéäw?+ ê¶Í½¶?`r?îlüµ¤VÞÏ/BNéZ¶ù\G¥jHØ{¦åJf÷µÞ¨ @`{JvX
º$ÂÓ¼¬Il¤IBQ ÁPËÝ =¾=YÉ3UP !Äw®ÙÓÈ# g2º¦ %¦Ñ¶®8X%Kdò©³Ü*Õÿãæã8Ý.ÝG1Û3V¸P^ѵ¯Tµß^2£«ÄÝd
Ë#©ÒQ
®ýÀ= ¡ùt¡
À×ùý ðP2-ÞÏ°®à$»1Íuó
k*¸WÜ5$½ðÒΣ¼Â:É¥dnV?~ôÈD«K øI A{Ùqû B,0s¡b§äÍéÏ,7àã3H0ä[|²
+Ä
À=,_4 à±DÃãßBĺ~|8(5U6Ù
ý~,fÝH ®!| ÷bOªMH£`@âóÑ0Ãæ0`ܼ+Íä9!*R§#¼¯»ÔRv2 púÒMC -
!2 fl¯ 5Åä2ZuÌm|¶Å¡v K Èâ[5çtNZ!-±0v#]C áqú¶Ä¸m·ÛdÀåÄá
ÔUº ÅH ÁRäªA YÎ$P
]xN@skC!Ä8AùÖ{ ä$q9 $ ¤®@cBUp!ßAszS»©XÀÙ² ÒæÏØ6Z CSPþÔäØ¢÷teB,çêêh+ÞÊÏYòÃïÍp4Ì O
¯ÈKú\äFµÍ2Ú3Æñ×$Xó·Ø×5sQtÅ1ØjΡqå°£hD´÷Ì?À1sk±
$³3mÑ
Re: [osg-users] Lighting problem when using help or stats handler
I have attached a simple example that reproduces the problem. I am not sure if
this is a OSG problem or if we are not using it properly.
The problem occurs when more than 2 pre-render stages are cascading (as
described in previous post of thread), as the inherited
PositionalStateContainer will stop at the 2nd stage and not be pushed on the
following cascading pre-rendering stages, which happens in our scene graph (and
reproduced in the attached example).
Run the example, see the cow with green specular light. Press 'h'. The cow does
not change. Now set MULTIPLE_PRERENDER_STAGES = true in prerenderbin.cpp line
26. Repeat the above procedure. The lighting changes when the help is
displayed...
cheers,
guillaume
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien
Guay
Sent: September-22-11 9:36 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Lighting problem when using help or stats handler
Hello Guillaume,
After some more digging I kind of have a feeling for what is happening
but again I have too little knowledge of the OSG internals to really
understand what is going on...
FWIW, we use the stats in all our apps, and we've never had any problems
where showing the stats on screen would change lighting in the rest of
the scene. The stats disable lighting on their subgraph anyways (in
general you don't use lighting on a 2D HUD), see
src/osgViewer/StatsHandler.cpp line 1062 in the current OSG trunk:
stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF);
So it seems weird to me that you're getting these problems. OSG's own
examples also use the stats almost all the time and the lighting of the
scene is not affected.
All this points to something you're doing that's causing this, or a
driver bug. In both cases, it might be useful for you to reduce your app
to a very simple test case, see if the problem is still there, then work
back up to find out what's causing it. When you get to a simple
self-contained example that reproduces your problem, if you're still in
the dark as to why it happens, you can send us that example, and we can
have a look. In general, sending small self-contained examples is much
more useful than sending code snippets, since with the former we can
actually compile it and debug into it, whereas in the latter case we can
only look at the code...
Hope this helps,
J-S
--
__
Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.dyndns-web.com/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
PK
uY;?
prerenderbin/PK Â}:?KíÚÖ Ìg prerenderbin/ALL_BUILD.vcprojí]]sÒ@}®3þ
:´U«Ø¢*#(Ty`¦ÂklÜM*õã¿{7h¡$m¿öÅI²wÏÝ{ïîa÷@ãÑëmiç2Lrn¯°ÓcvZYË}ÂÎ|eù½ýgû¹×¯îÞ9úoX]Ï aÒ¦ä32½»wv«Þ
Ê9a¢Õ ?ÎAÓǼTØÝåÞ6UÍÓêI£©çâîoNz9÷]ׯ?©å÷ äJ¥|õÙóRþÉÁni¯ò¢Z}vPùÉ»½C_
ù0ìsÜ+x|Ô¶ oL¨Íø]|ËoBﳧ¹b`[\2ªg'5sðèÒ³
ýÉüà{®ïéB$^í¢áxÚh
Åq
#L öK.EV÷vEÓ C ÆãZ9¨ô-ì`C¬Öñ ¶Q©A/N1®Çf· O
j0.òʹý _b ®æ¡}¬Õ5b»ØB·ñÎÜÕhù «á?Ç+çj/®($¼G%=âÓÓú ÜAÁ9]9è
5Üé`¿P*¼`tz¨ÏLäro
gdÁ, ¼#TGcÛq¿Ê»úiã}OotÊ_|â ¹ ¯£Á3ì!ÔÄÌä1ô.jçÃp
s÷ 6 ^ÐGh,®OÏbW}l\·ì F|j¢ßÚço}@Þ\¢usæ r;´'ßNÏ äÕsLc#¦à°é
Âê fnÁj¡÷:'Qw f6
,¬9~ó¨àYÃÀîêJ ¼EÆQ^ä8ÓÐHo6uÃ3b+þZËcÃDDÇx Ò).a ÍÅ+¬ÖgªÌ¬ú98ãÍ×Û6±sÈ0o%îQq{®gÀ²ÁÐZ[¤`Á°âÁLx0ÌfR
ͮȡbCÅײ!°OȦË5¥àĸ¢ÅLh1NhRf{(r\IÅ 7í?ao
G3k9ò²a
\2®\NjR¾\î¥8ssFoþ×¼yé#y0ÁÕ¸ð0Àæ µ
oº4}áQä@ÖØÔZÆ
±Úùó[óÏ
ÞÌ #+ÜU-
íã]·ÜÃf 1bWP o
ja¬u| iµÅh°ÅÅÁÂÚ±¡àV,@ж$M{8{qðH«íÃç¡6ÜÐ
Zþí:ÇZ¾º¾)oNyga»ù1xÓTq®ÞBÐïÁ½Ù®~Èÿ â±(%ÔBçÈÒö´
ñös¢K¨WçMQä1êÈå^
qµÁ§#éÊóûù`',vKÇðÍ¿,4l ñÔµ{Ádg¿[ÀN¤|Wºg2y¼µè/óyªØ9ñ°Å2ûÆ)#HÉj¿ÿæµß¿}fû}
¹K ëÖM¾¢vðyyí6³gèKÃø4Óê]Ææ Æ:¥÷Ë£Ïøla×|G vnOw |×5 b¤®nóÄþ-
¾!%NÓp
âýæBJ æè8GÂL¯ÑÈO¥ÚÈÜIÛ
5l×ÂöøY¯Ì½ÔB|cÁ0°D1kWhê°#$Ñ=EÇ~?ìÑÎ^æÇÜFâÞYqM/¢q®+üæc$Z| !èXÜ(d¬RR(ÈbW4¬dâVø%o)yKÉ[JÞúã7cJÞRòVí§·R5²ÏVÉ[²æ·6zØö¡SF Ô3µ%oeͶ·Âni$îפñ¢ä-¹òVü#o¥p)
K)\Jáúã÷cJáR
W ¨R¸R 7²ÏV)\²æR¸6zØö¹SF Ô©3µ¥peͶR¸Âni$îפñ¢.¹
×òä*K©\JåR*× ¿'S*R¹ìBÊòÈ|¶°Jå5 ʵÑöÏ2ê N©½(+£l¶ÊvÛL#qטּ¥rÝNå¿ÖKè]0/^¿(ÒÔá
ðƵ[½ìÒ Æ
üWieiÑHW*h·VEz£²Î!6Wtg³ní þIñóÆÿ1²Dô1T]L
7ác\¾±ÈаÄu1¾9*®ø?xàù/PK :Y;?Oë½Ç
4 prerenderbin/ALL_BUILD.vcproj.DSNRCCA.poiriergu.useríQOÛ0ÇÄw¨üÖ¦06mJ²vh©k¾ðbkâͱ#Û)ñá¹$Ŷ*ñHr¿óï.EvÏVï.Ai
G=tAD2fñÈXÞêOãÓcr6p¯.(M3y©A3©ÿ
2w9x¤^Ó t]=åþÖs©¼õ9/#µGk(ñow$Å%
¢Ct6XI
Re: [osg-users] Lighting problem when using help or stats handler
Hello Guillaume, After some more digging I kind of have a feeling for what is happening but again I have too little knowledge of the OSG internals to really understand what is going on... FWIW, we use the stats in all our apps, and we've never had any problems where showing the stats on screen would change lighting in the rest of the scene. The stats disable lighting on their subgraph anyways (in general you don't use lighting on a 2D HUD), see src/osgViewer/StatsHandler.cpp line 1062 in the current OSG trunk: stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF); So it seems weird to me that you're getting these problems. OSG's own examples also use the stats almost all the time and the lighting of the scene is not affected. All this points to something you're doing that's causing this, or a driver bug. In both cases, it might be useful for you to reduce your app to a very simple test case, see if the problem is still there, then work back up to find out what's causing it. When you get to a simple self-contained example that reproduces your problem, if you're still in the dark as to why it happens, you can send us that example, and we can have a look. In general, sending small self-contained examples is much more useful than sending code snippets, since with the former we can actually compile it and debug into it, whereas in the latter case we can only look at the code... Hope this helps, J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ 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] Lighting problem when using help or stats handler
After some more digging I kind of have a feeling for what is happening but again I have too little knowledge of the OSG internals to really understand what is going on... When looking at the culling phase I see that there is the root render stage, then 2 levels of pre render bins (excluding root level). First the root render stage has the correct light attribute in its _renderStageLighting and a null _inheritedPositionalStateContainer, then the 1st level _preRenderList render bin's _inheritedPositionalStateContainer is from the parent render stage _renderStageLighting. Its _renderStageLighting however is not inherited and contains no light attributes. Therefore on the 2rd level pre render bin the _inheritedPositionalStateContainer is from the 1st level _renderStageLighting, but this has an empty _attrList... Basically it seems that when having a hierarchy of pre render stages / bins the light attribute does not trickle down the hierarchy and is not applied before my geometry is drawn... Not sure if that makes sense... Any idea ? cheers, guillaume From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier, Guillaume Sent: September-19-11 5:16 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Lighting problem when using help or stats handler Hi Paul and al., Yes the geometries do have color and normal arrays. From what I understand the problem is that the scene light is applied only after the geometry is drawn, therefore using last frame light settings when drawing the geometry. Since the help / stats handlers apply their default light at the end of the frame, it will be used for the next frame scene render. This render order issue seems to be directly related to the implementation of the EffectNode and its overriding of the traverse() and cull() functions. cheers, guillaume From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: September-19-11 4:56 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Lighting problem when using help or stats handler On 9/19/2011 2:43 PM, Poirier, Guillaume wrote: Hello OSG users, My problem is simple to describe: When in our application we press 's' or 'h' to display either the stats or help, the lighting changes when it should not. Check to make sure that all Geometry objects in your scene specify a color array and a normal array. OSG does not provide a default if these are missing, so they inherit the value last set in the OpenGL state machine. Both affect lighting (color affects lighting because OSG's default is to enable GL_COLOR_MATERIAL if no Material StateAttributes are present). -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Lighting problem when using help or stats handler
Hello OSG users,
My problem is simple to describe: When in our application we press 's' or 'h'
to display either the stats or help, the
lighting changes when it should not.
Now although I've used OSG for a little while, I am not familiar with the
rendering backend of it and may need some
suggestions to figure out what exactly the problem is.
I saw that these two handlers use a renderer with a default light and it is
that light that is active when the scene is rendered.
Actually if I look at the Light::apply() and Geometry::drawImplementation()
functions, I can see that first the drawImplementation()
is called for my geometry / scene, then the Light::apply() for the scene light,
then the Light::apply() of the HelpHandler.
Therefore at the next frame the active light is always the default HelpHandler
one when the scene is drawn. Looks like the rendering
/ light apply order is screwed up, and even without the handlers I am always
using the light setting set at the end of the previous frame.
I have an effect in the scene that does RTT to a quad and another branch that
renders the RTT result on a quad. The scene graph is the
EffectNode with the Scene as child. The RTTCam and RenderQuad are not in the
scene graph, they are added by hand in the traversals. Any idea of what is
wrong ?
void EffectNode::traverse(osg::NodeVisitor nv)
{
if (nv.getVisitorType() == osg::NodeVisitor::UPDATE_VISITOR)
{
osg::Group::traverse(nv);
if(m_pSceneRTTCam.valid())
m_pSceneRTTCam-traverse(nv);
if(m_pRenderQuad.valid())
m_pRenderQuad-traverse(nv);
}
else if (nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR
dynamic_castosgUtil::CullVisitor*(nv))
{
cull(*static_castosgUtil::CullVisitor*(nv));
}
else
{
osg::Group::traverse(nv);
}
}
void EffectNode::cull(osgUtil::CullVisitor cv)
{
// do RTT camera traversal, rendering the scene graph under EffectNode
group
m_pSceneRTTCam-accept(cv); // write to texture
// render texture on quad and apply post-process shader
cv.apply(*m_pRenderQuad.get());
}
m_pSceneRTTCam-setCullCallback(new CameraCullCallback(this)); // this ==
EffectNode
/*!
Needed to be able to render the scene which is not a child of
a camera (which has this culling callback)
*/
class VSSFX_Export CameraCullCallback : public osg::NodeCallback
{
public:
CameraCullCallback(osg::Group* fx) : m_fx(fx)
{ }
virtual void operator()(osg::Node*, osg::NodeVisitor* nv)
{ m_fx-osg::Group::traverse(*nv); }
private:
osg::observer_ptrosg::Group m_fx; /// group which has the scene
under it
};
cheers,
guillaume
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting problem when using help or stats handler
On 9/19/2011 2:43 PM, Poirier, Guillaume wrote: Hello OSG users, My problem is simple to describe: When in our application we press 's' or 'h' to display either the stats or help, the lighting changes when it should not. Check to make sure that all Geometry objects in your scene specify a color array and a normal array. OSG does not provide a default if these are missing, so they inherit the value last set in the OpenGL state machine. Both affect lighting (color affects lighting because OSG's default is to enable GL_COLOR_MATERIAL if no Material StateAttributes are present). -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting problem when using help or stats handler
Hi Paul and al., Yes the geometries do have color and normal arrays. From what I understand the problem is that the scene light is applied only after the geometry is drawn, therefore using last frame light settings when drawing the geometry. Since the help / stats handlers apply their default light at the end of the frame, it will be used for the next frame scene render. This render order issue seems to be directly related to the implementation of the EffectNode and its overriding of the traverse() and cull() functions. cheers, guillaume From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: September-19-11 4:56 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Lighting problem when using help or stats handler On 9/19/2011 2:43 PM, Poirier, Guillaume wrote: Hello OSG users, My problem is simple to describe: When in our application we press 's' or 'h' to display either the stats or help, the lighting changes when it should not. Check to make sure that all Geometry objects in your scene specify a color array and a normal array. OSG does not provide a default if these are missing, so they inherit the value last set in the OpenGL state machine. Both affect lighting (color affects lighting because OSG's default is to enable GL_COLOR_MATERIAL if no Material StateAttributes are present). -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting for point sprites
Hi Don, The osgFX BumpMapping class is based around conventional geometry meshes, and won't work at all for point sprites. I think you'll need to come up with an approach that does the lighting in fragment shader, with the orientation of point sprite assumed to be orthogonal to the eye vector and the light source vector/position. The eye vector and light source vector/position you can compute in the vertex shader and then pass to the fragment shader. Robert. On Mon, Oct 18, 2010 at 11:31 PM, Don Leich d...@ilight.com wrote: Hi all, I've been using point sprites with a small 2-d texture map of a sphere for some time now with great results. I'd like to be able to vary the lighting on my spheres and was hoping that I'd be able to replace the picture of the sphere with a flat disc and use a bump map to affect lighting. Is this a direction worth persuing? It looks like the internals of the BumpMapping class in osgFX are doing some BIND_PER_VERTEX assignments. Will everything bind to the single vertex of the point sprite? -Don Leich ___ 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] lighting for point sprites
Hi all, I've been using point sprites with a small 2-d texture map of a sphere for some time now with great results. I'd like to be able to vary the lighting on my spheres and was hoping that I'd be able to replace the picture of the sphere with a flat disc and use a bump map to affect lighting. Is this a direction worth persuing? It looks like the internals of the BumpMapping class in osgFX are doing some BIND_PER_VERTEX assignments. Will everything bind to the single vertex of the point sprite? -Don Leich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
Hi Aitor In your code lightPosition = (x=0, y=40, z=0, w=0.3), so you use a directional light (w != 1.0). so you need in your shader a directional light computation. (see Orange book or here http://www.lighthouse3d.com/opengl/glsl/index.php?ogldir1 for more explanation) Or you want a point light and you can keep your shader but lightPosition.w must be equal to 1.0. HTH David Callu 2010/10/5 Aitor Ardanza aitoralt...@terra.es: Trajce (Nick) Nikolov wrote: maybe better to put something in while we can compile and test and see if can help - including the model-Nick Ok, here you have... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32382#32382 ___ 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] Lighting shader problem
ledocc wrote: Or you want a point light and you can keep your shader but lightPosition.w must be equal to 1.0. HTH David Callu OK, has been a pretty big mistake, sorry. Setting w to 1 everything is ok! Thanks -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32554#32554 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
ledocc wrote:
Is you normal of your model well defined and normalized ?
Whitout shaders model looks perfect, and you can see the changes moving the
light of the site.
ledocc wrote:
I suppose you used an osg::Light to define your light.
Have you put it in a osg::LightSource ?
Code:
int const LIGHTS = 1;
osg::StateSet *lightStateSet = scene-getOrCreateStateSet();
osg::Geode *lightMarker[LIGHTS];
osg::LightSource *lightSource[LIGHTS];
// Create Lights
osg::Vec4 lightColors[] = {osg::Vec4(1.0,1.0,1.0,1.0), osg::Vec4(0.0, 1.0,
0.0, 1.0), osg::Vec4(0.0, 0.0, 1.0, 1.0)};
for (int i = 0; i LIGHTS; i++) {
lightMarker[i] = new osg::Geode();
lightMarker[i]-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0, 40.0, 0.0), 5.0)));
osg::Material *light_material = new osg::Material();
light_material-setDiffuse(osg::Material::FRONT, osg::Vec4(1.0, 1.0,
1.0, 1.0));
light_material-setSpecular(osg::Material::FRONT, osg::Vec4(0.1, 0.1,
0.1, 1.0));
light_material-setEmission(osg::Material::FRONT, lightColors[i]);
lightMarker[i]-getOrCreateStateSet()-setAttribute(light_material);
lightSource[i] = new osg::LightSource();
osg::Light *light = new osg::Light();
// each light must have a unique number
light-setLightNum(0);
// we set the light's position via a PositionAttitudeTransform object
light-setPosition(osg::Vec4(0.0, 40.0, 0.0, 0.3));
light-setSpecular(osg::Vec4(0.1,0.1,0.1,1.0));
light-setAmbient( osg::Vec4(0.2,0.2,0.2,1.0));
light-setDiffuse(lightColors[i]);
lightSource[i]-setLight(light);
lightSource[i]-setLocalStateSetModes(osg::StateAttribute::ON);
lightSource[i]-setStateSetModes(*lightStateSet,
osg::StateAttribute::ON);
lightTransform[i] = new osg::PositionAttitudeTransform();
lightTransform[i]-addChild(lightSource[i]);
lightTransform[i]-addChild(lightMarker[i]);
lightTransform[i]-setPosition(osg::Vec3(0, 0,200));
//lightTransform[i]-setScale(osg::Vec3(0.1,0.1,0.1));
scene-addChild(lightTransform[i]);
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=32364#32364
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
the viewer by default is attaching a light. Setup your viewer with NO_LIGHT (or something like that, look in the code), and then create and control your own light -Nick On Mon, Oct 4, 2010 at 11:19 AM, Aitor Ardanza aitoralt...@terra.es wrote: ledocc wrote: bug fix: - ViewDirection = normalize(eyePosition - fvObjectPosition.xyz); + ViewDirection = normalize( - fvObjectPosition.xyz); I already had tried before, but does not solve the problem. If you disable the shader, with the standard osg lighting, gives me no problems, the model normals are well. If approached the camera at a distance close enough to the model, everything is fine, but if you walk away a bit, whole model is lit regardless of the position of the light ... Thanks for the answer! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32342#32342 ___ 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] Lighting shader problem
ledocc wrote: bug fix: - ViewDirection = normalize(eyePosition - fvObjectPosition.xyz); + ViewDirection = normalize( - fvObjectPosition.xyz); I already had tried before, but does not solve the problem. If you disable the shader, with the standard osg lighting, gives me no problems, the model normals are well. If approached the camera at a distance close enough to the model, everything is fine, but if you walk away a bit, whole model is lit regardless of the position of the light ... Thanks for the answer! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32342#32342 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
Hi Aitor, Is you normal of your model well defined and normalized ? I suppose you used an osg::Light to define your light. Have you put it in a osg::LightSource ? Could you provide an example to reproduce your issue This will become hard to solved it without more information. David Callu 2010/10/4 Aitor Ardanza aitoralt...@terra.es: Trajce (Nick) Nikolov wrote: the viewer by default is attaching a light. Setup your viewer with NO_LIGHT (or something like that, look in the code), and then create and control your own light-Nick Neither solves ... Could I use the standard osg lighting if I use a vertex program to change the position of the vertices? yes, you can. If I coment Code: //gl_FrontColor = diffuse + globalAmbient + ambient + specular; the result is this... [Image: http://img210.imageshack.us/img210/4333/30581070.jpg ] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32359#32359 ___ 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] Lighting shader problem
Trajce (Nick) Nikolov wrote: the viewer by default is attaching a light. Setup your viewer with NO_LIGHT (or something like that, look in the code), and then create and control your own light-Nick Neither solves ... Could I use the standard osg lighting if I use a vertex program to change the position of the vertices? If I coment Code: //gl_FrontColor = diffuse + globalAmbient + ambient + specular; the result is this... [Image: http://img210.imageshack.us/img210/4333/30581070.jpg ] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32359#32359 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
maybe better to put something in while we can compile and test and see if
can help - including the model
-Nick
On Mon, Oct 4, 2010 at 5:37 PM, Aitor Ardanza aitoralt...@terra.es wrote:
ledocc wrote:
Is you normal of your model well defined and normalized ?
Whitout shaders model looks perfect, and you can see the changes moving the
light of the site.
ledocc wrote:
I suppose you used an osg::Light to define your light.
Have you put it in a osg::LightSource ?
Code:
int const LIGHTS = 1;
osg::StateSet *lightStateSet = scene-getOrCreateStateSet();
osg::Geode *lightMarker[LIGHTS];
osg::LightSource *lightSource[LIGHTS];
// Create Lights
osg::Vec4 lightColors[] = {osg::Vec4(1.0,1.0,1.0,1.0), osg::Vec4(0.0,
1.0, 0.0, 1.0), osg::Vec4(0.0, 0.0, 1.0, 1.0)};
for (int i = 0; i LIGHTS; i++) {
lightMarker[i] = new osg::Geode();
lightMarker[i]-addDrawable(new osg::ShapeDrawable(new
osg::Sphere(osg::Vec3(0.0, 40.0, 0.0), 5.0)));
osg::Material *light_material = new osg::Material();
light_material-setDiffuse(osg::Material::FRONT, osg::Vec4(1.0,
1.0, 1.0, 1.0));
light_material-setSpecular(osg::Material::FRONT, osg::Vec4(0.1,
0.1, 0.1, 1.0));
light_material-setEmission(osg::Material::FRONT, lightColors[i]);
lightMarker[i]-getOrCreateStateSet()-setAttribute(light_material);
lightSource[i] = new osg::LightSource();
osg::Light *light = new osg::Light();
// each light must have a unique number
light-setLightNum(0);
// we set the light's position via a PositionAttitudeTransform
object
light-setPosition(osg::Vec4(0.0, 40.0, 0.0, 0.3));
light-setSpecular(osg::Vec4(0.1,0.1,0.1,1.0));
light-setAmbient( osg::Vec4(0.2,0.2,0.2,1.0));
light-setDiffuse(lightColors[i]);
lightSource[i]-setLight(light);
lightSource[i]-setLocalStateSetModes(osg::StateAttribute::ON);
lightSource[i]-setStateSetModes(*lightStateSet,
osg::StateAttribute::ON);
lightTransform[i] = new osg::PositionAttitudeTransform();
lightTransform[i]-addChild(lightSource[i]);
lightTransform[i]-addChild(lightMarker[i]);
lightTransform[i]-setPosition(osg::Vec3(0, 0,200));
//lightTransform[i]-setScale(osg::Vec3(0.1,0.1,0.1));
scene-addChild(lightTransform[i]);
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=32364#32364
___
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] Lighting shader problem
Thanks for the correction, but the result is the same ... Aitor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32254#32254 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
Hi Aitor try this: Your code do the job in eye coordinate so eyePosition = vec3(0,0,0) and you don't need eyePosition uniform; bug fix: - ViewDirection = normalize(eyePosition - fvObjectPosition.xyz); + ViewDirection = normalize( - fvObjectPosition.xyz); HTH David Callu 2010/10/1 Aitor Ardanza aitoralt...@terra.es: Thanks for the correction, but the result is the same ... Aitor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32254#32254 ___ 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] Lighting shader problem
Hi,
I'm doing tests with shader for the lighting and the following problem happens
to me ...
With the camera close enough, all goes well, but if they turn away, do not seem
to take into account the position of the light.
Two images: the first up close, and the other from a distance and back lighting.
[Image: http://img227.imageshack.us/img227/3906/lighting1.jpg ][Image:
http://img266.imageshack.us/img266/7084/lighting2.jpg ]
vertex shader:
Code:
uniform vec3 eyePosition;
varying vec2 Texcoord;
varying vec3 ViewDirection;
varying vec3 LightDirection;
varying vec3 Normal;
varying vec4 color;
varying vec3 position;
void main( void )
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
Texcoord= gl_MultiTexCoord0.xy;
position = gl_Vertex.xyz;
vec4 fvObjectPosition = gl_ModelViewMatrix * gl_Vertex;
ViewDirection = normalize(eyePosition - fvObjectPosition.xyz);
LightDirection = normalize(gl_LightSource[0].position.xyz -
fvObjectPosition.xyz);
Normal = gl_NormalMatrix * gl_Normal;
float NdotL = max(dot(Normal, LightDirection), 0.0);
vec4 diffuse = NdotL * gl_FrontMaterial.diffuse * gl_LightSource[0].diffuse;
vec4 ambient = gl_FrontMaterial.ambient * gl_LightSource[0].ambient;
vec4 globalAmbient = gl_LightModel.ambient * gl_FrontMaterial.ambient;
vec3 fvReflection = normalize( ( ( 2.0 * Normal ) * NdotL ) -
LightDirection );
float fRDotV = max( 0.0, dot( fvReflection, ViewDirection ) );
vec4 specular = gl_FrontMaterial.specular * gl_LightSource[0].specular *
pow(fRDotV,200.0);
gl_FrontColor = diffuse + globalAmbient + ambient + specular;
}
Any idea what can be the problem?
Thank you!
Cheers,
Aitor
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=32224#32224
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
Hi Aitor, I'm definitely not a shader guy but how does your eyePosition variable ever get set?? Cheers, Greg -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32228#32228 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
Hi, I get it by : Code: osg::Vec3f eye; osg::Vec3f center; osg::Vec3f up; getCamera()-getViewMatrixAsLookAt(eye, center, up); if(!aniModel-getAvatar()-getOrCreateStateSet()-getUniform(eyePosition)-setElement(0,osg::Vec3(eye._v[0],eye._v[1],eye._v[2]))) osg::notify(osg::WARN) Update eyePosition: can't set uniform at 0 elements std::endl; Thanks your answer! Cheers, Aitor[/quote] -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=32231#32231 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
if(!aniModel-getAvatar()-getOrCreateStateSet()-getUniform(eyePosition)-setElement(0,osg::Vec3(eye._v[0],eye._v[1],eye._v[2]))) why not : if(!aniModel-getAvatar()-getOrCreateStateSet()-getUniform(eyePosition)-set(eye)) ? -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Lighting an HeighField.
Hello, I am creating a scene composed of two objects : - A (yellow) submarine, and a osg::ShapeDrawable created from an osg::HeightField : The Seabed. I use a spot light to illuminate this scene. The spot light is positinoned 1 meter above the submarine, the submarine is 10 meters above the seabed. My Submarine is a 3ds file correctly imported. My light is defined as : Code: osg::ref_ptr osg::LightSource m_spotAvant; osg::ref_ptr osg::Light m_lumSpotAvant; m_spotAvant = new LightSource; m_lumSpotAvant = m_spotAvant-getLight(); m_lumSpotAvant-setLightNum(0); m_lumSpotAvant-setPosition(Vec4f(0,0,-89,1)); m_lumSpotAvant-setDirection(Vec3f(0,0,-1)); m_lumSpotAvant-setSpotCutoff(90.); m_lumSpotAvant-setSpotExponent(50); m_lumSpotAvant-setConstantAttenuation(0.1); m_lumSpotAvant-setDiffuse(osg::Vec4(1.0f,0.0f,1.0f,1.0f)); m_spotAvant-setLocalStateSetModes(osg::StateAttribute::ON); I suppose to have a part of my submarine illuminated (because of the spotCutOff and the Spot exponent), and part of the seabed illuminated to. My Submarine is illuminated, but not the sea bed... It is completly black ! I decide to positione a cylinder created in this way : Code: osg::ref_ptr osg::Cylinder m_testCylindre = new osg::Cylinder(osg::Vec3f(0,0,-95), 5, 2); osg::ref_ptr osg::Geode m_gCylindre = new Geode; m_gCylindre-addDrawable(new osg::ShapeDrawable(m_testCylindre)); scene-addChild(m_gCylindre); So this cylinder is 5 meter below the submarine, and 5 meter above the seabed. The cylinder is well illuminated ! So why my cylinder is well illuminated, and not my seabed ? Both objects are osg::ShapeDrawable... Of course I try to find answer to this question looking in the OSG Examples. I try to run the osgspotlight example, and this sample seems to have the same behaviour. The HeightMaps is black, I can't see the spot light ! Best regards, A. BARRAL. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31926#31926 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting an HeighField.
Hi Adrian, The osgspotlight example that illustrates the use of multi-texturing to do a spot light, rather than just using OpenGL lighting to do the spot light. From your explanation I can't work out whether the osgspotlight example is working correctly on your system. When I run the example what I see is a cessna moving through a circle with a region of the terrain in front and below it light up, but the rest of the terrain is darkened by not completely black. If you aren't seeing the light up area then it sounds like very basic features of OpenGL are not working on your system and you need to look at the driver/hardware. As for the height field not being illuminated, there is no reason for this not to work if you've set up everything correctly. Personally I wouldn't use ShapeDrawable's for this type of work as they are just very primitive convenience classes, they don't scale well to handle complete rendering requirements or provide best performance. Robert. On Wed, Sep 22, 2010 at 9:18 AM, BARRAL Adrien a...@robopec.com wrote: Hello, I am creating a scene composed of two objects : - A (yellow) submarine, and a osg::ShapeDrawable created from an osg::HeightField : The Seabed. I use a spot light to illuminate this scene. The spot light is positinoned 1 meter above the submarine, the submarine is 10 meters above the seabed. My Submarine is a 3ds file correctly imported. My light is defined as : Code: osg::ref_ptr osg::LightSource m_spotAvant; osg::ref_ptr osg::Light m_lumSpotAvant; m_spotAvant = new LightSource; m_lumSpotAvant = m_spotAvant-getLight(); m_lumSpotAvant-setLightNum(0); m_lumSpotAvant-setPosition(Vec4f(0,0,-89,1)); m_lumSpotAvant-setDirection(Vec3f(0,0,-1)); m_lumSpotAvant-setSpotCutoff(90.); m_lumSpotAvant-setSpotExponent(50); m_lumSpotAvant-setConstantAttenuation(0.1); m_lumSpotAvant-setDiffuse(osg::Vec4(1.0f,0.0f,1.0f,1.0f)); m_spotAvant-setLocalStateSetModes(osg::StateAttribute::ON); I suppose to have a part of my submarine illuminated (because of the spotCutOff and the Spot exponent), and part of the seabed illuminated to. My Submarine is illuminated, but not the sea bed... It is completly black ! I decide to positione a cylinder created in this way : Code: osg::ref_ptr osg::Cylinder m_testCylindre = new osg::Cylinder(osg::Vec3f(0,0,-95), 5, 2); osg::ref_ptr osg::Geode m_gCylindre = new Geode; m_gCylindre-addDrawable(new osg::ShapeDrawable(m_testCylindre)); scene-addChild(m_gCylindre); So this cylinder is 5 meter below the submarine, and 5 meter above the seabed. The cylinder is well illuminated ! So why my cylinder is well illuminated, and not my seabed ? Both objects are osg::ShapeDrawable... Of course I try to find answer to this question looking in the OSG Examples. I try to run the osgspotlight example, and this sample seems to have the same behaviour. The HeightMaps is black, I can't see the spot light ! Best regards, A. BARRAL. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31926#31926 ___ 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] Lighting an HeighField.
Thanks for your answer... Now, osgspotlight example is working on my computer... (I didn't download the ressources file, shame on me). I will try to do exactly like in this sample, and I hope all wil be right ! So in this sample, they use a HeighMap and a osg::ShapeDrawable. You said that's not a good idea to use these classes : Personally I wouldn't use ShapeDrawable's for this type of work as they are just very primitive convenience classes, they don't scale well to handle complete rendering requirements or provide best performance What kine of OSG object do you use for that ? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31932#31932 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting an HeighField.
Hi Adrian, On Wed, Sep 22, 2010 at 10:32 AM, BARRAL Adrien a...@robopec.com wrote: Personally I wouldn't use ShapeDrawable's for this type of work as they are just very primitive convenience classes, they don't scale well to handle complete rendering requirements or provide best performance What kine of OSG object do you use for that ? It depends upon how much you want things to scale. For very large terrains, you'll want to use a paged databases, either using VirtualPlanetBuilder to build it off line, or using the 3rd party osgEarth NodeKit to do it runtime. For smaller terrain, such as under a million vertices, you can just use one or more osgTerrain::TerrainTile, or just create your own osg::Geometry directly. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting in osgViewer...
Thanks John. I'll give it a try. So I assume that this overrides the osgViewer default light settings? Thanks again for the help... -Shayne -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Tuesday, June 10, 2008 4:36 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] lighting in osgViewer... Shayne, If you really want to control lighting, you have to use osg::Light and osg::LightSource. If you look at the code for the example osglight you will see how those types of lights are set up. Say for instance, you want a constant, non-directional light. Copy the osglight example, but instead of what they do with the osg::Light, do: m_Light = new osg::Light(); m_Light-setLightNum( 0 ); // this will override the Look at me, I am the sun light. m_Light-setAmbient( osg::Vec4f( 1.0f, 1.0f, 1.0f, 1.0f ) ); m_Light-setDiffuse( osg::Vec4f( 0.0f, 0.0f, 0.0f, 0.0f ) ); and you don't have to worry about where it's located because it has 0 directional lighting. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC Sent: Tuesday, June 10, 2008 6:09 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] lighting in osgViewer... This may be a silly question but can anyone enlighten me on what osgViewer::setLight() does? Does it set the attributes for a global light source in the scene? I want to change the defaults in the viewer. Thanks in advance -Shayne smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] lighting in osgViewer...
This may be a silly question but can anyone enlighten me on what osgViewer::setLight() does? Does it set the attributes for a global light source in the scene? I want to change the defaults in the viewer. Thanks in advance -Shayne smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] lighting in osgViewer...
Shayne, If you really want to control lighting, you have to use osg::Light and osg::LightSource. If you look at the code for the example osglight you will see how those types of lights are set up. Say for instance, you want a constant, non-directional light. Copy the osglight example, but instead of what they do with the osg::Light, do: m_Light = new osg::Light(); m_Light-setLightNum( 0 ); // this will override the Look at me, I am the sun light. m_Light-setAmbient( osg::Vec4f( 1.0f, 1.0f, 1.0f, 1.0f ) ); m_Light-setDiffuse( osg::Vec4f( 0.0f, 0.0f, 0.0f, 0.0f ) ); and you don't have to worry about where it's located because it has 0 directional lighting. John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC Sent: Tuesday, June 10, 2008 6:09 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] lighting in osgViewer... This may be a silly question but can anyone enlighten me on what osgViewer::setLight() does? Does it set the attributes for a global light source in the scene? I want to change the defaults in the viewer... Thanks in advance -Shayne ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Lighting problem in obj and 3ds format
Hi, I have a few models made in 3D Studio and when I try to display someone in osgviewer or in my own application based on OSG library I get incorrect result. The lighting on surface has only two state - full enlightened or benighted. I get the same result with model exported as obj format. Is there any problem with normals,etc.? Can you test one of my model? You can download it from http://decibel.fi.muni.cz/~flasar/zidle.zip . Thank you for your help, Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting problem in obj and 3ds format
Hi Jan, Quoting Jan Flasar [EMAIL PROTECTED]: application based on OSG library I get incorrect result. The lighting on surface has only two state - full enlightened or benighted. I get the same result with model exported as obj format. Is there any problem with normals,etc.? As far as I can tell the normals aren't normalized properly (length != 1). But apart from that there are some bugs/omissions in the obj loader. I'm submitting fixes to Robert. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting behavior and osgViewer::osgViewer
Hi Christophe, The SVN and 2.1.x versions of the OSG have cleaned up light management in osg::View, the management of SceneView for rendering is also more exposed via osgViewer::Renderer. Robert. On 9/13/07, Christophe Medard [EMAIL PROTECTED] wrote: OK thanks, the code I was looking for to understand the whole thing lies inside osgUtil::SceneView.cpp. The chain is : osgViewer::Viewer::setUpRenderingSupport() -- osgUtil::SceneView::setDefaults() , on each SceneView the Viewer has... The _light member inside osgViewer::Viewer in the code as is, as far as I can see, isn't associated to any StateSet nor any LightSource so is useless for now (but maybe is to add itself to the SceneView::_globalStateSet one in the future versions of OSG). OK... Having multiple levels where things can be (osg::Light in this case) is a bit tricky indeed. Thanks for the help, I understand the mecanics... --- The ony thing that remains is that : - SceneView::_globalStateSet isn't set in any scenegraph the user can modify after osgViewer creation : it is used along display list (if I understand correctly, being still a little rookie), established through cullVisitor and alike - due to protection levels one cannot access easily to sceneViews and their _globalStateSet having a pointer to the mere Viewer. Therefore, in other words, using osgViewer as is, and remaining at the scene graph level isn't possible to solve the problem. The other alternative would be to override some function of osgViewer::Viewer or osgUtil::SceneViews but there again it's hard since the non-virtual status of concerned methods prevent their overriding... To sum up, it's quite hard to obtain a neutral lighting (but maybe also of other properties) with current version of osgView and osgViewer. Is there examples of OpenSceneGraph mainloops that don't use osgViewer as the core ?? (It would prevent to have to do those resettings...) I don't have seen any in http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.0.0/examples/ . -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 - Original Message - From: Paul Martz To: 'OpenSceneGraph Users' The fact that osgViewer/SceneView set up default lighting does seem to confuse many users, as your posting demonstrates. However, lighting state is really no different from any other state. You can control it in your own scene graph using standard OSG setMode, setAttribute, and setAttributeAndModes calls. StateSet::setMode( GL_LIGHTING, OFF ); // Disable the OpenGL lighting feature StateSet::setMode( GL_LIGHT_0, OFF ); // Disable OpenGL light 0 The above two calls disable the two features enabled in osgViewer/SceneView by default. If you want to leave lighting and light 0 enabled and simply control the light's attribute (position, color, etc) then you should use osg::Light and the osg::LightSource node as demonstrated in the osglighting example program. Hope that helps, Paul Martz ___ 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] Lighting behavior and osgViewer::osgViewer
Hi Christophe -- If I'm reading your email right, you have two concerns: 1. You don't understand how SceneView uses its _light member variable. Without digging into the code, I'm not sure either. But I suspect it circumvents the typical update/cull traversals and slaps the light state directly into the positional state of the draw traversal. As _light just controls GL_LIGHT_0, you don't need to access _light or even its StateSet -- you just need to specify your own alternate values for GL_LIGHT_0. 2. You seem to be unsure that you can fully control lighting and simultaneously use osgViewer. This is not the case, and again I direct you to the osglight example program, which uses osgViewer and overrides lighting effects directly in the scene graph. Hope that helps, -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard Sent: Thursday, September 13, 2007 2:57 AM To: OpenSceneGraph Users Subject: [osg-users] Lighting behavior and osgViewer::osgViewer OK thanks, the code I was looking for to understand the whole thing lies inside osgUtil::SceneView.cpp. The chain is : osgViewer::Viewer::setUpRenderingSupport() -- osgUtil::SceneView::setDefaults() , on each SceneView the Viewer has... The _light member inside osgViewer::Viewer in the code as is, as far as I can see, isn't associated to any StateSet nor any LightSource so is useless for now (but maybe is to add itself to the SceneView::_globalStateSet one in the future versions of OSG). OK... Having multiple levels where things can be (osg::Light in this case) is a bit tricky indeed. Thanks for the help, I understand the mecanics... --- The ony thing that remains is that : - SceneView::_globalStateSet isn't set in any scenegraph the user can modify after osgViewer creation : it is used along display list (if I understand correctly, being still a little rookie), established through cullVisitor and alike - due to protection levels one cannot access easily to sceneViews and their _globalStateSet having a pointer to the mere Viewer. Therefore, in other words, using osgViewer as is, and remaining at the scene graph level isn't possible to solve the problem. The other alternative would be to override some function of osgViewer::Viewer or osgUtil::SceneViews but there again it's hard since the non-virtual status of concerned methods prevent their overriding... To sum up, it's quite hard to obtain a neutral lighting (but maybe also of other properties) with current version of osgView and osgViewer. Is there examples of OpenSceneGraph mainloops that don't use osgViewer as the core ?? (It would prevent to have to do those resettings...) I don't have seen any in http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.0 .0/examples/ . -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 - Original Message - From: Paul mailto:[EMAIL PROTECTED] Martz To: 'OpenSceneGraph Users' mailto:osg-users@lists.openscenegraph.org The fact that osgViewer/SceneView set up default lighting does seem to confuse many users, as your posting demonstrates. However, lighting state is really no different from any other state. You can control it in your own scene graph using standard OSG setMode, setAttribute, and setAttributeAndModes calls. StateSet::setMode( GL_LIGHTING, OFF ); // Disable the OpenGL lighting feature StateSet::setMode( GL_LIGHT_0, OFF ); // Disable OpenGL light 0 The above two calls disable the two features enabled in osgViewer/SceneView by default. If you want to leave lighting and light 0 enabled and simply control the light's attribute (position, color, etc) then you should use osg::Light and the osg::LightSource node as demonstrated in the osglighting example program. Hope that helps, Paul Martz ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting behavior and osgViewer::osgViewer
In fact I was puzzled by the fact that if no directional Light is set in the scene graph, the one set transversally onto the draw traversal by the osgViewer (through the cull visitor, ie not in the scenegraph) becomes active. I was unsure about that indeed, but as you say it's not as soon as at least one light is present in the scene graph (GL_LIGHT0 == Viewer's HEADLIGHT if and only if no LightSource is present in the scene). Debugging a light effect where you can have to deactivate diffuse lights appear tricky not knowing that. Maybe a default behaviour of the viewer where lighting is OFF would have been clearer. Now I have the whole picture thanks to you and Robert, thanks. - Effectively, you can merely work into the scenegraph with osgViewer, since viewer.getCamera()-getOrCreateStateSet()-setMode(..) only activate things on attributes and modes not encountered in the loaded scenegraph ; those who are set in the scenegraph aren't reset by osgViewer. So does the osglight example work. - Debugging peacefully an ambient effect can be done : passing through viewer.getCamera()-getOrCreateStateSet()-setMode(..) works to disable the 'transversal' diffuse light established by the viewer. - viewer.setLightingMode() doesn't seem too work well, in v.2.0.0 nor 2.1.10 (it's not vital to me). Christophe - Original Message - From: Paul Martz To: 'OpenSceneGraph Users' Sent: Thursday, September 13, 2007 4:41 PM Subject: Re: [osg-users] Lighting behavior and osgViewer::osgViewer Hi Christophe -- If I'm reading your email right, you have two concerns: 1. You don't understand how SceneView uses its _light member variable. Without digging into the code, I'm not sure either. But I suspect it circumvents the typical update/cull traversals and slaps the light state directly into the positional state of the draw traversal. As _light just controls GL_LIGHT_0, you don't need to access _light or even its StateSet -- you just need to specify your own alternate values for GL_LIGHT_0. 2. You seem to be unsure that you can fully control lighting and simultaneously use osgViewer. This is not the case, and again I direct you to the osglight example program, which uses osgViewer and overrides lighting effects directly in the scene graph. Hope that helps, -Paul - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, September 13, 2007 3:28 PM Subject: Re: [osg-users] Lighting behavior and osgViewer::osgViewer Hi Christophe, I wouldn't recommended messing with SceneView unless you really have to. osgViewer now honours the Camera's StateSet, and this acts as the global StateSet. You can simply sets modes and attributes you want on the camera i.e. viewer.getCamera()-getOrCreateStateSet()-setMode(..); Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Lighting behavior and osgViewer::osgViewer
Hi all, I'm stuck with an issue that should be extremely simple, but anyway I don't get it. - How is running the default Lighting Mode set in osgViewer ? That class contains an osg::Light _light member that is instanciated but I can find anywhere its linking to the scene graph !? - What is the difference between HEADLIGHT and SKY_LIGHT ? The question is raised because I don't see indeed the _light member use... - Isn't it strange that osgViewer::setLightingMode(NO_LIGHT) doesn't unref and free the _light member ? The default is HEADLIGHT when the users instanciates his osgViewer : if right after he chooses setLightingMode(NO_LIGHT) before calling run(), _light is allocated even if it is not in use... - How can I deactivate the lighting set by default by the osgViewer ? I've been trying : osgViewer::Viewer viewer(arguments); viewer.addEventHandler(new osgViewer::XXXHandler); osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFiles(arguments); skyModel-setScene(loaded.get()); viewer.setLight(NULL); // 1 viewer.setLightingMode(NO_LIGHT); // 2 viewer.getCamera()-getOrCreateStateSet()-setMode(GL_LIGHTING, osg::StateAttribute::OFF); // 3 viewer.setSceneData( root.get() ); 1, 2 or 3 seems to be of no use , the default lighting coming with osgViewer adds itself to the one contained in my scene (loadedModel), which harass me to debug my scene content... Any help or explanation would be great, maybe I missed something obvious...? -- Christophe Médard Société OKTAL (http://www.oktal.fr) 2 impasse Boudeville 31100 Toulouse (France) Tél. : (+33) 5 62 11 50 10 Fax : (+33) 5 62 11 50 29 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] lighting example
Hello, can somebody tell me, where I can find the source code of the lighting example with the materials of the OSG quickstartguide? I have searched the webpage, but haven't found anything. Thanks. Marcus ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
