[osg-users] [osgPlugins] OSG Collada Bug
Hi, I'm importing models from openflight to collada using OSG. After install using these directions http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MingwColladaEclipse Everything seemed to have worked fine, until I ran the Coherency Test on one of the models exported. It failed across the board. I also tried to upload the model onto Google's 3D warehouse, but it appears to be using the wrong schema. Upon closer inspection, it seems that OSG has a bug in it's collada exporter: - All the arrays names ...texcoord_0 are boggus. They all contain Zero elements. - All the geometry seem to want to have 2 texcoord per vertex (texcoord_0 and texcoord_1) but only the texcoord_1 is valid. Materials all reference the texcoord_0, I did not see any reference to texcoord_1 in the file. Is there a fix to this problem? or do I have to correct every model manually? It seems that I can't upload any dae files, so i uploaded it online: http://rapidshare.com/files/244289716/smp_schafer6.dae Thank you! Cheers, Adam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14055#14055 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Example of Camera Following a Node: Know of current one?
Hi Allen, Try osgDB::NodeTrackeManipulator, it's used in osgsimulation example (search in the examples of the sources). Rafa. On Tue, Jun 16, 2009 at 10:36 PM, Allen Saucierallen.sauc...@itt.com wrote: Hi all, does anyone know of a good example of a Camera Following a Node that is current? Thx! Allen Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14051#14051 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Rafael Gaitán Linares Instituto de Automática e Informática Industrial http://www.ai2.upv.es Ciudad Politécnica de la Innovación Universidad Politécnica de Valencia ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OSG Collada Bug
Hello Adam, a quick inspection of the model shows two problems: 1.) There are two nodes with the same name so apparently the Collada writer does not check for uniqueness of the node id. 2.) All meshes have generated two sets of texture coordinates. The first being an empty set causing all kinds of problems. I guess the original OpenFlight model only had a single set of texture coordinates per model part. What version of OSG are you using? regards, Roland Smeenk -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14058#14058 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] OSG Composer released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ashraf Sultan wrote: SimLab releases OSG Composer ... OSG Composer Lite, is our gift to the great OSG community, we hope you like it. http://www.simlab-soft.com/Products.html Gee, this looks good, but no Linux version? Even though there is a Mac one? I am sure there would be customers for Linux version too, this type of work is done mostly on Windows and Linux these days. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKOKSpn11XseNj94gRAvPvAKDBWRnZJMdz87Ln7DBt+msQRD5DPgCfVCFk Yf+6nO6JqN6KcYFpDoQY+jc= =tc9Z -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the policy concerning ref_ptr implicit conversion in OSG itself?
Hi JS, Periodically I do test the OSG build with OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION off, but I haven't don't it recently - I'll fire off a build this morning and fix any problems that arise. Robert. On Tue, Jun 16, 2009 at 8:23 PM, Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com wrote: Hi all, I'm compiling OSG with OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION off because our own software can interchangeably use OSG 2.2, 2.6 and (eventually) 2.10, so I need to be sure everywhere a ref_ptr is used, .get() or .valid() is used to get it or check it. Unfortunately, even OSG itself doesn't compile cleanly with OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION off right now. (I'll submit some changed files soon to fix that) So I was wondering if the policy was that code inside OSG should continue to use .get() and .valid() so that it continues to build cleanly whether OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION is on or off, or if we should just phase out the OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION option altogether (always keep it on, not expose it in CMake). I think whatever policy is chosen within OSG, it should be made clear. Client code could do what it wants and it's the client's responsibility to make sure they're using the right thing with respect to the version of OSG they link to, but within OSG, we need to pick one. Thanks in advance, J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.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] multiple render targets / cameras
Hi Bob, The answer is almost always answered by answering the simple question - no you logically have two separate views or do the two cameras that are taken the pictures share the same view. In your case it does sound like you have a single view, but two ways of rendering it - so you don't have multiple view's, and since you only have a single view then a osgViewer::Viewer (which is a View) will be appropriate. Robert. On Tue, Jun 16, 2009 at 9:59 PM, Bob Youmansbyoum...@knology.net wrote: Hi, thanks for the great advice. if i'm going to have 2 render targets, one a memory image (ultimately custom shader) and one the GUI view window, should i still use Viewer, or CompositeViewer? It would be nice to be able to turn off the visible one for more performance. They will have exactly the same transform matrix, but be different resolutions. So, i need to switch between user / program control of the transformation matrix, and also switch between rendering the memory / visible images (or both). Is this doable? Does it make sense? Thank you! Cheers, Bob -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14052#14052 ___ 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] DisplaySettings::setNumOfHttpDatabaseThreadsHint Bug
Hi Ryan,
Well spotted, I've just fixed this in the svn/trunk and OSG-2.8 branch.
Robert.
On Wed, Jun 17, 2009 at 12:33 AM, Kawicki, Ryan
Hryan.h.kawi...@boeing.com wrote:
I believe there to be a bug in
DisplaySettings::setNumOfHttpDatabaseThreadsHint.
Current implementation
/** Set the hint for number of threads in the DatbasePager to dedicate
to reading http requests.*/
void setNumOfHttpDatabaseThreadsHint(unsigned int numThreads) {
_numDatabaseThreadsHint = numThreads; }
I think it should be
/** Set the hint for number of threads in the DatbasePager to dedicate
to reading http requests.*/
void setNumOfHttpDatabaseThreadsHint(unsigned int numThreads) {
_numHttpDatabaseThreadsHint = numThreads; }
Thanks.
Ryan H. Kawicki
The Boeing Company
Training Systems Services
Software Engineer
___
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] Qt osgviewer
Hi, More recently, Don Leich has proposed a new example on osg-submissions which seems to be very good. Sadly, it seems that we were very few to have looked into it and I'm far from being an expert in QT. Hence, it would be interesting to have others feedback. A link to the thread : http://www.mail-archive.com/osg-submissi...@lists.openscenegraph.org/msg03649.html regrads Loïc Simon On Tue, Jun 16, 2009 at 4:58 PM, Martin Beckett m...@mgbeckett.com wrote: See http://forum.openscenegraph.org/viewtopic.php?t=2517 for some links to Qt examples Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14042#14042 ___ 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] Time management and eventqueue
Hi osg-users, I'm experiencing some problem with time management and osgViewer. I'm under Windows Vista, OSG SVN. I'm using a composite viewer and my rendering code is : pCompoViewer-advance(MyTime); pCompoViewer-getFrameStamp()-setReferenceTime(MyTime); pCompoViewer-getFrameStamp()-setSimulationTime(MyTime); pCompoViewer-eventTraversal(); pCompoViewer-updateTraversal(); pCompoViewer-renderingTraversals(); instead of : pCompoViewer-frame() because I wand to trigger my rendering with a computed time 'MyTime based on a FPS I need. But my problem is that when I use my manipulator and ea.getTime() I do not have the same time as MyTime when event received is for example osgGA::GUIEventAdapter::PUSH. ea.getTime() is equal to MyTime only when receiving osgGA::GUIEventAdapter::FRAME. I tracked down this behaviour, in function GraphicsWindowWin32::handleNativeWindowingEvent because event time is : double eventTime = getEventQueue()-getTime(); and getTime is returning : osg::Timer::instance()-delta_s(_startTick, osg::Timer::instance()-tick()); That's why It doesnt match my rendering time... Is there any way I can resolve this problem ? (Except making my own eventqueue class) -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Time management and eventqueue
Hi Alaxandre, You should leave the ReferenceTime alone, it's only SimulationTime that you should alter and calling frame or advance with this time is suffiicient - there is no need for the extra calls setting the time. The ReferenceTime is meant to be real-time value of the frames - something you'd use for doing stats collection etc., while SimulationTime is meant to be the time used when compute animations and physical simulations in the scene. The _startTick that the event queue uses should be the same one as the ReferenceTime uses and makes sure the ReferenceTime and event times are in sync. It's not typically appropriate to use the SimulationTime when doing event handling, but if you want to then you'll need to use the frames FrameStamp to get the current SimulationTime. Robert. On Wed, Jun 17, 2009 at 10:23 AM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi osg-users, I'm experiencing some problem with time management and osgViewer. I'm under Windows Vista, OSG SVN. I'm using a composite viewer and my rendering code is : pCompoViewer-advance(MyTime); pCompoViewer-getFrameStamp()-setReferenceTime(MyTime); pCompoViewer-getFrameStamp()-setSimulationTime(MyTime); pCompoViewer-eventTraversal(); pCompoViewer-updateTraversal(); pCompoViewer-renderingTraversals(); instead of : pCompoViewer-frame() because I wand to trigger my rendering with a computed time 'MyTime based on a FPS I need. But my problem is that when I use my manipulator and ea.getTime() I do not have the same time as MyTime when event received is for example osgGA::GUIEventAdapter::PUSH. ea.getTime() is equal to MyTime only when receiving osgGA::GUIEventAdapter::FRAME. I tracked down this behaviour, in function GraphicsWindowWin32::handleNativeWindowingEvent because event time is : double eventTime = getEventQueue()-getTime(); and getTime is returning : osg::Timer::instance()-delta_s(_startTick, osg::Timer::instance()-tick()); That's why It doesnt match my rendering time... Is there any way I can resolve this problem ? (Except making my own eventqueue class) -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ 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] PolytopeIntersector
Hi, I have a lot of questions for you! But, there is one really more critical than the others. Let me just introduce the problem :). (I am sorry if I bother, but I searched on the net, in the doc and examples and didn't find answers. I apologize if this is because I badly searched.) I want to cut my primitives along the frustum of a camera. 1) To do this I first have to get my planes equations. I have found a page dealing about this problem in OpenGL: http://www2.ravensoft.com/users/ggribb/plane%20extraction.pdf I think I'll use it, replacing in OSG conventions. I also found this: http://markmail.org/message/eeolcuruqpsbgrgu#query:osg%20frustum+page:1+mid:eeolcuruqpsbgrgu+state:results From famous Paul ;). Well, it draws the frustum, but it can be used to get the planes equations. (for whom it may interest) 2) Then I have my equations. Thus I can declare many osg::Plane. Question If the plane is a Vec4d (a,b,c,d) does it well represent the equation ax+by+cz+d = 0 ? I would like to use a PolytopeIntersector. In the doc it's written planes normals have to point the inside of the polytope. Question How are the normals set when the plane is initialized? Question Is there any problem declaring a non-closed (also called opened) polytope? I don't mind about the far plane. 3) Once I have a polytope, I would like to intersect the polytope with the scene. Thus I declare a PolytopeIntersector I associate to an IntersectionVisitor. The BIG Question How do I associate the IntersectionVisitor to a model? I saw for a LineIntersector it is possible to associate it to a view via computeIntersections(), but it doesn't seem possible to do the same with polytope. 4) Question Having the intersected points, is it possible to easily get the primitive or do I have to use this (it is in french, sorry): http://www.enseignement.polytechnique.fr/profs/informatique/Philippe.Chassignet/03-04/INF_431/td_16.html (exercise 4) Thank you a lot! Cheers, Maxime -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14070#14070 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] Is the osgOcean Linux bug still present?
Pierre, are you using FFTW or FFTSS? This error is known to appear with FFTW, can you try out FFTSS? Thanks! Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14071#14071 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Is the osgOcean Linux bug still present?
Hi Kim, i've just tried with an updated OSG to 2.9.4 and it's still the same... Pierre. Le mardi 16 juin 2009 à 19:50 +0100, Kim C Bale a écrit : Hi all, I know it's only been out one day, but I was wondering if those linux users (it only seemed to occur on certain linux distributions) that experienced the patchy ocean surface bug with the previous version have managed to test the library and noticed if they still have the same issue? It sounded like a pretty nasty bug and I'd like to sort it if it's still present. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Pierre BOURDIN I.M.E.R.I.R. Av. Pascot BP 90443 66004 PERPIGNAN tél: 04 68 56 84 95 fax: 04 68 55 03 86 email: bour...@imerir.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Time management and eventqueue
Hi Robert, Some explanation on what I want to do in my application. First I need to shoot video from rendering at a specified frame rate (25FPS for example). So to do that I have a callback writting images on disk every frame, and I have to slow down my rendering rate, and to increment my time from 1/25 of sec. After that I call advance with this new time (+1/25s). But the main problem occurs when I want to play a path at this low rate, the path manipulator is using real time reference to compute position and orientation so when I shoot my video at 25FPS the path is accelerated. I hope you understand what I need to do (my english vocabulary is limited when it comes to technical explanation, sorry for that). Unfortunately the only solution I had to solve my problem is to change reference time with function setReferenceTime and give it my own time computed on desired frame rate. 2009/6/17 Robert Osfield robert.osfi...@gmail.com Hi Alaxandre, You should leave the ReferenceTime alone, it's only SimulationTime that you should alter and calling frame or advance with this time is suffiicient - there is no need for the extra calls setting the time. The ReferenceTime is meant to be real-time value of the frames - something you'd use for doing stats collection etc., while SimulationTime is meant to be the time used when compute animations and physical simulations in the scene. The _startTick that the event queue uses should be the same one as the ReferenceTime uses and makes sure the ReferenceTime and event times are in sync. It's not typically appropriate to use the SimulationTime when doing event handling, but if you want to then you'll need to use the frames FrameStamp to get the current SimulationTime. Robert. On Wed, Jun 17, 2009 at 10:23 AM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi osg-users, I'm experiencing some problem with time management and osgViewer. I'm under Windows Vista, OSG SVN. I'm using a composite viewer and my rendering code is : pCompoViewer-advance(MyTime); pCompoViewer-getFrameStamp()-setReferenceTime(MyTime); pCompoViewer-getFrameStamp()-setSimulationTime(MyTime); pCompoViewer-eventTraversal(); pCompoViewer-updateTraversal(); pCompoViewer-renderingTraversals(); instead of : pCompoViewer-frame() because I wand to trigger my rendering with a computed time 'MyTime based on a FPS I need. But my problem is that when I use my manipulator and ea.getTime() I do not have the same time as MyTime when event received is for example osgGA::GUIEventAdapter::PUSH. ea.getTime() is equal to MyTime only when receiving osgGA::GUIEventAdapter::FRAME. I tracked down this behaviour, in function GraphicsWindowWin32::handleNativeWindowingEvent because event time is : double eventTime = getEventQueue()-getTime(); and getTime is returning : osg::Timer::instance()-delta_s(_startTick, osg::Timer::instance()-tick()); That's why It doesnt match my rendering time... Is there any way I can resolve this problem ? (Except making my own eventqueue class) -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ 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 -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, Firsty congratulations for these awesome works. When I try to create solution file in cmake on VisualStudio2008 I get the errors; CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: FFTSS_INCLUDE_DIR used as include directory in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean FFTSS_LIBRARY linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean OPENTHREADS_LIBRARY_DEBUG linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean I have compiled the FFTSS library and locate it in same folder with osgOcean-Source folder. Should I declare specific Environment Variable to help cmake for finding right fftss include directory and library? And Do we have to OpenThreads library in debug mode? I have a OSG distiribution in only release mode. Regards. 2009/6/16 Kim C Bale k.b...@hull.ac.uk Hi Martin, This problem arises with two particular effects, the glare and the underwater dof which require special treatment of the alpha component in the framebuffer. You can disable those using: enableUnderwaterDOF(false) enableGlare(false) Then you need to disable the default scene shader with this: setUseDefaultSceneShader(false) In the OceanScene class. If you remove the default shader you'll also lose the underwater light scattering and fogging calculations on models below the surface. Trying to offer lots of out-of-the-box shader effects whilst also accommodating the fixed pipeline is a tricky problem and this area needs a little work, but that should work for you. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Scheffler Sent: 16 June 2009 15:18 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I compiled osgOcean and everything works fine here. I ran into trouble when integrating it with my existing application. When I used the last version of osgOcean, I could just put the ocean somewhere in the scene graph and it did not interact with my other stuff. Now osgOcean blocks my view onto the other objects in the scene. When I add the objects as children to the OceanScene, the objects are shown, but the ocean shaders are applied to the objects. This add some sparkling effects to my animations, which looks nice but is not really what I want. So how can I add my objects to the scene without interference? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14038#14038 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or ghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or%0Ag * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the policy concerning ref_ptr implicit conversion in OSG itself?
Hi JS, On Wed, Jun 17, 2009 at 9:33 AM, Robert Osfieldrobert.osfi...@gmail.com wrote: Periodically I do test the OSG build with OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION off, but I haven't don't it recently - I'll fire off a build this morning and fix any problems that arise. I've now got svn/trunk compiling cleanly with OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION set to OFF, and svn update will get these fixes. I also checked the OSG-2.8 branch and it's clean already and didn't require any mods. For the 2.10 release we'll need to do this same check, please don't assume I'll remember and test it out yourself to make sure that I don't miss anything. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with RTT-cameras when changing window s
Hi, my guess is that the RTT cameras are not fully adapting to the new texture size (even with your calls to dirtyTextureObject and setTextureSize). Have a look through the RTT code path for a method called setupcamera or something similar. You would maybe have to reset the rtt camera (prior to the next renderstage being run) using this. Similar problems exist when one needs to change the camera attachments, I have not found an elegant solution yet. Once you found the method, also search the old mailing list archives, I remember the whole RTT camera reset thing being discussed a while ago. What you could try (as a hack to pinpoint the problem, not a solution) is to create new RTT camera and attachments after resize and see if the problem goes away. rgds jp Guy Volckaert wrote: I guess I should have made the problem more clearer. Essentially, when ever the window is resized, the window become fully black (and I don't know why). The scene graph layout is faily simple, but I decided to provide an image anyways (see attached image). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14012#14012 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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
Re: [osg-users] PolytopeIntersector
Hi Maxime, Maxime BOUCHER schrieb: Hi, I have a lot of questions for you! But, there is one really more critical than the others. Let me just introduce the problem :). (I am sorry if I bother, but I searched on the net, in the doc and examples and didn't find answers. I apologize if this is because I badly searched.) I want to cut my primitives along the frustum of a camera. 1) To do this I first have to get my planes equations. I have found a page dealing about this problem in OpenGL: http://www2.ravensoft.com/users/ggribb/plane%20extraction.pdf I think I'll use it, replacing in OSG conventions. I also found this: http://markmail.org/message/eeolcuruqpsbgrgu#query:osg%20frustum+page:1+mid:eeolcuruqpsbgrgu+state:results From famous Paul ;). Well, it draws the frustum, but it can be used to get the planes equations. (for whom it may interest) 2) Then I have my equations. Thus I can declare many osg::Plane. Question If the plane is a Vec4d (a,b,c,d) does it well represent the equation ax+by+cz+d = 0 ? The plane uses the above plane equation. (If you are familiar with projective spaces, the Vec4 can be seen as the projective normal in homogenous coordinates: (a,b,c,d) dot (x,y,z,w) = 0, where w=1 for affine points ) Note the the representation is only unique up to a factor (you can always multiply the equation with a factor != 0.0) I would like to use a PolytopeIntersector. In the doc it's written planes normals have to point the inside of the polytope. Question How are the normals set when the plane is initialized? The normal is given implicitly by the representation. Given the above equation, the normal is (a,b,c). You can easily change the direction of the plane normal unsing its flip()-method. Question Is there any problem declaring a non-closed (also called opened) polytope? I don't mind about the far plane. No problem at all. PolytopeIntersector uses open polytopes internally when the geometry lies to one side of a plane. 3) Once I have a polytope, I would like to intersect the polytope with the scene. Thus I declare a PolytopeIntersector I associate to an IntersectionVisitor. The BIG Question How do I associate the IntersectionVisitor to a model? I saw for a LineIntersector it is possible to associate it to a view via computeIntersections(), but it doesn't seem possible to do the same with polytope. You call the method accept(osg::NodeVisitor) of your model (which is a osg::Node). See the example osgkeyboardmouse. 4) Question Having the intersected points, is it possible to easily get the primitive or do I have to use this (it is in french, sorry): http://www.enseignement.polytechnique.fr/profs/informatique/Philippe.Chassignet/03-04/INF_431/td_16.html (exercise 4) This exercise is about polygons not polytopes! As for the PolytopeIntersector: It will give you all points, lines, triangles and quads which truly intersect the polytope volume, given by the primitive index. Thank you a lot! Cheers, Maxime Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Umit, Firsty congratulations for these awesome works. Thank you, still plenty to fix though it seems J CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: FFTSS_INCLUDE_DIR When you run CMake it should let you set these manually if they're not found automatically. You will need to explicitly specify the path to the include directory and also the fftss.lib file (this is what I do when I run CMake) When you run the example application the fftss.dll will need to be in the same directory as the exe or by adding the directory it's in to your PATH environment variable (if you're in windows) OPENTHREADS_LIBRARY_DEBUG linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean I think if you just point it to the release mode version of OpenThreads it will let you build the project. But be careful, if you try and build a debug version of the application/library it's highly likely you'll get errors. If that doesn't solve it get back to me. Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 17 June 2009 11:48 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Firsty congratulations for these awesome works. When I try to create solution file in cmake on VisualStudio2008 I get the errors; CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: FFTSS_INCLUDE_DIR used as include directory in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean FFTSS_LIBRARY linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean OPENTHREADS_LIBRARY_DEBUG linked by target osgOcean in directory C:/Projects/Ocean/osgOcean-Source/src/osgOcean I have compiled the FFTSS library and locate it in same folder with osgOcean-Source folder. Should I declare specific Environment Variable to help cmake for finding right fftss include directory and library? And Do we have to OpenThreads library in debug mode? I have a OSG distiribution in only release mode. Regards. 2009/6/16 Kim C Bale k.b...@hull.ac.uk Hi Martin, This problem arises with two particular effects, the glare and the underwater dof which require special treatment of the alpha component in the framebuffer. You can disable those using: enableUnderwaterDOF(false) enableGlare(false) Then you need to disable the default scene shader with this: setUseDefaultSceneShader(false) In the OceanScene class. If you remove the default shader you'll also lose the underwater light scattering and fogging calculations on models below the surface. Trying to offer lots of out-of-the-box shader effects whilst also accommodating the fixed pipeline is a tricky problem and this area needs a little work, but that should work for you. Regards, Kim. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Martin Scheffler Sent: 16 June 2009 15:18 To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I compiled osgOcean and everything works fine here. I ran into trouble when integrating it with my existing application. When I used the last version of osgOcean, I could just put the ocean somewhere in the scene graph and it did not interact with my other stuff. Now osgOcean blocks my view onto the other objects in the scene. When I add the objects as children to the OceanScene, the objects are shown, but the ocean shaders are applied to the objects. This add some sparkling effects to my animations, which looks nice but is not really what I want. So how can I add my objects to the scene without interference? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14038#14038 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or%0Ag * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, Thanks for tips. I have changed the fft library fftss to fftw and I can compiled without any error. When I run the example I get errors as follows. Building scene... . Loading cubemaps: 0.660514s . Generating ocean surface: 0.0465612s . Creating ocean scene: 0.0113174s . Loading islands: 0.079017s . Setting up lighting: 1.81587e-005s complete. Time Taken: 0.798147s VERTEX glCompileShader terrain_vertex_shader FAILED VERTEX Shader terrain_vertex_shader infolog: Vertex shader failed to compile with the following errors: ERROR: 0:34: '*' : wrong operand types no operation '*' exists that takes a le ft-hand operand of type 'uniform 4-component vector of float' and a right operan d of type '3-component vector of float' (or there is no acceptable conversion) ERROR: 0:34: 'assign' : cannot convert from 'uniform 4-component vector of floa t' to 'out 3-component vector of float' ERROR: 2 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Vertex shader(s) were not successfully compiled before glLinkProgram() was calle d. Link failed. Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) VERTEX glCompileShader scene_shader_vertex_shader FAILED VERTEX Shader scene_shader_vertex_shader infolog: Vertex shader failed to compile with the following errors: ERROR: 0:29: '*' : wrong operand types no operation '*' exists that takes a le ft-hand operand of type 'uniform 4-component vector of float' and a right operan d of type '3-component vector of float' (or there is no acceptable conversion) ERROR: 0:29: 'assign' : cannot convert from 'uniform 4-component vector of floa t' to 'out 3-component vector of float' ERROR: 0:45: 'computeScattering' : no matching overloaded function found ERROR: 3 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Vertex shader(s) were not successfully compiled before glLinkProgram() was calle d. Link failed. FRAGMENT glCompileShader downsample_glare_fragment_shader FAILED FRAGMENT Shader downsample_glare_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:2: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader
Re: [osg-users] Time management and eventqueue
Hi, Isn't it possible to make a function in eventqueue class to set a specific time ( setTime(double time) ) instead of using delta between _startTick and current tick ?? We could add a variable to this class to keep in memory an altered time. This way I could keep synchronisation between my custom reference time and the event time. I really have to set a specific frame rate for my viewer to shoot images at this frame rate, and to keep functionnality from the viewer like playing path. Has anyone already experienced the same problem ?? 2009/6/17 Alexandre Amalric alex.pix...@gmail.com Hi Robert, Some explanation on what I want to do in my application. First I need to shoot video from rendering at a specified frame rate (25FPS for example). So to do that I have a callback writting images on disk every frame, and I have to slow down my rendering rate, and to increment my time from 1/25 of sec. After that I call advance with this new time (+1/25s). But the main problem occurs when I want to play a path at this low rate, the path manipulator is using real time reference to compute position and orientation so when I shoot my video at 25FPS the path is accelerated. I hope you understand what I need to do (my english vocabulary is limited when it comes to technical explanation, sorry for that). Unfortunately the only solution I had to solve my problem is to change reference time with function setReferenceTime and give it my own time computed on desired frame rate. 2009/6/17 Robert Osfield robert.osfi...@gmail.com Hi Alaxandre, You should leave the ReferenceTime alone, it's only SimulationTime that you should alter and calling frame or advance with this time is suffiicient - there is no need for the extra calls setting the time. The ReferenceTime is meant to be real-time value of the frames - something you'd use for doing stats collection etc., while SimulationTime is meant to be the time used when compute animations and physical simulations in the scene. The _startTick that the event queue uses should be the same one as the ReferenceTime uses and makes sure the ReferenceTime and event times are in sync. It's not typically appropriate to use the SimulationTime when doing event handling, but if you want to then you'll need to use the frames FrameStamp to get the current SimulationTime. Robert. On Wed, Jun 17, 2009 at 10:23 AM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi osg-users, I'm experiencing some problem with time management and osgViewer. I'm under Windows Vista, OSG SVN. I'm using a composite viewer and my rendering code is : pCompoViewer-advance(MyTime); pCompoViewer-getFrameStamp()-setReferenceTime(MyTime); pCompoViewer-getFrameStamp()-setSimulationTime(MyTime); pCompoViewer-eventTraversal(); pCompoViewer-updateTraversal(); pCompoViewer-renderingTraversals(); instead of : pCompoViewer-frame() because I wand to trigger my rendering with a computed time 'MyTime based on a FPS I need. But my problem is that when I use my manipulator and ea.getTime() I do not have the same time as MyTime when event received is for example osgGA::GUIEventAdapter::PUSH. ea.getTime() is equal to MyTime only when receiving osgGA::GUIEventAdapter::FRAME. I tracked down this behaviour, in function GraphicsWindowWin32::handleNativeWindowingEvent because event time is : double eventTime = getEventQueue()-getTime(); and getTime is returning : osg::Timer::instance()-delta_s(_startTick, osg::Timer::instance()-tick()); That's why It doesnt match my rendering time... Is there any way I can resolve this problem ? (Except making my own eventqueue class) -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ 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 -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Umit, VERTEX glCompileShader terrain_vertex_shader FAILED VERTEX Shader terrain_vertex_shader infolog: I've just fixed this one, if you download the code from the svn it will go away. The rest of the errors seem to suggest that your graphics card / drivers don't support texture rectangles (at least in the shaders), which may well be the case if it's very old. However, you can bypass the texture rectangles by using: oceanScene::setEnableGlare(false); oceanScene::setEnableUnderwaterDOF(false); Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun Sent: 17 June 2009 13:38 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi Kim, Thanks for tips. I have changed the fft library fftss to fftw and I can compiled without any error. When I run the example I get errors as follows. Building scene... . Loading cubemaps: 0.660514s . Generating ocean surface: 0.0465612s . Creating ocean scene: 0.0113174s . Loading islands: 0.079017s . Setting up lighting: 1.81587e-005s complete. Time Taken: 0.798147s VERTEX glCompileShader terrain_vertex_shader FAILED VERTEX Shader terrain_vertex_shader infolog: Vertex shader failed to compile with the following errors: ERROR: 0:34: '*' : wrong operand types no operation '*' exists that takes a le ft-hand operand of type 'uniform 4-component vector of float' and a right operan d of type '3-component vector of float' (or there is no acceptable conversion) ERROR: 0:34: 'assign' : cannot convert from 'uniform 4-component vector of floa t' to 'out 3-component vector of float' ERROR: 2 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Vertex shader(s) were not successfully compiled before glLinkProgram() was calle d. Link failed. Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) VERTEX glCompileShader scene_shader_vertex_shader FAILED VERTEX Shader scene_shader_vertex_shader infolog: Vertex shader failed to compile with the following errors: ERROR: 0:29: '*' : wrong operand types no operation '*' exists that takes a le ft-hand operand of type 'uniform 4-component vector of float' and a right operan d of type '3-component vector of float' (or there is no acceptable conversion) ERROR: 0:29: 'assign' : cannot convert from 'uniform 4-component vector of floa t' to 'out 3-component vector of float' ERROR: 0:45: 'computeScattering' : no matching overloaded function found ERROR: 3 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Vertex shader(s) were not successfully compiled before glLinkProgram() was calle d. Link failed. FRAGMENT glCompileShader downsample_glare_fragment_shader FAILED FRAGMENT Shader downsample_glare_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:2: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader failed to compile with the following errors: ERROR: 0:4: 'samplerRect' : syntax error parse error ERROR: 1 compilation errors. No code generated. glLinkProgram FAILED Program infolog: Fragment shader(s) were not successfully compiled before glLinkProgram() was cal led. Link failed. FRAGMENT glCompileShader streak_shader_fragment_shader FAILED FRAGMENT Shader streak_shader_fragment_shader infolog: Fragment shader
Re: [osg-users] What is the policy concerning ref_ptr implicit conversion in OSG itself?
Hi Robert, For the 2.10 release we'll need to do this same check, please don't assume I'll remember and test it out yourself to make sure that I don't miss anything. OK, so I assume the policy I was asking about is: keep the option and continue to make sure OSG itself compiles cleanly with both settings. It should really have been made explicit before, so that all contributors remember to use .get() when necessary. Now it is, thanks. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Kim, Ümit, When you run the example application the fftss.dll will need to be in the same directory as the exe or by adding the directory it’s in to your PATH environment variable (if you’re in windows) Actually FFTSS doesn't have a DLL, it's a static-link library. FFTW has a DLL (though you could compile it to link statically too if you wanted). When I run the example I get errors as follows. [... snip lots of shader errors ...] I think these all related about driver because of my driver 2.5 years old and it's last updated driver support only opengl 2.1 and GLSL 1.20. I think I can't run osgOcean in my company computer. I have to use another newer one. Any suggestions? Well, some drivers are more permissive than others regarding implicit casts from vec4 to vec3. Some of the errors above seem to be what some drivers would only give warnings about. I'll try to tighten up the shaders so they give no warnings, that will reduce the number of errors you get, but it won't eliminate all of them, because others are about texture rectangles, which your card/driver doesn't seem to support. The full-screen effects require texture rectangles (NPOT textures) to be able to render at the same resolution as your screen (which is in general not in power-of-two resolutions)... Tuth is, 2.5 years is a long time in Graphics. I assume you have a good reason for not updating your driver, but there's little we can do to support such old drivers and still retain all functionality. We could do it if funded to do so, but if not we have to choose a subset of cards/drivers we need to support and do what is necessary for those. If you want to try and fix all errors, of course, we'll be glad to fold your changes into the source :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build Error VS 2005 / SVN 10352
Hi Adrian, I can not build the Latest SVN 10352 Version of OSG because of forward declrations in osgAnimation. Already reported yesterday: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/46477 J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Time management and eventqueue
HI Alexandre, I think your specific problem is related to how the AnimationPathManipulator is not using the SimulationTime, rather than the requirement that events all supply a time relating to SimulationTime. In the case of actual device events they come in at other times than then frame start and it's important to know how and when device events happen in actual time. For AnimatioPathManipulator I can see value in making it possible to use the SimulationTime. This manipulator could be modified to get the current viewer FrameStamp by doing a dynamic cast to osg::View and get the osg::FrameStamp from it rather than than FRAME event. Robert. On Wed, Jun 17, 2009 at 2:10 PM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi, Isn't it possible to make a function in eventqueue class to set a specific time ( setTime(double time) ) instead of using delta between _startTick and current tick ?? We could add a variable to this class to keep in memory an altered time. This way I could keep synchronisation between my custom reference time and the event time. I really have to set a specific frame rate for my viewer to shoot images at this frame rate, and to keep functionnality from the viewer like playing path. Has anyone already experienced the same problem ?? 2009/6/17 Alexandre Amalric alex.pix...@gmail.com Hi Robert, Some explanation on what I want to do in my application. First I need to shoot video from rendering at a specified frame rate (25FPS for example). So to do that I have a callback writting images on disk every frame, and I have to slow down my rendering rate, and to increment my time from 1/25 of sec. After that I call advance with this new time (+1/25s). But the main problem occurs when I want to play a path at this low rate, the path manipulator is using real time reference to compute position and orientation so when I shoot my video at 25FPS the path is accelerated. I hope you understand what I need to do (my english vocabulary is limited when it comes to technical explanation, sorry for that). Unfortunately the only solution I had to solve my problem is to change reference time with function setReferenceTime and give it my own time computed on desired frame rate. 2009/6/17 Robert Osfield robert.osfi...@gmail.com Hi Alaxandre, You should leave the ReferenceTime alone, it's only SimulationTime that you should alter and calling frame or advance with this time is suffiicient - there is no need for the extra calls setting the time. The ReferenceTime is meant to be real-time value of the frames - something you'd use for doing stats collection etc., while SimulationTime is meant to be the time used when compute animations and physical simulations in the scene. The _startTick that the event queue uses should be the same one as the ReferenceTime uses and makes sure the ReferenceTime and event times are in sync. It's not typically appropriate to use the SimulationTime when doing event handling, but if you want to then you'll need to use the frames FrameStamp to get the current SimulationTime. Robert. On Wed, Jun 17, 2009 at 10:23 AM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi osg-users, I'm experiencing some problem with time management and osgViewer. I'm under Windows Vista, OSG SVN. I'm using a composite viewer and my rendering code is : pCompoViewer-advance(MyTime); pCompoViewer-getFrameStamp()-setReferenceTime(MyTime); pCompoViewer-getFrameStamp()-setSimulationTime(MyTime); pCompoViewer-eventTraversal(); pCompoViewer-updateTraversal(); pCompoViewer-renderingTraversals(); instead of : pCompoViewer-frame() because I wand to trigger my rendering with a computed time 'MyTime based on a FPS I need. But my problem is that when I use my manipulator and ea.getTime() I do not have the same time as MyTime when event received is for example osgGA::GUIEventAdapter::PUSH. ea.getTime() is equal to MyTime only when receiving osgGA::GUIEventAdapter::FRAME. I tracked down this behaviour, in function GraphicsWindowWin32::handleNativeWindowingEvent because event time is : double eventTime = getEventQueue()-getTime(); and getTime is returning : osg::Timer::instance()-delta_s(_startTick, osg::Timer::instance()-tick()); That's why It doesnt match my rendering time... Is there any way I can resolve this problem ? (Except making my own eventqueue class) -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ 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
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still on my list of things to do. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ 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] What is the policy concerning ref_ptr implicit conversion in OSG itself?
Hi JS, On Wed, Jun 17, 2009 at 2:30 PM, Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com wrote: For the 2.10 release we'll need to do this same check, please don't assume I'll remember and test it out yourself to make sure that I don't miss anything. OK, so I assume the policy I was asking about is: keep the option and continue to make sure OSG itself compiles cleanly with both settings. Yes this is the current policy, but it's a little informal. As long as the code base can be easily maintained to work without the implicit casts I'm happy to maintain backwards compatibility. There might be a point in the future that the pain vs gain no longer justifies this - for instance an OSG-3.0 we might just drop this as other sweeping changes would not be backwards compatible anyway. It should really have been made explicit before, so that all contributors remember to use .get() when necessary. Now it is, thanks. I'm note quite where little things like this might be made explicit - on the wiki, on mailing lists threds. There are lots of little things that we could potential tie down and formalize, but many things are that cast in stone and evolve, often it's just easier to take things as they come as resolve problems as they arise. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still on my list of things to do. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ 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* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html
Re: [osg-users] Example of Camera Following a Node: Know of current one?
Thanks Rafa! Will do. :) Allen -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14094#14094 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PolytopeIntersector
Hi Maxime, Maxime BOUCHER schrieb: [...] Peter Hrenka wrote: You call the method accept(osg::NodeVisitor) of your model (which is a osg::Node). See the example osgkeyboardmouse. My bad, I should have seen it. We certainly need an osgpolytopeintersector example... Meanwhile grep is your friend. Peter Hrenka wrote: This exercise is about polygons not polytopes! Yes, I meant testing this way for each primitive. Well... I fail to see an analogy here. The point of Polytopes is that they are convex which makes all kinds of tests very easy. If you want to modell something non-convex (something like Constructive Solid Geometry) then PolytopeIntersector will not help you as it is. Peter Hrenka wrote: As for the PolytopeIntersector: It will give you all points, lines, triangles and quads which truly intersect the polytope volume, given by the primitive index. Sorry, I'm not sure I really understand. It is possible to get the intersected triangle instead of just a list of intersections coordinates? The struct PolytopeIntersector::Intersection contains a int-member primitiveIndex which probably is what you want. There is code to output the primitiveIndex in the osgkeyboardmouse example. You can access the first intersection with PolytopeIntersector::getFirstIntersection() or the set of all Intersections with PolytopeIntersector::getIntersections(). Cheers, Peter -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Time management and eventqueue
Hi Robert, First thank you for answering me so quick, I think that all manipulators should use simulation time, take the case of the DriveManipulator, it would be nice to use it when simulation time is altered (speed should be slower at a 25FPS rate on 3D rendering but when making my video with video editing software at 25FPS, the speed will be normal). User could be able to drive at an altered frame rate in the same way he use it with a normal frame rate (same can be applied to flightmanipulator). That's why I agree with you that modifying reference time isn't the ideal solution, and it's very valuable for osg community to modify manipulators in a way that they use simulation time instead of FRAME event like you said. I'm not sure on how to do that, but i'll try in my own manipulator... 2009/6/17 Robert Osfield robert.osfi...@gmail.com HI Alexandre, I think your specific problem is related to how the AnimationPathManipulator is not using the SimulationTime, rather than the requirement that events all supply a time relating to SimulationTime. In the case of actual device events they come in at other times than then frame start and it's important to know how and when device events happen in actual time. For AnimatioPathManipulator I can see value in making it possible to use the SimulationTime. This manipulator could be modified to get the current viewer FrameStamp by doing a dynamic cast to osg::View and get the osg::FrameStamp from it rather than than FRAME event. Robert. On Wed, Jun 17, 2009 at 2:10 PM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi, Isn't it possible to make a function in eventqueue class to set a specific time ( setTime(double time) ) instead of using delta between _startTick and current tick ?? We could add a variable to this class to keep in memory an altered time. This way I could keep synchronisation between my custom reference time and the event time. I really have to set a specific frame rate for my viewer to shoot images at this frame rate, and to keep functionnality from the viewer like playing path. Has anyone already experienced the same problem ?? 2009/6/17 Alexandre Amalric alex.pix...@gmail.com Hi Robert, Some explanation on what I want to do in my application. First I need to shoot video from rendering at a specified frame rate (25FPS for example). So to do that I have a callback writting images on disk every frame, and I have to slow down my rendering rate, and to increment my time from 1/25 of sec. After that I call advance with this new time (+1/25s). But the main problem occurs when I want to play a path at this low rate, the path manipulator is using real time reference to compute position and orientation so when I shoot my video at 25FPS the path is accelerated. I hope you understand what I need to do (my english vocabulary is limited when it comes to technical explanation, sorry for that). Unfortunately the only solution I had to solve my problem is to change reference time with function setReferenceTime and give it my own time computed on desired frame rate. 2009/6/17 Robert Osfield robert.osfi...@gmail.com Hi Alaxandre, You should leave the ReferenceTime alone, it's only SimulationTime that you should alter and calling frame or advance with this time is suffiicient - there is no need for the extra calls setting the time. The ReferenceTime is meant to be real-time value of the frames - something you'd use for doing stats collection etc., while SimulationTime is meant to be the time used when compute animations and physical simulations in the scene. The _startTick that the event queue uses should be the same one as the ReferenceTime uses and makes sure the ReferenceTime and event times are in sync. It's not typically appropriate to use the SimulationTime when doing event handling, but if you want to then you'll need to use the frames FrameStamp to get the current SimulationTime. Robert. On Wed, Jun 17, 2009 at 10:23 AM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi osg-users, I'm experiencing some problem with time management and osgViewer. I'm under Windows Vista, OSG SVN. I'm using a composite viewer and my rendering code is : pCompoViewer-advance(MyTime); pCompoViewer-getFrameStamp()-setReferenceTime(MyTime); pCompoViewer-getFrameStamp()-setSimulationTime(MyTime); pCompoViewer-eventTraversal(); pCompoViewer-updateTraversal(); pCompoViewer-renderingTraversals(); instead of : pCompoViewer-frame() because I wand to trigger my rendering with a computed time 'MyTime based on a FPS I need. But my problem is that when I use my manipulator and ea.getTime() I do not have the same time as MyTime when event received is for example osgGA::GUIEventAdapter::PUSH. ea.getTime() is equal to MyTime only when receiving
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still on my list of things to do. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *
Re: [osg-users] Time management and eventqueue
Hi Alexandre, Interactive event based interaction shouldn't happen in simulation time, general animations and simulation should happen in simulation time. If you have a proper drive simulation then all the physics you'd do in simulation time, the DriveManipulator we have isn't a physical simulation though, it's just a interactive camera manipulator that gives a driving style interactive, it isn't meant to be physically based. AnimationPathManipulator is potentially a bit different though, as it's not interactive. Robert. On Wed, Jun 17, 2009 at 3:39 PM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi Robert, First thank you for answering me so quick, I think that all manipulators should use simulation time, take the case of the DriveManipulator, it would be nice to use it when simulation time is altered (speed should be slower at a 25FPS rate on 3D rendering but when making my video with video editing software at 25FPS, the speed will be normal). User could be able to drive at an altered frame rate in the same way he use it with a normal frame rate (same can be applied to flightmanipulator). That's why I agree with you that modifying reference time isn't the ideal solution, and it's very valuable for osg community to modify manipulators in a way that they use simulation time instead of FRAME event like you said. I'm not sure on how to do that, but i'll try in my own manipulator... 2009/6/17 Robert Osfield robert.osfi...@gmail.com HI Alexandre, I think your specific problem is related to how the AnimationPathManipulator is not using the SimulationTime, rather than the requirement that events all supply a time relating to SimulationTime. In the case of actual device events they come in at other times than then frame start and it's important to know how and when device events happen in actual time. For AnimatioPathManipulator I can see value in making it possible to use the SimulationTime. This manipulator could be modified to get the current viewer FrameStamp by doing a dynamic cast to osg::View and get the osg::FrameStamp from it rather than than FRAME event. Robert. On Wed, Jun 17, 2009 at 2:10 PM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi, Isn't it possible to make a function in eventqueue class to set a specific time ( setTime(double time) ) instead of using delta between _startTick and current tick ?? We could add a variable to this class to keep in memory an altered time. This way I could keep synchronisation between my custom reference time and the event time. I really have to set a specific frame rate for my viewer to shoot images at this frame rate, and to keep functionnality from the viewer like playing path. Has anyone already experienced the same problem ?? 2009/6/17 Alexandre Amalric alex.pix...@gmail.com Hi Robert, Some explanation on what I want to do in my application. First I need to shoot video from rendering at a specified frame rate (25FPS for example). So to do that I have a callback writting images on disk every frame, and I have to slow down my rendering rate, and to increment my time from 1/25 of sec. After that I call advance with this new time (+1/25s). But the main problem occurs when I want to play a path at this low rate, the path manipulator is using real time reference to compute position and orientation so when I shoot my video at 25FPS the path is accelerated. I hope you understand what I need to do (my english vocabulary is limited when it comes to technical explanation, sorry for that). Unfortunately the only solution I had to solve my problem is to change reference time with function setReferenceTime and give it my own time computed on desired frame rate. 2009/6/17 Robert Osfield robert.osfi...@gmail.com Hi Alaxandre, You should leave the ReferenceTime alone, it's only SimulationTime that you should alter and calling frame or advance with this time is suffiicient - there is no need for the extra calls setting the time. The ReferenceTime is meant to be real-time value of the frames - something you'd use for doing stats collection etc., while SimulationTime is meant to be the time used when compute animations and physical simulations in the scene. The _startTick that the event queue uses should be the same one as the ReferenceTime uses and makes sure the ReferenceTime and event times are in sync. It's not typically appropriate to use the SimulationTime when doing event handling, but if you want to then you'll need to use the frames FrameStamp to get the current SimulationTime. Robert. On Wed, Jun 17, 2009 at 10:23 AM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi osg-users, I'm experiencing some problem with time management and osgViewer. I'm under Windows Vista, OSG SVN. I'm using a composite viewer and my rendering code is :
Re: [osg-users] Time management and eventqueue
Hi Robert, Ok let's forget drive and flight manipulators, I still have a question about your last post. You said AnimationPathManipulator could be modified to get the current viewer FrameStamp by doing a dynamic cast to osg::View and get the osg::FrameStamp from it rather than than FRAME event Dynamic cast to osg::View has to be done on wich object ?? When I try to dynamic cast my derived osgGA::MatrixManipulator to an osg::View the pointer is null. Could you point me in the right direction please ? 2009/6/17 Robert Osfield robert.osfi...@gmail.com Hi Alexandre, Interactive event based interaction shouldn't happen in simulation time, general animations and simulation should happen in simulation time. If you have a proper drive simulation then all the physics you'd do in simulation time, the DriveManipulator we have isn't a physical simulation though, it's just a interactive camera manipulator that gives a driving style interactive, it isn't meant to be physically based. AnimationPathManipulator is potentially a bit different though, as it's not interactive. Robert. On Wed, Jun 17, 2009 at 3:39 PM, Alexandre Amalricalex.pix...@gmail.com wrote: Hi Robert, First thank you for answering me so quick, I think that all manipulators should use simulation time, take the case of the DriveManipulator, it would be nice to use it when simulation time is altered (speed should be slower at a 25FPS rate on 3D rendering but when making my video with video editing software at 25FPS, the speed will be normal). User could be able to drive at an altered frame rate in the same way he use it with a normal frame rate (same can be applied to flightmanipulator). That's why I agree with you that modifying reference time isn't the ideal solution, and it's very valuable for osg community to modify manipulators in a way that they use simulation time instead of FRAME event like you said. I'm not sure on how to do that, but i'll try in my own manipulator... 2009/6/17 Robert Osfield robert.osfi...@gmail.com HI Alexandre, I think your specific problem is related to how the AnimationPathManipulator is not using the SimulationTime, rather than the requirement that events all supply a time relating to SimulationTime. In the case of actual device events they come in at other times than then frame start and it's important to know how and when device events happen in actual time. For AnimatioPathManipulator I can see value in making it possible to use the SimulationTime. This manipulator could be modified to get the current viewer FrameStamp by doing a dynamic cast to osg::View and get the osg::FrameStamp from it rather than than FRAME event. Robert. On Wed, Jun 17, 2009 at 2:10 PM, Alexandre Amalric alex.pix...@gmail.com wrote: Hi, Isn't it possible to make a function in eventqueue class to set a specific time ( setTime(double time) ) instead of using delta between _startTick and current tick ?? We could add a variable to this class to keep in memory an altered time. This way I could keep synchronisation between my custom reference time and the event time. I really have to set a specific frame rate for my viewer to shoot images at this frame rate, and to keep functionnality from the viewer like playing path. Has anyone already experienced the same problem ?? 2009/6/17 Alexandre Amalric alex.pix...@gmail.com Hi Robert, Some explanation on what I want to do in my application. First I need to shoot video from rendering at a specified frame rate (25FPS for example). So to do that I have a callback writting images on disk every frame, and I have to slow down my rendering rate, and to increment my time from 1/25 of sec. After that I call advance with this new time (+1/25s). But the main problem occurs when I want to play a path at this low rate, the path manipulator is using real time reference to compute position and orientation so when I shoot my video at 25FPS the path is accelerated. I hope you understand what I need to do (my english vocabulary is limited when it comes to technical explanation, sorry for that). Unfortunately the only solution I had to solve my problem is to change reference time with function setReferenceTime and give it my own time computed on desired frame rate. 2009/6/17 Robert Osfield robert.osfi...@gmail.com Hi Alaxandre, You should leave the ReferenceTime alone, it's only SimulationTime that you should alter and calling frame or advance with this time is suffiicient - there is no need for the extra calls setting the time. The ReferenceTime is meant to be real-time value of the frames - something you'd use for doing stats collection etc., while SimulationTime is meant to be the time used when compute animations and physical
Re: [osg-users] Time management and eventqueue
Hi Alexandre,
On Wed, Jun 17, 2009 at 4:03 PM, Alexandre Amalricalex.pix...@gmail.com wrote:
You said
AnimationPathManipulator could be modified to get the
current viewer FrameStamp by doing a dynamic cast to osg::View and get
the osg::FrameStamp from it rather than than FRAME event
Dynamic cast to osg::View has to be done on wich object ?? When I try to
dynamic cast my derived osgGA::MatrixManipulator to an osg::View the pointer
is null.
Could you point me in the right direction please ?
Have a look at the osgpick example as it has an example of code
casting to a View from the GUIActionHandler :
bool PickHandler::handle(const osgGA::GUIEventAdapter
ea,osgGA::GUIActionAdapter aa)
{
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::PUSH):
{
osgViewer::View* view = dynamic_castosgViewer::View*(aa);
if (view) pick(view,ea);
return false;
}
In your case casting to an osg::View* would be sufficient as it has an
osg::FrameStamp. osgViewer::View subclasses from osg:View so the cast
should resolve this fine.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation compile errors in SVN
Hi all,
Is there any news from Cedric on this problem ? The current SVN still don't
build under Windows and VS...
As a side note, anyone knows if there is a way to tell CMAKE to not stop the
installation step if one of the libs or plugins as failed to compile ? Not
all my projects use osgAnimation so it's not a big problem that it doesn't
build, but it's much more anoying to have to do the installation process by
hand because it stops when it tries to install the osgAnimation lib.
Thanks,
On Tue, Jun 16, 2009 at 4:42 PM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi JS,
It's actually Cedric's that fixed most of the problems (he has write
permission on osgAnimation). he works under Linux though so won't have
seen this one. I've added him explictly to the CC to make sure that
he spots your email and knows that things are quite yet resolved.
Robert.
On Tue, Jun 16, 2009 at 3:36 PM, Jean-Sébastien
Guayjean-sebastien.g...@cm-labs.com wrote:
Hi Robert, all,
I'm getting compile errors in osgAnimation, its plugin and one of its
examples (osganimationtimeline) after an SVN update (which fixed other
compile errors seen on my CDash build - thanks Robert :-) ). They all
come
from the fact that a class is forward-declared, and then used in a
ref_ptr.
Here are the two cases (they are repeated wherever the headers are
included,
but there are only two unique cases):
in osgAnimation/Timeline:
namespace osgAnimation {
// ...
class StatsActionVisitor;
// ...
class OSGANIMATION_EXPORT Timeline : public Action
{
// ...
protected:
// ...
osg::ref_ptrosgAnimation::StatsActionVisitor _statsVisitor;
// ...
};
}
and the same thing in osgAnimation::ActionVisitor, for
std::vectorosg::ref_ptrTimeline _stackTimeline;
in the ActionVisitor class.
Not sure how to fix this one, as the forward declaration seems to be used
to
remove a circular dependency but it seems the complete type must be
known.
I've attached the complete compiler output.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
1-- Build started: Project: osgAnimation, Configuration: Release
Win32
--
1Compiling...
1Timeline.cpp
1TimelineAnimationManager.cpp
1C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osg/ref_ptr(33) :
error
C2027: use of undefined type 'osgAnimation::StatsActionVisitor'
1
C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgAnimation/Timeline(29)
: see declaration of 'osgAnimation::StatsActionVisitor'
1
C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osg/ref_ptr(33) :
while compiling class template member function
'osg::ref_ptrT::~ref_ptr(void)'
1with
1[
1T=osgAnimation::StatsActionVisitor
1]
1
C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgAnimation/Timeline(96)
: see reference to class template instantiation 'osg::ref_ptrT' being
compiled
1with
1[
1T=osgAnimation::StatsActionVisitor
1]
1C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osg/ref_ptr(33) :
error
C2227: left of '-unref' must point to class/struct/union/generic type
1StatsHandler.cpp
1..\..\..\src\osgAnimation\StatsHandler.cpp(428) : warning C4245:
'argument' : conversion from 'int' to 'osg::Node::NodeMask',
signed/unsigned
mismatch
1..\..\..\src\osgAnimation\StatsHandler.cpp(444) : warning C4245:
'argument' : conversion from 'int' to 'osg::Node::NodeMask',
signed/unsigned
mismatch
1StatsVisitor.cpp
1ActionVisitor.cpp
1C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osg/ref_ptr(33) :
error
C2027: use of undefined type 'osgAnimation::StatsActionVisitor'
1
C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgAnimation/Timeline(29)
: see declaration of 'osgAnimation::StatsActionVisitor'
1
C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osg/ref_ptr(33) :
while compiling class template member function
'osg::ref_ptrT::~ref_ptr(void)'
1with
1[
1T=osgAnimation::StatsActionVisitor
1]
1
C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgAnimation/Timeline(96)
: see reference to class template instantiation 'osg::ref_ptrT' being
compiled
1with
1[
1T=osgAnimation::StatsActionVisitor
1]
1C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osg/ref_ptr(33) :
error
C2227: left of '-unref' must point to class/struct/union/generic type
1ActionCallback.cpp
1C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osg/ref_ptr(33) :
error
C2027: use of undefined type 'osgAnimation::StatsActionVisitor'
1
C:\Dev\OpenSceneGraph-SVN\OpenSceneGraph\include\osgAnimation/Timeline(29)
:
Re: [osg-users] osgAnimation compile errors in SVN
On Wed, Jun 17, 2009 at 5:41 PM, Serge Lagesserge.la...@gmail.com wrote: Is there any news from Cedric on this problem ? The current SVN still don't build under Windows and VS... No news yet. I'll got look into the problem myself to see if I can spot a way of resolving the issue. As a side note, anyone knows if there is a way to tell CMAKE to not stop the installation step if one of the libs or plugins as failed to compile ? Not all my projects use osgAnimation so it's not a big problem that it doesn't build, but it's much more anoying to have to do the installation process by hand because it stops when it tries to install the osgAnimation lib. I'm not aware of one. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation compile errors in SVN
On 17/6/09 6:41 PM, Serge Lages wrote: Is there any news from Cedric on this problem ? The current SVN still don't build under Windows and VS... Also does not build on OS X. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with RTT-cameras when changing window s
As you may have noticed from my scene graph layout, I have a switch node above the RTT camera. This switch node allows me to enable/disable the RTT process. By default, this switch node has the RTT process disabled. So, the RTT process is not executed. I also found that (by default) the update traversal mode is set to traverse all children (TRAVERSE_ALL_CHILDREN). I originally thought that this was my problem, so I changed the traversal mode to TRAVERSE_ACTIVE_CHILDREN, but I still get the same problem when update callbacks are being called twice every frame. Example: m_pViewer-getUpdateVisitor( )-setTraversalMode( osg::NodeVisitor::TRAVERSE_ACTIVE_CHILDREN ); Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14106#14106 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation compile errors in SVN
Hi Guys, I've just checked in a little re-factor to try and address these issues. Could you do an svn update and see if this fixes the problems? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy Possibly the most important change is that the library is now held under a LGPL license. The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for the FFT library dependancy which resolves the license issue. FFTW is the faster option, but the differance if fairly negliable within the context that it's used. The library now searches for it's resource dependancies using the osgDB registry so they're not bound to a specific path. I've also included a fix for the shader bug on 7 series nVidia cards which caused an error when indexing arrays using uniform variables. The example application now supports real-time changes to the ocean surface and effects so you can have a play with the settings to see what they do. A lot of the work has been submitted by Jean-Sebastian. If anybody else would like to contribute do get in touch. Many hands make light work and all that ;) For those of you that suggested features/enhancement that aren't in this release, don't worry I haven't forgotten about them, they're still
Re: [osg-users] Threading Bug Revisit
Robert, The issue brought up in the original thread has been already been addressed in recent OSG versions, so the getRefMutex no longer returns NULL, but returns the shared global mutex. So I don't believe this is an issue any more. Many apologies. I did not mean to bring this out as a crash bug needing to be fixed, but rather wanted to know the reason behind using a global mutex. I'm not clear on how this example would cause a problem with a single mutex lock being used in this context. Do you have an actual crash/error in behavior that you have observed? No crash to report but more of a behavioral problem. If the main thread is constructing objects while the database pager is constructing sections of the terrain, there is the possibility for the main thread to be blocked by the database thread. The more database threads there are, I would assume the greater the chance any one of the threads will be blocked. The argument here isn't that the operation is not thread safe. The argument here is that addParent is serializing itself across multiple threads, even when the data is unrelated. Speed of creation and deletion objects and memory consumption is the reason not to have a Mutex per Referenced object. Mutex's are relatively large and slow to create/destroy which is amoung the reasons why using atomic ref counts where possible is desirable. Makes perfect sense. Currently, I do not have an idea on how to change this. I just wanted to make this known. Ryan H. Kawicki The Boeing Company Training Systems Services Software Engineer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with RTT-cameras when changing window s
Hi, Please disregard my last 2 postings. I am such an idiot (*sometimes*). I just noticed a big flaw in my scen graph layout that was causing the problem. Sorry for the confusion. Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14112#14112 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation compile errors in SVN
Thanks Robert, it works (under Windows) ! On Wed, Jun 17, 2009 at 6:55 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Guys, I've just checked in a little re-factor to try and address these issues. Could you do an svn update and see if this fixes the problems? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up properly, then the window goes blank with the following printed to the console: Building scene... . Loading cubemaps: 0.213689s . Generating ocean surface: 1.89968e-005s . Creating ocean scene: 0.000278248s . Loading islands: 0.0593453s . Setting up lighting: 1.73206e-005s complete. Time Taken: 0.276148s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,) RenderStage::drawInner(,) FBO status= 0x8cd5 It works fine if I run at 1024x768. Is this likely a driver problem, or is there something I can tweak in the FBO setup? I'm not familiar with their use at all. Thanks Martins Kim C Bale wrote: Hi all, After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. http://code.google.com/p/osgocean/ Feature list: - FFT ocean simulation model and rendering - Foam caps - Refraction/Reflection Passes - God Rays - Surface glare - Underwater depth of field - Underwater/above water fogging - Simulated light absorption and scattering - Silt effects - Screen distortion effects - Choice of FFT library dependancy
Re: [osg-users] PolytopeIntersector
[quote]The point of Polytopes is that they are convex which makes all kinds of tests very easy. If you want to modell something non-convex (something like Constructive Solid Geometry) then PolytopeIntersector will not help you as it is.[quote] My solutution was to triangulate the convex polygon I wanted to search using osgUtil::Tessellator and then use polytrope interceptor for each triangle. I also looked at splitting the polygon into a number of convex polygons but there was no speed difference for polygons having 100 sides. Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14115#14115 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgMovie - Possible shader error?
Hi Robert, I had some people bug reports about the use of samplerRect in the osgOcean shaders. I've found out that the prefered format is now sampler2DRect and texture2DRect. Since this has caused problems for me, i noticed you still have a dangling samplerRect in one of the shaders in http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/examples/osgmovie/osgmovie.cpp uniform samplerRect movie_texture;\n On line 413. Just thought I'd point it out since sampler2DRect is used everywhere else the OSG. Regards, Kim. * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Hi Martin, Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. I've seen that too, and also: If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. Perhaps they're the same problem, and the black line you see from underwater is peeking over the water only at certain places, hence when above water you only see a few black pixels at different points as the waves move? These two are probably just problems in the shaders, not bugs in drivers or such. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation compile errors in SVN
I compiled the trunk on the last vc express on win32 virtual machine. I thought it was resolved. I will take time to check it Cheers, Cedric On Wed, 2009-06-17 at 17:46 +0100, Robert Osfield wrote: On Wed, Jun 17, 2009 at 5:41 PM, Serge Lagesserge.la...@gmail.com wrote: Is there any news from Cedric on this problem ? The current SVN still don't build under Windows and VS... No news yet. I'll got look into the problem myself to see if I can spot a way of resolving the issue. As a side note, anyone knows if there is a way to tell CMAKE to not stop the installation step if one of the libs or plugins as failed to compile ? Not all my projects use osgAnimation so it's not a big problem that it doesn't build, but it's much more anoying to have to do the installation process by hand because it stops when it tries to install the osgAnimation lib. I'm not aware of one. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Threading Bug Revisit
HI Ryan, On Wed, Jun 17, 2009 at 6:16 PM, Kawicki, Ryan Hryan.h.kawi...@boeing.com wrote: No crash to report but more of a behavioral problem. If the main thread is constructing objects while the database pager is constructing sections of the terrain, there is the possibility for the main thread to be blocked by the database thread. The more database threads there are, I would assume the greater the chance any one of the threads will be blocked. The argument here isn't that the operation is not thread safe. The argument here is that addParent is serializing itself across multiple threads, even when the data is unrelated. This would only be a problem is the main thread or database thread hold on to this mutex - they just lock an object access the data and unlock the data. There are very few mutexes that hold on to a mutex for any period of time. I wouldn't expect this sharing of mutexes in this particular context to be a major issue for performance. Has there been anything that has made your think that this might be a performance issue? Robert ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation compile errors in SVN
Hi Cedric, On Wed, Jun 17, 2009 at 7:06 PM, Cedric Pinsoncedric.pin...@plopbyte.net wrote: I compiled the trunk on the last vc express on win32 virtual machine. I thought it was resolved. I will take time to check it Could you check out my changes. The only contenious one was changing an std::vectorref_ptrTimeline to a std::vectorTimeline* in ActionVisitor.For performance using a Timeline* would be preferable any way. Robert/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgOcean 1.0 (LGPL) Released
Martins, J-S, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Yep it's a bug in the library. Looks like a polygon break to me, possibly a corner piece. I must have been trying to ignore it as it's a nightmare to debug that bit of code. I'll log it, but it could take a while to find that blighter. If you disable godrays, silt and dof (basically disable all underwater effects) then go underwater, you'll see a black like at the horizon. it looks like fog is not being applied for a line of pixels at the horizon. I think this is a fogging issue, the wave tops are probably going over the fog line and exposing unfogged geometry. Shouldn't be too bad that one. Cheers all. Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 19:35 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, Here you go. If you zoom in to 400% or so you can see 3 pixels near the horizon that are really dark. They flicker during the simulation, sometimes individual pixels, other times it looks like larger groups. Sorry if this comes through twice, looks like the first one was too big for the list. Martins Kim C Bale wrote: Hi Martins, It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. Could you post a screen shot of that? Does sound a like it could be a bug in the rendering rather than a driver issue. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. I've jumped to conclusion on that one. I just tested that on mine and get the same RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd errors as yourself. I'll look into it. Cheers chap, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 17:56 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Kim, OK, I upgraded the driver to the latest version (185.85) and have made some progress. It now works at any resolution in 32 bit color, but with some shimmering black pixels where the sky meets the ocean. Kind of like you get if you had a bad DVI cable going to your monitor. At 16 bit color, I can get it to work if I toggle off glare. I still get the FBO setup errors, but it seems to look ok, and the out of memory errors are gone. So I guess I'll chalk it up to drivers, I'll keep checking for newer ones. Thanks for the suggestions. Martins Kim C Bale wrote: Hi Martins, Sorry, little hasty with the send button there. This is an odd one, I don't understand why changing your screen resolution would affect the program, so, I *suspect* this is a driver problem. I had similar problems just a week ago with osgOcean when I updated to the latest set of drivers for my 8800GTS 512, and it was giving me the 'out of memory' errors you've got. Rolling back my drivers solved it. Perhaps J-S has some ideas on this one. In the mean time you should be able to disable all the effects that use FBOs with the following keys. r - reflections R - refractions o - depth of field g - glare G - godrays Regards, Kim. From: osg-users-boun...@lists.openscenegraph.org on behalf of Martins Innus Sent: Wed 17/06/2009 15:16 To: OpenSceneGraph Users Subject: Re: [osg-users] osgOcean 1.0 (LGPL) Released Hi, I'm having trouble getting this to run. Machine Specs: Windows XP Visual Studio 2003 NVIDIA Quadro FX 1600M OSG 2.8.1 Compiled osgOcean with FFTSS and it builds fine. With my display set to 1920x1200 at 16 bit color I get the following: E:\Windows\OSG\2.8.1\install\binoceanExample.exe Building scene... . Loading cubemaps: 0.212617s . Generating ocean surface: 2.43048e-005s . Creating ocean scene: 0.000286629s . Loading islands: 0.0594939s . Setting up lighting: 2.26286e-005s complete. Time Taken: 0.274954s RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd and just a blank screen shows up. If I change to 32 bit color at the same resolution, I get a couple frames that show up
Re: [osg-users] osgAnimation compile errors in SVN
On 17/6/09 6:55 PM, Robert Osfield wrote: I've just checked in a little re-factor to try and address these issues. Could you do an svn update and see if this fixes the problems? Compiles fine on OS X. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAnimation compile errors in SVN
Hi Robert, Thank you for the fix, i use by default ref_ptr and after only i think if it's a performance problem :) It better to keep your version. Thank you Cedric On Wed, 2009-06-17 at 19:49 +0100, Robert Osfield wrote: Hi Cedric, On Wed, Jun 17, 2009 at 7:06 PM, Cedric Pinsoncedric.pin...@plopbyte.net wrote: I compiled the trunk on the last vc express on win32 virtual machine. I thought it was resolved. I will take time to check it Could you check out my changes. The only contenious one was changing an std::vectorref_ptrTimeline to a std::vectorTimeline* in ActionVisitor.For performance using a Timeline* would be preferable any way. Robert/ -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:cedric.pin...@plopbyte.net http://www.plopbyte.net signature.asc Description: This is a digitally signed message part ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg OpenGL ES
Hi , I want to write a game for my phone with OSG.But i didn't find OSG lib which based on OpenGL ES.Who know something of this,please tell me.Thanks. hesanyuan___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
