Re: [osg-users] osgVolume not working with latest ATI Radeon drivers on Windows
Note that I have a warning when I run osgvolume: OpenSceneGraph-3.0.1-Win64\binosgvolume C:\images\image.jpg Max texture size=8192 Max texture size=8192 (0.431373 0.427451 0.403922 1) (1 1 1 1) C:\images\image.jpg Min value 0.431373 0.427451 0.403922 1 Max value 1 1 1 1 Single image 1 volumes. Locator::computeLocalBounds Warning: RenderBin DepthSortedBin implementation not found, using default RenderBin as a fallback. Can anyone with an ATI card and 5 minutes to spare tell me if they can load an image with osgvolume and the most recent drivers (I am using 8.951.0.0 08/03/2012) ? Note that you will have to drag and rotate the initial view to see the image slice... cheers, guillaume From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier, Guillaume Sent: April-18-12 4:23 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgVolume not working with latest ATI Radeon drivers on Windows Hello OSG users, osgvolume does not work for me with an ati card and found the following thread in the archives which sounds like the same issue but unfortunately without a solution: http://forum.openscenegraph.org/viewtopic.php?t=8913start=0postdays=0postorder=aschighlight= I am using Windows Vista 64 with a ATI Radeon HD 5800 with the most recent Catalyst driver and get a black screen whenever I load a stack of images in osgvolume. The volume displays fine with a GeForce card. Other people have had similar issues ? cheers, guillaume ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume not working with latest ATI Radeon drivers on Windows
Hello OSG users, osgvolume does not work for me with an ati card and found the following thread in the archives which sounds like the same issue but unfortunately without a solution: http://forum.openscenegraph.org/viewtopic.php?t=8913start=0postdays=0postorder=aschighlight= I am using Windows Vista 64 with a ATI Radeon HD 5800 with the most recent Catalyst driver and get a black screen whenever I load a stack of images in osgvolume. The volume displays fine with a GeForce card. Other people have had similar issues ? cheers, guillaume ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture image memory leak issue
Thanks for your input. I've upgraded from OSG 2.9.8 to 3.0.1 and the issue seems to be gone... -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Filip Arlet Sent: December-12-11 3:56 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Texture image memory leak issue Hi, if you check your program on memory leaks (for example with visual leak detector) and don't find any leaks, it's probably fine. The problem is in memory management. There are many things that can cause increasing memory: 1) Creating any type of object or buffer on GPU is slow operation, so osg recyclates them. 2) Acquiring memory from OS is slow operation. c++ library is usually very hungry and call of delete doesn't have to return memory to OS. 3) fragmentation - you can only get whole memory pages. If you allocate something persistent in page, you cannot return it and this is something you can't solve without custom heap only for your 3D texture. 4) when you do huge allocation request, it's very likely that you can do it again, so OS or C++ library can optimalize next request. Cheers, Filip -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44334#44334 ___ 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] Texture image memory leak issue
Hello all, We are using quite large 3D textures in our application loaded from images (a couple hundred MB). On reload the texture / underlying image are deleted and we can see that the Texture3D destructor is called properly and that the application memory is released looking at the process in the Windows Task Manager. However, the global memory of the computer keeps on increasing with each reload which might point to a possible graphics driver memory issue. I was wondering if other people have had similar experiences... We are using a 64-bit release OSG 2.9.8 under Windows Vista Ultimate 64-bit SP2 with a GeForce GTX580 driver version 285.62. cheers, bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG question on asynchronous texture readback
Hi, I checked the osgscreencapture example (from 2.9.8). It seems to only work asynchronously if I use the --rgba flag (time for read pixels = 0.045694ms time for memcpy = 1.5924ms) which sets the pixel format to GL_BGRA. Any other combination and the read-back slows down quite significantly (time for read pixels = 8.7473ms time for memcpy = 1.2335ms). My case is slightly different since I am trying to read-back from a FBO float texture instead of the framebuffer directly. I tried using GL_RGBA32F_ARB as internal format, GL_BGRA as source format, and GL_FLOAT as source type, ping-ponging between 2 PBOs and textures, and doing the read-back in the first camera but without success... Has anyone managed to read a texture asynchronously into a PBO and could suggest ideas ? cheers, guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P. Delport Sent: October-20-11 12:54 AM To: Poirier, Guillaume Cc: osg users Subject: Re: [osg-users] OSG question on asynchronous texture readback Hi, the GPURegionOfInterestCallback does not do async read at the moment, but you can have a look at the osgscreencapture example. Specifically check the code path for the --double-pbo command line option. Also see this page, it has the best explanation of async pbo I've come across. http://www.songho.ca/opengl/gl_pbo.html Getting data from GPU to CPU is still a bottleneck for many apps, make sure you send back as little as possible. cheers jp On 19/10/2011 19:13, Poirier, Guillaume wrote: Hello J-P, I saw on the OSG forum archives your GPURegionOfInterestCallback code. Can it provide asynchronous GPU - CPU readback ? I don't know much about PBO and I currently does the readback by simply attaching an image to my RTT camera, however it slows down the application significantly. Can you show an example of how to use the GPURegionOfInterestCallback ? cheers, guillaume -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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 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$Å%
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
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] Question on optimizer flatten static transforms and line intersections
Hello OSG users, I extract geometries from the scene graph and perform some line intersections directly on them. If there are some transformations above in the tree then the intersections will not take them into account. I'd like to use osgUtil::Optimizer::FLATTEN_STATIC_TRANSFORMS so that the geometries are flattened and the intersections work on the transformed/flattened geometries. So I do: // Create a node visitor to set all transforms to static in scene. // Optimize osgUtil::Optimizer optimzer; optimzer.optimize(pScene.get(), osgUtil::Optimizer::FLATTEN_STATIC_TRANSFORMS | osgUtil::Optimizer::MERGE_GEOMETRY | osgUtil::Optimizer::CHECK_GEOMETRY | osgUtil::Optimizer::MAKE_FAST_GEOMETRY); // Gather geometries. // Do intersections. When I do this the geometries look transformed/flattened but the line intersections do not. However, if I write / read the scene to disk before I gather geometries then the intersections are good (transformation/flattened): // Optimize // ... osgDB::writeNodeFile(*pScene.get(), tmp.osg); pScene = osgDB::readNodeFile(tmp.osg); // ... I'd rather not do that ! What am I missing here ??! cheers, bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgUtil::Optimizer::MergeGeometryVisitor
Hello OSG community ! Just a quick question on the MergeGeometryVisitor. What is it supposed to do exactly ? My expectation is that it will merge all geometry drawables of a geode into one ? I created and exported a simple cube in 3DSMax. The file has one geode and 6 drawables, one for each face. osg::ref_ptrosg::Node pScene = osgDB::readNodeFile(cube.3ds); // create a geode and add all pScene geometries to it as drawables // [...] // attempt to merge geometries pScene = 0; osgUtil::Optimizer::MergeGeometryVisitor mgv; mgv.setTargetMaximumNumberOfVertices(100); mgv.mergeGeode(*createdGeode.get()); At this point the createdGeode still has 6 drawables... It looks like the mergeGeode() function can only return false, which is not very helpful, and does not really tell you if there is a problem with the input and what it might be. It seems that geometryContainsSharedArrays() returns true for all my geometries, which might be why it does not do what I want. So, is it my expectation of what the MergeGeometryVisitor does that is erroneous ? It does not like my input somehow ? Anyone has an idea or suggestion ? cheers ! bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgVolume write isosurface to mesh file
Hi, I'd like to know if osgVolume can write an isosurface to a mesh file. cheers, bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MatrixTransform and particle system
Hi Tom, Thanks for helping out. I am indeed using a ModularEmitter and ParticleSystemUpdater. I was doing something like: effect-addChild(emitter); effect-addChild(program); effect-addChild(updater); geode-addChild(particleSystem); transform-addChild(geode); effect-addChild(transform); root-addChild(effect); I was expecting that if with no transform the particles are emitted towards +Z say, then I could add a rotation transform to emit them towards the +X axis for example. Not sure what was the problem with adding a MatrixTransform. The behavior was add one geode, the particles go towards +Z. Add a parent rotation to move towards +X, the particles still emit towards +Z. Now add another geode with particle system before previous one (no transform), and particles are emitted both towards +Z and +X (see first post)... What I did to solve my problem is that I computed the theta and phi angles of the desired rotation and set the emitter to those values using setThetaRange() and setPhiRange(). This works as intended. Either there is something I was doing wrong / not understanding before, or maybe there is a bug somewhere in osgParticle... cheers ! bill From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jolley, Thomas P Sent: October-06-09 11:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] MatrixTransform and particle system Hi Bill, Do you have a ModularEmitter and ParticleSystemUpdater? If so, where are they in the scene graph? Are you expecting the particles, after being emitted, to move with the transform or stay in the world coordinate system. Tom Jolley From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier, Guillaume Sent: Monday, October 05, 2009 12:09 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MatrixTransform and particle system Yes sorry I should have mentioned that... I am using 2.8.2. cheers ! bill From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jolley, Thomas P Sent: October-05-09 12:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MatrixTransform and particle system Hi Bill, What version of osg are you using? Tom Jolley From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier, Guillaume Sent: Monday, October 05, 2009 11:18 AM To: OpenSceneGraph Users Subject: [osg-users] MatrixTransform and particle system I am trying to apply a transform to a particle system like this: _transform = new osg::MatrixTransform; _transform-setMatrix(osg::Matrix::rotate(fromDir, toDir)); _geode = new osg::Geode; _geode-addDrawable(particleSystem.get()); _transform-addChild(_geode.get()); addChild(_transform.get()); Unfortunately adding the transform does not transform my particles... However if I add another geode like this before the previous code: osg::ref_ptrosg::Geode pDummy = new osg::Geode; pDummy-addDrawable(particleSystem.get()); addChild(pDummy.get()); Then I have one set of transformed particles and one set of untransformed ones. Probably I am missing something simple here ? Anyone has a suggestion ? cheers ! bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MatrixTransform and particle system
Thanks Tom ! So the transform is applied to the emitter, not the geode / drawable... This makes sense :-) cheers ! bill From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jolley, Thomas P Sent: October-06-09 3:19 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MatrixTransform and particle system Hi Bill, I think what you want is to put the ModularEmitter under a Transform. A Geode with the ParticleSystem will be a sister to the Transform. Make sure the ModularEmitter has a reference to the same ParticleSystem in the Geode. The ParticleSystemUpdater will also need a reference to the ParticleSystem. You can control the direction (and position) of the particles with the Transform. I usually use a MatrixTransform. Tom Jolley From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier, Guillaume Sent: Tuesday, October 06, 2009 1:25 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MatrixTransform and particle system Hi Tom, Thanks for helping out. I am indeed using a ModularEmitter and ParticleSystemUpdater. I was doing something like: effect-addChild(emitter); effect-addChild(program); effect-addChild(updater); geode-addChild(particleSystem); transform-addChild(geode); effect-addChild(transform); root-addChild(effect); I was expecting that if with no transform the particles are emitted towards +Z say, then I could add a rotation transform to emit them towards the +X axis for example. Not sure what was the problem with adding a MatrixTransform. The behavior was add one geode, the particles go towards +Z. Add a parent rotation to move towards +X, the particles still emit towards +Z. Now add another geode with particle system before previous one (no transform), and particles are emitted both towards +Z and +X (see first post)... What I did to solve my problem is that I computed the theta and phi angles of the desired rotation and set the emitter to those values using setThetaRange() and setPhiRange(). This works as intended. Either there is something I was doing wrong / not understanding before, or maybe there is a bug somewhere in osgParticle... cheers ! bill From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jolley, Thomas P Sent: October-06-09 11:55 AM To: OpenSceneGraph Users Subject: Re: [osg-users] MatrixTransform and particle system Hi Bill, Do you have a ModularEmitter and ParticleSystemUpdater? If so, where are they in the scene graph? Are you expecting the particles, after being emitted, to move with the transform or stay in the world coordinate system. Tom Jolley From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier, Guillaume Sent: Monday, October 05, 2009 12:09 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MatrixTransform and particle system Yes sorry I should have mentioned that... I am using 2.8.2. cheers ! bill From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jolley, Thomas P Sent: October-05-09 12:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MatrixTransform and particle system Hi Bill, What version of osg are you using? Tom Jolley From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier, Guillaume Sent: Monday, October 05, 2009 11:18 AM To: OpenSceneGraph Users Subject: [osg-users] MatrixTransform and particle system I am trying to apply a transform to a particle system like
[osg-users] MatrixTransform and particle system
I am trying to apply a transform to a particle system like this: _transform = new osg::MatrixTransform; _transform-setMatrix(osg::Matrix::rotate(fromDir, toDir)); _geode = new osg::Geode; _geode-addDrawable(particleSystem.get()); _transform-addChild(_geode.get()); addChild(_transform.get()); Unfortunately adding the transform does not transform my particles... However if I add another geode like this before the previous code: osg::ref_ptrosg::Geode pDummy = new osg::Geode; pDummy-addDrawable(particleSystem.get()); addChild(pDummy.get()); Then I have one set of transformed particles and one set of untransformed ones. Probably I am missing something simple here ? Anyone has a suggestion ? cheers ! bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MatrixTransform and particle system
Yes sorry I should have mentioned that... I am using 2.8.2. cheers ! bill From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jolley, Thomas P Sent: October-05-09 12:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] MatrixTransform and particle system Hi Bill, What version of osg are you using? Tom Jolley From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Poirier, Guillaume Sent: Monday, October 05, 2009 11:18 AM To: OpenSceneGraph Users Subject: [osg-users] MatrixTransform and particle system I am trying to apply a transform to a particle system like this: _transform = new osg::MatrixTransform; _transform-setMatrix(osg::Matrix::rotate(fromDir, toDir)); _geode = new osg::Geode; _geode-addDrawable(particleSystem.get()); _transform-addChild(_geode.get()); addChild(_transform.get()); Unfortunately adding the transform does not transform my particles... However if I add another geode like this before the previous code: osg::ref_ptrosg::Geode pDummy = new osg::Geode; pDummy-addDrawable(particleSystem.get()); addChild(pDummy.get()); Then I have one set of transformed particles and one set of untransformed ones. Probably I am missing something simple here ? Anyone has a suggestion ? cheers ! bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
My question is: If I have 1024 slices as 1024 png image files, how do I load them in osgvolume ? Sorry this is trivial... Also I noticed a typo in osgvolume.cpp, REPLACE_ALPHA_WITH_LUMINANACE. cheers ! guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-18-09 6:12 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgVolume ready for testing Hi Guillaume, I'm sorry but your explanation doesn't mean anything to me, I just don't understand the problem you have that your are trying to solve. Please also remember the osgvolume example is just an code example, it's not a tool, you as programming will be using the osgVolume NodeKit, it's up to you how your app assembles it's data. Robert. On Mon, Aug 17, 2009 at 6:14 PM, Poirier, Guillaumeguillaume.poir...@nrc-cnrc.gc.ca wrote: Sorry I meant that you can do something like: osgvolume --images data/*.png or osgvolume --images data/data_000.png And it would load all 256 slices from data_000.png to say data_255.png. guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-17-09 1:04 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgVolume ready for testing Ho Guillaume, On Mon, Aug 17, 2009 at 4:58 PM, Guillaume Poirierguillaume.poir...@nrc.ca wrote: Sorry for the simple question... I am trying to load a list of images using the --images flag. Looking at the osgvolume.cpp code in 2.8.2, I don't see how it can detect *.png like you mentioned, or detect the list of slices from the filenames. Am I right on this ? It doesn't need to detect the image file type, it just passes the filename to readImageFile() and it's does the reading via the OSG's normal plugin mechanism. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Thanks. The typos are on lines 687, 689, 695, and 930. guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-18-09 10:02 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgVolume ready for testing Hi Guiillaume, On Tue, Aug 18, 2009 at 2:52 PM, Poirier, Guillaumeguillaume.poir...@nrc-cnrc.gc.ca wrote: My question is: If I have 1024 slices as 1024 png image files, how do I load them in osgvolume ? Sorry this is trivial... osgconv --image *.png is how I'd do it... Also I noticed a typo in osgvolume.cpp, REPLACE_ALPHA_WITH_LUMINANACE. ? Which line numbers?? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
I got the source from http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGrap h-2.8.2.zip In osgvolume.cpp. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-18-09 10:53 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgVolume ready for testing On Tue, Aug 18, 2009 at 3:40 PM, Poirier, Guillaumeguillaume.poir...@nrc-cnrc.gc.ca wrote: Thanks. The typos are on lines 687, 689, 695, and 930. And which version of the OSG are you talking about??? These line numbers don't make sense for the svn/trunk version. The best way to point to an issue like this is to fix and then provide the changed file. As a general note, I'm not diagnosed but have many of the traits of dyslexia, this comes out in practice with me making typo/spelling mistakes that I never spot on review myself, it's only via spell checkers in email clients that I can hide how many mistakes I make in general mail, with coding alas there is no such safety net... so for code it's the community that have the eagles eyes and spot and correct my mistakes. Thankfully C++ compilers catch the vast majority of actual coding typo's, so it tends to be just variable names, or comments that you'll see mistakes in, in the case of variable name typo's, they be carried over to all instances otherwise it wouldn't compile. Curiously we don't actually see many bugs introduced due to me problems with spelling ineptitude, with is lucky really... ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Yes. I will be testing the osgVolume in the next couple days, this looks exciting :) cheers ! guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-18-09 11:11 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgVolume ready for testing Hi Guillaume, Just to be clear, it looks to me that the typo was LUMINANACE (an extra A crept in) which should be LUMINANCE. Robert. On Tue, Aug 18, 2009 at 4:01 PM, Poirier, Guillaumeguillaume.poir...@nrc-cnrc.gc.ca wrote: I got the source from http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGrap h-2.8.2.zip In osgvolume.cpp. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-18-09 10:53 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgVolume ready for testing On Tue, Aug 18, 2009 at 3:40 PM, Poirier, Guillaumeguillaume.poir...@nrc-cnrc.gc.ca wrote: Thanks. The typos are on lines 687, 689, 695, and 930. And which version of the OSG are you talking about??? These line numbers don't make sense for the svn/trunk version. The best way to point to an issue like this is to fix and then provide the changed file. As a general note, I'm not diagnosed but have many of the traits of dyslexia, this comes out in practice with me making typo/spelling mistakes that I never spot on review myself, it's only via spell checkers in email clients that I can hide how many mistakes I make in general mail, with coding alas there is no such safety net... so for code it's the community that have the eagles eyes and spot and correct my mistakes. Thankfully C++ compilers catch the vast majority of actual coding typo's, so it tends to be just variable names, or comments that you'll see mistakes in, in the case of variable name typo's, they be carried over to all instances otherwise it wouldn't compile. Curiously we don't actually see many bugs introduced due to me problems with spelling ineptitude, with is lucky really... ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume ready for testing
Sorry I meant that you can do something like: osgvolume --images data/*.png or osgvolume --images data/data_000.png And it would load all 256 slices from data_000.png to say data_255.png. guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: August-17-09 1:04 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgVolume ready for testing Ho Guillaume, On Mon, Aug 17, 2009 at 4:58 PM, Guillaume Poirierguillaume.poir...@nrc.ca wrote: Sorry for the simple question... I am trying to load a list of images using the --images flag. Looking at the osgvolume.cpp code in 2.8.2, I don't see how it can detect *.png like you mentioned, or detect the list of slices from the filenames. Am I right on this ? It doesn't need to detect the image file type, it just passes the filename to readImageFile() and it's does the reading via the OSG's normal plugin mechanism. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LineSegmentIntersector with transformations
Hello, I am trying to use a LineSegmentIntersector and want to specify start and end points in world space coordinates. Aditionally, the Drawable I want to intersect has parent nodes with transformations (translate / rotate / scale). How can I achieve this ? regards, bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Ideas for glow effects on 3D objects
Hi Paul, I would suggest that you check the nvidia shader library where there are many glow effects. Usually it is done in screen space with some blur and additive colouring. http://developer.download.nvidia.com/shaderlibrary/webpages/shader_library.html bill From: osg-users-boun...@lists.openscenegraph.org on behalf of Paul Griffiths Sent: Thu 5/14/2009 4:19 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Ideas for glow effects on 3D objects Hi, Im creating a music application, below is a screenshot, im after a glow effect for my enabled buttons. does anyone have any ideas? Anything goes just don't want to use up too many gpu cycles though. [Image: http://img401.imageshack.us/img401/8212/pichbu.jpg ] ... Thank you! Cheers, PaulG -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=12150#12150 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sketchup rendering
Hi Serge, You could probably achieve that look with flat shading (maybe some color quantization) combined with edge / silhouettes / creases extraction. Check out something like http://postulate.org/silhouette.php From: osg-users-boun...@lists.openscenegraph.org on behalf of Serge Lages Sent: Thu 2/5/2009 1:29 PM To: OpenSceneGraph Users Subject: [osg-users] Sketchup rendering Hi all, I would like to have some advices on how to render a scene with the same look and feel than Sketchup (very bright, black edges... I've attached a screenshot showing it). I looked at the Cartoon effect into osgFX but the result is really not the same. Any ideas on how to achieve it ? -- Serge Lages http://www.tharsis-software.com http://www.tharsis-software.com/ winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Framestamp time non-increasing
Any idea why in Windows the simulation / reference time is not always
increasing ?
I tested in Linux and it works fine as expected... I base an animation on it is
it is
jerky. The frame number is always increasing properly but not the time.
I do
void Update::operator() (osg::Node* node, osg::NodeVisitor* nv)
{
const osg::FrameStamp* fs = nv-getFrameStamp();
float currTime = fs-getSimulationTime();
// ...
traverse(node,nv);
}
bill
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] custom drawImplementation with multiple shaders
Hello, I have a class deriving from Drawable. In the drawImplementation(), I'd like to render 2 objects, with 2 different programs (and different textures, uniforms). What is the best way to do this ? I tried: pProgram1-apply(state); // draw something pProgram2-apply(state); // draw something else emptyProgram-apply(state); This works but is it the best / correct way ? regards, bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom drawImplementation with multiple shaders
Thanks Robert. Yes I understand why using a state set is better. Would it also be possible to use state.pushStateSet(prog1SS) and popStateSet(prog1SS) in a drawImplementation() function or this is not intended to be used like that ? regards, bill From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield Sent: Mon 12/22/2008 1:16 PM To: OpenSceneGraph Users Subject: Re: [osg-users] custom drawImplementation with multiple shaders Hi Bill, Just use attach your Drawable the scene graph without a StateSet, then use two Geode's that decorate your Drawable, each Geode will have a StateSet with program one and the second will have program two. This mechanism is far more flexible that embedded state into Drawables, and it also wont' break any of the OSG's lazy state updating. It will also provide the best performance as the OSG will be able to do state sorting and lazy state updating, something you can't do if you embed state into Drawables. Robert. On Mon, Dec 22, 2008 at 4:12 PM, Poirier, Guillaume guillaume.poir...@nrc-cnrc.gc.ca wrote: Hello, I have a class deriving from Drawable. In the drawImplementation(), I'd like to render 2 objects, with 2 different programs (and different textures, uniforms). What is the best way to do this ? I tried: pProgram1-apply(state); // draw something pProgram2-apply(state); // draw something else emptyProgram-apply(state); This works but is it the best / correct way ? regards, bill ___ 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 winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] BlendEquation with RGBA_MIN / RGBA_MAX
Hello Robert et al.,
I am trying to get in a texture the minimum and maximum depths for each texels.
I render my scene to a FBO using
a float texture (GL_RGBA32F_ARB). The scene has different fragments in depths
that maps to one texel. I disable
the depth test to process all those fragments in my fragment shader, where I
output its depth (gl_FragCoord.z).
I enable the blending and use RGBA_MAX as my blend equation. Now when I read
back the texture I rendered to,
I would expect to have all the furthest fragments. If I use RGBA_MIN, I would
expect to have all the closest
fragments... Is my reasoning correct ? Now I always get the same values in the
texture regardless whether I
use RGBA_MIN or RGBA_MAX... Any idea ? Anyone used RGBA_MIN / RGBA_MAX with
success ?
Here is how I setup the camera to render to the texture:
osg::ref_ptrosg::Camera pCam = new osg::Camera;
pCam-setClearColor(osg::Vec4(-1, -1, 0, 0));
pCam-setClearMask(GL_COLOR_BUFFER_BIT);
pCam-getProjectionMatrix().makeIdentity();
pCam-setReferenceFrame(osg::Transform::RELATIVE_RF);
pCam-setViewport(0, 0, m_uiWidth, m_uiHeight);
pCam-setRenderOrder(osg::Camera::PRE_RENDER);
pCam-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
pCam-setComputeNearFarMode(osg::Camera::COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES);
pCam-getOrCreateStateSet()-setMode(GL_DEPTH_TEST,
osg::StateAttribute::OFF|osg::StateAttribute::PROTECTED|osg::StateAttribute::OVERRIDE);
pCam-getOrCreateStateSet()-setAttributeAndModes(new
osg::Depth(osg::Depth::ALWAYS),
osg::StateAttribute::ON|osg::StateAttribute::PROTECTED|
osg::StateAttribute::OVERRIDE);
pCam-getOrCreateStateSet()-setMode(GL_BLEND,
osg::StateAttribute::ON|osg::StateAttribute::PROTECTED|osg::StateAttribute::OVERRIDE);
osg::BlendEquation* blendMax = new
osg::BlendEquation(osg::BlendEquation::RGBA_MAX); // or RGBA_MIN
pCam-getOrCreateStateSet()-setAttributeAndModes(blendMax,
osg::StateAttribute::PROTECTED|osg::StateAttribute::OVERRIDE);
pCam-attach(osg::Camera::COLOR_BUFFER0, texture.get());
// attach additional image for readback (slow)
{
osg::Image* pImg = new osg::Image();
pImg-allocateImage(m_uiWidth, m_uiHeight, 1, GL_RGBA, GL_FLOAT);
pImg-setInternalTextureFormat(GL_RGBA32F_ARB);
pCam-attach(m_RenderTargets[TU_MINMAXDEPTH0], pImg);
pCam-setPostDrawCallback(new WriteCameraAttachments());
}
pCam-getOrCreateStateSet()-setAttributeAndModes(writeDepthProg.get(),
osg::StateAttribute::ON|osg::StateAttribute::PROTECTED); // writes
gl_FragCoord.z in frag
// add to scene graph
regards,
Bill
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 2.6 and geometry shader issue
Hello again, My program outputs the maximum vertices output for a geometry shader as follows: GLint maxGeomVerts; glGetIntegerv(GL_MAX_GEOMETRY_OUTPUT_VERTICES_EXT, maxGeomVerts); osg::notify(osg::NOTICE) Max geometry shader output vertices: maxGeomVerts std::endl; Interestingly, building with osg2.4 yields 1024, whereas the exact same program built with osg2.6 yields 0. Is this a bug ? regards, Bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to large float textures
FYI I googled it up quickly and did not find anything. I tried however to use GL_RGB16F_ARB instead of GL_RGB32F_ARB and it worked. I don't need the extra precision so that solves my problem... -bill -Original Message- From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Sat 2/23/2008 4:41 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Render to large float textures Hi Bill, I have never tried to allocate such a large FBO or associate osg::Image so can't really say too much. osg::Image itself doesn't really care how big dimensions you choose, it should in theory be able to allocate as big as you need. The OpenGL side is governed by how much the OpenGL driver hardware can support, up till the 8 series NVidia were limited to 4096x4096 but in theory the new 8+ series should be able to cope with 8192x8192 for textures, but I'm not sure about FBO's you'll need to look this up. Robert. On Fri, Feb 22, 2008 at 9:41 PM, Poirier, Guillaume [EMAIL PROTECTED] wrote: Hello OSGers ! I am trying to render to a large float image of dimension 4368 X 2912. I allocate an osg::Image of that size, GL_RGB, GL_FLOAT, and GL_RGB32F_ARB. I attach that image to my camera COLOR_BUFFER. Interestingly when I read back the image pixels 4096 in x wrap around. Everything 4096 is fine. If I don't render to a float image but rather an unsigned byte image I can render correctly my image 4096 in x... I work under linux with a GeForce 8800 GTX, openGL 2.1.1, and driver 100.14.11. Does anyone ever encountered such issue ? Many thanks in advance, - bill ___ 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 winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerQT + StatsHandler (possible modif in osgviewerQT)
Ha I know what is going on... It does work my apologies... I had changed the line in void AdapterWidget::keyPressEvent( QKeyEvent* event ) _gw-getEventQueue()-keyPress( (osgGA::GUIEventAdapter::KeySymbol) *(event-text().toAscii().data() ) ); to _gw-getEventQueue()-keyPress( (osgGA::GUIEventAdapter::KeySymbol) event-key() ); The reason was that the former was producing '0' for all arrow keys... This is I guess because there is no ASCII code for the arrow keys ? I made the following change in osgviewerQT to solve the problem: if(event-key() == Qt::Key_Left) _gw-getEventQueue()-keyPress(osgGA::GUIEventAdapter::KEY_Left); else if(event-key() == Qt::Key_Right) _gw-getEventQueue()-keyPress(osgGA::GUIEventAdapter::KEY_Right); else if(event-key() == Qt::Key_Up) _gw-getEventQueue()-keyPress(osgGA::GUIEventAdapter::KEY_Up); else if(event-key() == Qt::Key_Down) _gw-getEventQueue()-keyPress(osgGA::GUIEventAdapter::KEY_Down); else _gw-getEventQueue()-keyPress( (osgGA::GUIEventAdapter::KeySymbol) *(event-text().toAscii().data() ) ); bill -Original Message- From: [EMAIL PROTECTED] on behalf of Mario Valle Sent: Wed 10/17/2007 9:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgviewerQT + StatsHandler Poirier, Guillaume wrote: Hello ! Sorry if this was already discussed... I checked on the gmane archive and could not find anything on the topic :( Is the osgviewerQT supposed to work with the StatsHandler ? Most viewer examples use it except osgviewerQT.cpp. When I do ViewerQT* viewerWindow = new ViewerQT; viewerWindow-addEventHandler(new osgViewer::StatsHandler); and press 's' I get a Stats report: printout but see nothing in the window. The same was happening to osgviewerWX. It happens because WX passes 'S' instead of 's' to osg in OnKeyUp and OnKeyDown, ie. the uppercase lettere is always passed. I think the same is happening in Qt. Hope it helps mario Cheers ! bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ing. Mario Valle Visualization Group | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multipassshading in OSG v1.2
I've seen a lot of posts lately regarding multi-pass shading. I think
the core osg should probably offer more high level capabilities wrt
shaders. I am attaching some code I've made that works for me to do
what I call ModelEffects (multi-pass shaders on models) and PostEffects
(multi-pass post-rendering on screen) that work with both Cg and glsl. I am not
a good programmer but this might maybe help some people. I tried to include
some high-level functionality that I thought would be helpful, for example
render scene depth in a 32-bit float buffer or create PostEffects with
multiple
passes of different render target sizes, for example to perform reduction
on the GPU (obtain buffer min/max values in final 1x1 texture).
The osgFX / osgNV was a good step in the direction of high-level shader
constructs
but it did not support glsl and unfortunately the project is on halt.
It would also be interesting to see in the future how shaders could be
combined in a scene graph hierarchy. I've not worked with the nvidia scene
graph but I would be curious to see its multiple shader combination
capabilities. Perhaps this is something that we should investigate...
I would also take a look at Sh that looks very good on the architecture
standpoint and high-level capabilities (http://libsh.org/).
regards,
bill
-Original Message-
From: [EMAIL PROTECTED] on behalf of Swen Walkowski
Sent: Fri 10/12/2007 2:33 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Multipassshading in OSG v1.2
Hello all,
thanks for the answers! I have tried a look to the osgFX and to the
source code (thanks Christian).
One question I have. See I that right that I can just use Multipass
sading at the time in OSG. I have to write my own solution like what
you have posted Christian, or do the inflexibility way?
I think about it, because I have to use it in my diploma thesis and at
the time we don't know in wisch way we have to use the shading. So
maybe it is good to do an onw solution.
Christian, from your expiriance how long you meen it takes to get
thinks with an own solution running?
Thanks a lot,
Swen
On 10/11/07, Swen Walkowski [EMAIL PROTECTED] wrote:
Hello all,
i try to do Multipassshading in OSG v1.2.
I have written my own shader class in the class I use the osg::shader
for shading. At the time my shading code looks like that:
Shader::Shader(void) {
//creating program
program = new osg::Program;
//creating shader
vertShader = new osg::Shader(osg::Shader::VERTEX);
fragShader = new osg::Shader(osg::Shader::FRAGMENT);
}
Shader::~Shader(void) {
}
void Shader::apply(osg::StateSet state) {
state.setAttributeAndModes(program, osg::StateAttribute::ON);
vertShader-loadShaderSourceFromFile(shaders/Fixed_Functionality.vert);
fragShader-loadShaderSourceFromFile(shaders/Fixed_Functionality.frag);
program-addShader(vertShader);
program-addShader(fragShader);
//parameterize the shader with video texture (0 by default)
state.addUniform(new osg::Uniform(texture, 0));
posXUniform = new osg::Uniform(posX, (float)0.0);
posYUniform = new osg::Uniform(posY, (float)0.0);
intensityUniform = new osg::Uniform(intensity, (float)1.0);
radiusUniform = new osg::Uniform(radius, (float)0.2);
state.addUniform(posXUniform);
state.addUniform(posYUniform);
state.addUniform(intensityUniform);
state.addUniform(radiusUniform)
}
That works well.
Now i try to add an secend shading pass. I have read a lot over
rendering to texture (RTT) in OSG in the mailinglist. So I tryed to
find the examples or something in the OSG documentation.But without
luke.
Hope someone can tell me were I find the documentation for
Multipassshading in OSG or an example or maybe how it works.
Thangs,
Swen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
winmail.dat___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trackball and view question
, if there are any examples that better fit what I am trying to do, I would be much obliged. Thank you kindly, Morne ---8-- Poirier, Guillaume wrote: Well this is what I was trying, using viewer.getCamera()-getViewMatrixAsLookAt(osg::Vec3 eye, osg::Vec3 center, osg::Vec3 up, float lookDistance=1.0f). In step 2 (with trackball manipulator) I read back the eye, center, and up values in the camera post draw callback. When the pose is almost identical as in the first step, I read the values and they look quite different than what I was setting in the first step. I am still unclear whether this is normal or not. So my question is, if it's normal, is there a transformation I can do to recuperate the step 1 values ? Or do I need to implement a custom view manipulator to achieve what I am looking for ? regards, bill -Original Message- From: [EMAIL PROTECTED] on behalf of Alberto Luaces Sent: Thu 9/27/2007 4:38 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Trackball and view question Hi Robert et al. Let me explain what I want to do accomplish an example: I load a model with no camera manipulator. I know the camera parameters (eye, ctr, up) that yield a desired pose. I set the viewer camera with those parameters and obtain the desired pose. Now I want to assume that I don't know those parameters. A user loads a model with a trackball manipulator. He / she can manipulate the model until the desired pose is obtained and recuperate the camera parameters (eye, ctr, up), which should be what I used in the previous step... Is that more clear ? How would I achieve this ? regards, Bill What about osg::Camera::getViewMatrixAsLookAt (osg::Vec3 eye, osg::Vec3 center, osg::Vec3 up, float lookDistance=1.0f) ? Alberto -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trackball and view question
Hi Robert et al. Let me explain what I want to do accomplish an example: I load a model with no camera manipulator. I know the camera parameters (eye, ctr, up) that yield a desired pose. I set the viewer camera with those parameters and obtain the desired pose. Now I want to assume that I don't know those parameters. A user loads a model with a trackball manipulator. He / she can manipulate the model until the desired pose is obtained and recuperate the camera parameters (eye, ctr, up), which should be what I used in the previous step... Is that more clear ? How would I achieve this ? regards, Bill -Original Message- From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Tue 9/18/2007 11:28 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Trackball and view question Hi Bill, The camera manipulators role is to modifying the view matrix so I'm a bit perplexed that you are suprised by this. Also please considering move from SimpleViewer up to osgViewer::Viewer working as an embedded viewer in 2.x rather than using SimpleViewer as it only existed for a short while and has been totally superseded. Robert. On 9/18/07, Poirier, Guillaume [EMAIL PROTECTED] wrote: Hello everyone, I am using a SimpleViewer. I set up a post draw callback on its main camera. In it I read the camera eye, center, and up vectors. Initially, this give me (0, 0, 0), (0, 0, -1), and (0, 1, 0) respectively. This is what I expect and it gives me a particular view of my scene. Now I add a trackball manipulator to the main camera and set up the view similar to what I had previously. When I read back the data it is quite different. I would have expected the same camera position / orientation than before since what I see is similar. Unless the trackball affects the model position / orientation and not just the view ? How can I use a trackball and read back in the post draw callback the values I want ? sincerely, Bill ___ 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 winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Trackball and view question
Hello everyone, I am using a SimpleViewer. I set up a post draw callback on its main camera. In it I read the camera eye, center, and up vectors. Initially, this give me (0, 0, 0), (0, 0, -1), and (0, 1, 0) respectively. This is what I expect and it gives me a particular view of my scene. Now I add a trackball manipulator to the main camera and set up the view similar to what I had previously. When I read back the data it is quite different. I would have expected the same camera position / orientation than before since what I see is similar. Unless the trackball affects the model position / orientation and not just the view ? How can I use a trackball and read back in the post draw callback the values I want ? sincerely, Bill ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Convertion to osg::Image from IplImage (OpenCV) for useas texture
Hi John,
I wrote a osgImage2IplImage, not sure if it could help you, but here it is:
/*! Image conversion functions
Utility functions to convert between different image representations */
IplImage* osgImage2IplImage(const osg::Image p_osgImage)
{
const unsigned char *buffer = p_osgImage.data();
IplImage* pImg = cvCreateImage(cvSize(p_osgImage.s(), p_osgImage.t()),
IPL_DEPTH_8U, p_osgImage.r() );
if(p_osgImage.r() == 3)
{
struct pixelStruct { unsigned char r, g, b; };
struct pixelStruct* pPixel = ( struct pixelStruct * ) ( buffer );
struct pixelStruct* pCurrentPixel = NULL;
for(int x = 0; x p_osgImage.s(); x++ ) {
for(int y = 0; y p_osgImage.t(); y++ ) {
pCurrentPixel = pPixel[ y * p_osgImage.s() + x ];
int invertedY = p_osgImage.t()-1-y;
// blue
((uchar*)(pImg-imageData + pImg-widthStep*invertedY))[x*3] =
pCurrentPixel-b;
// green
((uchar*)(pImg-imageData + pImg-widthStep*invertedY))[x*3+1] =
pCurrentPixel-g;
// red
((uchar*)(pImg-imageData + pImg-widthStep*invertedY))[x*3+2] =
pCurrentPixel-r;
}
}
}
else if(p_osgImage.r() == 4)
{
struct pixelStruct { unsigned char r, g, b, a; };
struct pixelStruct* pPixel = ( struct pixelStruct * ) ( buffer );
struct pixelStruct* pCurrentPixel = NULL;
for(int x = 0; x p_osgImage.s(); x++ ) {
for(int y = 0; y p_osgImage.t(); y++ ) {
pCurrentPixel = pPixel[ y * p_osgImage.s() + x ];
int invertedY = p_osgImage.t()-1-y;
// alpha
((uchar*)(pImg-imageData + pImg-widthStep*invertedY))[x*3] =
pCurrentPixel-a;
// blue
((uchar*)(pImg-imageData + pImg-widthStep*invertedY))[x*3+1] =
pCurrentPixel-b;
// green
((uchar*)(pImg-imageData + pImg-widthStep*invertedY))[x*3+2] =
pCurrentPixel-g;
// red
((uchar*)(pImg-imageData + pImg-widthStep*invertedY))[x*3+3] =
pCurrentPixel-r;
}
}
}
else
{
osg::notify(osg::NOTICE)osgImage2IplImage: Error, unrecognized image
depth.std::endl;
}
return pImg;
}
bill
-Original Message-
From: [EMAIL PROTECTED] on behalf of John Steinbis
Sent: Sun 9/16/2007 9:23 PM
To: OpenSceneGraph Users
Subject: [osg-users] Convertion to osg::Image from IplImage (OpenCV) for useas
texture
Hi,
I'm trying to convert an IplImage (OpenCV) type to osg::Image type for
use as a texture within OSG. My conversion routine attempts to utilize
setImage(...) of image class. It crashes and I havent been able to
track down the problem.
Does anyone have experience with a conversion like this or advise
about building osg images from other types? Thank you!
-- John
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
winmail.dat___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
