[osg-users] Lighting problem

2011-11-15 Thread Hartmut Leister
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

2011-11-15 Thread Chris 'Xenon' Hanson
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

2011-11-15 Thread Ulrich Hertlein
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

2011-11-15 Thread Shayne Tueller
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

2011-09-29 Thread Poirier, Guillaume
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/PKe|:?7”%Ž)prerenderbin/CMakeLists.txt•TMoÚ0¾#ñ,Æ!½Pm“vëÁI
ÍâÈvPw²Râ¶ÖH’ 
vCü÷½v€@Ú‰Ä~ž÷ێýNá¬+U©SՓ.n†ƒá`™§?•Ìu¡óM.+õk£+•9Âx@#ôeòmòÕçØcԘ͈a=ÀËe˜„K‰#_úî
µ 4¥Œ`ïÞYé'4Þí
ÏU3ÎxÛâ;T®ë?*C£ñä»ÊÔÓæåðw¼õæøHŸ¸ÉLƔ‹ið¸Yë$òOÀ‡ƒô³ƒ*y
¸àà˜D‹-å3É(O›I®ê:}QšbCI£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®Ìjžz½Y¥Ð˜áàÄ·I6ˆóAöÚÒ$òÑç#–pGp4˜0‚\JC4JjeèV;†‚,0yQ·;8砝ÞKeWÃNفÿ£45…§Uv
 Èl°œçÊa‚!n÷Ob„„Zs2Ã-‹ƒÎN±9h}Ù8Ë “íÃé_R’3Ï“å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(½+UK¤ò:
   ¼£%ÙH4‡½)‹`5sYÄȃ‹!—7ðȊ‘…«ù]Öûß³!Ëpî°¯=΅÷þÖGò7žÇ¡
ÒÝ[÷ÊÐ/¸кP©òV+‡ú‰«{Z‚2/öÊ«IW됉“‘xÒhû`úl­|
XƒÜ0÷„lƒÈãÛYðiR›ï=rŠ+öUłô­T8»bȶT­ŠáN]¦rjE ›7É$VëX™ók’x¨’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=ÍûƒΓ¹3˜9vCWANœÅŠ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$ƒ5”n—(½Éj:lýFœ¼þ_ÎóÿÄX¤ýY,w#3AZÆbuƒÚä÷×.JEª›Ô
Eå8¼Ü\)Bî\£ê:å\•Ê2dé °¾1k—X,^[A¤ˆ¾l‚Ks)¯ÁV|Èë¡ՀPI”ÏÎ)
Ƀó³8Õn‘n4è½*÷. Pl¯2 V±é`JïH2uœ”Ó,UP»tµXFD›@=|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Ó9“O:f°±Zíý̆‹T Î­f1^'}ž–ØøǸ§eÊ’Óe§p™'-]6Iu:ÓÁ¨ë
_æÓÓfï'BßÁ¹K±òô,ƒéï*@ó!VШIQû-}Ÿ?¤ö›z:èí1a½¼‘ÐGíàJ•¢®_–¹
v±¸˜š¥bôØÅÌ̈ÕÛ»¬)žOgà[×o¨K…yÆ¢®™ª1YLàüLëóLí³4*šu§Òùü¤³ÿúW«u0IÌrj»°¿ai
   
lгú`P¡ab.Ut­cjMØ¿Ñ7Èò¹u(™ß$k÷Ñl2zå`²h7hKôõlíã­ìP)3ŠÅMhœë*}C2áUv÷ŽyØ6ðM`F™ûƒƒØüéäw“?+ê¶Í½¶?`r?îlüµ¤VÞÏ/BN•éZ¶ù’\G¥jHØ{¦åJˆf÷µÞ”¨@`{JvX
 
º$ÂÓ¼¬Il¤IBQÁPËݐ=’¾=YÉ3U‹P!Ēw®ÙÓÈ#g2º¦ %¦Ñ’¶®8X%KŽd“Ÿò©³Ü*Õÿãæ•ã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à‡ã3Hˆ0ä[|²…+Ä
À=‚,_™4 à±DÃã›ßBĺ~|‰8(5U6ق…ýœ~,f‡ÝH®„!|‘÷b—Oª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@s†k—C!Ä8AùÖ{˜ä$‘q9$¤®@cBUp!ßAszS»©XÀ‡Ù”‡²žÒæÏØ6ZCSP”ŠþÔ䁏آ÷teB,çêêh+ÞÊÏYòˆÃïÍp4‚ÌO
¯È”‚Kú\ä”F‰µÍ2žÚ3Æñ×$Xó·Ø×5sQtÅ1†Øj­Î¡šžq困£hD´÷š‰Ì?À1sk±
$³3ˆŒmÑ

Re: [osg-users] Lighting problem when using help or stats handler

2011-09-27 Thread Poirier, Guillaume
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í’ÚÖÌgprerenderbin/ALL_BUILD.vcprojí]]sÒ@}®3þ‡

:ŽŽ´U«Ø¢„*#(Ty`¦Âk“lÜM*õã¿{7›h¡$m¿öÅI²wÏÝ{ïîa÷@ãÑë™miçˆ2Lœrn¯°›Óc’vZYË}ÂΈ|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/N˜1®Ç•f·O
j˜0˜.òʹý _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Ï ä՝sL‰c#¦à“°é
žÂêfnŒÁjž¡÷:'Qwf6 
,¬9~ó¨àYÃÀîêJŒ¼EÆQ^ä8ÓÐHo6uÃ3b+þZËcÃDD€ÇxÒ).˜aÍÅ+¬Ögª̬ú98ãÍ×Û6±s–È”0o%îQq‰{®gÀ²ÁÐZœ[¤`Á°‡âÁLx0ÌfR
ͮȡbCņײ!°OȦË5„¥àĸ“¢ÅLh1NhRfŒ{(r\IŏŠ7í?ao
G‹†3k9ò²a
ž\2®\NjR¾\î¥8ssFoþ×¼y鑐#y0ÁՎ¸ð0Àæµ
oº4}áQä@ևØÔZÆ
±Ú‚ùó[óÏ
ÞÌ #œ+ÜU-
íã„]·ÜÃf1“bWPo
ja¬u|iµ—Åh°ÅÅÁ—ÂÚ±¡àV,@Є¶$M{8{qðH«íÒ硛6ÜÐ
‰Zþí:ÇZ¾º¾)oN‘y–gža»ù1xӒTq®ÞBÐïÁ½Ù®~Èÿ­ⱆ(%ÔBçÈÒö´
ñˆö’s¢K¨WçMQä1êÈå^ 
qµ‹Á§#éÊóûù`',vKÇðÍ¿,4lñÔµ{ÁdgŽ¿[ÀNˆœ¤|Wºg2žy¼µèƒ/óy­ªØ9ñ°Å2ŸûÆ)#HÉj¿ÿ—æµß¿}fû}
 
¹K ëÖM¾¢vðy‘y‚í6³g‚èKÁø‚4Óê]Ææƙ:¥•”÷ˣϛ–øla—×|G•vnOw|ב5‹bžœ¤®˜nóÄþ-
¾!%NÓp
☚ýæˆBJæè8GÂ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’í§’·Rž5²‚ÏVÉ[²æƒ’·6zØö¡SFԑ3µ%oe”Ͷ’·Ân›i$îפñ¢ä-¹òVü#o¥p)…K)\Jáúã÷cJáR
W’¨R¸R7²‚ÏV)\²æƒR¸6zØö¹SFÔ©3µ¥pe”ͶR¸Ân›i$îפñ¢.¹
×òŸä*•K©\JåR*׿'S*—R¹’ìB•Ê•òȑ|¶°Jå’5”ʵÑöϞ2ê Nž©½(•+£l¶•Ê•vÛL#qטּ¥rÝN嚿ÖKè]0/^¿(ÒÔá
ƒðƵ[½ìÒÆ
üžW‚i†eiÑHW*h·—VEz£²Î!6Wtg³n™ížþI”ñóÆÿ1²Dô1—‹T]L
7ác\¾±ÈаÄu1¾9*®ø?xàù/PK:Y;?O†ë½Ç‰
4prerenderbin/ALL_BUILD.vcproj.DSNRCCA.poiriergu.userí–QOÛ0ǟ‹Äw¨üŠÖ¦06mJŠ²vh•–©k€¾ðb’kâͱ#Û)ñá¹$Ő¶€*ñ˜H‰r¿óï.EvÏVï.Ai…G=‡tAD2fñȜ‰XÞêOƒãÓcr6p¯˜.(M3y©A3‡©’ÿ
 2w9x¤^Ót]=åþÖsœ„©¼õ9/#µG”k(ñow$ł%…¢Ct‰6XI

Re: [osg-users] Lighting problem when using help or stats handler

2011-09-22 Thread Jean-Sébastien Guay

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

2011-09-21 Thread Poirier, 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...

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

2011-09-19 Thread Poirier, Guillaume
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

2011-09-19 Thread Paul Martz

  
  
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

2011-09-19 Thread Poirier, Guillaume
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

2007-10-11 Thread Jan Flasar
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

2007-10-11 Thread Ulrich Hertlein
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