[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÷ObZs2Ã-Î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%]:ÊÕÚS2ßò[-Ì},}ë¾Ã±Öe°íEh,#æiôáj¾~ kÈ:ÌÛÈNGoÜ«ÜxH=¯/è ÌÒ®`T1Ç(ë!dÂæü5sïX7nÛðåË÷Nì[[ö ì´ZÀ9ò3¦®-ÆlFTDZ25=-F lµ´ì)Ê©ç l=Íûι39vCWANÅu:ÓÓ;^L'Î çú{¨8ÃñãÿAûÑh0îÿá4 NwÜd MùÇK¬MIL2/ ¥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- !2fl¯ 5Åä2ZuÌm|¶Å¡vKÈâ[5çtNZ!-±0v#]C áqú¶Ä¸m·ÛdÀåÄá ÔUº ÅHÁRäªA YÎ$P ]xN@skC!Ä8AùÖ{ ä$q9$¤®@cBUp!ßAszS»©XÀÙ² ÒæÏØ6ZCSPþÔäØ¢÷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- íã]·ÜÃf1bWPo 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×|GvnOw|×5b¤®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¸R7²Ï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
[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