Re: [osg-users] glCopyTexImage2D or Frame Buffer Object
Ok thank you. And what do you think about osg::Texture2D::copyTexImage2D(...)? Is this a worse solution than the FBO? Thank you very much. Best regards Martin Original-Nachricht > Datum: Tue, 19 Apr 2011 16:03:03 +0100 > Von: Robert Osfield > An: OpenSceneGraph Users > Betreff: Re: [osg-users] glCopyTexImage2D or Frame Buffer Object > Hi Martin, > > FBO's do support multi-sampling - but the setup is different from the > frame buffer set up of multi-sampling, instead you you provide the > settings when you call Camera::attach(). The relevant methods are: > > /** Attach a Texture to specified buffer component. > * The level parameter controls the mip map level of the > texture that is attached. > * The face parameter controls the face of texture cube map > or z level of 3d texture. > * The mipMapGeneration flag controls whether mipmap > generation should be done for texture.*/ > void attach(BufferComponent buffer, osg::Texture* texture, > unsigned int level = 0, unsigned int face=0, bool > mipMapGeneration=false, > unsigned int multisampleSamples = 0, > unsigned int multisampleColorSamples = 0); > > /** Attach a Image to specified buffer component.*/ > void attach(BufferComponent buffer, osg::Image* image, > unsigned int multisampleSamples = 0, > unsigned int multisampleColorSamples = 0); > > As for anaglyphic stereo, this is managed currently by > osgUtil::SceneView for frame buffers where it sets up two traversals > one for each eye, and sets up the color write mask to render the cyan > and red for the left and right eye traverals. A straight render to > texture Camera won't use this higher level feature, if you want to > implement stereo within a render to texture camera you'll need to > manage the left/right eye passes as a subgraph of the Camera, or have > two Camera and share the same FBO. > > Robert. > > > 2011/4/19 "Martin Großer" : > > Hello, > > > > Few month ago, I got an application, which realized a "render to > texture" with glCopyTexImage2D(GL_TEXTURE_2D,0,...) and the antialiasing and > the > anaglyphic works well. Today I tried the render-to-texture with the frame > buffer object as render target for the osg::Camera and in this case the > antialiasing doesn't work. Also the anaglyphic view doesn't work. > > > > Why did antialiasing and anaglyphic work with glCopyTexImage2D? > > > > I have read that the frame buffer object doesn't support antialiasing, > is it true? > > > > Thanks > > > > Martin > > -- > > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > ___ > > 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 -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-based excavator simulator
Hi, That looks great! What sky framework did you use? It looks a little bit like Simul trueSky... Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38617#38617 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-based excavator simulator
Hello Eduardo, Congratulations on the visual quality, it's really good. I'm curious about the shadows, did you use OSG's shadow system for them? Yep, that's osgShadow::LightSpacePerspectiveShadowMapDB in action. There were some recent improvements to help with stability of the shadows, it's not perfect but it helped. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-based excavator simulator
Hello Jean-Sebastien, Congratulations on the visual quality, it's really good. I'm curious about the shadows, did you use OSG's shadow system for them? Cheers Eduardo On Tue, Apr 19, 2011 at 12:41 PM, Jean-Sébastien Guay < jean-sebastien.g...@cm-labs.com> wrote: > Hi all, > > I just wanted to give you guys a heads up about a prototype project we > worked on lately, and which I think looks great. There's a video of it on > our YouTube channel: > > http://www.youtube.com/user/vortexsim#p/u/1/RhJR0qQJfAQ > > (set it to 1080p if you can) > > We did that demo in 3 weeks (2 people for graphics and physics programming, > one modeler for the excavator model). > > Quick list of effects specific to this project: > - Normal mapping > - Specular mapping > - Reflection mapping > - HDR (using osgPPU) > - Soil uses hardware instancing for the many small rocks > - Mound of earth uses vertex texture fetch to render the height field > (displace vertices, calculate normals in vertex shader) > - Dust particles rendered with soft particle technique (depth buffer test) > to avoid hard edges > > It's the most GPU-intensive simulator we've ever done, and it looks great, > and it's OSG-based, so I thought I'd show it to anyone who's interested. :-) > > While you're on our YouTube page you can have a look at the other cool > things we've done in the past, the offshore and port crane simulators are > recent projects and are very nice as well (and they use osgOcean :-) ). > > http://www.youtube.com/user/vortexsim#p/u/9/KBGr74TMTrU > http://www.youtube.com/user/vortexsim#p/u/0/dZeQ-eBrBDk > > Thanks, > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ >http://whitestar02.dyndns-web.com/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-based excavator simulator
Hi Greg, 3 weeks with 2 developers!!! Now I really feel like a rookie! Out of pure modesty, I have to admit we already had a lot of framework in place for heavy equipment simulation. Nevertheless, this vehicle and the graphical effects I listed were new and were done in that time span. I won't tell you how many hours a day we worked though! :-) It was a crazy project but we pulled it off. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-based excavator simulator
Hi J-S, 3 weeks with 2 developers!!! Now I really feel like a rookie! Cheers, Greg -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38612#38612 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FrameBufferObject problems on OSG 2.9.11
Hi Paul, On Tue, Apr 19, 2011 at 4:13 PM, Robert Osfield wrote: > I have just tried your modified osgprerender and can confirm that > problems exists on my system as well. I don't the cause of the > problem, my best guess right now would be something like inappropriate > reuse of GL objects. I have checked 2.9.10 and also find it to work fine with the modified osgprerender. I cleaned the test example up a bit so ensure we can use the same options on each run through the viewer, modified example attached. I've done a diff between the FrameBufferObject.cpp and RenderStage.cpp and found no diffrences of note, and even patched the svn/trunk with the 2.9.10 versions and still get the same problems, so the problem isn't related directly to FBO setup and usage. I also patched the Texture.cpp and header, and despite the many differences still didn't see any fix... I'll keep reverting changes till I spot the file that is the root of the problem. Robert. /* OpenSceneGraph example, osgprerender. * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN * THE SOFTWARE. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include // call back which creates a deformation field to oscillate the model. class MyGeometryCallback : public osg::Drawable::UpdateCallback, public osg::Drawable::AttributeFunctor { public: MyGeometryCallback(const osg::Vec3& o, const osg::Vec3& x,const osg::Vec3& y,const osg::Vec3& z, double period,double xphase,double amplitude): _firstCall(true), _startTime(0.0), _time(0.0), _period(period), _xphase(xphase), _amplitude(amplitude), _origin(o), _xAxis(x), _yAxis(y), _zAxis(z) {} virtual void update(osg::NodeVisitor* nv,osg::Drawable* drawable) { // OpenThreads::Thread::microSleep( 1000 ); const osg::FrameStamp* fs = nv->getFrameStamp(); double simulationTime = fs->getSimulationTime(); if (_firstCall) { _firstCall = false; _startTime = simulationTime; } _time = simulationTime-_startTime; drawable->accept(*this); drawable->dirtyBound(); osg::Geometry* geometry = dynamic_cast(drawable); if (geometry) { osgUtil::SmoothingVisitor::smooth(*geometry); } } virtual void apply(osg::Drawable::AttributeType type,unsigned int count,osg::Vec3* begin) { if (type == osg::Drawable::VERTICES) { const float TwoPI=2.0f*osg::PI; const float phase = -_time/_period; osg::Vec3* end = begin+count; for (osg::Vec3* itr=begin;itrgetPixelFormat()==GL_RGBA && _image->getDataType()==GL_UNSIGNED_BYTE) { // we'll pick out the center 1/2 of the whole image, int column_start = _image->s()/4; int column_end = 3*column_start; int row_start = _image->t()/4; int row_end = 3*row_start; // and then invert these pixels for(int r=row_start; rdata(column_start, r); for(int c=column_start; cdirty(); } else if (_image && _image->getPixelFormat()==GL_RGBA && _image->getDataType()==GL_FLOAT) { // we'll pick out the center 1/2 of the whole image, int column_start = _image->s()/4; int column_end = 3*column_start; int row_start = _image->t()/4; int row_end = 3*row_start; // and then invert these pixels for(int r=row_start; rdata(column
Re: [osg-users] addSlave messup main cameras stateset
thank you for getting back robet, i agree that i didnt present all the code, however its mostly standard from the examples. one thing i ought to mention is that i am using osg with wxWidgets. I tried to go back and look at the code and i found that even if i just add a new camera it screws with the state set. In the handler function code below i print the pointer before and after add slave. first time i get an address, second time its null Code: osgViewer::Viewer *viewer = cloudglobals::rootFrame->osg_viewer; switch(ea.getEventType()) { case(osgGA::GUIEventAdapter::PUSH): { osg::StateSet *stateSet = viewer->getCamera()->getOrCreateStateSet(); osg::Point *pointState = (osg::Point*)stateSet->getAttribute(osg::StateAttribute::POINT); cout{{"# "{{pointState{{" "; // this is NOT NULL (how to add angular brkts for cout?) viewer->addSlave(new osg::Camera, false); // add slave camera to viewer stateSet = viewer->getCamera()->getOrCreateStateSet(); pointState = (osg::Point*)stateSet->getAttribute(osg::StateAttribute::POINT); cout{{pointState{{endl; } } -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38610#38610 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] clipping problem with PagedLODs--RESOLVED
Hi Robert. I actually did successfully get clip planes working with your help via this list in June of last year (in the same way that you explain below). My concern was that it did not seem to be working with PagedLOD models. However, it turned out that I was looking in the wrong place. The pagedLOD geometry was using a different vertex shader than I was expecting. This shader did not calculate gl_ClipVertex = gl_ModelViewMatrix * gl_Vertex; Now that I added this line to the vertex shader, the reuseable clip plans (as you suggest below) does indeed work with PagedLODs. Thanks, Jason -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, April 19, 2011 1:33 AM To: OpenSceneGraph Users Subject: Re: [osg-users] clipping problem with PagedLODs Hi Jason, The wa that the OSG handles positional state like clip planes is pair the a specific modelview matrix with the positional state, the modelview matrix used in provided when the cull traversal encounters a positional state node like ClipNode, TexGenNode or LightSource, and the pairing is done such that there is only one posible modelview matrix per positional state, on per RenderStage basis. This approach ensures that clip planes, eye linear texgen and light sources all have a single place in space for rendering a whole stage, but it does mean you can't reuse a clip plane, eye linear tex gen, or light within on stage. The only ways to support multiple clip planes or other positional state is to dispense with the positional state nodes completely and have custom state attribute that binds a specific modelview matrix to that state and applies this before applying the state, but straight away after applying the state will need to restore the original modelview matrix. You will also need to geneate the specific modelview matrix somehow, a custom node like ClipNode might be approrpriate. How this all relates to what you have done I can't say, there is no way for me to comment as the code is infront of you not me. Robert. On Mon, Apr 18, 2011 at 11:48 PM, Jason Jerald wrote: > > > I created two new classes: ClipNodeReused inherited from ClipNode, and > ClipPlaneReused from ClipPlane (basically just overriding > apply(osg::State&)). These classes enable me to reuse the OpenGL clipping > planes so that I can do more than the graphics hardware limit of 6-8 > clipping planes. This has worked well. However, I recently discovered that > some model files do not get clipped correctly. The only thing that I see is > different about these files is that they contain PagedLODs. I am not sure > of the details of LODs to know if some form of clipping (perhaps as part of > some form of culling?) might be happening that is keeping my custom clipping > from occurring. Have others been able to clip PagedLODs successfully? Any > ideas what might be going wrong here? > > > > Thanks! > > > > Jason > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG-based excavator simulator
Hi all, I just wanted to give you guys a heads up about a prototype project we worked on lately, and which I think looks great. There's a video of it on our YouTube channel: http://www.youtube.com/user/vortexsim#p/u/1/RhJR0qQJfAQ (set it to 1080p if you can) We did that demo in 3 weeks (2 people for graphics and physics programming, one modeler for the excavator model). Quick list of effects specific to this project: - Normal mapping - Specular mapping - Reflection mapping - HDR (using osgPPU) - Soil uses hardware instancing for the many small rocks - Mound of earth uses vertex texture fetch to render the height field (displace vertices, calculate normals in vertex shader) - Dust particles rendered with soft particle technique (depth buffer test) to avoid hard edges It's the most GPU-intensive simulator we've ever done, and it looks great, and it's OSG-based, so I thought I'd show it to anyone who's interested. :-) While you're on our YouTube page you can have a look at the other cool things we've done in the past, the offshore and port crane simulators are recent projects and are very nice as well (and they use osgOcean :-) ). http://www.youtube.com/user/vortexsim#p/u/9/KBGr74TMTrU http://www.youtube.com/user/vortexsim#p/u/0/dZeQ-eBrBDk Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] R: glFlush and osg
Thanks Robert, I'll try to replace my drawables with those provided by osg. Gianluca -Messaggio originale- Da: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: martedì 19 aprile 2011 17:26 A: OpenSceneGraph Users Oggetto: Re: [osg-users] glFlush and osg Hi Gianluca, There isn't much we can probably suggest given you are using a custom Drawable implementation. General comments would be that glFlush shouldn't affect the quality of the results, only the speed at which handled. Using glFlush forces the GL driver to pause the application thread calling GL to wait until all the commands and data in GL drivers' fifo buffer have been passed to the graphics card. glFlush doesn't itself change any OpenGL state so in principle should not effect results. Given glFlush shouldn't have the effect you are describing perhaps it's just co-incidence and that a threading issue in your application is causing problems. I would also suggest replacing your custom Drawable with code based on osg::Geometry, this may or may not be possible, but trying this would at least give you a test using code that others have access to, and is known to work. Robert. On Tue, Apr 19, 2011 at 4:03 PM, Gianluca Natale wrote: > Hi there, > I have an issue with glFlush, and I don't know exactly if this is related to > OSG. > > Basically, I have a very complicated scenegraph, whose drawables are my own > classes > > derived from osg::drawable. So, they implement the drawImplementation, by > using standard > > OpenGL rendering commands (basically vertex arrays). > > I had to put a glFlush() at the end of each drawImplmentation() to make it > work correctly. > I mean that, if I didn't, the drawing would be completely wrong, as if wrong > normals were applied > > to lighting computations. But glFlush() should only flush the content of the > command buffer to the graphic board. > > Am I worng? > > Furthermore, it does not behave wrongly on every graphic board, only some > cards shows the problem > (mine is a nVidia Quadro FX 2500M). > > > > What's even worse is that putting such calls slows down my application a lot > (from 22 to 13 fps). > > > > So, I just wonder if it might be a problem related to OSG (since I mixed osg > with direct OpenGL commands), > or if it might be related to specific drivers of my graphic board. > > > > Thanks in advance, > > Gianluca > > > > P.S. = BTW, if I replaced glFlush() with a double call to glPointSize(), > passing 3.0 and 1.0 in sequence as sizes > (but without making any other call inbetween). It still works > good, as if glFlush() was issued, but without the > side effect of slowness. So, actually they act as a glFlush() in > my code! > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glFlush and osg
Hi Gianluca, There isn't much we can probably suggest given you are using a custom Drawable implementation. General comments would be that glFlush shouldn't affect the quality of the results, only the speed at which handled. Using glFlush forces the GL driver to pause the application thread calling GL to wait until all the commands and data in GL drivers' fifo buffer have been passed to the graphics card. glFlush doesn't itself change any OpenGL state so in principle should not effect results. Given glFlush shouldn't have the effect you are describing perhaps it's just co-incidence and that a threading issue in your application is causing problems. I would also suggest replacing your custom Drawable with code based on osg::Geometry, this may or may not be possible, but trying this would at least give you a test using code that others have access to, and is known to work. Robert. On Tue, Apr 19, 2011 at 4:03 PM, Gianluca Natale wrote: > Hi there, > I have an issue with glFlush, and I don’t know exactly if this is related to > OSG. > > Basically, I have a very complicated scenegraph, whose drawables are my own > classes > > derived from osg::drawable. So, they implement the drawImplementation, by > using standard > > OpenGL rendering commands (basically vertex arrays). > > I had to put a glFlush() at the end of each drawImplmentation() to make it > work correctly. > I mean that, if I didn’t, the drawing would be completely wrong, as if wrong > normals were applied > > to lighting computations. But glFlush() should only flush the content of the > command buffer to the graphic board. > > Am I worng? > > Furthermore, it does not behave wrongly on every graphic board, only some > cards shows the problem > (mine is a nVidia Quadro FX 2500M). > > > > What’s even worse is that putting such calls slows down my application a lot > (from 22 to 13 fps). > > > > So, I just wonder if it might be a problem related to OSG (since I mixed osg > with direct OpenGL commands), > or if it might be related to specific drivers of my graphic board. > > > > Thanks in advance, > > Gianluca > > > > P.S. = BTW, if I replaced glFlush() with a double call to glPointSize(), > passing 3.0 and 1.0 in sequence as sizes > (but without making any other call inbetween). It still works > good, as if glFlush() was issued, but without the > side effect of slowness. So, actually they act as a glFlush() in > my code! > > ___ > 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] FrameBufferObject problems on OSG 2.9.11
Hi Paul, I have just tried your modified osgprerender and can confirm that problems exists on my system as well. I don't the cause of the problem, my best guess right now would be something like inappropriate reuse of GL objects. Robert. On Tue, Apr 19, 2011 at 3:39 PM, Paul Palumbo wrote: > I've recently switched my application from 2.9.9 to 2.9.12 and now I'm having > FrameBufferObject problems (there seems to have been recent changes in this > area). > > The problem can be replicated in osgprerender example with a few minor > changes (see attached). These changes simple "recreate" the viewer after > hitting the escape key rather than simply exiting the executable. These > errors (constantly displayed) started showing up once the viewer is displayed > the second time: > Warning: detected OpenGL error 'invalid operation' at after > RenderBin::draw(..) > I do not have this problem with OSG 2.9.9 and 2.9.10 but do have this > problem with 2.9.11 and 2.9.12 when using this same exact test program. > > I'm running this version of osgprerender example with the --fbo option but I > believe this is the default option. > > Are you sure that these FBOs are being created correctly in OSG >= 2.9.10? > > Paul Palumbo > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=38598#38598 > > > > > ___ > 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] glFlush and osg
Hi there, I have an issue with glFlush, and I don't know exactly if this is related to OSG. Basically, I have a very complicated scenegraph, whose drawables are my own classes derived from osg::drawable. So, they implement the drawImplementation, by using standard OpenGL rendering commands (basically vertex arrays). I had to put a glFlush() at the end of each drawImplmentation() to make it work correctly. I mean that, if I didn't, the drawing would be completely wrong, as if wrong normals were applied to lighting computations. But glFlush() should only flush the content of the command buffer to the graphic board. Am I worng? Furthermore, it does not behave wrongly on every graphic board, only some cards shows the problem (mine is a nVidia Quadro FX 2500M). What's even worse is that putting such calls slows down my application a lot (from 22 to 13 fps). So, I just wonder if it might be a problem related to OSG (since I mixed osg with direct OpenGL commands), or if it might be related to specific drivers of my graphic board. Thanks in advance, Gianluca P.S. = BTW, if I replaced glFlush() with a double call to glPointSize(), passing 3.0 and 1.0 in sequence as sizes (but without making any other call inbetween). It still works good, as if glFlush() was issued, but without the side effect of slowness. So, actually they act as a glFlush() in my code! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glCopyTexImage2D or Frame Buffer Object
Hi Martin, FBO's do support multi-sampling - but the setup is different from the frame buffer set up of multi-sampling, instead you you provide the settings when you call Camera::attach(). The relevant methods are: /** Attach a Texture to specified buffer component. * The level parameter controls the mip map level of the texture that is attached. * The face parameter controls the face of texture cube map or z level of 3d texture. * The mipMapGeneration flag controls whether mipmap generation should be done for texture.*/ void attach(BufferComponent buffer, osg::Texture* texture, unsigned int level = 0, unsigned int face=0, bool mipMapGeneration=false, unsigned int multisampleSamples = 0, unsigned int multisampleColorSamples = 0); /** Attach a Image to specified buffer component.*/ void attach(BufferComponent buffer, osg::Image* image, unsigned int multisampleSamples = 0, unsigned int multisampleColorSamples = 0); As for anaglyphic stereo, this is managed currently by osgUtil::SceneView for frame buffers where it sets up two traversals one for each eye, and sets up the color write mask to render the cyan and red for the left and right eye traverals. A straight render to texture Camera won't use this higher level feature, if you want to implement stereo within a render to texture camera you'll need to manage the left/right eye passes as a subgraph of the Camera, or have two Camera and share the same FBO. Robert. 2011/4/19 "Martin Großer" : > Hello, > > Few month ago, I got an application, which realized a "render to texture" > with glCopyTexImage2D(GL_TEXTURE_2D,0,...) and the antialiasing and the > anaglyphic works well. Today I tried the render-to-texture with the frame > buffer object as render target for the osg::Camera and in this case the > antialiasing doesn't work. Also the anaglyphic view doesn't work. > > Why did antialiasing and anaglyphic work with glCopyTexImage2D? > > I have read that the frame buffer object doesn't support antialiasing, is it > true? > > Thanks > > Martin > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > ___ > 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] FrameBufferObject problems on OSG 2.9.11
Maybe I should have added that I'm running on Linux with a Quadro FX 5800 video card. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38601#38601 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Forked osgIntrospection to cppintrospection
Hi Alexandre, Sorry for not following the thread because of my client work and the coming plan for the OSG cookbook (not started at present, but will be on the way soon :-). 2011/4/19 Alexandre Quessy : > For the name of the project, Mike Wozniewski and I think we need this > project to be renamed cppintrospection to avoid a name clash with the > former one, unless I am misled. We still use some old OSG that is > packaged in Debian, and it contains a osgIntrospection library. > I'm OK with the name cppintrospection as it could be used in many other projects to wrap c++ source codes. osgWrappers could be just an important but not necessary component of it, which demonstrates the functionalities of the introspection framework and shows how to use the wrappers in other languages and for reflection use. > Also, I really want to avoid working with Subversion, as Git is much > more fun to work with. > It should be OK to use a more powerful source control utility in my opinion. But I just failed to checkout the cppintrospection project with tortoiseGIT this afternoon. Maybe it is because of my terrible network or there was some maintenances on the github website? :-) > Those two issues are not really issues, after all. I would really like > to collaborate with you, Wang Rui, and benefit from your future > changes to this project. I don't plan to make any change to it, as I > am only interested in seeing it packaged, especially for Debian > GNU/Linux. > I'll try to compile and make cppintrospection work on my Windows system these few days. After that I'll start to work on the cmake support and in the future, think of using the wrappers with SWIG to generate code for other languages like C# and Python. Don't wait for my contribution because I'm still busy in the following months. Cheers, Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I am back
heh :) . ok Nick On Tue, Apr 19, 2011 at 4:35 PM, Jean-Sébastien Guay < jean-sebastien.g...@cm-labs.com> wrote: > Hi Nick, > > > thanks J-S .. What has happened in the last couple of months ? >> > > Well, the usual, a few dev releases, lots of submissions, the project > moving forward at a steady pace :-) > > I'll let you have a look at the archives for more details :-) > > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ >http://whitestar02.dyndns-web.com/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FrameBufferObject problems on OSG 2.9.11
I've recently switched my application from 2.9.9 to 2.9.12 and now I'm having FrameBufferObject problems (there seems to have been recent changes in this area). The problem can be replicated in osgprerender example with a few minor changes (see attached). These changes simple "recreate" the viewer after hitting the escape key rather than simply exiting the executable. These errors (constantly displayed) started showing up once the viewer is displayed the second time: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) I do not have this problem with OSG 2.9.9 and 2.9.10 but do have this problem with 2.9.11 and 2.9.12 when using this same exact test program. I'm running this version of osgprerender example with the --fbo option but I believe this is the default option. Are you sure that these FBOs are being created correctly in OSG >= 2.9.10? Paul Palumbo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38598#38598 /* OpenSceneGraph example, osgprerender. * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN * THE SOFTWARE. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include // call back which creates a deformation field to oscillate the model. class MyGeometryCallback : public osg::Drawable::UpdateCallback, public osg::Drawable::AttributeFunctor { public: MyGeometryCallback(const osg::Vec3& o, const osg::Vec3& x,const osg::Vec3& y,const osg::Vec3& z, double period,double xphase,double amplitude): _firstCall(true), _startTime(0.0), _time(0.0), _period(period), _xphase(xphase), _amplitude(amplitude), _origin(o), _xAxis(x), _yAxis(y), _zAxis(z) {} virtual void update(osg::NodeVisitor* nv,osg::Drawable* drawable) { // OpenThreads::Thread::microSleep( 1000 ); const osg::FrameStamp* fs = nv->getFrameStamp(); double simulationTime = fs->getSimulationTime(); if (_firstCall) { _firstCall = false; _startTime = simulationTime; } _time = simulationTime-_startTime; drawable->accept(*this); drawable->dirtyBound(); osg::Geometry* geometry = dynamic_cast(drawable); if (geometry) { osgUtil::SmoothingVisitor::smooth(*geometry); } } virtual void apply(osg::Drawable::AttributeType type,unsigned int count,osg::Vec3* begin) { if (type == osg::Drawable::VERTICES) { const float TwoPI=2.0f*osg::PI; const float phase = -_time/_period; osg::Vec3* end = begin+count; for (osg::Vec3* itr=begin;itrgetPixelFormat()==GL_RGBA && _image->getDataType()==GL_UNSIGNED_BYTE) { // we'll pick out the center 1/2 of the whole image, int column_start = _image->s()/4; int column_end = 3*column_start; int row_start = _image->t()/4; int row_end = 3*row_start; // and then invert these pixels for(int r=row_start; rdata(column_start, r); for(int c=column_start; cdirty(); } else if (_image && _image->getPixelFormat()==GL_RGBA && _image->getDataType()==GL_FLOAT) { // we'll pick out the center 1/2 of the whole image, int column_start = _image->s()/4; int column_end = 3*column_start; int row_start = _image->t()/4; int row_end = 3*row_start; // and then invert
Re: [osg-users] glCopyTexImage2D or Frame Buffer Object
Hello, I have the answer of the question what is different. Frame Buffer Object is render to texture. So the texture use the frame buffer and you render on it directly. Copy to texture means that the frame buffer is copy to the texture buffer after the rendering. I hope this is true. And if I copy it after the rendering I get the antialiasing and anagyphic features. Another question. What is better? Is the copy too slow with a texture resolution of 1400x1050? Thanks Martin Original-Nachricht > Datum: Tue, 19 Apr 2011 16:30:19 +0200 > Von: "Martin Großer" > An: osg-users@lists.openscenegraph.org > Betreff: [osg-users] glCopyTexImage2D or Frame Buffer Object > Hello, > > Few month ago, I got an application, which realized a "render to texture" > with glCopyTexImage2D(GL_TEXTURE_2D,0,...) and the antialiasing and the > anaglyphic works well. Today I tried the render-to-texture with the frame > buffer object as render target for the osg::Camera and in this case the > antialiasing doesn't work. Also the anaglyphic view doesn't work. > > Why did antialiasing and anaglyphic work with glCopyTexImage2D? > > I have read that the frame buffer object doesn't support antialiasing, is > it true? > > Thanks > > Martin > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I am back
Hi Nick, thanks J-S .. What has happened in the last couple of months ? Well, the usual, a few dev releases, lots of submissions, the project moving forward at a steady pace :-) I'll let you have a look at the archives for more details :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] glCopyTexImage2D or Frame Buffer Object
Hello, Few month ago, I got an application, which realized a "render to texture" with glCopyTexImage2D(GL_TEXTURE_2D,0,...) and the antialiasing and the anaglyphic works well. Today I tried the render-to-texture with the frame buffer object as render target for the osg::Camera and in this case the antialiasing doesn't work. Also the anaglyphic view doesn't work. Why did antialiasing and anaglyphic work with glCopyTexImage2D? I have read that the frame buffer object doesn't support antialiasing, is it true? Thanks Martin -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I am back
thanks J-S .. What has happened in the last couple of months ? nick On Mon, Apr 18, 2011 at 5:46 PM, Jean-Sébastien Guay < jean-sebastien.g...@cm-labs.com> wrote: > Hi Nick, > > > I am back :) ... this time from macedonia .. have you missed me?? >> > > Welcome back! > > J-S > -- > __ > Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ >http://whitestar02.dyndns-web.com/ > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] rewind imported animated model
Hi, in my program I load a file (a collada animation) then like in osganimationviewer example I make a AnimationManagerFinder structure, I set setPlayMode(osgAnimation::Animation::ONCE); and I play animation. This file is referenced by some objects but after I play for the first time the animation, if I try to restart the animation it stuck in last frame. Can you help me? thanks daniele -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38590#38590 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Need Efficient mesh data structures
Hi, depends on your requirements, for geometry processing i would recommend openmesh or vcg. VCG is part of the MeshLab tool on sourceforge. Its a bit harder to find. Google for "vcglib". Hope this helps, Tim manish8892 wrote: > Hi, > I am looking for an efficient general mesh data structure. > Having feature like Generating normal arrays and texture coordinate for > model,Parameterization of Triangulated Surface Meshes ; texture mapping > and that can easily integrate with OSG. > > I know some of them like : > openMesh > osgmodeling > CGAL > I need better solution which one is most suitable or there some other library > which can be helpful to me. > I had hoped that someone might have used it before. > > > ... > > > Thank you! > > Cheers, > manish -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38589#38589 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPPU] osgPPU with CompositeViewer
Hi, Has anyone been trying to use the osgPPU with CompositeViewer? I tried to run the same code i succesfully use with a regular viewer but it fails when i try to apply it to the second view. First view works fine but the second fails. Basically i'm just applying the processor to the view camera instead of the viewer camera. I would just like to know if someone has used it succesfully to make sure the problem is in my code :-) I am using the 0.4.0 version of osgPPU. Thank you! Cheers, Sami -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38587#38587 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Immutable means "cannot be changed". So I mean that the "Value" class should not have a "set" method and all "get" methods should be const. E.g. template class Value { private: T v; public: Value(const T& _v) : v(_v) { } const T& get() { return v; } // type conversion operator, so you can write // Value a(5); // int b = a; const T& operator T () { return v; } }; On 4/19/2011 5:46 AM, Sukender wrote: > Hi Peter, > > Okay, we'll certainely try your ideas. I guess ValueBase is meant to be > derived, but Value isn't. > > However, I'm not sure I understand the "immutable" thing. Do you mean you > preference goes to >function( someParam ) > rather than >function( Value(someParam) ) > ? > > If so, yes. And that's of course easier to write and read. -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
On 4/19/2011 5:49 AM, Sukender wrote: > hmmm... > > Why did you write > template void addMeta(const std::string&, const Value& v); > ? > > Wouldn't this be simpler: > template void addMeta(const std::string&, const T & v); > ? > You're right, that is confusing. Here's a better way to compare the alternatives: template void addMeta(const std::string&, const Value& v) { // Supports v as a subclass of Value Value* localcopy = v.clone(); } template void addMeta(const std::string&, const T & v) { // Can only customize Value through template specialization Value* localcopy = new Value(v); } -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] broken osgViewer header installation
HI Mattias, Thanks for spotting this regression. Could you make the changes that fix the problem and post them to osg-submissions. I'm just emarking on a big osg-submissions purge so want to concentrate on this. Cheers, Robert. On Tue, Apr 19, 2011 at 12:13 PM, Mattias Helsing wrote: > Hi all, > > I have discovered that the installation of the osgViewer headers got > broken with rev 12208 and 12231. These are part of the Android > integration (which is a great addition btw) > > The old cmake code went through some extra hoops to rebuild the source > tree structure in the installation step, e.g. GraphicHandleX11 went > into CMAKE_INSTALL_PREFIX/include/osgViewer/api/X11/. This is > important since GraphicsWindowX11 includes > , not > which is where it gets installed now. > > The reason that this hasn't been noticed is probably that the old > headers are still installed to the correct place and still gets > included. > > I'm suggesting to revert the old installation step only for platform > specific header ( under include/osgViewer/api ) but keep other changes > from 12208. > > cheers > Mattias > ___ > 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] broken osgViewer header installation
Hi all, I have discovered that the installation of the osgViewer headers got broken with rev 12208 and 12231. These are part of the Android integration (which is a great addition btw) The old cmake code went through some extra hoops to rebuild the source tree structure in the installation step, e.g. GraphicHandleX11 went into CMAKE_INSTALL_PREFIX/include/osgViewer/api/X11/. This is important since GraphicsWindowX11 includes , not which is where it gets installed now. The reason that this hasn't been noticed is probably that the old headers are still installed to the correct place and still gets included. I'm suggesting to revert the old installation step only for platform specific header ( under include/osgViewer/api ) but keep other changes from 12208. cheers Mattias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.9.12 tagged
Hi All, I have just tagged the OpenSceneGraph-2.9.12 release, I pushed this out before I dive into another round of handling osg-submissions as handling the submissions is likely to take me to the end of the week and possibly beyond. I intend to get 2.9.13 once we back up to date with submissions. Dev release page contains all the links: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases The details are: OpenSceneGraph-2.9.12, released on 19th April 2011, key deliverables in this dev release are: Android support Improved Iphone and Ipad support DatabasePager and IncrementalCompileOperation improvements for better thread safety and ability to manage constant frame rates when paging A number of bug fixes and minor feature improvements/optimizations. source package : OpenSceneGraph-2.9.12.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.12 OpenSceneGraph Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
hmmm... Why did you write template void addMeta(const std::string&, const Value& v); ? Wouldn't this be simpler: template void addMeta(const std::string&, const T & v); ? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - "Peter Amstutz" a écrit : > You could use an implicit constructor, e.g. > > template > class Value { > Value(T); > Value(const Value&); > }; > > class Value; > > template > void addMeta(const std::string&, const Value& v) { > Value* localcopy = new Value(v); > } > > so the function call: > > addMeta("myMeta", 5); > > is implicitly converted to: > > addMeta(std::string("myMeta"), Value(5)); > > > Two considerations: > - There is some copying involved, which might be undesirable for > large > arrays. C++ 2011 move constructors are intended to solve this > problem > in general, but it's unlikely that OSG compatibility requirements > will > allow the use of C++ 2011 features for a while. > > - The way it is described here, any customization for Value must > occur through template specialization, rather than subclassing. To > support subclassing, use a clone() method instead of new Value(v). > > On a related note, my preference would be for the Value class to > be > immutable so that you are required to set metadata values through the > API rather than poking Value objects directly. This is necessary > if > you want to support alternate backing stores which don't use Value > objects in the backend at all. > > - Peter > > On 4/15/2011 11:10 AM, Sukender wrote: > > Hi Peter, > > > > Thanks... but what for the addMeta()? > > I mean it's okay having a addMeta(string, ValueBase *), but this > will force you to write > > o->addMeta( "myMeta", new Value(5) ); > > instead of simply > > o->addMeta( "myMeta", 5 ); > > which could be nice. Any idea? > > > > Sukender > > PVLE - Lightweight cross-platform game engine - > http://pvle.sourceforge.net/ > -- > Peter Amstutz > Senior Software Engineer > Technology Solutions Experts > Natick, MA > 02131 > > ___ > 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] Meta-data in core OSG - project started
Hi Peter, Okay, we'll certainely try your ideas. I guess ValueBase is meant to be derived, but Value isn't. However, I'm not sure I understand the "immutable" thing. Do you mean you preference goes to function( someParam ) rather than function( Value(someParam) ) ? If so, yes. And that's of course easier to write and read. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - "Peter Amstutz" a écrit : > You could use an implicit constructor, e.g. > > template > class Value { > Value(T); > Value(const Value&); > }; > > class Value; > > template > void addMeta(const std::string&, const Value& v) { > Value* localcopy = new Value(v); > } > > so the function call: > > addMeta("myMeta", 5); > > is implicitly converted to: > > addMeta(std::string("myMeta"), Value(5)); > > > Two considerations: > - There is some copying involved, which might be undesirable for > large > arrays. C++ 2011 move constructors are intended to solve this > problem > in general, but it's unlikely that OSG compatibility requirements > will > allow the use of C++ 2011 features for a while. > > - The way it is described here, any customization for Value must > occur through template specialization, rather than subclassing. To > support subclassing, use a clone() method instead of new Value(v). > > On a related note, my preference would be for the Value class to > be > immutable so that you are required to set metadata values through the > API rather than poking Value objects directly. This is necessary > if > you want to support alternate backing stores which don't use Value > objects in the backend at all. > > - Peter > > On 4/15/2011 11:10 AM, Sukender wrote: > > Hi Peter, > > > > Thanks... but what for the addMeta()? > > I mean it's okay having a addMeta(string, ValueBase *), but this > will force you to write > > o->addMeta( "myMeta", new Value(5) ); > > instead of simply > > o->addMeta( "myMeta", 5 ); > > which could be nice. Any idea? > > > > Sukender > > PVLE - Lightweight cross-platform game engine - > http://pvle.sourceforge.net/ > -- > Peter Amstutz > Senior Software Engineer > Technology Solutions Experts > Natick, MA > 02131 > > ___ > 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] addSlave messup main cameras stateset
HI Suneel, >From reading your post there is no way I can guess what is going on in your app. There is no reason for the OSG to detach a StateSet from a master Camera so would presume there is something wrong in your code, as to what I can't not guess as there is too little information. I would recommend just stepping through you app and double check all the code and assumptions you are making. Robert. On Tue, Apr 19, 2011 at 6:15 AM, suneel suresh wrote: > hi in order to display a rectangle roi over the 3d scene i use the example > provided in osg hud. however before drawing the roi i press a toggle > selection button which gets the stateset of the main camera as given below > > > Code: > > osg::StateSet *stateSet = osg_viewer->getCamera()->getOrCreateStateSet(); > osg::Point *pointState = > (osg::Point*)stateSet->getAttribute(osg::StateAttribute::POINT); > > > > > The 2d rectangle is drawn by mouse drag using the handler function. In the > handler function the slave camera is created and added to the viewer as > addSlave. > > > Code: > > case(osgGA::GUIEventAdapter::PUSH): > { > camera_slaveBBox = createBBoxCamera(); > viewer->addSlave(camera_slaveBBox, false); > } > > > > > As the mouse the dragged the rectangle is drawn and all is good > untill..On pressing the toggle selection button again in the first code > "stateSet" is now returned NULL :( > > Now if i comment > > Code: > > //commentviewer->addSlave(camera_slaveBBox, false) > > > > > then stateSet indeed has some value. whats is the problem? > > [/code] > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=38572#38572 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] clipping problem with PagedLODs
Hi Jason, The wa that the OSG handles positional state like clip planes is pair the a specific modelview matrix with the positional state, the modelview matrix used in provided when the cull traversal encounters a positional state node like ClipNode, TexGenNode or LightSource, and the pairing is done such that there is only one posible modelview matrix per positional state, on per RenderStage basis. This approach ensures that clip planes, eye linear texgen and light sources all have a single place in space for rendering a whole stage, but it does mean you can't reuse a clip plane, eye linear tex gen, or light within on stage. The only ways to support multiple clip planes or other positional state is to dispense with the positional state nodes completely and have custom state attribute that binds a specific modelview matrix to that state and applies this before applying the state, but straight away after applying the state will need to restore the original modelview matrix. You will also need to geneate the specific modelview matrix somehow, a custom node like ClipNode might be approrpriate. How this all relates to what you have done I can't say, there is no way for me to comment as the code is infront of you not me. Robert. On Mon, Apr 18, 2011 at 11:48 PM, Jason Jerald wrote: > > > I created two new classes: ClipNodeReused inherited from ClipNode, and > ClipPlaneReused from ClipPlane (basically just overriding > apply(osg::State&)). These classes enable me to reuse the OpenGL clipping > planes so that I can do more than the graphics hardware limit of 6-8 > clipping planes. This has worked well. However, I recently discovered that > some model files do not get clipped correctly. The only thing that I see is > different about these files is that they contain PagedLODs. I am not sure > of the details of LODs to know if some form of clipping (perhaps as part of > some form of culling?) might be happening that is keeping my custom clipping > from occurring. Have others been able to clip PagedLODs successfully? Any > ideas what might be going wrong here? > > > > Thanks! > > > > Jason > > > > ___ > 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 lights in a scene
Hi Chris, Hi Jean-Sébastien I just ending a similar work for a client and i could provide some advice on the subject. First, I derived from osg::LightSource to osgLighting::LightSource (that could contain many light, not only one as osg::LightSource) and add a cullCallback to do a similar job of osgUtil::CullVisitor::accept(osg::LightSource). I create a osgLighting::LightGroup (not a node) which contain light parameter (ambient, diffuse, position, direction ...) in uniforms arrays, and be shared by all lights I derived from osg::Light to osgLighting::Light that contain an osgLighting::LightGroup to store parameter in it. Shader is handle by a shader generator so I can't help you on this point. But I conclude after some test that per pixel lighting is not a choice. If you want apply shadow per light, you have to combine each light/shadow pair in the pixel shader. you can't compute light in vertex shader, then pass result of each light in pixel shader, and apply shadow on each light result. if you have 40 lights in you scene. you have to pass 40 vec3 from vertex shader to pixel shader ouch!!! according to Real-Time Rendering 3ed, Shader Model 4 have 16 interpolation registre between Vertex and Geometry/Pixel Shader and 32 between Geometry and Pixel Shader. J-S: About deferred shading, this is my first reflex to not pay the Z complexity of the scene. But OpenGL allow only 8 texture target to render in, so 8*4=32 values. We can use 3 for eye position, 3 for normal. This let's us with 26 value to pass light direction/position. That is largely under the need to handle more that 8 lights. I read an article about Unreal Engine that push the 3 nearest lights in RTT, and all others lights are combined in one, so only 4 light is pass to RTT, then computed in deferred shader. I have to dig this way ... Still according to Real Time Rendering 3ed, if you don't write the gl_FragDepth in your shader, recent hardware discard automatically the pixel computation if pixel in frame buffer is front of the incoming pixel. You can use OSG_DEFAULT_BIN_SORT_MODE=SORT_FRONT_TO_BACK to help hardware to do the job. I am in negotiation with my client to put osgLighting and osgGLSL (the shader generator) in OpenSource. But this will not happen before summer I think. Many people to convince that OpenSource is the good way for every body. HTH David Callu 2011/4/19 Jean-Sébastien Guay > Hi Chris, > > First of all, I have to commend you on all the work you've put into doing > this. You obviously put a lot of thought and research into your problem, and > explored multiple avenues before posting, which I have to admire! > > I've personally never needed more than the 8 light sources the fixed > pipeline gave me, so I've always used the built-in gl_LightSource[i] > structure and osg::LightSource+osg::Light to manage my lights. I have a > mechanism in place that lets me reuse light IDs when lights get turned on or > off (a light turned off frees its light ID, and a light turned on will take > the first available light ID), and this uses IDs 0-7, which has been > sufficient for me. Add to that the fact that OSG's built-in shadow > techniques support casting shadows from only one light, and I've never > really had a need (personally or from client requirements) to go further. > But that's not to say it won't happen. > > What I'd say in response to your question is, I think you have a good idea > of what is the best solution to your problem (solution 1), but it requires > some small changes to OSG itself in order to be feasible. So what prevents > you from proposing these changes? Robert hasn't been against making some > methods virtual when needed in the past, and even deeper changes will be > possible when they're justified. > > About the CullVisitor, I don't understand what you mean about not > recognizing new classes. First of all, sure, you could add new classes to > its interface, but even if not, you can always, in the > accept(osg::LightSource&) method, check with a dynamic_cast if the > lightSource is of your derived class: > > virtual void accept(osg::LightSource& ls) > { > if (dynamic_cast(&ls) != 0) > { >// My light source subclass. > } > else > { >// Plain old osg::LightSource > } > } > > But whatever you decide, I think you shouldn't rule out changes to the core > OSG. The fixed pipeline is out, and shaders are in, and if OSG could be made > to support its own osg_LightSource[i] uniforms, with indices limited only by > shader memory (while not ruling out the possibility that the first 8 of > those be mapped to the fixed pipeline light sources if the fixed pipeline is > available) then that would be very nice indeed. > > I'll just add one last note, another way to deal with many light sources > would be to do deferred shading, maybe you should look this up. It all > depends on what you're doing, but deferred shading has the advantage that > all complex lighting calculations (per pixel lighting, normal mapping