[osg-users] Animations in osg format
Hi, I am successfully exporting models with 3D Studio to osg format, but, when loading, it seems like only keyframe animations work (but keyframeless animations dont work). Is it possible to export models with animations to osg format without keyframes? Thank you. Héctor ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Clipping planes for slave camera
Hi Yefei, On Mon, Sep 26, 2011 at 9:20 PM, He, Yefei yefei...@uiowa.edu wrote: Is it possible for a slave camera to have different near and far clipping planes from the master camera? Are there examples for it? I figure it will be more complicated than changing the angle of view or adding a shear to the view frustum. You have assign different projection matrices to the slave camera either by setting the projection offset matrix for the slave and keeping the slave Camera's ReferenceFrame set to RELATIVE_RF (relative the master Camera) or by setting the view and projection matrices directly on the slave Camera and setting the ReferenceFrame to ABSOLUTE_RF. There isn't a specific example that illustrates what you want but the osghud and osgdistortion examples should give you an idea of the different things you can. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] unexpected behavior
HI Keith, From the scant details and the number of variables that could effect thigns we can only guess what might be the problem. My best guess would be that perhaps the sky dome is very large so pushing the far plane and the near plane with it, such that the near plane is clipping out the geometry you are expecting to see. Robert. On Tue, Sep 27, 2011 at 3:20 AM, Keith Parkins kpark...@cs.rochester.edu wrote: Hi all, I am having the weirdest problem. I have generated a scene graph with a pre-render camera that does the skydome and then this: osg::ref_ptrosg::Group root = new osg::Group; root-setName(root); setSceneData(root.get()); osg::ref_ptrmear::SkyDome sky = new mear::SkyDome; sky-setView(this); root-addChild(sky.get()); // for testing //root-addChild(osgDB::readNodeFile(GH_Geometry_6_29_11.osgb)); root-addChild(osgDB::readNodeFile(/home/keith/GH_Geometry_6_29_11.osgb)); root-addChild(osgDB::readNodeFile(cow.osgt)); Now, if I leave the fullpath GH model and the cow in there, I see the GH model and the cow. If I comment out the GH model line, I just see the cow. If I leave the fullpath model loaded and comment the cow out I don't see anything (except the sky). This is called from a View setup in a CompositeViewer/QWidget. bizarre, -Keith ___ 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] Current time when displaying an image stream
Hi Brad, I have also a simple video player using the ImageStream class and the FFmpeg plugin. For the slider, I get the maximum value from the ImageStream-getLenght() method and to update the current position I call periodically ImageStream-getReferenceTime(). I think that this is the 'curentTime' function you are looking for. If you need any help, just let me know ;) Cheers, Julen. 2011/9/23 Christiansen, Brad brad.christian...@thalesgroup.com.au Hi, ** ** I am creating a basic video player using the ImageStream class. I have created a standard 'position' slider to seek within the stream. Seeking is working with no problems but I cant see any way of reliabily updating the position of the slider as the stream is played. ** ** As well as the seek() and length() function I was hoping to find a 'curentTime' like function, basically the 'getter' for 'seek'. Without this function it looks like I will have to assume that length and seek are both in seconds and then calculate my own 'currentTime' based on elapsed time since play was called. This seems overly complex and somewhat unreliable as it also assumes that the stream is playing with exactly the correct timing. ** ** Has anyone solved this? Have I missed something? ** ** Cheers, Brad - DISCLAIMER: This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. - ___ 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] Current time when displaying an image stream
Hi, Thanks for the info. That works for the ffmpeg plugin but wasn't implemented at all in the direct show function. I have posted a submission which adds a new function ( getCurrentTime ) to ImageStream and have implemented the new methon in the direct show plugin, and implemented it in ffmpeg by simply calling getReferenceTime. I took this approach as I am not sure what the 'correct' meaning of getReferenceTime is as there is also a setReferenceTime as well as a seek function. Cheers, Brad From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Julen Garcia Sent: Tuesday, 27 September 2011 4:51 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Current time when displaying an image stream Hi Brad, I have also a simple video player using the ImageStream class and the FFmpeg plugin. For the slider, I get the maximum value from the ImageStream-getLenght() method and to update the current position I call periodically ImageStream-getReferenceTime(). I think that this is the 'curentTime' function you are looking for. If you need any help, just let me know ;) Cheers, Julen. 2011/9/23 Christiansen, Brad brad.christian...@thalesgroup.com.aumailto:brad.christian...@thalesgroup.com.au Hi, I am creating a basic video player using the ImageStream class. I have created a standard 'position' slider to seek within the stream. Seeking is working with no problems but I cant see any way of reliabily updating the position of the slider as the stream is played. As well as the seek() and length() function I was hoping to find a 'curentTime' like function, basically the 'getter' for 'seek'. Without this function it looks like I will have to assume that length and seek are both in seconds and then calculate my own 'currentTime' based on elapsed time since play was called. This seems overly complex and somewhat unreliable as it also assumes that the stream is playing with exactly the correct timing. Has anyone solved this? Have I missed something? Cheers, Brad - DISCLAIMER: This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. - ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org - DISCLAIMER: This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Autoshadow aliasing in shadow maps
Hi all, Thanks for your posts, and sorry for my very late response. I´ve been on holidays and working in another things, so I left this issue abandoned. But finally, I could get rid of these artifacts, and therefore, solve my problem. Although the filters mitigated the effect, they were still noticeable and the performance was affected. But the solution that Robert proposed works almost perfectly for me! As Robert said, the key was to do the lighting calculations in the fragment shader, and multiply the shadow factor by the diffuse light component. After that, I can add the ambient light factor to achieve a well lighted surface. This solution is so easy conceptually and to implement that I´m mad at myself because I didn´t think about it ;) Thank you very much for your help, I think that this thread can be marked as solved. Cheers, Justo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43038#43038 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Draw a line from world to screen
Thansk for pointing me to these topics. So, I found the solution : (be carefull, these function use WORLD coordinates, not local coordinates) worldToScreen : Code: osg::Vec2d worldToScreen(const osg::Vec3d worldPosition, const osg::Camera* pCamera) { osg::Vec2d screenPosition; if (pCamera!= NULL) { osg::Matrixd MVPW = pCamera-getViewMatrix() * pCamera-getProjectionMatrix() * pCamera-getViewport()-computeWindowMatrix(); osg::Vec4d screenPosition4d = osg::Vec4d(worldPosition, 1.0) * MVPW; screenPosition4d = screenPosition4d / screenPosition4d.w(); screenPosition4d.y() = pCamera-getViewport()-height() - screenPosition4d.y(); screenPosition.set(screenPosition4d.x(), screenPosition4d.y()); } return screenPosition; } screenToWorld : Code: osg::Vec3d screenToWorld(const osg::Vec2d screenPosition, const osg::Camera* pCamera) { osg::Vec3d worldPosition; if (pCamera!= NULL) { osg::Vec4 screenPositionNear(screenPosition.x(), pCamera-getViewport()-height() - screenPosition.y(), 0.0, 1.0); osg::Vec4 screenPositionFar(screenPosition.x(), pCamera-getViewport()-height() - screenPosition.y(), 1.0, 1.0); osg::Matrixd iMVPW = osg::Matrixd::inverse(pCamera-getViewMatrix() * pCamera-getProjectionMatrix() * pCamera-getViewport()-computeWindowMatrix()); osg::Vec4 worldPositionNear = screenPositionNear * iMVPW; osg::Vec4 worldPositionFar = screenPositionFar * iMVPW; worldPositionNear = worldPositionNear / worldPositionNear.w(); worldPositionFar = worldPositionFar / worldPositionFar.w(); worldPosition.set((worldPositionNear.x() + worldPositionFar.x())/2.0, (worldPositionNear.y() + worldPositionFar.y())/2.0, (worldPositionNear.z() + worldPositionFar.z())/2.0); } return worldPosition; } -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43039#43039 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] qtOsg EventHandler issue
1 - The program starts with no scenario windows 2 - I can add or remove Windows with a new/open file operation. 3 - for the first window to be opened everything works perfect regarding events ( mouse click, mouse press, drag, etc ). 4 - For all the others i have to wait a time till the event handler starts to work. Sometimes, It takes more than 5 seconds. Do i have to force some call to make the current window active together with its current viewer's event handler ? When using osg 2.9.15 i had no trouble with this. Now I'm using osg 3.0.1 Try with ON_DEMAND frame scheme: setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND); Why? In the viewer event traversal there is a line: double cutOffTime = (_runFrameScheme==ON_DEMAND) ? DBL_MAX : _frameStamp-getReferenceTime(); Your app is waiting because osg cannot pull all queued events within a period of cutOffTime. Sometimes many frames are needed to process all accumulated events to get to your mouse/keyboard events. You can also leave default frame scheme as is and clear osg event queue yourself. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Error: 0xc0150002 Win7 x64, VS2010, osg 2.9.11 current Trunk, wrong dependency in osgDBd.dll Manifest ?
Hi, I just had the same problem with the current trunk on Win 7 x86. Your hack worked. Is there any news on a proper solution? Cheers, Karan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43041#43041 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] qtOsg EventHandler issue
Hi Robert Milharcic. Hi Gentlemen. It worked here. Thank you very much. Chris, my application uses QMdiArea as the main manager for each CompositeViewerWidget. And all CompositeViewerWidgets inherits from QMainWindow. Hope it helps. Best Regards Andre 2011/9/27 Robert Milharcic robert.milhar...@ib-caddy.si: 1 - The program starts with no scenario windows 2 - I can add or remove Windows with a new/open file operation. 3 - for the first window to be opened everything works perfect regarding events ( mouse click, mouse press, drag, etc ). 4 - For all the others i have to wait a time till the event handler starts to work. Sometimes, It takes more than 5 seconds. Do i have to force some call to make the current window active together with its current viewer's event handler ? When using osg 2.9.15 i had no trouble with this. Now I'm using osg 3.0.1 Try with ON_DEMAND frame scheme: setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND); Why? In the viewer event traversal there is a line: double cutOffTime = (_runFrameScheme==ON_DEMAND) ? DBL_MAX : _frameStamp-getReferenceTime(); Your app is waiting because osg cannot pull all queued events within a period of cutOffTime. Sometimes many frames are needed to process all accumulated events to get to your mouse/keyboard events. You can also leave default frame scheme as is and clear osg event queue yourself. Robert Milharcic ___ 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] Clipping planes for slave camera
Thanks, Robert, I'll take a look at the examples. Another question: in a composite viewer, if I set the view and projection matrices directly on the slave camera, what are the internal differences between doing this and simply creating another view and setting the view and projection matrices of its camera? I'm trying to set up a composite viewer with multiple views of the same scenegraph. I noticed that the main view (the first view added to the composite viewer) and its slave cameras all render properly, but in the contents of the other views, the depth sorting is incorrect, most noticeably the skydome obscures a lot of faces that should be in front of the skydome. Yefei -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, September 27, 2011 3:16 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Clipping planes for slave camera Hi Yefei, On Mon, Sep 26, 2011 at 9:20 PM, He, Yefei yefei...@uiowa.edu wrote: Is it possible for a slave camera to have different near and far clipping planes from the master camera? Are there examples for it? I figure it will be more complicated than changing the angle of view or adding a shear to the view frustum. You have assign different projection matrices to the slave camera either by setting the projection offset matrix for the slave and keeping the slave Camera's ReferenceFrame set to RELATIVE_RF (relative the master Camera) or by setting the view and projection matrices directly on the slave Camera and setting the ReferenceFrame to ABSOLUTE_RF. There isn't a specific example that illustrates what you want but the osghud and osgdistortion examples should give you an idea of the different things you can. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] unexpected behavior
Hi Robert, Thanks for the help. It was late and I was stuck, but you definitely pointed me in the right direction. The one non-stock piece that ended up being the culprit was the computeHomePosition method in my camera manipulator. I ended up dumping camera information to see the difference between the home position (as well as checking the clip near/far clip planes) when both models were loaded and when only my model was loaded. thanks again for all your work! -K On Tue, 27 Sep 2011, Robert Osfield wrote: HI Keith, From the scant details and the number of variables that could effect thigns we can only guess what might be the problem. My best guess would be that perhaps the sky dome is very large so pushing the far plane and the near plane with it, such that the near plane is clipping out the geometry you are expecting to see. Robert. On Tue, Sep 27, 2011 at 3:20 AM, Keith Parkins kpark...@cs.rochester.edu wrote: Hi all, I am having the weirdest problem. I have generated a scene graph with a pre-render camera that does the skydome and then this: osg::ref_ptrosg::Group root = new osg::Group; root-setName(root); setSceneData(root.get()); osg::ref_ptrmear::SkyDome sky = new mear::SkyDome; sky-setView(this); root-addChild(sky.get()); // for testing //root-addChild(osgDB::readNodeFile(GH_Geometry_6_29_11.osgb)); root-addChild(osgDB::readNodeFile(/home/keith/GH_Geometry_6_29_11.osgb)); root-addChild(osgDB::readNodeFile(cow.osgt)); Now, if I leave the fullpath GH model and the cow in there, I see the GH model and the cow. If I comment out the GH model line, I just see the cow. If I leave the fullpath model loaded and comment the cow out I don't see anything (except the sky). This is called from a View setup in a CompositeViewer/QWidget. bizarre, -Keith ___ 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] Lighting problem when using help or stats handler
I have attached a simple example that reproduces the problem. I am not sure if this is a OSG problem or if we are not using it properly. The problem occurs when more than 2 pre-render stages are cascading (as described in previous post of thread), as the inherited PositionalStateContainer will stop at the 2nd stage and not be pushed on the following cascading pre-rendering stages, which happens in our scene graph (and reproduced in the attached example). Run the example, see the cow with green specular light. Press 'h'. The cow does not change. Now set MULTIPLE_PRERENDER_STAGES = true in prerenderbin.cpp line 26. Repeat the above procedure. The lighting changes when the help is displayed... cheers, guillaume -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: September-22-11 9:36 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Lighting problem when using help or stats handler Hello Guillaume, After some more digging I kind of have a feeling for what is happening but again I have too little knowledge of the OSG internals to really understand what is going on... FWIW, we use the stats in all our apps, and we've never had any problems where showing the stats on screen would change lighting in the rest of the scene. The stats disable lighting on their subgraph anyways (in general you don't use lighting on a 2D HUD), see src/osgViewer/StatsHandler.cpp line 1062 in the current OSG trunk: stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF); So it seems weird to me that you're getting these problems. OSG's own examples also use the stats almost all the time and the lighting of the scene is not affected. All this points to something you're doing that's causing this, or a driver bug. In both cases, it might be useful for you to reduce your app to a very simple test case, see if the problem is still there, then work back up to find out what's causing it. When you get to a simple self-contained example that reproduces your problem, if you're still in the dark as to why it happens, you can send us that example, and we can have a look. In general, sending small self-contained examples is much more useful than sending code snippets, since with the former we can actually compile it and debug into it, whereas in the latter case we can only look at the code... Hope this helps, J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org PK uY;? prerenderbin/PK Â}:?KíÚÖ Ìg prerenderbin/ALL_BUILD.vcprojí]]sÒ@}®3þ :´U«Ø¢*#(Ty`¦ÂklÜM*õã¿{7h¡$m¿öÅI²wÏÝ{ïîa÷@ãÑëmiç2Lrn¯°ÓcvZYË}ÂÎ|eù½ýgû¹×¯îÞ9úoX]ÏaÒ¦ä32½»wvÂ«Þ Ê9a¢Õ?ÎAÓǼTØÝåÞ6UÍÓêI£©çâîoNz9÷]ׯ?©å÷äJ¥|õÙóRþÉÁni¯ò¢Z}vPùÉ»½C_ ù0ìsÜ+x|Ô¶oL¨Íø]|ËoBﳧ¹b`[\2ªg'5sðèÒ³ ýÉüà{®ïéB$^í¢áxÚh Åq #LöK.EV÷vEÓ CÆãZ9¨ô-ì`C¬Öñ¶Q©A/N1®Çf·O j0.òʹý _b®æ¡}¬Õ5b»ØB·ñÎÜÕhù«á?Ç+çj/®($¼G%=âÓÓúÜAÁ9]9è 5Üé`¿P*¼`tz¨ÏLäro gdÁ, ¼#TGcÛq¿Ê»úiã}OotÊ_|⹯£Á3ì!ÔÄÌä1ô.jçÃp s÷6^ÐGh,®OÏbW}l\·ì F|j¢ßÚço}@Þ\¢usær;´'ßNÏ äÕsLc#¦à°é Âê fnÁj¡÷:'Qw f6 ,¬9~ó¨àYÃÀîêJ¼EÆQ^ä8ÓÐHo6uÃ3b+þZËcÃDDÇxÒ).aÍÅ+¬ÖgªÌ¬ú98ãÍ×Û6±sÈ0o%îQq{®gÀ²ÁÐZ[¤`Á°âÁLx0ÌfR ͮȡbCÅײ!°OȦË5¥àĸ¢ÅLh1NhRf{(r\IÅ7í?ao G3k9ò²a \2®\NjR¾\î¥8ssFoþ×¼yé#y0ÁÕ¸ð0Àæµ oº4}áQä@ÖØÔZÆ ±Úùó[óÏ ÞÌ #+ÜU- íã]·ÜÃf1bWPo ja¬u|iµÅh°ÅÅÁÂÚ±¡àV,@ж$M{8{qðH«íÃç¡6ÜÐ Zþí:ÇZ¾º¾)oNyga»ù1xÓTq®ÞBÐïÁ½Ù®~Èÿâ±(%ÔBçÈÒö´ ñös¢K¨WçMQä1êÈå^ qµÁ§#éÊóûù`',vKÇðÍ¿,4lñÔµ{Ádg¿[ÀN¤|Wºg2y¼µè/óyªØ9ñ°Å2ûÆ)#HÉj¿ÿæµß¿}fû} ¹K ëÖM¾¢vðyyí6³gèKÃø4Óê]ÆæÆ:¥÷Ë£Ïøla×|GvnOw|×5b¤®nóÄþ- ¾!%NÓp âýæBJæè8GÂL¯ÑÈO¥ÚÈÜIÛ 5l×ÂöøY¯Ì½ÔB|cÁ0°D1kWhê°#$Ñ=EÇ~?ìÑÎ^æÇÜFâÞYqM/¢q®+üæc$Z|!èXÜ(d¬RR(ÈbW4¬dâVø%o)yKÉ[JÞúã7cJÞRòVí§·R5²ÏVÉ[²æ·6zØö¡SFÔ3µ%oeͶ·Âni$îפñ¢ä-¹òVü#o¥p) K)\Jáúã÷cJáR W¨R¸R7²ÏV)\²æR¸6zØö¹SFÔ©3µ¥peͶR¸Âni$îפñ¢.¹ ×òä*K©\JåR*׿'S*R¹ìBÊòÈ|¶°Jå5ʵÑöÏ2ê N©½(+£l¶ÊvÛL#qטּ¥rÝNå¿ÖKè]0/^¿(ÒÔá ðƵ[½ìÒÆ üWieiÑHW*h·VEz£²Î!6Wtg³níþIñóÆÿ1²Dô1T]L 7ác\¾±ÈаÄu1¾9*®ø?xàù/PK :Y;?Oë½Ç 4 prerenderbin/ALL_BUILD.vcproj.DSNRCCA.poiriergu.useríQOÛ0ÇÄw¨üÖ¦06mJ²vh©k¾ðbkâͱ#Û)ñá¹$Ŷ*ñHr¿óï.EvÏVï.Ai G=tAD2fñÈXÞêOãÓcr6p¯.(M3y©A3©ÿ 2w9x¤^Ót]=åþÖs©¼õ9/#µGk(ñow$Å%
[osg-users] Open Flight characteristic not reflected in the current OSG
Greetings All: Something I found that is interesting in Creator 3.4 (Open Flight) that is not reflected in OSG. In Creator Face Attributes, under the Drawing tab, If your set the Shade to Gouraud, you are shading at the vector level, hence you usually set the colors at the vector points. What I found interesting is that if you don't set a vector color (leave the index color set to -1), since it is undefended, in Creators view it defaults to the Face color (or Primary Color). This does not happen in the Open Flight plug-in in either 2.8.1 or the latest I've tested 3.0.1 . I know this is not a documented feature, but maybe we need to cover this in the Open Flight Plug-in anyway so we are computable to that standard. It would be better than trying to explain to some of these modelers why they have to brake old habits when from their perspective, it only happens on OSG. ... Thank you! David Glenn - D Glenn 3D Computer Graphics Media Systems. D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43046#43046 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Open Flight characteristic not reflected in the current OSG
On 9/27/2011 10:55 AM, David Glenn wrote: Greetings All: Something I found that is interesting in Creator 3.4 (Open Flight) that is not reflected in OSG. In Creator Face Attributes, under the Drawing tab, If your set the Shade to Gouraud, you are shading at the vector level, hence you usually set the colors at the vector points. What I found interesting is that if you don't set a vector color (leave the index color set to -1), since it is undefended, in Creators view it defaults to the Face color (or Primary Color). Do you have a small reproducer model that could be added to the regression suite at osgfltexport.googlecode.com? This does not happen in the Open Flight plug-in in either 2.8.1 or the latest I've tested 3.0.1 . Can you describe what OSG does and how it's different from the expected behavior? -Paul I know this is not a documented feature, but maybe we need to cover this in the Open Flight Plug-in anyway so we are computable to that standard. It would be better than trying to explain to some of these modelers why they have to brake old habits when from their perspective, it only happens on OSG. ... Thank you! David Glenn - D Glenn 3D Computer Graphics Media Systems. D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43046#43046 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GLSL shaders and projective texturing
Hi folks, I'm looking for a complete example showing projective texturing with GLSL shaders in OSG. I'm simply trying to implement a spotlight just like the osgspotlight example. What I've found doesn't quite paint the whole picture for me. Anything would be helpful. Cheers, Brad --- Brad Colbert Renaissance Sciences Corporation (480) 374-5073 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shaders and projective texturing
On 9/27/2011 2:16 PM, Brad Colbert wrote: Hi folks, I'm looking for a complete example showing projective texturing with GLSL shaders in OSG. I'm simply trying to implement a spotlight just like the osgspotlight example. What I've found doesn't quite paint the whole picture for me. Anything would be helpful. This one seemed fairly complete. http://www.jotschi.de/?p=378 Ping me if you need help on the project. -- 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] Open Flight characteristic not reflected in the current OSG
Paul Martz wrote: On 9/27/2011 10:55 AM, David Glenn wrote: Greetings All: Something I found that is interesting in Creator 3.4 (Open Flight) that is not reflected in OSG. In Creator Face Attributes, under the Drawing tab, If your set the Shade to Gouraud, you are shading at the vector level, hence you usually set the colors at the vector points. What I found interesting is that if you don't set a vector color (leave the index color set to -1), since it is undefended, in Creators view it defaults to the Face color (or Primary Color). Do you have a small reproducer model that could be added to the regression suite at osgfltexport.googlecode.com? This does not happen in the Open Flight plug-in in either 2.8.1 or the latest I've tested 3.0.1 . Can you describe what OSG does and how it's different from the expected behavior? -Paul I know this is not a documented feature, but maybe we need to cover this in the Open Flight Plug-in anyway so we are computable to that standard. It would be better than trying to explain to some of these modelers why they have to brake old habits when from their perspective, it only happens on OSG. ... Thank you! David Glenn - D Glenn 3D Computer Graphics Media Systems. D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43046#43046 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum Quick answers 1) Yes, Ill make a reproduction you can use, as soon as I can get some free time to make one and to test it to verify the results - just in case! 2) Any elements that appear colored in Creator 3.4 display, appear as white in OSG 2.8.1 and OSG 3.0.1 that I tested. I post something here when I send it there or have any problems. David Glenn - D Glenn 3D Computer Graphics Media Systems. D Glenn (a.k.a David Glenn) - Moving Heaven and Earth! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43050#43050 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GLSL shaders and projective texturing
Hi Chris, Thanks for the quick reply and the lead. I'm still fumbling around with that example and I think I've found an issue with it. It appears to be sensitive to the camera position (ie not the correct projection solution). This little bit in the shader makes me feel that it's suspect (+vec2(0.5,0.5)): vec4 color = texture2D(projectionMap,dividedCoord.st+vec2(0.5,0.5) ); Do embedded images come across in these emails: Startup: [cid:image001.png@01CC7D27.0D484B60] Moving in slide to the right (projection moves to the far right): [cid:image002.png@01CC7D27.5588D890] -B -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chris 'Xenon' Hanson Sent: Tuesday, September 27, 2011 1:44 PM To: OpenSceneGraph Users Subject: Re: [osg-users] GLSL shaders and projective texturing On 9/27/2011 2:16 PM, Brad Colbert wrote: Hi folks, I'm looking for a complete example showing projective texturing with GLSL shaders in OSG. I'm simply trying to implement a spotlight just like the osgspotlight example. What I've found doesn't quite paint the whole picture for me. Anything would be helpful. This one seemed fairly complete. http://www.jotschi.de/?p=378 Ping me if you need help on the project. -- 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 inline: image001.pnginline: image002.png___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Culling and intersects with ocean and model...
I've just managed to get the technique described above. Here is the result: [Image: http://img825.imageshack.us/img825/926/stencilsolution.jpg ] I've also posted a video showing the difference here: http://www.youtube.com/watch?v=Rf1yJObCLKI In order to get this to work I had to first understand that the FFTOceanSurface's (Geode derivative) stateset will get overwritten any time a call to FFTOceanSurface::initStateSet is called. Unfortunately, this happens any time one of the many functions in FFTOceanTechnique gets called (ie setLightColor, setWindSpeed, etc...). To get around this I am waiting until after the stateset gets created the first time and then applying the stencil to it. If did it beforehand, it would be wiped out in the call initStateSet. Then whenever I change the lightColor (my app has changing time of day), i recreate the stencil on the next frame since the stateset for this surface will also have been recreated. This process would be made much easier if ocean surface only created a new stateset if a previous one didn't exist. Is there a reason for recreating it? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=43052#43052 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Culling and intersects with ocean and model...
Hi Michael, This process would be made much easier if ocean surface only created a new stateset if a previous one didn't exist. Is there a reason for recreating it? No reason other than laziness. If any attribute that's being stored in the stateset gets changed, rather than just changing that attribute (and potentially others that depend on it, and so on) and thus scattering the code that creates the state set in many different methods, we just dirty the state set which causes it to be recreated and repopulated in the next frame. You're welcome to do it differently if you want and submit the change. In fact it would really be nice if you could merge your technique into osgOcean's own code and submit the change. I'm sure many people would appreciate such functionality, if you have the time to do it. J-S -- __ Jean-Sebastien 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] GLSL shaders and projective texturing
To add more to this: I've adapted this to where the camera is the projector (ie the image is projected from the viewpoint, well, at least that is the idea): http://www.jotschi.de/?p=378 and I would like to say I'm close, but I'm still a ways away from a solution. I do see the clock projected onto my model, but the movement is not properly coordinated with my camera, and I'm quite sure I see the reverse projection at times. I'm including my source below hoping someone can find what I've done wrong. // #include osg/Version #include osg/Camera #include osg/NodeVisitor #include osg/TexGenNode #include osg/TexMat #include osgSim/MultiSwitch #include osgDB/ReadFile #include osgDB/FileUtils #include osgDB/FileNameUtils #include osgDB/DatabasePager #include osgViewer/ViewerEventHandlers #include osgGA/TrackballManipulator #include osgGA/FlightManipulator #include osgGA/DriveManipulator #include osgGA/KeySwitchMatrixManipulator #include osgGA/StateSetManipulator #include osgGA/AnimationPathManipulator #include osgGA/TerrainManipulator #include osgGA/CameraManipulator #include iostream #include osg/Notify #include osg/MatrixTransform #include osg/ShapeDrawable #include osg/PositionAttitudeTransform #include osg/Geometry #include osgGA/TrackballManipulator #include osg/Texture2D #include osg/Geode #include osg/LightSource #include osg/TexGenNode #include osg/TexMat #include osgDB/WriteFile #include osgUtil/Optimizer #include osgDB/Registry #include osgDB/ReadFile #include osgViewer/Viewer #include osgViewer/CompositeViewer using namespace std; osgViewer::View* viewA = new osgViewer::View; osg::TexMat* texMat = new osg::TexMat; osg::Uniform* ViewMatInv = new osg::Uniform( osg::Uniform::FLOAT_MAT4, ViewMatInv ); osg::ref_ptrosg::Program addShader() { osg::ref_ptrosg::Program projProg(new osg::Program); osg::ref_ptrosg::Shader projvertexShader(osg::Shader::readShaderFile( osg::Shader::VERTEX, surface.main.vert.glsl)); osg::ref_ptrosg::Shader projfragShader(osg::Shader::readShaderFile( osg::Shader::FRAGMENT, surface.main.frag.glsl)); projProg-addShader(projvertexShader.get()); projProg-addShader(projfragShader.get()); return projProg; } void addProjectionInfoToState(osg::StateSet* stateset, string fn) { osg::Vec4 centerColour(1.0f,1.0f,1.0f,1.0f); osg::Vec4 ambientColour(0.05f,0.05f,0.05f,1.0f); /* 1. Load the texture that will be projected */ osg::Texture2D* texture = new osg::Texture2D(); texture-setImage( osgDB::readImageFile(fn) );//VTB::createSpotLightImage(centerColour, ambientColour, 64, 1.0)); texture-setWrap(osg::Texture::WRAP_S, osg::Texture::CLAMP_TO_BORDER); texture-setWrap(osg::Texture::WRAP_T, osg::Texture::CLAMP_TO_BORDER); texture-setWrap(osg::Texture::WRAP_R, osg::Texture::CLAMP_TO_BORDER); stateset-setTextureAttributeAndModes( (int)spotTUnit, texture, osg::StateAttribute::ON); // set up tex gens stateset-setTextureMode((int)spotTUnit, GL_TEXTURE_GEN_S, osg::StateAttribute::ON); stateset-setTextureMode((int)spotTUnit, GL_TEXTURE_GEN_T, osg::StateAttribute::ON); stateset-setTextureMode((int)spotTUnit, GL_TEXTURE_GEN_R, osg::StateAttribute::ON); stateset-setTextureMode((int)spotTUnit, GL_TEXTURE_GEN_Q, osg::StateAttribute::ON); /* 3. Handover the texture to the fragment shader via uniform */ osg::Uniform* texUniform = new osg::Uniform(osg::Uniform::SAMPLER_2D, projectionMap); texUniform-set( (int)spotTUnit ); stateset-addUniform(texUniform); /* 4. set Texture matrix*/ //If you want to create the texture matrix by yourself you can do this like this way: //osg::Vec3 projectorPos = osg::Vec3(0.0f, 0.0f, 324.0f); //osg::Vec3 projectorDirection = osg::Vec3(osg::inDegrees(dirX),osg::inDegrees(dirY), osg::inDegrees(dirZ)); //osg::Vec3 up(0.0f, 1.0f, 0.0f); //osg::Vec3 target = osg::Vec3(0.0f, 0.0f,0.0f); //float projectorAngle = 80.f; //FOV //mat = osg::Matrixd::lookAt(projectorPos, projectorPos*target ,up) * osg::Matrixd::perspective(projectorAngle, 1.0, 1.0, 10); osg::Matrix mat = viewA-getCamera()-getViewMatrix() * viewA-getCamera()-getProjectionMatrix(); texMat-setMatrix(mat); stateset-setTextureAttributeAndModes((int)spotTUnit, texMat, osg::StateAttribute::ON); stateset-addUniform( ViewMatInv ); } osg::StateSet* createProjectorState() { osg::StateSet* stateset = new osg::StateSet; osg::ref_ptrosg::Program prog = addShader(); addProjectionInfoToState(stateset, C:\\Users\\bcolbert\\Desktop\\Work\\OpenSceneGraph-Data-3.0.0\\Images\\clockface.JPG); stateset-setAttribute(prog.get());
[osg-users] heip
liu_junli___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org