[osg-users] Warning: TangentSpaceGenerator: unknown primitive mode 9
Hi, it looks like TangentSpaceGenerator doesn't support POLYGON (mode 9), and outputs this warning. Is there a possibility that the tangent could be computed for polygons ? Thank you, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Support for glFramebufferTextureEXT ?
Hi, I would like to use the glFramebufferTextureEXT function introduced in the EXT_geometry_shader4 extension. My need is to control the layer of the 3D texture target with the gl_Layer variable present in geometry shaders. For the moment, I hacked the FrameBufferObject sources to replace the call to glFramebufferTexture3D (which needs a fixed zoffset) by a call to glFramebufferTexture that rely on gl_Layer. I volunteer to propose something cleaner but I would like to read some implementations tips or ideas on how to do this. Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Support for glFramebufferTextureEXT ?
Hi Robert, - "Robert Osfield" a écrit : > HI Fred, > > > I would like to use the glFramebufferTextureEXT function introduced > in the EXT_geometry_shader4 extension. My need is to control the layer > of the 3D texture target with the gl_Layer variable present in > geometry shaders. For the moment, I hacked the FrameBufferObject > sources to replace the call to glFramebufferTexture3D (which needs a > fixed zoffset) by a call to glFramebufferTexture that rely on > gl_Layer. > > > > I volunteer to propose something cleaner but I would like to read > some implementations tips or ideas on how to do this. > > I'm not familiar with this extension yet, so can't provide an tips > off the cuff. I'll need to learn about the extension and how it's used. > > I could happily use your modifications as means of learning how it's > used and then give you feedback ;-) The change I made is straightforward : Original code, FrameBufferObject.cpp, line 536 : case Pimpl::TEXTURE3D: ext->glFramebufferTexture3D(target, attachment_point, GL_TEXTURE_3D, tobj->id(), _ximpl->level, _ximpl->zoffset); break; New code : case Pimpl::TEXTURE3D: ext->glFramebufferTexture(target, attachment_point, tobj->id(), _ximpl->level); break; plus the initialising code to get the glFramebufferTexture pointer. The EXT_geometry_shader4 extension says that you can control the zoffset parameter in the original code by setting the gl_Layer inside the geometry shader. That way you can draw to the whole 3D texture target, instead of having to draw layer by layer. This is also useful when rendering to a cube map texture because you can control the targeted face. Same with 2D texture arrays. BTW, I didn't see how to control the zoffset parameter in the original code. Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Telemetry Data (Motion Data) supported Free Game?
Hi Ümit, - "Ümit Uzun"a écrit : > Hi All, > > Thanks for your all replies. Brede, I will look all suggested games > ASAP. may be it helps me for a while before we grow our project. > > Jan, I mean motion information data(pitch, roll, yaw, planetary > accelaration, velocity and etc). I need a game which has an interface > or partial plugin to interrogate the game's motion informations like > Microsoft Flight Simulations. I can interrogate FS by FSUIPC framework > then I can send these motion data to my any device(for example motion > platform or Separate 3D Models). Did you consider FlightGear ? It can output any kind of data, has a scripting language and a bunch of customizable protocols. And it is built over OSG. -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] "Footprint" of a drawable on screen.
Hi, I am trying to implement a view dependent LOD scheme that needs the size and position of a drawable (or a node) on screen. A 2D bounding box could make the job. Is there something already done in OSG or should I continue to use unproject on vertices ? Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] "Footprint" of a drawable on screen.
Hi Laurens, and thank you for the hint. There are a lot of reason I should derive my nodes from osg::LOD (actually osg::PagedLOD) and this one is another good. FWIW, I want to improve this thing : http://www.youtube.com/watch?v=7WYH27KyUBk Regards, -Fred - "Laurens Voerman" a écrit : > Hi Fred, > Are you aware of RangeMode PIXEL_SIZE_ON_SCREEN in osg::LOD ? > it's not using the position on screen, but it is efficiently > calculating > the diameter of the bounding sphere in pixels on screen, and switches > > lod level on that basis. > Laurens. > > On 6/1/2010 6:34 PM, Frederic Bouvier wrote: > > Hi, > > > > I am trying to implement a view dependent LOD scheme that needs the > size and position of a drawable (or a node) on screen. A 2D bounding > box could make the job. Is there something already done in OSG or > should I continue to use unproject on vertices ? > > > > Regards, > > -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ping pong fbo geometry problem
Hi Julien,
aren't you supposed to attach a texture to the framebuffer ? I don't see a call
to glFramebufferTexture2D or something equivalent in your code.
In OSG term, it's the Camera::attach method that should be called.
-Fred
- "Julien Valentin" a écrit :
> Hello,
>
> I would like to do RTT via FBO .
> For this i overload osg::Geometry class
> and reimplements the drawimplementation method
> it now looks like it:
>
> Code:
>
> myGeometry::drawimplemetation(renderinfo)const{
>
> (_ext)->glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbos[*_curst]);
> glPushAttrib(GL_VIEWPORT_BIT | GL_COLOR_BUFFER_BIT);
> osg::ref_ptr st=new osg::State;
> //load the pass dependant stateset
> st->apply(_StateSet[*_curst].get());
> renderInfo.setState(st);
> glViewport(0,0,256, 256);
>
> // Set the render target
> glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
>
> // Render as normal here
> // output goes to the FBO and it’s attached textures
> osg::Geometry::drawimplementation(renderinfo);
>
> glPopAttrib();
>
> //pingpong the render passes
> if(*_curst==0)*_curst=1;
> else *_curst=0;
> }
>
>
>
> To do my prerender stuff i add a prerender camera that draw the stuff
>
> Code:
>
> _Camera->setClearMask(GL_DEPTH_BUFFER_BIT);
> // projection and view
> _Camera->setProjectionMatrix(osg::Matrix::ortho2D(0,_TextureHeight,0,_TextureHeight));
> _Camera->setProjectionMatrix(osg::Matrix::ortho2D(0,1,0,1));
> _Camera->setReferenceFrame(osg::Transform::ABSOLUTE_RF);
> _Camera->setViewMatrix(osg::Matrix::identity());
> // viewport
> _Camera->setViewport(0, 0, _TextureWidth, _TextureHeight);
> _Camera->setRenderOrder(osg::Camera::PRE_RENDER,0);
>
>
>
> and an other camera that display the generated texture
>
> However I get an opengl error 0x506
> I think it's due to the camera that handle the preprocess pass cause i
> don't know how to setup the render implementation as i overload it
> during myGeometry::drawimplementation
>
> Can anyone give me an advice on how to do it ?
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=28539#28539
>
>
>
>
>
> ___
> 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] 2.8 planned date?
Hi Robert, Robert Osfield a écrit : > Hi Tim, > > Forgot to asks. Which openscenegraph components will the next release > of FlightGear rely on? The bit I'm particular curious about is what > OSG packages you'll need, I presume it'll be libopenscenegraph for > runtime, and libopenscenegraph-dev for build, but will you need some > of the more specialist plugins too? > In Windows terms, we are using : OSG50-OSG.DLL OSG50-OSGDB.DLL OSG50-OSGGA.DLL OSG50-OSGPARTICLE.DLL OSG50-OSGTEXT.DLL OSG50-OSGUTIL.DLL OSG50-OSGVIEWER.DLL OSGDB_AC.DLL OSGDB_PNG.DLL OSGDB_RGB.DLL OSGDB_TXF.DLL OT11-OPENTHREADS.DLL plus few other plugins ( OSG/3DS/JPEG ) loaded on demand, depending the aircraft choosen or the models laid on the terrain visited. > My thought is that for next round of Linux releases they are likely to > want to roll in the new version FlightGear if it comes in time, and at > that point we'd also want the OSG packages all prepared for inclusion > as well. > Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8 planned date?
Yes, we provide an installer with the complete OSG binary collection inside ( or at least the modules I managed to build - few plugins doesn't compile for me, mainly because I didn't manage to get the dependencies right ). And I think the Mac distribution follow this rule too. -Fred Robert Osfield a écrit : > Hi Fred, > > Thanks for the list. This looks like the runtime OSG package > requirement would be: > >libopenthreads >libopenscenegraph > > And for dev work: > >libopenthreads-dev >libopenscenegraph-dev > > Under an package system like debian the dependencies will be > automatically pulled in. > > Under Windows do you plan to roll OpenSceneGraph/OpenThreads and > dependencies directly into your installer? > > Robert. > > On Sat, Dec 13, 2008 at 10:42 AM, Frederic Bouvier wrote: > >> Hi Robert, >> >> Robert Osfield a écrit : >> >>> Hi Tim, >>> >>> Forgot to asks. Which openscenegraph components will the next release >>> of FlightGear rely on? The bit I'm particular curious about is what >>> OSG packages you'll need, I presume it'll be libopenscenegraph for >>> runtime, and libopenscenegraph-dev for build, but will you need some >>> of the more specialist plugins too? >>> >>> >> In Windows terms, we are using : >> >> OSG50-OSG.DLL >> OSG50-OSGDB.DLL >> OSG50-OSGGA.DLL >> OSG50-OSGPARTICLE.DLL >> OSG50-OSGTEXT.DLL >> OSG50-OSGUTIL.DLL >> OSG50-OSGVIEWER.DLL >> OSGDB_AC.DLL >> OSGDB_PNG.DLL >> OSGDB_RGB.DLL >> OSGDB_TXF.DLL >> OT11-OPENTHREADS.DLL >> >> plus few other plugins ( OSG/3DS/JPEG ) loaded on demand, depending the >> aircraft choosen or the models laid >> on the terrain visited. >> >> >>> My thought is that for next round of Linux releases they are likely to >>> want to roll in the new version FlightGear if it comes in time, and at >>> that point we'd also want the OSG packages all prepared for inclusion >>> as well. >>> >>> >> Regards, >> -Fred >> >> -- >> Frédéric Bouvier >> http://my.fotolia.com/frfoto/ Photo gallery >> http://fgsd.sourceforge.net/FlightGear Scenery Designer >> >> ___ >> 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 > > -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Precipitation effect coming too fast, and hiding on some areas
Jumping into the thread, Robert Osfield a écrit : >> Second question >> It also rains inside my car. I tried adding a node mask for that, but it >> didn't seem to work. Is it possible not to make it rain inside the cars >> (which are on a separete osg::Group)? >> > > PrecipitationEffect doesn't have an support itself for constraining > the effect to appear inside/outside specified geometries. > > The best thing you could do would be to either try using the stencil > buffer to prevent the fragments of the effect being rendered where you > don't want them. > The same problem affect FlightGear too : it rains into the cockpit. Would it be possible to kill a particle when it comes under a certain distance from the viewer ? If you want to see this funny effect in action, watch this video http://www.vimeo.com/2511328 ( move forward to 5:00 ) -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8 planned date?
Robert Osfield a écrit : > Hi FlightGear-er's, > > On Fri, Dec 12, 2008 at 6:46 PM, Robert Osfield > wrote: > >> What time frame are you working to? >> > > No answer, but it's important for me to have an idea. If you are > pushing out a release this weekend then there is no way we can get 2.8 > in time, if it's next two weeks there is chance, in the next month > then we'll certainly be able to get 2.8. > > I would like to get 2.8 in time for your release, as it makes sense > for both communities to have stable releases coinciding. > The release manager was talking about making the release at the end of next week ( around the 19th ) -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Precipitation effect coming too fast, and hiding on some areas
Hi Robert, Robert Osfield a écrit : > Hi Fred, > > On Sat, Dec 13, 2008 at 4:02 PM, Frederic Bouvier wrote: > >> The same problem affect FlightGear too : it rains into the cockpit. >> Would it be possible to kill a particle when it comes under a certain >> distance from the viewer ? >> >> If you want to see this funny effect in action, watch this video >> http://www.vimeo.com/2511328 ( move forward to 5:00 ) >> > > The particle positions are generated down in the vertex program, so to > cull based on position them you'd need to add logic into the vertex > program to modify the alpha value to 0.0 to make it disappear. It's > worth mentioning you can't cull vertices and associated primitives > with a vertex program as it's strictly one vertex one vertex out. You > could use a geometry shader to cull, or a fragment shader. > Thank you for pointing out the direction to take. > A simpler route would be to use the stencil buffer to clip out the > fragment where you don't want rain. > I don't think it will work because we want to see rain through the windshield but we don't want to see droplets or snowflakes in front of it. > Another route would be to drawn the scene in two passes, first draw > the terrain and precipitation effect, then draw the cockpit. Using > such an approach would allow you to depth partition the scene and get > better depth precision for the two parts of the scene. Personally > this would be the route I'd take. > Same problem here. Snowflakes in front of the windshield will not be erased. I have a patch to PrecipitationEffect that seems to work. I'll submit it to osg-submissions -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.7.8 dev release tagged
Hi Robert, Robert Osfield a écrit : > ps. FlightGear contributors... you guys have gone quite over the last > two days, no doubt busy with other pressing work... any chance of an > update? Is FG going for a release today? Is 2.7.8 sufficient for > your purposes? Do you need a 2.8 branch? > The release is still schedule for later today. There will be 2.7.8 in the binary release. But as flightgear has a huge display bug when compiled with OSG versions older than 2.7.3, we can predict problems with people wanting to install FG from source, but relying on the OSG available in their distro. I presume a warning will accompany the release announcement -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.7.8 dev release tagged
Robert Osfield a écrit : > Hi Fred, > > On Sat, Dec 20, 2008 at 8:32 AM, Frederic Bouvier wrote: > >> The release is still schedule for later today. There will be 2.7.8 in >> the binary release. But as flightgear has a huge display bug when >> compiled with OSG versions older than 2.7.3, we can predict problems >> with people wanting to install FG from source, but relying on the OSG >> available in their distro. I presume a warning will accompany the >> release announcement >> > > Will there be a follow up release? Will the release & docs be able > refreshed to map to OSG-2.8 once 2.8 goes out? > > Once OSG-2.8 is out I would like to get this supported in the various > distro's. If the distro's want to go with the new FG release as well > then what will they need to do? If the FG release maps to 2.8 then > things will be clearer. > There shouldn't be a long period before 1.9.1 ( this one is flagged 1.9.0 ). Usually, we don't produce binary release for Linux. So the distro maintainers may want to wait OSG 2.8 before packaging flightgear 1.9.0, or directly 1.9.1 if it is ready in the meantime. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake error with 2.7.8
Hi Robert, I have a problem trying to build 2.7.8 on Linux (Debian etch). CMake (2.4.5) complains that FindPkgConfig ( .cmake ? ) is not found. It is referenced in src/osgViewer/CMakeLists.txt -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.7.8 dev release tagged
Hi Robert, Robert Osfield a écrit : > Hi Fred, > > On Sat, Dec 20, 2008 at 11:06 AM, Frederic Bouvier wrote: > >> There shouldn't be a long period before 1.9.1 ( this one is flagged >> 1.9.0 ). Usually, we don't produce binary release for Linux. So the >> distro maintainers may want to wait OSG 2.8 before packaging flightgear >> 1.9.0, or directly 1.9.1 if it is ready in the meantime. >> > > I thought I'd go and check out this FlightGear release but I can't see > any mention of the 1.9.0 release, the cvs docs just refer to > flightgear-0.9 so are rather out of date. These webpages don't > mention anything about the OSG being a new dependency. > > Are there more up to date webpages available specifying how to pull > down and build the latest version of FlightGear? > > We are still preparing packages. The location of the files will be announced later -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error with 2.7.8
Thank you. Here is another one, in main CMakeLists.txt:25 IF had incorrect arguments : POLICY CMP0008 ( Unknown arguments specified ) I checked if there is a newer than 2.4.5 version of CMake under Etch but it seems there isn't. -Fred Robert Osfield a écrit : > Hi Fred, > > Argg... I missed an OPTIONAL entry in the src/osgViewer/CMakeLists.txt > file, alas not enough of the commmunity tested svn/trunk before > 2.7.8... it should read: > > #use pkg-config to find various modues > INCLUDE(FindPkgConfig OPTIONAL) > > IF(PKG_CONFIG_FOUND) > ... > > I've now added this and checked it in. The file is also attached, > could you please try this. > > Robert. > > > On Sat, Dec 20, 2008 at 12:37 PM, Frederic Bouvier wrote: > >> Hi Robert, >> >> I have a problem trying to build 2.7.8 on Linux (Debian etch). CMake >> (2.4.5) complains that FindPkgConfig ( .cmake ? ) is not found. It is >> referenced in src/osgViewer/CMakeLists.txt >> >> -Fred >> >> -- >> Frédéric Bouvier >> http://my.fotolia.com/frfoto/ Photo gallery >> http://fgsd.sourceforge.net/FlightGear Scenery Designer >> >> ___ >> 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 -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error with 2.7.8
Robert Osfield a écrit :
> Hi Fred,
>
> On Sat, Dec 20, 2008 at 1:57 PM, Frederic Bouvier wrote:
>
>> Thank you. Here is another one, in main CMakeLists.txt:25
>> IF had incorrect arguments : POLICY CMP0008 ( Unknown arguments specified )
>>
>> I checked if there is a newer than 2.4.5 version of CMake under Etch but
>> it seems there isn't.
>>
>
> Could you try putting a if cmake version check around the offending
> lines? There are other such checks in the main CMakeLists.txt so you
> should be able to copy these.
>
I enclosed the line and the other two below in a
IF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION GREATER 4)
ENDIF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION GREATER 4)
or
IF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
ENDIF(${CMAKE_MAJOR_VERSION EQUAL} 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
bloc, but the error is still there. I removed the 3 lines for the moment
-Fred
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling VSYNC
Hi Robert, as far as I can see, only GraphicsWindowCarbon makes use of it (vsync) -Fred - "Robert Osfield" a écrit : > HI Xam, > > When setting up the GraphicsWindow you pass in a > GraphicsContext::Traits object, this has a field vsync that defaults > to true. > > The other route would be to use putenv() in your app if you want to > use env vars to control the driver. > > Robert. > > > On Tue, Jan 13, 2009 at 7:00 PM, Xam > wrote: > > Is there any way to disable VSYNC inside OSG? > > > > I need a way to enable and disable vsync on my program with out > using the nvidia driver override or environmental variables. The > Nvidia Driver settings for Vsync should be set to "Use the 3D > application setting" > > I seem to remember that i was able to do that in previous versions > of OSG when i was still using producer, I remember getting fps in the > hundreds, but now i only get what ever my screen refresh rate is. > After the removal of producer, i lost the ability to have vsync > control. > > > > Any help would be appreciated, > > > > MS > > > > -- > > Read this topic online here: > > http://osgforum.tevs.eu/viewtopic.php?p=4528#4528 > > > > > > > > > > > > ___ > > 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] OpenThreads in OSG...
James Moliere a écrit : > Hello, > I'm looking at documentation for OpenThreads and am wondering if > OpenThreads is anticipated library of the future in OSG? > > > When trying to download the latest version of OpenThreads, I get an > error... > cvs -d :pserver:cvsgu...@openscenegraph.org:/cvs/openthreads co > OpenThreads > cvs [checkout aborted]: connect to openscenegraph.org(158.42.9.11):2401 > failed: Connection timed out > The project switched to subversion (svn) some time ago -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
Csaba Halász a écrit : > On Fri, Feb 6, 2009 at 1:18 PM, Robert Osfield > wrote: > >> Could you please try out the svn/trunk or OSG-2.8 branch to double >> check that the lwo plugin is now behaving itself. >> > > Hi Robert, > Apparently both versions now load the model, thank you. > There is only the original issue with multitexturing remaining, as > reported by Marco in november. That mail thread seems to have died > without ever receiving a reply from the author of the change causing > the breakage (Bob) Well, apparently, the problem is only partly solved. Please compare the two images below : http://frbouvi.free.fr/flightsim/suv_debug.png displayed by osgViewerd compiled with MSVC 7.1 in Debug mode http://frbouvi.free.fr/flightsim/suv_release.png displayed by osgViewer compiled with MSVC 7.1 in Release mode The source is the 2.8 branch as of this morning ( clean download and rebuild ) It looks to me that some variables are not initialised. It is notorious that MSVC sets some local variables to 0 in debug mode and not in Release mode. The original model can be found here : http://www.marlinstudios.com/files/trafficfree/trafficfree.zip -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
Frederic Bouvier a écrit : > Csaba Halász a écrit : > >> On Fri, Feb 6, 2009 at 1:18 PM, Robert Osfield >> wrote: >> >> >>> Could you please try out the svn/trunk or OSG-2.8 branch to double >>> check that the lwo plugin is now behaving itself. >>> >>> >> Hi Robert, >> Apparently both versions now load the model, thank you. >> There is only the original issue with multitexturing remaining, as >> reported by Marco in november. That mail thread seems to have died >> without ever receiving a reply from the author of the change causing >> the breakage (Bob) >> > > Well, apparently, the problem is only partly solved. Please compare the > two images below : > http://frbouvi.free.fr/flightsim/suv_debug.png displayed by osgViewerd > compiled with MSVC 7.1 in Debug mode > http://frbouvi.free.fr/flightsim/suv_release.png displayed by osgViewer > compiled with MSVC 7.1 in Release mode > > The source is the 2.8 branch as of this morning ( clean download and > rebuild ) > > It looks to me that some variables are not initialised. It is notorious > that MSVC sets some local variables to 0 in debug mode and not in > Release mode. > > The original model can be found here : > http://www.marlinstudios.com/files/trafficfree/trafficfree.zip > I disabled optimisations in the release mode ( /Od ) and the model shows up as expected. This code beats the compiler :-( -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LWO loading problem
Robert Osfield a écrit : > On Sat, Feb 7, 2009 at 6:10 PM, Frederic Bouvier wrote: > >> I disabled optimisations in the release mode ( /Od ) and the model shows >> up as expected. This code beats the compiler :-( >> > > Is this another VS compiler bug then? > Maybe. Someone reported success with VS2005 on the FG ml -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setCursor problem
Hi Romain,
if you followed the thread I initiated on osg-submissions list, you'd realize
that the current code can only show the left arrow.
So in other words, don't change your code, and apply the patches I submitted.
I am sure Robert will take care of this soon.
Regards,
-Fred
- "Romain Charbit" a écrit :
> Hi,
>
> I've seen some discussions about the mouse cursor, but it doesn't
> answer my question.
>
> How can I set a cursor with the function setCursor. When I make a
> setCursor :
>
>
> Code:
>
> osgViewer::GraphicsWindow::MouseCursor mouseCursor;
> mouseCursor = osgViewer::GraphicsWindow::DestroyCursor;
> gw->setCursor(mouseCursor);
>
>
>
>
> it does absolutely nothing.
>
> The only way I can have a cursor, is to do :
>
>
> Code:
>
> while(!viewer.done())
> {
> viewer.frame();
> gw->setCursor(mouseCursor);
> }
>
>
>
>
> And it does not a proper set, it sets the new cursor only when the
> mouse is not moving.
>
> I watched the source code, and I find it a bit confusing :
>
> osgViewer/GraphicsWindowWin32.cpp
>
> GraphicsWindowWin32::setCursor( MouseCursor mouseCursor )
>
>
> Code:
>
> if (mouseCursor != LeftRightCursor &&
> mouseCursor != UpDownCursor &&
> mouseCursor != TopLeftCorner &&
> mouseCursor != TopRightCorner &&
> mouseCursor != BottomLeftCorner &&
> mouseCursor != BottomRightCorner)
> {
> _appMouseCursor = mouseCursor;
> }
>
>
>
>
> then :
>
> Code:
>
> case WM_NCHITTEST :
>
> ...
> ...
>
> default:
> if (_traits->useCursor && _appMouseCursor != InheritCursor)
>setCursor(LeftArrowCursor);
> break;
>
>
>
>
>
>
> so if I set a cursor, _appMouseCursor will be equal to the new cursor,
> but will be erased by the case WM_NCHITTEST;
>
> Is there something I'm missing?
>
> Thank you.
>
> Romain.
>
>
> Romain Charbit
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=10917#10917
>
>
>
>
>
> ___
> 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] Rendering a series of nodes in precise order...
Hi, - "Nathan Monteleone" a écrit : > Mathias Fröhlich wrote: > > Well, as far as I understand, and as far as I have my own applications for > > such kind of scenes. You will need an own render bin number for each object > > if every object just depends on the previous object to be rendered before. > > Else the StateSet sorting might reorder the drawables - true? > > > > Anyway, Robert, I believe it would help to have a 'SceneGraphOrderSorted' > > renderbin where the sorting order of the of the child nodes is just taken. > > Can we have such a beast? > > > > > Yeah this is exactly my situation. I could use the > SceneGraphOrderSorted renderbin too - thanks for the suggestion, and > to Robert for taking it. I was thinking how I could implement a CSG algorithm ( like the one implemented here : http://www.opencsg.org/ ) using OSG. It seems a class like that could help a lot. -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Read texels from texture in GPU memory
Hi Martin, you can look at the osgprerender example when use_image is set. You attach an image to the camera and read the image data in a postdraw callback -Fred - "Martin Aasen" a écrit : > Hi all! > > I am currently rendering to a texture by attaching it to a camera as > Camera::COLOR_BUFFER. > > Now I want to read data back to the CPU from this texture. I have > looked at the examples and examined the forum, but I still don't > understand how to do this. > > Can anyone please point me to the information I need or provide some > code examples to get me started? > > Cheers, > Martin > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=28741#28741 > > > > > > ___ > 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] Read texels from texture in GPU memory
As far as I can tell, glGetTexImage retrieve the whole texture data. If you want to read a subset of that, you'll have to read the framebuffer object with glReadBuffer/glReadPixels as suggested by Gordon. -Fred - "Martin Aasen" a écrit : > Hi, > > Thanks for the replies, guys! I think we are on to something, but I > have to make myself a bit more clear. > > What I want is a function like > > float getSample(Texture2D* tex, Vec2 pos), > > which will return the float value stored in tex at pos (tex is a float > 32 texture with one component) on demand. I would also need a function > that will read a subset of the texture, not only a single texel. I > guess I want the functionality provided by osg::Image::readPixels, but > I want to read from a specified texture, not the window frame buffer. > > I don't want to transfere the full texture image from GPU to CPU on > each frame, which is what I believe osgprerender does. Sorry for not > making this clear from the start. Any ideas on how to do this? > > > Cheers, > Martin > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=28748#28748 > > > > > > ___ > 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] Weekend adventure
Hi Robert, - "Robert Osfield" a écrit : > As for the area, if you can come to Scotland be sure to visit the > north west coast, the 3 hours drive there was stunning all the way > and > the final destination topped it all. Sure the weather can be stormy > sometimes, but that's what you get when the Atlantic Sea's first > landfall is a wall of mountains, for those with the required wet > weather gear it just makes the scenery all the more dramatic ;-) as I had the chance to visit the area twice, I can only confirm that the scenery is one of the most stunning I ever see. The Isle of Skye and the surrounding of Ullapool are marvelous, whatever the weather is. And if you don't like the weather, just wait 20 minutes ;-) Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Headtracking
Hi,
Maybe you already have a Matrix/Camera Manipulator that override your update
callback ?
-Fred
- "Thomas Klemmer" a écrit :
> Hi folks
>
> I'm sitting here trying to set up a head tracking...
> I got an api that spits out a viewmatrix for the camera and now I have
> to get this matrix in the write place.
>
> I wrote an updateCallback for the Cameras (left/right) that looks like
> this.
>
> class updateCameraPosCallback : public osg::NodeCallback
> {
> virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
> {
> osg::Camera* cam =
> dynamic_cast (node);
>
> if(cam)
> {
> osg::Matrix mat(s->getMatrix().data());
> cam->setViewMatrix( mat);
> }
> }
>
> };
>
> I checked the matrix and it looks ok, but somhow the cameras don't
> move!
>
> Any tips??
>
> Thank you!
>
> Cheers,
> Thomas
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=30181#30181
>
>
>
>
>
> ___
> 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] Unresolved externals while building Plugins gif/jpeg/png/etc
- "Kris Dale" a écrit : > > ReaderWriterPNG.obj : error LNK2019: unresolved external symbol > png_get_io_ptr referenced in function "void __cdecl > png_read_istream(struct png_struct_def *,unsigned char *,unsigned > __int64)" (?png_read_istream@@YAXPEAUpng_struct_def@@pea...@z) I fixed that by downloading and compiling libpng 1.4 -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to 3D image...
- "Emmanuel Roche" a écrit : > Just let me know if you need some code to have a better idea of what > I'm doing (but almost everything is written in Lua). If you have OSG 2.9.8, there is a new possible value for the face parameter : osg::Camera::FACE_CONTROLLED_BY_GEOMETRY_SHADER To render to a 3d texture in one run, with only one camera, you can : * draw a quad with draw instancing, the number of instance being the number of slice, * in the vertex shader, copy the gl_InstanceID uniform to a varying * in the geometry shader, copy the varying holding the instance id into gl_Layer that control the slice * do what you want in the fragment shader. If you get http://www-evasion.imag.fr/Membres/Eric.Bruneton/PrecomputedAtmosphericScattering2.zip Look in Main.cpp and in copyInscatter1.glsl, there is a variant of this, without instancing, drawing each quad separately. Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to 3D image...
- "Emmanuel Roche" a écrit : > Hey, thanks for the info Frederic! > > > Actually, the atmospheric scattering effect you're pointing me at is > what I've been trying to integrate into OSG for a few days now and the > reason why I ask those questions :-) So have a look here : http://www.youtube.com/user/fgfred64 ;-) -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio 2010 and iostream
Hi Jason, - "Jason Alexander" a écrit : > Recently Brad Christiansen uploaded some 3rd party binaries built with > Visual Studio 2010. (Thanks!) He noted problems with iostream. I > still have iostream problems when linking in OSG into my application > in specific places under Visual Studio 2010. Does anyone understand > what the issue is? > > Originally, I thought that the 3rd party libraries I was using were > built with a previous version of VS and, thus, caused these linking > issues when rolled into my application. I would have thought that > using 3rd party libraries totally built with vs2010 would have > resolved this, but Brad even noted this problem when he originally > posted the binaries. Any insight would be appreciated! I also encountered these issues. I ended up adding /FORCE:MULTIPLE to my link arguments. There is a field for that in the link topic of the project properties. -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio 2010 and iostream
Hi Martin, to be precise, I don't see any errors when building OSG. The problem arise when liking the application (here, it is FlightGear). I use 3rd party libs already used for the VS2008 build. VS2010 is used to build OSG and FlightGear. -Fred - "Martin Naylor" a écrit : > Interesting, I have just managed to build it VS2010 with no problems > using 2008 libaries. > You could try using CMake to generate 2008 projects files and convert > them to 2010 using VS2010, see if it makes a difference? > > Regards > > Martin. > > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Frederic Bouvier > Sent: 06 August 2010 13:44 > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] Visual Studio 2010 and iostream > > Hi Jason, > > - "Jason Alexander" a écrit : > > > Recently Brad Christiansen uploaded some 3rd party binaries built > with > > Visual Studio 2010. (Thanks!) He noted problems with iostream. I > > still have iostream problems when linking in OSG into my application > > in specific places under Visual Studio 2010. Does anyone understand > > what the issue is? > > > > Originally, I thought that the 3rd party libraries I was using were > > built with a previous version of VS and, thus, caused these linking > > issues when rolled into my application. I would have thought that > > using 3rd party libraries totally built with vs2010 would have > > resolved this, but Brad even noted this problem when he originally > > posted the binaries. Any insight would be appreciated! > > I also encountered these issues. I ended up adding /FORCE:MULTIPLE to > my link arguments. There is a field for that in the link topic of the > project properties. > > -Fred > ___ > 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] Visual Studio 2010 and iostream
This error is gone with CMake 2.8.2 -Fred - "Martin Naylor" a écrit : > Hi Fred, > A that explains why I don’t see errors... > I am still using vs2008 as VS2010 seems to leave the exe files in the > bin and lib folders whenever I build and I had funny linker errors > last time ( a few months back). > > I might have a go at building flightgear later, let you know how it > goes or doesn’t! > > Regards > > Martin. > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Frederic Bouvier > Sent: 06 August 2010 15:21 > To: OpenSceneGraph Users > Subject: Re: [osg-users] Visual Studio 2010 and iostream > > Hi Martin, > > to be precise, I don't see any errors when building OSG. The problem > arise when liking the application (here, it is FlightGear). I use 3rd > party libs already used for the VS2008 build. VS2010 is used to build > OSG and FlightGear. > > -Fred > > - "Martin Naylor" a écrit : > > > Interesting, I have just managed to build it VS2010 with no problems > > using 2008 libaries. > > You could try using CMake to generate 2008 projects files and > convert > > them to 2010 using VS2010, see if it makes a difference? > > > > Regards > > > > Martin. > > > > > > -Original Message- > > From: osg-users-boun...@lists.openscenegraph.org > > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > > Frederic Bouvier > > Sent: 06 August 2010 13:44 > > To: osg-users@lists.openscenegraph.org > > Subject: Re: [osg-users] Visual Studio 2010 and iostream > > > > Hi Jason, > > > > - "Jason Alexander" a écrit : > > > > > Recently Brad Christiansen uploaded some 3rd party binaries built > > with > > > Visual Studio 2010. (Thanks!) He noted problems with iostream. > I > > > still have iostream problems when linking in OSG into my > application > > > in specific places under Visual Studio 2010. Does anyone > understand > > > what the issue is? > > > > > > Originally, I thought that the 3rd party libraries I was using > were > > > built with a previous version of VS and, thus, caused these > linking > > > issues when rolled into my application. I would have thought that > > > using 3rd party libraries totally built with vs2010 would have > > > resolved this, but Brad even noted this problem when he originally > > > posted the binaries. Any insight would be appreciated! > > > > I also encountered these issues. I ended up adding /FORCE:MULTIPLE > to > > my link arguments. There is a field for that in the link topic of > the > > project properties. > > > > -Fred > > ___ > > 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 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] Transfer osgViewer "stream" wirelessly to a remote monitor
> I used: > view->setUpViewOnSingleScreen(1); //for views 1,2,3 with graphics context gc > view->setUpViewOnSingleScreen(2); //for view 4 with graphics context gc2 In my dual screen setup, screens are numbered 0 and 1, not 1 and 2 HTH -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] newbie pixelSize() vs. measured screen size query
Hi, I discovered recently that it is a bounding box that is first calculated for drawables. Then the bounding sphere of nodes is the bounding sphere of the bounding boxes. -Fred - "paul graham" a écrit : > Hi, I've modified the osg billboard example and am examining the pixel > size computed from one of the billboard's bounding spheres. > > I'm sure I'm missing something fundamental in my understanding of > what's going on, but I expected the pixel size computed by pixelSize() > to correspond to the length of the billboard's diagonal as measured on > the screen? > > Can anyone explain to me the relationship between the pixel size > returned from the pixelSize() function and the on-screen pixel size > (ie. of the billboard) in this instance? > > Many thanks > > Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] newbie pixelSize() vs. measured screen size query
- "paul graham" a écrit : > Thanks Frederic - as you say, for the case of a square, you'd expect > the bounding sphere diameter to contain the bounding box - ie. in this > case the square itself. Only if your geometry is axis-aligned, but I supposed it is in your case. -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] newbie pixelSize() vs. measured screen size query
> - "paul graham" a écrit : > > > Thanks Frederic - as you say, for the case of a square, you'd expect > > the bounding sphere diameter to contain the bounding box - ie. in > this > > case the square itself. > > Only if your geometry is axis-aligned, but I supposed it is in your > case. I did a small drawing in case it is not clear : http://frbouvi.free.fr/flightsim/bounding_sphere.jpg -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio 2010 and iostream
The /FORCE:MULTIPLE issue is still there with CMake 2.8.2. What is gone with 2.8.2 is the problem with the build of OSG itself because the bin and dll are still in Release and Debug directories. -Fred - "Brad Christiansen" a écrit : > Hi, > > As mentioned before, I also had the same issue linking VPB (but not my > own application). I also ended up resorting to adding /FORCE:MULTIPLE. > This was all done using CMake 2.8.1. I will try with 2.8.2 as you > suggested. Did you have to rebuild OSG from scratch to resolve the > issue? > > Cheers, > > Brad > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Frederic Bouvier > Sent: Saturday, 7 August 2010 12:16 AM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Visual Studio 2010 and iostream > > This error is gone with CMake 2.8.2 > > -Fred > > - "Martin Naylor" a écrit : > > > Hi Fred, > > A that explains why I don’t see errors... > > I am still using vs2008 as VS2010 seems to leave the exe files in > the > > bin and lib folders whenever I build and I had funny linker errors > > last time ( a few months back). > > > > I might have a go at building flightgear later, let you know how it > > goes or doesn’t! > > > > Regards > > > > Martin. > > > > -Original Message- > > From: osg-users-boun...@lists.openscenegraph.org > > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > > Frederic Bouvier > > Sent: 06 August 2010 15:21 > > To: OpenSceneGraph Users > > Subject: Re: [osg-users] Visual Studio 2010 and iostream > > > > Hi Martin, > > > > to be precise, I don't see any errors when building OSG. The > problem > > arise when liking the application (here, it is FlightGear). I use > 3rd > > party libs already used for the VS2008 build. VS2010 is used to > build > > OSG and FlightGear. > > > > -Fred > > > > - "Martin Naylor" a écrit : > > > > > Interesting, I have just managed to build it VS2010 with no > problems > > > using 2008 libaries. > > > You could try using CMake to generate 2008 projects files and > > convert > > > them to 2010 using VS2010, see if it makes a difference? > > > > > > Regards > > > > > > Martin. > > > > > > > > > -Original Message- > > > From: osg-users-boun...@lists.openscenegraph.org > > > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > > > Frederic Bouvier > > > Sent: 06 August 2010 13:44 > > > To: osg-users@lists.openscenegraph.org > > > Subject: Re: [osg-users] Visual Studio 2010 and iostream > > > > > > Hi Jason, > > > > > > - "Jason Alexander" a écrit : > > > > > > > Recently Brad Christiansen uploaded some 3rd party binaries > built > > > with > > > > Visual Studio 2010. (Thanks!) He noted problems with iostream. > > > I > > > > still have iostream problems when linking in OSG into my > > application > > > > in specific places under Visual Studio 2010. Does anyone > > understand > > > > what the issue is? > > > > > > > > Originally, I thought that the 3rd party libraries I was using > > were > > > > built with a previous version of VS and, thus, caused these > > linking > > > > issues when rolled into my application. I would have thought > that > > > > using 3rd party libraries totally built with vs2010 would have > > > > resolved this, but Brad even noted this problem when he > originally > > > > posted the binaries. Any insight would be appreciated! > > > > > > I also encountered these issues. I ended up adding > /FORCE:MULTIPLE > > to > > > my link arguments. There is a field for that in the link topic of > > the > > > project properties. > > > > > > -Fred > > > ___ > > > 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-us
Re: [osg-users] Visual Studio 2010 and iostream
Yes I do. Windows 7 64, VS2010, CMake 2.8.2 -Fred - "Martin Naylor" a écrit : > Hi Fred, > I just removed cmake 2.8 and installed cmake 2.8.2 and rechecked out > OSG and I still have the same issue with exe and dll's not being moved > or created in the OSG bin folder, it's a pain everytime you recompile > anything as it's a manual copy job.. > > Just tried it on my 32bit machine and still the same results. > I am beginning to suspect it's something different in Windows 7, is > anyone else compiling with Windows 7x64/32 and VS2010? > > > Regards > > Martin. > > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Frederic Bouvier > Sent: 06 August 2010 17:16 > To: OpenSceneGraph Users > Subject: Re: [osg-users] Visual Studio 2010 and iostream > > This error is gone with CMake 2.8.2 > > -Fred > > - "Martin Naylor" a écrit : > > > Hi Fred, > > A that explains why I don’t see errors... > > I am still using vs2008 as VS2010 seems to leave the exe files in > the > > bin and lib folders whenever I build and I had funny linker errors > > last time ( a few months back). > > > > I might have a go at building flightgear later, let you know how it > > goes or doesn’t! > > > > Regards > > > > Martin. > > > > -Original Message- > > From: osg-users-boun...@lists.openscenegraph.org > > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > > Frederic Bouvier > > Sent: 06 August 2010 15:21 > > To: OpenSceneGraph Users > > Subject: Re: [osg-users] Visual Studio 2010 and iostream > > > > Hi Martin, > > > > to be precise, I don't see any errors when building OSG. The problem > > arise when liking the application (here, it is FlightGear). I use > 3rd > > party libs already used for the VS2008 build. VS2010 is used to > build > > OSG and FlightGear. > > > > -Fred > > > > - "Martin Naylor" a écrit : > > > > > Interesting, I have just managed to build it VS2010 with no > problems > > > using 2008 libaries. > > > You could try using CMake to generate 2008 projects files and > > convert > > > them to 2010 using VS2010, see if it makes a difference? > > > > > > Regards > > > > > > Martin. > > > > > > > > > -Original Message- > > > From: osg-users-boun...@lists.openscenegraph.org > > > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > > > Frederic Bouvier > > > Sent: 06 August 2010 13:44 > > > To: osg-users@lists.openscenegraph.org > > > Subject: Re: [osg-users] Visual Studio 2010 and iostream > > > > > > Hi Jason, > > > > > > - "Jason Alexander" a écrit : > > > > > > > Recently Brad Christiansen uploaded some 3rd party binaries > built > > > with > > > > Visual Studio 2010. (Thanks!) He noted problems with iostream. > > I > > > > still have iostream problems when linking in OSG into my > > application > > > > in specific places under Visual Studio 2010. Does anyone > > understand > > > > what the issue is? > > > > > > > > Originally, I thought that the 3rd party libraries I was using > > were > > > > built with a previous version of VS and, thus, caused these > > linking > > > > issues when rolled into my application. I would have thought > that > > > > using 3rd party libraries totally built with vs2010 would have > > > > resolved this, but Brad even noted this problem when he > originally > > > > posted the binaries. Any insight would be appreciated! > > > > > > I also encountered these issues. I ended up adding /FORCE:MULTIPLE > > to > > > my link arguments. There is a field for that in the link topic of > > the > > > project properties. > > > > > > -Fred > > > ___ > > > 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.cg
Re: [osg-users] [3rdparty] specify particular mimap level image
Hi Alice, - "Alice Yin" a écrit : > Hi, > > I am rewriting my code into OSG. One function I want to use is to > specify each level of the mipmap image by myself, just as > glTexImage2D(GL_TEXTURE_2D, level, GL_RGB, cols, rows, 0, GL_RGB, > GL_FLOAT, Data) does. > > Is there a function in OSG like this? I haven't found yet. If not, is > it possible to extend the osg::Texture2D class to do this job? Mipmap control is located in osg::Image. You can tell if you want automatic generation or if you want to provide your own data for each level. In that latter case, you have to concatenate the levels in the data, and provide offsets to tell where in the data, each level starts. -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] parameters
- "Robert Osfield" a écrit : > Hi Ricky, > > On Tue, Aug 10, 2010 at 6:34 PM, Ricky Flintoff > wrote: > > So there is no way I can capture focal length effects in OSG using > the Prespective projection matrix? > > By "focal length effects" do you mean depth of field? One can also mean field of view, zooming or even lens distortion too. -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgBullet Build unsuccessful
Hi, often you can see in depends that some registered dll are loaded dynamically. This shouldn't cause any arm because the error is usually catched. What you should do to really find your problem is to start your test application inside depends and do a profiling. You can do that by loading your exe in depends, and go to the Profile > Start profiling... menu. Regards, -Fred - "Sanat Talmaki" a écrit : > Hi, > > I am trying to build osgBullet and while the projects build correctly > in VisualStudio, when I try to run the binaries created, they hang on > me. > > I hav the binaries from osgBullet and osgWorks copied into the > binaries folder for osgBullet. > > When I opened the dll for osgdb_osgbBullet.dll in depends.exe, I got > the following: > MSJAVA.DLL : System cannot find the file specified. > > And osgbBullet.dll: > MSJAVA.DLL : System cannot find the file specified. > > I cannot understand why this dll would be causing my binaries to > hang. > > I was hoping to get some advise from other users who have built > osgBullet successfully or who may have experienced any similar > problems. > > Thank you > > Sincerely, > Sanat ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] transparent texture and linear filtering issue
Hi, - "Vivien Delage" a écrit : > Hi, > > I have an issue with rendering transparent textures and activating > linear filtering on them. I am using TRANSPARENT_BIN with > DepthSortedBin. > > My textures are not semi transparent, they only have parts with either > alpha 1 or with alpha 0. > > When the filtering is not activated everything looks good. But as soon > as I activate the filtering then I get artifact for the pixels that > have been smoothed by the filter. Looks at the two attached image to > give you an idea. > > Is there any know way to fix this issue? Pixel with alpha=0 are often set to black by the image editor. You can try to set a very low, not null, alpha value, and set the rgb value of the adjacent pixels to the same color than the opaque pixels at the border. -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync false doesn't change frame rate
Le 05/09/2010 19:06, Tomas Starka a écrit : > Thanks, but as I've wrote earlier: Driver change isn't an option. I believe, > that OSG have some clean way to do this. I just can't figure it out. I don't think OSG is able to override driver settings. You have to switch it off in the user settings before. In other words : vsync = driver || OSG => !vsync = !driver && !OSG ;-) -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why I can not call discardAllDeletedGLObejcts function
- "Licheng Zhang" a écrit : > Hi, > I encountered the same problem in > http://forum.openscenegraph.org/viewtopic.php?t=4527 > according to robertosfield's suggestion. > > In terms of manually forcing the discard of all the GL handles you can > > do a scene->releaseGLObjects() and then a osg::discardAllGLObjects(); > > This is for svn/trunk & 2.9.6 but for prior versions you'll need to > call osg::discardAllDeletedGLObejcts() as the discardAllGLobjects() is > > a recent addition. > > why can't I use osg::discardAllDeletedGLObejcts()? Because it looks like a typo and the real function should be use osg::discardAllDeletedGLObjects() -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Preparing for OpenSceneGraph-2.9.9 developer release, please test :-)
There is still a bad flicker when, in osgViewer, I drag with the mouse in one screen, stop the drag, and restart in the other screen. No flicker as long as drags occur in the same screen. -Fred - "Martin Naylor" a écrit : > Mmmm, I think I may have found the problem! > Download the latest 260.63 drivers(BETA) from Nvidia, and all is well > on my > system with aero enabled. > No wonder I could never find what was going on ;) > > > -Original Message- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Jean-Sébastien Guay > Sent: 16 September 2010 18:29 > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] Preparing for OpenSceneGraph-2.9.9 developer > release, please test :-) > > Hi Torben, Dženan, Robert, > > > please read this thread: > http://forum.openscenegraph.org/viewtopic.php?t=6526&highlight= > > > > more people including me have the black screen problem, it seems to > be a > driver issue. > > Indeed, and without any solution yet. It's not annoying enough to me > that I would go out of my way to find a solution, someone with the > inclination could work on finding a solution and I'd be happy though. > I > just set OSG_WINDOW=x y w h or use --window x y w h. > > 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 > > ___ > 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] Please help, linking errors with OpenSceneGraph
Hi Renesis, - "Jean-Sébastien Guay" a écrit : > Hi Renesis, > > > [...] but now when the program runs I get this runtime error: > > > > Code: > > > > Windows has triggered a breakpoint in test.exe. > > This may be due to a corruption of the heap, which indicates a bug > in test.exe or any of the DLLs it has loaded. > > This may also be due to the user pressing F12 while test.exe has > focus. > > The output window may have more diagnostic information. > > > > And then it takes me to malloc.c. > > This is typically because you have compiled your program in debug but > > have linked to release libraries, or the opposite. If you're compiling > > your project in debug you need to link to debug libraries (the OSG > libraries have a 'd' at the end when they're debug versions) and vice > versa. > > Check that your project matches what you're linking to. This always > something to check when compiling with Visual C++. You can search the > > net or even this mailing list if you want more information on this, > it's > been discussed at length in the past. > > Hope this helps, Your test program should also be compiled with /MDd in debug mode and with /MD in release mode (see C/C++ / Code generation property page) -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] convertLatLongHeightToXYZ
Hi Lucie, x and y change should be proportional to cos( lat ), z change should be proportional to sin( lat ) -Fred - "lucie lemonnier" a écrit : > Hi, > > I understood that the XYZ are in Earth Center Earth Fixed > coordinates. > So is it normal that X,Y are calculated based on height? > In fact, I put a latitude, longitude and height on a model, I use > osg::EllipsoidModel::convertLatLongHeightToXYZ to obtain the position > x,y,z and I transform my point with the MatrixTransforms applied on > the terrain model and I place my model with the transformed point. > Is it the step to be followed? > > Thank you! > > Cheers, > lucie > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=32170#32170 > > > > > > ___ > 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 camera 'layers'
Hi, - "Jean-Sébastien Guay" a écrit : > Hello Mike, > > > I would like to create a 2D background (can this be done using the > main camera? If so how?) I would then like to have other multiple > cameras each rendering their own 3D sub scene with a transparent > background (how does each camera have a transparent background?) but > be able to position the output of the 3D cameras on the 2D background. > I was thinking adding all the 3D cameras as slaves to the parent but > then I wondered how can I translate the output of each camera on the > 2D background. Would I need to put a MatrixTransform above the > cameras? If I am adding the 3D cameras as slaves how can I put a > MatrixTransform above them? > > I would do each background by creating a textured quad that fills the > > view and rendered before everything else with depth write off. > > Then your idea of slave cameras is good, and for each of your slave > cameras you can specify an osg::Viewport that will give, in pixel > coordinates, where you want the camera to render inside the main > window > (the view's master camera will have its viewport set to fill the > window). > > Using RTT for this is overkill IMHO. For the 2D background, you can replicate the HUD example, and use setRenderOrder( PRE_RENDER ) instead of ( POST_RENDER ) when you draw your unit quad, and avoid clearing the color buffer for your 3D cameras. -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Lighting shader problem
>
> if(!aniModel->getAvatar()->getOrCreateStateSet()->getUniform("eyePosition")->setElement(0,osg::Vec3(eye._v[0],eye._v[1],eye._v[2])))
why not :
if(!aniModel->getAvatar()->getOrCreateStateSet()->getUniform("eyePosition")->set(eye))
?
-Fred
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to texture
Hi, An advanced way to do that is to combine layered rendering with a geometry shader and geometry instancing to generate the slices. OSG SVN has support to let the geometry shader choose the right layer via the gl_Layer variable. -Fred - "Mahendra G.R" a écrit : > Hello Robert, > > Ok, will do that. I'm pretty new to ALL these things. > > > On Fri, Oct 1, 2010 at 3:38 PM, Robert Osfield < > robert.osfi...@gmail.com > wrote: > > > Hi Mahendra, > > Hows about looking at the osg::Camera API, it should become obvious > how one sets a specific face of texture cube map or a 3d texture when > doing render to texture. Learning how to investigate how to solve > your own problems by looking at the API and examples will really speed > your progress. > > Robert. > > On Fri, Oct 1, 2010 at 2:32 PM, Mahendra G.R < mahen...@mahendragr.com > > wrote: > > Hello, > > > > Sorry guys, i have a problem agian. What i'm trying to do is render > into a > > 3D texture and i have a problem here, as far as i know, what i'm > doing now > > is render into a 2D texture (using a FBO). I saw some samples in > opengl > > where they actually loop through all the slices in Z direction and > produce a > > 3D texture. how should i do this in osg?. Sorry if my questions are > stupid > > > > > > Thanks, > > Best regards > > > > On Fri, Oct 1, 2010 at 2:47 PM, Mahendra G.R < > mahen...@mahendragr.com > > > wrote: > >> > >> Hello Robert, > >> > >> Thanks, i figured it out. > >> > >> On Fri, Oct 1, 2010 at 2:42 PM, Robert Osfield < > robert.osfi...@gmail.com > > >> wrote: > >>> > >>> HI Mahendra > >>> > >>> On Fri, Oct 1, 2010 at 1:30 PM, Mahendra G.R < > mahen...@mahendragr.com > > >>> wrote: > >>> > Thanks or ur reply, how should i read back the data from the > texture, > >>> > can i > >>> > attach an image to the camera(or texture?) and read data from > that > >>> > image?, > >>> > is it possible and how. > >>> > >>> See osgprerender example, in particular the code path that is used > when > >>> you run: > >>> > >>> osgprerender --image > >>> > >>> Robert. > >>> ___ > >>> osg-users mailing list > >>> osg-users@lists.openscenegraph.org > >>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > >> > >> > >> -- > >> http://www.mahendragr.com > > > > > > > > -- > > http://www.mahendragr.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 > > > > -- > http://www.mahendragr.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] Save texture changes via fragment shader
> // load texture as an image
> imgTexture = osgDB::readImageFile("model/BAKE_OVERRIDE.jpg");
> // if the image is successfully loaded
> if (imgTexture)
> {
> imgTexture->allocateImage(3500, 3500, 1, GL_RGBA,
> GL_UNSIGNED_BYTE);
Why are you reallocating space for an image loaded from file ?
Shouldn't the texture dimension be a power of 2 ?
> // create a new two-dimensional texture object
> texAvatar = new osg::Texture2D;
> // set the texture to the loaded image
> texAvatar->setImage(imgTexture);
> }
> node->getOrCreateStateSet()->setTextureAttributeAndModes(1, texAvatar,
> osg::StateAttribute::ON);
> node->getOrCreateStateSet()->addUniform(new osg::Uniform("editedMap",
> 1));
>
> // tell the camera to use OpenGL frame buffer objects
>
> //getCamera()->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
> getCamera()->attach(osg::Camera::COLOR_BUFFER1, imgTexture);
getCamera()->attach(osg::Camera::COLOR_BUFFER1, texAvatar);
Where is attachment for COLOR_BUFFER0 ?
You should read the framebuffer object spec :
http://www.opengl.org/registry/specs/ARB/framebuffer_object.txt
Especially the part that begins by "If the GL is bound to the default
framebuffer"...
attachement to osg::Camera::COLOR_BUFFER1 is only valid for a newly create
framebuffer, not the default one.
Regards,
-Fred
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stencil buffer and FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT
Hi Fred, - "Fred Smith" a écrit : > The following works fine: > > camera->attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, > GL_DEPTH_STENCIL_EXT); > > Why doesn't it work if I create a texture? I need to create a texture > and an image, as I want to retrieve stencil buffer data after frame() > has been called. I doubt it is possible to read back the stencil buffer, and attach it to a texture. Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stencil buffer and FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT
Maybe : textureDepthStencil->setInternalFormat( GL_DEPTH_STENCIL_EXT ); ... camera->attach(osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, textureDepthStencil); Could work. As the depth and stencil buffer are packed, so should the texture. (re)read http://www.opengl.org/registry/specs/EXT/packed_depth_stencil.txt there is a paragraph that starts with : In addition, a new base internal format, GL_DEPTH_STENCIL_EXT, can be used by both texture images and renderbuffer storage. When an image with a DEPTH_STENCIL_EXT internal format is attached to both the depth and stencil attachment points of a framebuffer object (see EXT_framebuffer_object), then it becomes both the depth and stencil buffers of the framebuffer... -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
Hi Sukender,
Add /FORCE:MULTIPLE to your link options
-Fred
- "Sukender" a écrit :
> Hi all,
>
> Any update on this side? I've got the same issue (I use fstream in my
> project which depends on osgDB, under VC2010 x64).
> Or is there a way to temporarily workaround this in OSG with an ugly
> #ifdef?
>
> Sukender
> PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
>
> - "Anders Backman" a écrit :
>
> > Ok, I have localized the problem.
> >
> >
> > For example, the class osgDB::fstream:
> >
> >
> >
> > class OSGDB_EXPORT fstream : public std::fstream
> > {
> >
> >
> > };
> >
> >
> > which just inherits from std:.fstream causes the symbols of
> > std::fstream to be exposed into osgDB.dll
> >
> >
> > This effectively means that It might cause problems for people
> linking
> > against osgDB.dll later on.
> > Same goes for inheriting from std::string, std::ostringstream etc.
> >
> >
> > This must obviously be a bug, a very serious one in VS2010.
> > We had a class derived from std::ostringstream, which exposed the
> > symbols in the vtable for the class:
> >
> >
> > namespace ns
> > {
> > class Notify : public std::ostringstream
> > {
> > };
> > }
> >
> >
> > Using depends.exe to analyze the dll-file gives:
> >
> >
> > const ns::Notify::`vftable'{for
> `std::basic_ostringstream > std::char_traits,class std::allocator >'}
> >
> >
> > My issue was reported to the msdn forum. Their first take was: Oh
> you
> > use CMake, thats not our product :-)
> > But in later threads, they tried to reproduce the problem without
> > luck...
> > So if you manage to reproduce this in a small example, go ahead and
> > post it. We must make them aware of this problem.
> >
> >
> >
> http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/191de00a-53c9-4bd9-9cb6-e844eb224ca2
> >
> >
> > /Anders
> >
> > On Mon, Aug 30, 2010 at 4:31 AM, Christiansen, Brad <
> > brad.christian...@thalesgroup.com.au > wrote:
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > Unfortunately I can't offer a solution, but I thought I would
> mention
> > I have come across this exact problem and have also pulled my hair
> out
> > trying to find a solution. This same problem exists when building
> > virtual planet builder, linking with osgDB causes the multiply
> defined
> > symbols. I had no other issues building the 3rd party libs and osg
> > with 2010.
> >
> >
> >
> > The only way I could move forward was to allow multiply defined
> > symbols (as has already been mentioned). I agree this seems
> dangerous
> > and is not a solution but it has allowed me to continue working. So
> > far it hasn’t caused any issues with my vpb build.
> >
> >
> >
> > Given you have used the streams extensively without issue and it
> seems
> > osgDB is the source of the trouble, have you had a look to see if
> > there is any discernable difference between your code and that in
> > osgDB ?
> >
> >
> >
> > I would love to find a solution to this.
> >
> >
> >
> > Cheers,
> >
> > Brad
> >
> >
> >
> >
> > From: osg-users-boun...@lists.openscenegraph.org [mailto:
> > osg-users-boun...@lists.openscenegraph.org ] On Behalf Of Anders
> > Backman
> > Sent: Friday, 27 August 2010 4:00 PM
> > To: OpenSceneGraph Users
> > Subject: Re: [osg-users] OT: VS2010 LNK2005 problem related to
> > ostringstream
> >
> >
> >
> >
> >
> >
> >
> > I have verified the build mode for all ingoing libraries.
> >
> >
> >
> >
> >
> > I build all the dependencies myself. Including OSG.
> >
> >
> >
> >
> >
> > The problem I have (which is OSG related), is that if I build
> without
> > OSG support (no rendering), it all works.
> >
> >
> > And I still use std::ostringstream and std::stringstream quite
> > extensively...
> >
> >
> > We still link against OpenThreads (but no rendering).
> >
> >
> >
> >
> >
> >
> >
> >
> > So only when I link against osg (osg.lib, osgDB.lib, osgText.lib,
> > osgShadow.lib, osgViewer.lib osgGA.lib) I get this problem.
> >
> >
> >
> >
> >
> > I have verified that osg (and OpenThreads) are all built
> consistently
> > all over the field. Release and /MD (MultiThreadedDLL), which is
> > default from CMake.
> >
> >
> >
> >
> >
> >
> >
> >
> > So I can use/link against OpenThreads.lib, but not OSG...
> >
> >
> >
> >
> >
> > Rather nasty problem, I'm trying to reduce it, but I'm getting
> > nowhere.
> >
> >
> > And once again, same settings, same CMake version, same code all
> over
> > the place, and it works in VS2008...
> >
> >
> >
> >
> >
> > /A
> >
> >
> >
> >
> >
> > On Thu, Aug 26, 2010 at 8:17 PM, Simon Hammett <
> > s.d.hamm...@googlemail.com > wrote:
> >
> > Ah ok, then next things to check:
> >
> > Make absolutely sure you aren't mixing up objects & libraries from
> the
> > different builds.
> > For my projects I include a vc version number in the name, so
> > .vc7.lib/vc7.dll & .vc9.lib/.vc9.dll
> > and I also use the vc version in the name of output & intermediate
> > directory
> >
> > Then check all the code for any use of
> >
> >
Re: [osg-users] Multitexture Issue in GLSL Fragment Shader
Hi Peter, try stateSet -> addUniform( new osg::Uniform( "stTexture" , 0 ) ) ; instead; Regards, -Fred - "Peter Wrobrl" a écrit : > Hi, > > yes, it should use texture 0, but how do I specify this ? The 1 in > this code line : > stateSet -> addUniform( new osg::Uniform( osg::Uniform::SAMPLER_2D , > "stTexture" , 1 ) ) ; > > does not choos a texture, but sets the number of elemets in the > uniform ( one sampler2D ). > > The texture unit association happens ( to my understanding ) with this > : > stateSet -> setTextureAttributeAndModes( 1 , projectionTexture , > osg::StateAttribute::ON ) ; > > But I can't do this for texture 0 ( stTexture ) as it is defined > inside the .osg file. > > So basically the question is, how to assotiate a sampler2D uniform > with a certain texture Unit ( from an .osg file ) ? > > > > Thank you! > > Cheers, > Peter > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=32941#32941 > > > > > > ___ > 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] [OT] I18N libraries
Hi Sukender, I never tried them, but I know there are some interesting stuff here : http://ftp.acc.umu.se/pub/gnome/binaries/win64/dependencies/ Regards, -Fred - "Sukender" a écrit : > Hi all, > > I was using gettext-intl to handle translated strings in my apps, but > now I'm compiling 64 bits it's a pain having this lib compiled. > Do you know where I can find this lib compiled for MSVC10 x64? > Do you know other libs (except Qt since it's too heavy for me)? > Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate mipmaps from arbitrary image
Hi Robert, I recently implemented a shader technique in FlightGear that needed to compute the mipmaps levels with the min operator on the alpha channel instead of the classical average that is usually used. For that technique, I computed the mipmaps on the CPU. If you design a new function that can compute mipmaps, would it be possible to choose the operation that merge the four source pixels into the pixel of the next level ? By providing a callback or a function object that default to average on all channels ? My implementation is here : http://gitorious.org/fg/simgear/blobs/next/simgear/scene/material/mipmap.cxx The technique implemented is shown in this short video : http://www.youtube.com/watch?v=lwVrKb2yShk Regards, -Fred - "Robert Osfield" a écrit : > Hi Sukender, > > My plan is to add a Image::buildMipmaps() functions that will use the > new local gluScaleImage function that no longer requires a graphics > context. However, this function won't support compressed textures as > GLU has never support texture compression, and our integration of GLU > parts into the OSG hasn't magically changed this. > > I am also planning to integrate NVidiaTextureTools as an OSG > plugin/extension which will be able to compliment the GLU functions > and add support for compressed texture formats. This will however > require the NVTT as external dependency. > > I may be able to get on to these tasks next week. > > Robert. > > > On Thu, Nov 4, 2010 at 11:47 AM, Sukender wrote: > > Hi all, > > > > I need to generate mipmaps from an osg::Image (a 2D image actually, > which may be S3TC-DXTC compressed or not), and I have no OpenGL > context. I just want my image to have mipmaps. Do you know anything > that may help me? > > - Something to get a context without having to realize something, or > with an invisible window? > > - Something to allocate mipmap memory, compute mipmaps, and store > them in the osg::Image? > > > > I guess osg::gluBuild2DMipmaps() is the key, but it needs a context > and process does not appear to be straightforward to me. > > Thanks. > > > > Cheers, > > > > Sukender > > PVLE - Lightweight cross-platform game engine - > http://pvle.sourceforge.net/ > > ___ > > 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] Blending two textures manualy
- "Aitor Ardanza" a écrit : > Ulrich Hertlein wrote: > > > > I believe your pixel address calculation is wrong; try this > instead: > > > > // i==row/y, j==column/x > > unsigned char* pixel = texture->getImage(0)->data() + ((i * > tex_width) + j) * 4; > > *(pixel+0) = r; > > *(pixel+1) = g; > > *(pixel+2) = b; > > *(pixel+3) = a; > > > > I get the same result ... thanks for the reply! There is also Image::data(i,j) See: http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00305.html#b25259a3084978232846b0f1c4aed4bd -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using Geometry Shaders in OSG 2.9.9
Hi Joel,
> layout (traingle_strip, max_vertices = 3) out;
I doubt this valid GLSL. Try
layout (triangle_strip, max_vertices = 3) out;
instead ;-)
Regards,
-Fred
- "Joel Graff" a écrit :
> Hi,
>
> I've been developing an app in OpenSceneGraph to help me learn
> shaders. One component of that is to be able to visualize normals
> (surface, lighting, camera, etc.). I am attempting to implement
> geometry shaders to do this in GLSL 1.5 and OSG 2.9.9. At present,
> I've had success loading vertex and fragment shaders, but the geometry
> shader implementation eludes me.
>
> From what little I understand of geometry shaders and GLSL, I don't
> see anything wrong with my shader, but since I can't use RenderMonkey
> to test for compile errors, I could be wrong.
>
> That said, I've attempted to implement the shader (vertex, geometry
> and fragment), and I don't see any compile errors on the console when
> I run the program in debug mode (using VS2010) and break execution
> just before I run the viewer. I have set OSG_NOTIFY_LEVEL to DEBUG,
> so I expect that any compile problems with the shaders would be output
> to the console window. If not, and I have to retrieve the info log
> myself, I'd appreciate some info on how to do that, as attempting to
> do so generates an unhandled exception for me.
>
> Relevant code:
>
> Vertex Shader
>
>
> Code:
> #version 150
> uniform mat4 osg_ModelViewMatrix; //from application program.
> uniform mat4 osg_ModelViewProjectionMatrix;
> in vec4 osg_Vertex; //from vertex buffer from app pgm.
>
> void main (void) {
> gl_Position = osg_ModelViewMatrix * osg_Vertex;
> }
>
>
>
> Geometry Shader
>
>
> Code:
> #version 150
> layout (triangles) in;
> layout (traingle_strip, max_vertices = 3) out;
> uniform mat4 osg_ProjectionMatrix; //from application program.
> out vec3 normal; //to fragment shader.
>
> void main (void) {
> vec3vector1;
> vec3vector2;
>
> vector1 = gl_in[1].gl_Position.xyz - gl_in[0].gl_Position.xyz;
> vector2 = gl_in[2].gl_Position.xyz - gl_in[0].gl_Position.xyz;
>
> normal = normalize (cross (vector1, vector2));
> gl_Position = osg_ProjectionMatrix * gl_in[0].gl_Position;
> EmitVertex ();
>
> gl_Position = osg_ProjectionMatrix * gl_in[1].gl_Position;
> EmitVertex ();
>
> gl_Position = osg_ProjectionMatrix * gl_in[2].gl_Position;
> EmitVertex ();
>
> EndPrimitve ();
> }
>
>
>
> Fragment Shader
>
>
> Code:
> #version 150
> in vec3 normal; //from geometry shader.
> out vec4 color; //to framebuffer.
>
> void main (void) {
> gl_FragColor = vec4 (normal, 1.0);
> }
>
>
>
> OSG Code
>
>
> Code:
> void loadShaders (osg::ref_ptr rootGroup)
> {
> osg::ref_ptr rootGeode (dynamic_cast
> (FindNode(rootGroup, "geode_root")->getFirst()));
> osg::ref_ptr SAQgeometry (FindGeometry(rootGeode,
> "geometry_ScreenAlignedQuad"));
>
> osg::ref_ptr vertexShader(
> osg::Shader::readShaderFile (osg::Shader::VERTEX,
> "C:/OpenSceneGraph/OpenSceneGraph-Data-2.8.0/myShaders/test.vert"));
>
> osg::ref_ptr geometryShader(
> osg::Shader::readShaderFile (osg::Shader::GEOMETRY,
> "C:/OpenSceneGraph/OpenSceneGraph-Data-2.8.0/myShaders/test.geom"));
>
> osg::ref_ptr fragShader(
> osg::Shader::readShaderFile (osg::Shader::FRAGMENT,
> "C:/OpenSceneGraph/OpenSceneGraph-Data-2.8.0/myShaders/test.frag"));
>
> osg::ref_ptr program (new osg::Program());
>
> program->addShader(vertexShader); //new
> osg::Shader(osg::Shader::VERTEX, vertexShaderSource));
> program->addShader(geometryShader);
> program->addShader(fragShader); //new
> osg::Shader(osg::Shader::FRAGMENT, fragmentShaderSource));
>
> program->setParameter( GL_GEOMETRY_VERTICES_OUT_EXT, 3 );
> program->setParameter( GL_GEOMETRY_INPUT_TYPE_EXT,
> GL_TRIANGLE_STRIP );
> program->setParameter( GL_GEOMETRY_OUTPUT_TYPE_EXT,
> GL_TRIANGLE_STRIP );
>
> program->addBindAttribLocation("osg_Vertex", 0);
> program->addBindAttribLocation("osg_Normal", 2);
>
> SAQgeometry->getOrCreateStateSet()->setAttribute(program);
>
>
> osg::ref_ptr ss = SAQgeometry->getStateSet();
> ...
> }
>
>
>
> Just to ensure there's nothing wrong with my OSG code, I commented out
> the geometry shader-related code and had the frag shader color the
> primitive yellow and it worked perfectly.
>
> Anyway, I've looked for answers and I'm finding geometry shader
> information, esp. as it relates to OSG is (not surprisingly) somewhat
> sparse.
>
> I appreciate any thoughts / comments / tips that anyone may have.
>
> Thanks.
>
> Joel
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=34101#34101
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegrap
Re: [osg-users] How to render the OSG scene to an image file?
Hi Igor, did you search in the example folder ? I am sure that more than one use a pbuffer. More use framebuffer objects. You can have a look to osgscreencapture Regards, -Fred - "Igor Galochkin" a écrit : > I am still stuck. Guys, any suggestions? > > My colleague tried to solve the problem and came to a conclusion that > Viewer can't render to any offscreen buffer. He tries to render the > OSG scene without using the Viewer, by direct calls to OpenGL. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ModelView and projection matrices in cull callback different from camera's view and projection matrices
Hi Fred, - "Fred Smith" a écrit : > Hi, > > In a drawable cull callback, I have found that > State::getModelViewMatrix() and State::getProjectionMatrix() are > different from the matrices returned by Camera::getViewMatrix() and > Camera::getProjectionMatrix(). > > I actually can't perform world to screen space coordinate conversion > using matrices provided by the State, at least not using this kind of > formula: screenSpacePoint = worldSpacePoint * view * proj * > viewPortComputedWindowMatrix. > > The same calculation works with camera matrices. > > Am I missing something? This is a wild guess but I think ModelViewMatrix != ViewMatrix so State::getModelViewMatrix() shouldn't be the same than Camera::getViewMatrix() Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Length unit
Hi Axel, - "Axel Spirtaat" a écrit : > Hi Torben, > thanks for your answer. I imagined it, but when i loaded the cow model > in my scene, the model was bigger than my room (that is, 8x5x3), so > I've had this doubt :-) So the right question is : In what unit is the cow ? and the room ? -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to texture 3D
Hi Julien,
It's me that submitted this change at
http://www.mail-archive.com/osg-submissions@lists.openscenegraph.org/msg05568.html
It's hard to tell what's going wrong without the full code of your camera setup.
In http://www.opengl.org/registry/specs/ARB/geometry_shader4.txt
error 0x8da8 refers to FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_ARB and the
document has possible cause for this error.
Regards,
-Fred
- "Julien Valentin" a écrit :
> Hi,
> I'm trying to make efficient fluid simulation with osg
> I've just found this page :
> http://www.mail-archive.com//msg05568.html
>
> It look pretty great as my 1 camera per slice code is very CPU time
> consuming.
>
> I develop a geometry shader that change gl_layer value per primitive.
> It work so i change my texture my texture attachement to camera's FBO
> as follow:
>
> Code:
>
> for(int i=0;i<_depth;i++){
> //one cam per slice
> _cameras[i]->attach( osg::Camera::COLOR_BUFFER,tex,0,i,false);
> }
>
> to
>
> for(int i=0;i<1;i++){
> //one overalll camera
> _cameras[0]->attach(
> osg::Camera::COLOR_BUFFER,tex,0,osg::Camera::FACE_CONTROLLED_BY_GEOMETRY_SHADER);
> }
>
> But this change make a crash:
>
>
> Code:
>
> RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8da8
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to texture 3D
I used
camera->setImplicitBufferAttachmentMask(
osg::Camera::IMPLICIT_COLOR_BUFFER_ATTACHMENT,
osg::Camera::IMPLICIT_COLOR_BUFFER_ATTACHMENT );
to avoid having a depth buffer attached.
HTH
Regards,
-Fred
- "Julien Valentin" a écrit :
> Thank for your answer:
> I've manage to make it work in pure GL3 without osg and see that your
> tweak in osg is the right thing to do.
> However it always doesnt work..
> here are the different GL call for fbo creation for 2 case:
>
> -working case (only one slice)
> cam->attach( osg::Camera::COLOR_BUFFER0,tex,0,0)
>
> Code:
> glGenRenderbuffersEXT(1, 048DEA40)
> | glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, 1)
> | glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT,
> GL_DEPTH_COMPONENT24_SGIX, 64, 64)
> | glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT,
> GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, 1)
> //render to only one slice
> | glFramebufferTexture3DEXT(GL_FRAMEBUFFER_EXT,
> GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_3D, 3, 0, 0)
> | glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT)
> | glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 1)
>
>
>
> -the FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS case with
> cam->attach(
> osg::Camera::COLOR_BUFFER0,tex,0,osg::Camera::FACE_CONTROLLED_BY_GEOMETRY_SHADER)
>
> Code:
>
> | glGenRenderbuffersEXT(1, 0484EA40)
> | glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, 1)
> | glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT,
> GL_DEPTH_COMPONENT24_SGIX, 64, 64)
> | glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT,
> GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, 1)
> //render to all slice
> | glFramebufferTextureEXT(GL_FRAMEBUFFER_EXT,
> GL_COLOR_ATTACHMENT0_EXT, 3, 0)
> | glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT)
>
>
>
> All seems right but error occurs on glCheckFramebufferStatusEXT..
>
>
> Further, my working version (pure GL3) dont initialize RenderBuffer
> with GL_DEPTH_COMPONENT24_SGIX, but with GL_RGBA
>
> Could it be a problem with it? Strange because it dont bother the
> "only one slice" version...
>
> Could it be because I use CORE 330 shaders?
>
> Please help
>
>
> Frederic Bouvier wrote:
> > Hi Julien,
> >
> > It's me that submitted this change at
> > http://www.mail-archive.com//msg05568.html
> >
> > It's hard to tell what's going wrong without the full code of your
> camera setup.
> > In http://www.opengl.org/registry/specs/ARB/geometry_shader4.txt
> > error 0x8da8 refers to FRAMEBUFFER_INCOMPLETE_LAYER_TARGETS_ARB and
> the
> > document has possible cause for this error.
> >
> > Regards,
> > -Fred
> >
> >
> > - "Julien Valentin" a écrit :
> >
> >
> > > Hi,
> > > I'm trying to make efficient fluid simulation with osg
> > > I've just found this page :
> > > http://www.mail-archive.com//msg05568.html
> > >
> > > It look pretty great as my 1 camera per slice code is very CPU
> time
> > > consuming.
> > >
> > > I develop a geometry shader that change gl_layer value per
> primitive.
> > > It work so i change my texture my texture attachement to camera's
> FBO
> > > as follow:
> > >
> > > Code:
> > >
> > > for(int i=0;i<_depth;i++){
> > > //one cam per slice
> > > _cameras[i]->attach( osg::Camera::COLOR_BUFFER,tex,0,i,false);
> > > }
> > >
> > > to
> > >
> > > for(int i=0;i<1;i++){
> > > //one overalll camera
> > > _cameras[0]->attach(
> > >
> osg::Camera::COLOR_BUFFER,tex,0,osg::Camera::FACE_CONTROLLED_BY_GEOMETRY_SHADER);
> > > }
> > >
> > > But this change make a crash:
> > >
> > >
> > > Code:
> > >
> > > RenderStage::runCameraSetUp(), FBO setup failed, FBO status=
> 0x8da8
> > >
> > ___
> > osg-users mailing list
> >
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> >
> > --
> > Post generated by Mail2Forum
>
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=35027#35027
>
>
>
>
>
> ___
> 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] BIND_PER_PRIMITIVE broken?
Hi Sukender,
> Actually, OpenGL can do this binding (even if it's slow), so why not
> supporting it if it's not that difficult? Should we name it
> differently?
it is my understanding that OpenGL can only do BIND_PER_VERTEX natively.
There is no such thing as a face normal or color. There is only linear
interpolation between values at vertices. So when you share vertex data
in a primitive, you can only share also normal, color and other attributes.
So emulating hypothetical BIND_PER_FACE requires a change in primitive
type for STRIP and FAN
Regards,
-Fred
- "Sukender" a écrit :
> Hi all,
>
> Interesting discusssion. I didn't guess that it wouyld bring so much
> comments!
>
> Well this cannot be a regression as I'm implementing it! I just need
> to make it work "the old style" way.
> However, I would expect that a primitive is one of {point, line,
> triangle, quad}, even id OpenGL says a strip is also a primitive (is
> there a naming issue there? Should we have something like "elements",
> "primitive" and "primitive set"???). So, for me, PER_PRIMITIVE is a
> binding for them, and PER_PRIMITIVE_SET is a binding for a "bunch" of
> them :
> TRIANGLES, TRIANGLE_STRIP, TRIANGLE_FAN : primitive = one triangle /
> primitive set = all triangles
> QUADS, QUAD_STRIP : primitive = one quad / primitive set = all quads
> Once again, that's only my point of view.
>
> Actually, OpenGL can do this binding (even if it's slow), so why not
> supporting it if it's not that difficult? Should we name it
> differently?
>
> Thank you all for your comments and ideas.
> Cheers,
>
> Sukender
> PVLE - Lightweight cross-platform game engine -
> http://pvle.sourceforge.net/
>
> - "Jason Daly" a écrit :
>
> > On 1/8/2011 6:19 AM, Robert Osfield wrote:
> > > Hi All,
> > >
> > > Perhaps we should be asking the question what was the behavior
> > prior
> > > to the refactor to I did for GL3/OpenGLES support. Sukender did
> > your
> > > Geometry work previously? Is this a regression or just a
> behaviour
> > > that you weren't expecting?
> >
> > Good question!
> >
> > ---
> >
> > Somehow I missed Wojtek's post, so I'll reply to that here:
> >
> > >> glBegin(GL_TRIANGLE)/glEnd() code with 2 triangles and one
> normal.
> > It will
> > >> be correct OpenGL code. Would you say that two triangles
> correspond
> > to one
> > >> OSG primitive or two OSG primitves in this case ? And if you do
> not
> > pass
> > >> normal before second triangle, OpenGL will use last normal passed
> > (ie the
> > >> one from first triangle):
> > >>
> > >> glBegin(GL_TRIANGLE);
> > >> glNormal3f(...);
> > >> glVertex3f(...); //1
> > >> glVertex3f(...); //2
> > >> glVertex3f(...); //3
> > >> // no normal and its no error !
> > >> glVertex3f(...); //4
> > >> glVertex3f(...); //5
> > >> glVertex3f(...); //6
> > >> glEnd();
> >
> > It's two primitives. Yes, you can use the same normal for two
> > separate
> > triangles, but that doesn't mean it's not two primitives. Actually
> > your
> > code is slightly incorrect, the glBegin() line should read:
> >
> > glBegin(GL_TRIANGLES);
> >
> > I'm not pointing this out just to be pedantic. It's evidence to
> > support
> > my position that it's actually two primitives (i.e.: two triangles)
> > in
> > that case :-)
> >
> >
> > >> In the same way OpenGL assumes that last passed normal is used
> for
> > the
> > >> triangle in triangle strip. Triangle Srip is just another method
> of
> > passing
> > >> vertices to OpenGL and each triangle may have its own unique
> > normals/colors.
> > >> If you don't agree, just do a reverse test: see if below would
> > render both
> > >> triangles with the same color or different colors. They will
> > differ, and
> > >> this is also correct OpenGL code:
> > >>
> > >> glShadeModel( GL_FLAT );
> > >> glBegin(GL_TRIANGLE_STRIP);
> > >> glColor4f( 1, 0, 0, 1 ); // RED
> > >> glVertex3f(0, 0, 0);
> > >> glVertex3f(0, 1, 0);
> > >> glVertex3f(1, 0, 0);
> > >> glColor4f( 0, 1, 0, 1 ); // GREEN
> > >> glVertex3f(1, 1, 0);
> > >> glEnd();
> >
> > Yes, I mentioned that in my previous post. It doesn't take away
> from
> >
> > the fact that the triangle strip is considered a single primitive.
> >
> > I actually wonder what the colors would look like here. Did you
> > actually run this code? My guess would be that the final vertex is
> > green, but the final triangle would blend from red to green across
> its
> >
> > surface, because its two other vertices were red (as specified in
> the
> >
> > code). I could be wrong (I haven't run the code myself), but
> that's
> >
> > what I would expect. Even if you consider each triangle in the
> strip
> > a
> > different "primitive", you still couldn't get a set of completely
> red
> >
> > triangles, followed by a completely green triangle, which is what
> the
> > OP
> > is looking for.
> >
> > >> Last argument is actually a postulate for OSG clarity. We have
> > >> BIND_PER_PRIMITIVE_SET flag. S
Re: [osg-users] Need Help ! How to get Camera Position inside shaders
Hi Laith, OSG defines the osg_ViewMatrixInverse uniform. You have to add uniform mat4 osg_ViewMatrixInverse; in your shader to use it and find the camera location in world coordinates. Otherwise, there is the gl_ModelViewMatrixInverse uniform if you want to transform the camera position from eye coordinates (0,0,0) into local object coordinates. Regards, -Fred - "Robert Osfield" a écrit : > Hi Laith, > > In OpenGL the camera position is always at 0,0,0, and the scene is > transformed into cameras coordinates by the modelview matrix. > > So... one has to ask are you wanting to do calculations in the > eye/camera coordinates, world coordinates or local object > coordinates? > You can transform the camera position into world or local object > coordinates by multipling by the inverse of the view or modelview > matrices respectively. > > Robert. > > On Thu, Jan 13, 2011 at 6:34 AM, Laith Dhawahir > wrote: > > Heey Guys, > > I hope you will fine, > > anyway, i have question about how i can get the camera position > inside shader from open scene graph do i must pass it, or open scene > graph already do that. > > > > Thank you! > > > > Cheers, > > Laith > > > > -- > > Read this topic online here: > > http://forum.openscenegraph.org/viewtopic.php?p=35600#35600 > > > > > > > > > > > > ___ > > 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] wrong calculation of bounding box
Hi John,
> De: "John Doves"
>
> Wrong calculation a bounding box of model which contains biped or bones. I'm
> used this code to calculate bounding box:
>
> Code:
>
> model = (osg::Geode*) osgDB::readNodeFile("testmodel.fbx");
>
> //calculating bounding box of model
> osg::ComputeBoundsVisitor cbbv;
> model->accept(cbbv);
>
> osg::BoundingBox bb = cbbv.getBoundingBox();
> osg::Vec3f sz = bb._max - bb._min;
>
>
> It returns double size of model which contains biped or bones. If model
> without biped or bones the size as expected. Does anyone have idea why so?
Maybe because mixing bounding boxes and bounding spheres inflate the result. I
did this diagram several month ago :
http://frbouvi.free.fr/flightsim/bounding_sphere.jpg
Regards,
-Fred
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Sharing depth buffer between fbos
Hi All, I need to initialize the content of the depth buffer of a FBO with the result of a RTT pass where I setup a DEPTH_ATTACHMENT to a depth texture. IOW, I want two fbos with the same depth buffer, the second being read only. AFAICS in gDebugger, the attachment to the second fbo cancels the attachment to the first. The only method I can think of at the moment, is to render a screen aligned quad with the depth texture bound to it and use a fragment shader to initialize the depth buffer of the second fbo using gl_FragDepth. So what do you think of that and how would you do something like that ? Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing depth buffer between fbos
Hi Sebastian, I am using slave cameras with different render order num. Are your cameras both using a different fbo (both calling setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT) ) , or your second camera is a child of the one with an fbo ? Regards, -Fred - Mail original - De: "Sebastian Messerschmidt" À: "OpenSceneGraph Users" Cc: "Frederic Bouvier" Envoyé: Lundi 5 Décembre 2011 17:02:17 Objet: Re: [osg-users] Sharing depth buffer between fbos Hi Frederic, I'm using a similar setup. I simply attach the the depth-buffer-texture to the first RTT pass and later on bind it to multiple passes that need to have depth writes disabled. This way everything works as expected. My RTT cameras are childs of the root node of the scene. Setting the render order of the cameras explicitly did the trick for me. cheers Sebastian > Hi All, > > I need to initialize the content of the depth buffer of a FBO with the result > of a RTT pass where I setup a DEPTH_ATTACHMENT to a depth texture. > IOW, I want two fbos with the same depth buffer, the second being read only. > AFAICS in gDebugger, the attachment to the second fbo cancels the attachment > to the first. > The only method I can think of at the moment, is to render a screen aligned > quad with the depth texture bound to it and use a fragment shader to > initialize the depth buffer of the second fbo using gl_FragDepth. > > So what do you think of that and how would you do something like that ? > > Regards, > -Fred > ___ > 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] Sharing depth buffer between fbos
I double checked and it appears to work now. I guess I have not tried hard enough the first time. Thank you -Fred - Mail original - De: "Sebastian Messerschmidt" Objet: Re: [osg-users] Sharing depth buffer between fbos They are set up in the exact same way. So both are using frame buffer objects. As I said, it is important to set the second camera to NOT write to depth buffer. It might be coincidence, but I just use Nvidia cards, so this might be a "specialty" of Nvidia drivers. cheers Sebastian > Hi Sebastian, > > I am using slave cameras with different render order num. > Are your cameras both using a different fbo (both calling > setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT) ) , or your second > camera is a child of the one with an fbo ? > > Regards, > -Fred > > > - Mail original - > De: "Sebastian Messerschmidt" > Objet: Re: [osg-users] Sharing depth buffer between fbos > > Hi Frederic, > > I'm using a similar setup. I simply attach the the depth-buffer-texture > to the first RTT pass and later on bind it to multiple passes that need > to have depth writes disabled. > This way everything works as expected. > My RTT cameras are childs of the root node of the scene. > Setting the render order of the cameras explicitly did the trick for me. > > cheers > Sebastian >> Hi All, >> >> I need to initialize the content of the depth buffer of a FBO with the >> result of a RTT pass where I setup a DEPTH_ATTACHMENT to a depth texture. >> IOW, I want two fbos with the same depth buffer, the second being read only. >> AFAICS in gDebugger, the attachment to the second fbo cancels the attachment >> to the first. >> The only method I can think of at the moment, is to render a screen aligned >> quad with the depth texture bound to it and use a fragment shader to >> initialize the depth buffer of the second fbo using gl_FragDepth. >> >> So what do you think of that and how would you do something like that ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VS2010 64bit compile problem
Hi Peter, Le 04/01/2012 10:52, Peter Bako a écrit : > Hi, > > I get errors, when I try to compile my project on visual studio for 64bit > platform. Before on ANYCPU configurations I had no problems. The error which > I get is > > variable "WINGDIAPI" is not a type name > c:\program files (x86)\microsoft sdks\windows\v7.0a\include\gl\gl.h > > and other 150 errors because of this "wingdiapi". > > I changed the platform, preprocessor definitions to WIN64;_WIN64;_DEBUG, the > path to 64bit dlls, libs and include directory. > > What else should I change? > > I am sending my project in the attachment. > > One more question: Is there any performance or other advantage if compiled > for 64bit instead of anyCPU? > > Thank you! There is no attachment to this thread, but IIRC, AnyCPU is a C# thing, not C++ If you are really compiling C++, then, as Mourad said, be sure you included before Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Separate rendering of renderbins
Hi Sebastian,
> De: Sebastian Messerschmidt
>
> I know this question has been asked before, but I didn't extract
> enough information out of the answers to understand it fully.
> What I want to achive seems simple. I have separate renderpasses with
> the same viewpoint to render different parts of the scene to different
> rendertargets.
> For example I need to split the opaque parts from the transparent/
> translucent ones.
> Right now, I'm using nodemasks on the cameras an respective parts of
> the scene. Unfortunally this brings two major problems:
> 1. Everything has to traversed/culled more by every camera. So if the
> scenegraph is large and complex with node masks only near the leaves,
> the accumulated cull time will be a problem.
> 2. If a geode has transparent and opaque parts it is impossible to do
> it correctly, as drawables are "second" class nodes i.e. don't carry
> nodemasks.
>
> So right now I'm splitting up geodes with different renderbins an
> reorder them. Naturally this can have a huge impact on the scene, as
> it get cluttered at the bottom effectively cutting my framerate in
> certain scenes to half and below.
> The idea I had in the last day would like this (in a rather abstract
> way):
>
> Cull the scene once and let different cameras use different
> renderbins to render to their target.
>
>
>
> Now my problem is, that I don't know where to start with this, or if
> there are some things in OSG that might even allow this naturally.
I am currently converting FlightGear to deferred rendering. See
http://wiki.flightgear.org/Project_Rembrandt for pointers and a log
of the conversion (and videos)
To address this particular problem, I have a first camera that
traverse the scenegraph to initialize the MRT buffers and another
camera that is used to render lighting. Both have the same view and
projection matrix and share the same depth buffer. Ambient light,
sun lighting, fog and bloom are rendered with additive blending
by drawing screen aligned quads while point and spot lights are
rendered like normal geometry (the light volume is then drawn).
So I can remove transparent bins from the renderstage of the first
camera and inject them in the renderstage of the second. I do that
with the code below :
As a global variable :
osgUtil::RenderBin::RenderBinList savedTransparentBins;
In the cull callback of the geometry camera (the one that traverse the
scenegraph) :
virtual void operator()( osg::Node *n, osg::NodeVisitor *nv)
{
osgUtil::CullVisitor* cv = static_cast(nv);
osg::Camera* camera = static_cast(n);
savedTransparentBins.clear();
cv->traverse( *camera );
// Save transparent bins to render later
osgUtil::RenderStage* renderStage = cv->getRenderStage();
osgUtil::RenderBin::RenderBinList& rbl =
renderStage->getRenderBinList();
for (osgUtil::RenderBin::RenderBinList::iterator rbi = rbl.begin(); rbi
!= rbl.end(); ) {
if (rbi->second->getSortMode() ==
osgUtil::RenderBin::SORT_BACK_TO_FRONT) {
savedTransparentBins.insert( std::make_pair( rbi->first,
rbi->second ) );
rbl.erase( rbi++ );
} else {
++rbi;
}
}
}
In the cull callback of the camera that should display transparent
objects :
virtual void operator()( osg::Node *n, osg::NodeVisitor *nv)
{
simgear::EffectCullVisitor* cv =
dynamic_cast(nv);
osg::Camera* camera = static_cast(n);
cv->traverse( *camera );
//
// Render saved transparent render bins
osgUtil::RenderStage* renderStage = cv->getRenderStage();
osgUtil::RenderBin::RenderBinList& rbl =
renderStage->getRenderBinList();
for (osgUtil::RenderBin::RenderBinList::iterator rbi =
savedTransparentBins.begin();
rbi != savedTransparentBins.end(); ++rbi ){
rbl.insert( std::make_pair( rbi->first + 1, rbi->second ) );
}
info->savedTransparentBins.clear();
}
For this to work correctly, we need the contribution of artists to flag the
really transparent objects and put them in transparent bins. The other (non
flagged) objects are put unconditionally in the normal RenderBin (with
alpha test enabled) because many part of a model are opaque but use a
texture atlas with alpha channel and the transparency detection from the
loader plugging is not reliable enough, resulting in a lot of false
positive (opaque object treated as transparent and incorrectly lit).
HTH
Regards,
-Fred
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fwd: Ambient Occlusion Implementation 2 review
Hi Robert, Le 10/02/2012 16:45, Robert Osfield a écrit : > Hi Adrian, > > I've not got most of the way through my submissions backlog - can > finally see the light at the end of the tunnel :-) So I'm now in much > better place to start looking at your Ambient Occlusion work. Do you > have any updates to the source since the your code drop on the 21st of > December? If you have any papers or webpages that explain the > approach I'd welcome pointers to these as well. Adrian posted this link : http://webaddon3d.assoftware.ch/AE/SSAO/GPUPro2_Proposal_Adrian_Egli_CUBIC_SPLINE_BASED_AMBIENT_OCCLUSION.rar (tested today) there is a pdf file in it that describes his algorithm. Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shadows and LOD
Hi, FlightGear now includes a deferred renderer that produce shadows. As the lighting is done from a Gbuffer in a fullscreen quad render, I can't (correct me if I'm wrong) use osgShadow. So in my implementation, I render the geometry of the whole scenegraph to a depth texture using an orthographic projection in the direction of the light. The view matrix sets the sun position at 1m from a position ahead of the viewer. But when the viewer is near an object that has a LOD node that has a range of 0 - 9000m, the model is not renderer in the shadow map and the viewer doesn't see a shadow. So the question : is there special code in osgShadow that address this kind of situation : a LOD range for the viewer unsuitable for the light source ? I tried to override the LOD::traverse method in a specific cull visitor that calls Group::traverse instead, but I was said it is a bad thing, and I can understand it breaks PagedLOD and any descendant too. Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and LOD
Thank you Robert, may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? Or does it inherit the viewpoint of the master camera ? Regards, -Fred > De: Robert Osfield > > Hi Fred, > > The osg::Camera has support for setting the reference frame so that it > inherits the viewpoint for LOD calculation so that you get the same > LOD's for your render to texture pass as you would for your main view. > In osgShadow you'll this used and set up thus: > >_camera->setReferenceFrame(osg::Camera::ABSOLUTE_RF_INHERIT_VIEWPOINT); > >This doesn't require any other changes so no need to try Sergey's > suggestion of LODScale() which would achieve rather different results. > > Robert. On 2 April 2012 13:12, Frederic Bouvier wrote: > Hi, > > FlightGear now includes a deferred renderer that produce shadows. As the > lighting is done from a Gbuffer in a fullscreen quad render, I can't (correct > me if I'm wrong) use osgShadow. > > So in my implementation, I render the geometry of the whole scenegraph to a > depth texture using an orthographic projection in the direction of the light. > The view matrix sets the sun position at 1m from a position ahead of the > viewer. But when the viewer is near an object that has a LOD node that has a > range of 0 - 9000m, the model is not renderer in the shadow map and the > viewer doesn't see a shadow. > > So the question : is there special code in osgShadow that address this kind > of situation : a LOD range for the viewer unsuitable for the light source ? > > I tried to override the LOD::traverse method in a specific cull visitor that > calls Group::traverse instead, but I was said it is a bad thing, and I can > understand it breaks PagedLOD and any descendant too. > > Regards, > -Fred > ___ > 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] Shadows and LOD
> On 2 April 2012 14:21, Frederic Bouvier wrote: >> may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? >> Or does it inherit the viewpoint of the master camera ? > >The OSG inherits state/settings from parents, there isn't any sibling >inheritance. Ok, thank you. I was a bit clueless until now about the use of the ABSOLUTE_RF_INHERIT_VIEWPOINT purpose. Maybe it's explained in Wang Rui's book. I will dive in the OSG source with that in mind Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and LOD
Hi Robert, > On 2 April 2012 14:21, Frederic Bouvier wrote: >> may I ask how a camera can inherit the viewpoint of a sister (slave) camera ? >> Or does it inherit the viewpoint of the master camera ? > >The OSG inherits state/settings from parents, there isn't any sibling >inheritance. One more thing: it happens that I implement cascaded shadow map with a single shadow map and 4 cascades. My scenegraph is like this : master camera => slave shadow camera (hold an fbo on a S x S depth texture) => cascade1 : child camera, viewport (S/2 x S/2 @ 0, 0) => cascade2 : child camera, viewport (S/2 x S/2 @ 0, S/2) => cascade3 : child camera, viewport (S/2 x S/2 @ S/2, 0) => cascade4 : child camera, viewport (S/2 x S/2 @ S/2, S/2) I want to know if the inherited viewpoint is propagated to the cascade camera if I set the reference frame of the main shadow camera and the 4 cascades to ABSOLUTE_RF_INHERIT_VIEWPOINT Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows and LOD
Hi Robert, > > On 2 April 2012 14:21, Frederic Bouvier wrote: > >> may I ask how a camera can inherit the viewpoint of a sister (slave) > >> camera ? > >> Or does it inherit the viewpoint of the master camera ? > > > >The OSG inherits state/settings from parents, there isn't any sibling > >inheritance. > > One more thing: it happens that I implement cascaded shadow map with a single > shadow map and 4 cascades. My scenegraph is like this : > > master camera > => slave shadow camera (hold an fbo on a S x S depth texture) >=> cascade1 : child camera, viewport (S/2 x S/2 @ 0, 0) >=> cascade2 : child camera, viewport (S/2 x S/2 @ 0, S/2) >=> cascade3 : child camera, viewport (S/2 x S/2 @ S/2, 0) >=> cascade4 : child camera, viewport (S/2 x S/2 @ S/2, S/2) > > I want to know if the inherited viewpoint is propagated to the cascade camera > if I set the reference frame of the main shadow camera and the 4 cascades to > ABSOLUTE_RF_INHERIT_VIEWPOINT to complement the question, I am asking myself if the code in SceneView::cullStage line 972 of SceneView.cpp (v3.0.1) that reads : cullVisitor->pushModelViewMatrix(mv.get(),osg::Transform::ABSOLUTE_RF); is right. It seems to ignore the reference frame settings of the slave camera and assume ABSOLUTE_RF. Should I manually set the viewpoint of my main shadow camera ? and how ? Regards, -Fred ___ 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] Shadows and LOD
> > > On 2 April 2012 14:21, Frederic Bouvier wrote: > > >> may I ask how a camera can inherit the viewpoint of a sister (slave) > > >> camera ? > > >> Or does it inherit the viewpoint of the master camera ? > > > > > >The OSG inherits state/settings from parents, there isn't any sibling > > >inheritance. > > > > One more thing: it happens that I implement cascaded shadow map with a > > single > > shadow map and 4 cascades. My scenegraph is like this : > > > > master camera > > => slave shadow camera (hold an fbo on a S x S depth texture) > >=> cascade1 : child camera, viewport (S/2 x S/2 @ 0, 0) > >=> cascade2 : child camera, viewport (S/2 x S/2 @ 0, S/2) > >=> cascade3 : child camera, viewport (S/2 x S/2 @ S/2, 0) > >=> cascade4 : child camera, viewport (S/2 x S/2 @ S/2, S/2) > > > > I want to know if the inherited viewpoint is propagated to the cascade > > camera > > if I set the reference frame of the main shadow camera and the 4 cascades > > to > > ABSOLUTE_RF_INHERIT_VIEWPOINT > > to complement the question, I am asking myself if the code in > SceneView::cullStage > line 972 of SceneView.cpp (v3.0.1) that reads : > > cullVisitor->pushModelViewMatrix(mv.get(),osg::Transform::ABSOLUTE_RF); > > is right. It seems to ignore the reference frame settings of the slave camera > and > assume ABSOLUTE_RF. Should I manually set the viewpoint of my main shadow > camera ? > and how ? to end my jabber, and for the record, I fixed my issue by setting the reference frame of the main shadow camera to ABSOLUTE_RF and a dummy view matrix where the eye point is at viewer's position. This view matrix is updated every frame. Cascade cameras use ABSOLUTE_RF_INHERIT_VIEWPOINT reference frame. Initially my cascade was not drawn because the frustum culling on the main camera was in the way, so instead of setting a projection volume that enclose the 4 volumes of its child, I disable culling with setCullingMode(NO_CULLING) Hope that can help Regards, -Fred ___ 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] Primitive Restart
Hi Robert, as I understand it, this feature enables one to put unconnected strips in a single primitive, while degenerated triangles may add a line between the end of a strip and the next. Regards, -Fred - Mail original - De: "Robert Osfield" À: "OpenSceneGraph Users" Envoyé: Mardi 3 Avril 2012 15:34:02 Objet: Re: [osg-users] Primitive Restart Hi Felix, Is there any reason why you can't just connect the tri strips together using a repeated indices to create a degenerate triangle that connects two strips together. This way you can put multiple tri strips into a single DrawElementUShort and avoid the heavy cost of lots of separate OpenGL calls. Using this approach just requires some post processing of the osg::Geometry rather than changes to the core OSG. The combining of tri strips this way will also perform better and use less memory. Robert. On 2 April 2012 00:25, Felix Nawothnig wrote: > Hey. > > Now comes a non-trivial one... :-) > > A while ago I added support for primitive restart to our internal > build to stitch triangle strips - this greatly improved performance > and VRAM usage for our very heavy CAD data. As primitive restart was > included in GL core a while a ago I suppose this feature has a chance > to be included in OSG. > > I havn't prepared a patch yet (mostly because I don't want to waste > the time in case this isn't going to be integrated anyway), so I'll > just outline what I did: > > - osg::DrawElements and friends got two new attributes, > PrimitiveRestart (bool) and PrimitiveRestartIndex (unsigned integer) > - osg::State was extended to allow setting the respective GL attributes > - The osg::PrimitiveFunctor and osg::PrimitiveIndexFunctor interfaces > were extended by a primitiveRestart() and setPrimitiveRestart(bool, > unsigned int) method > - osg::TriangleIndexFunctor was extended to implement the new functionality > > ... and all other PrimitiveFunctor / PrimitiveIndexFunctor > implementations everywhere were extended to support primitive restart. > > (I also have a visitor stitching strips which are contained in > seperate primitive sets but I did that outside of OSG ... if PS > support is included I suspect it might be useful to have a visitor to > do this in osgUtil somewhere too) > > So... should I prepare a patch? > > Cheers, > > Felix > ___ > 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] Multiple GPU/monitor issue on Windows 7/NVidia
Hi, I am pretty sure it has been discussed before, but I am unable to retrieve the right thread, so ... I have a dual card setup, each driving a single monitor. When I start osgViewer, the viewer span on both screen, an initial image is displayed on both too, but only the primary display is updated when I change the camera view with the mouse. Clicking on the frozen screen and then on the live screen update the image on the frozen screen but only for one frame. I have the last WHDL NVidia driver. Cards are 2 GF GTX470 and I tried with and without SLI enabled. The same problem occurs in a multiscreen setup of FlightGear. Any idea ? Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple GPU/monitor issue on Windows 7/NVidia
Hi Paul, I should have stated that I am using OSG 3.0.1. Is there a fix in a development release ? Regards, -Fred - Mail original - De: "Paul Martz" I thought this was an old issue already fixed. Are you saying this is still occurring on the current OSG trunk? What versions of OSG have you tested? -Paul On 5/19/2012 9:03 AM, Frederic Bouvier wrote: > Hi, > > I am pretty sure it has been discussed before, but I am unable to retrieve the > right thread, so ... > > I have a dual card setup, each driving a single monitor. When I start > osgViewer, > the viewer span on both screen, an initial image is displayed on both too, but > only the primary display is updated when I change the camera view with the > mouse. Clicking on the frozen screen and then on the live screen update the > image on the frozen screen but only for one frame. > > I have the last WHDL NVidia driver. Cards are 2 GF GTX470 and I tried with and > without SLI enabled. The same problem occurs in a multiscreen setup of > FlightGear. > > Any idea ? > > Regards, > -Fred > > ___ > 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] Multiple GPU/monitor issue on Windows 7/NVidia
Paul, I see the same issue with 3.1.2 Regards, -Fred - Mail original - De: "Frederic Bouvier" À: "OpenSceneGraph Users" Envoyé: Dimanche 20 Mai 2012 10:10:42 Objet: Re: [osg-users] Multiple GPU/monitor issue on Windows 7/NVidia Hi Paul, I should have stated that I am using OSG 3.0.1. Is there a fix in a development release ? Regards, -Fred - Mail original - De: "Paul Martz" I thought this was an old issue already fixed. Are you saying this is still occurring on the current OSG trunk? What versions of OSG have you tested? -Paul On 5/19/2012 9:03 AM, Frederic Bouvier wrote: > Hi, > > I am pretty sure it has been discussed before, but I am unable to retrieve the > right thread, so ... > > I have a dual card setup, each driving a single monitor. When I start > osgViewer, > the viewer span on both screen, an initial image is displayed on both too, but > only the primary display is updated when I change the camera view with the > mouse. Clicking on the frozen screen and then on the live screen update the > image on the frozen screen but only for one frame. > > I have the last WHDL NVidia driver. Cards are 2 GF GTX470 and I tried with and > without SLI enabled. The same problem occurs in a multiscreen setup of > FlightGear. > > Any idea ? > > Regards, > -Fred > > ___ > 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple GPU/monitor issue on Windows 7/NVidia
Hi Wojciech, Thank you for taking the time to reply to my question. I made some progress. First I use only one monitor per GPU because I need color calibration for my photography work and the Windows architecture has only one LUT per card. But I temporarily hooked up the second monitor to the first card and activated SLI. The same issue occurs in osgViewer : only the primary display is refreshed. But FlightGear has a handy configuration system where we can setup windows/graphic contexts and cameras separately. As you suggested, when I create only one window that span on both monitors (on screen 0) and bind the two cameras to two viewports of this window, both viewports are updated. I have a vague recollection that my setup with 1 monitor per GPU and 2 graphic contexts used to work with a 2.9 OSG. Unfortunately FlightGear has evolve in a way that it requires 3.0 but I will try to get osgViewer work with an older version. I also remember seeing submissions on the way swapping is done in OSG. Maybe there is something related Regards, -Fred - Mail original - De: Wojciech Lewandowski Hi, Frederic, I was testing similar situation on GeForces more than 2 years ago (I left the building in the meantime) and honestly don't remember if we have found 'an always working' recipee for this problem. All I remember we were somehow able to use multiple cards with multiple monitors but honestly I am not sure if this was just luck with drivers or we did some extra tricks (we tried several workarounds back then). This problem is probably related to Windows DWM screen update scheme vs NVidia optimizations and Windows 7 design that primary card renders all OpenGL contexts so second card is practically not used. I could be wrong but I believe we had most success with NVidia surround where we set up single Window spanning all monitors and this window was split into 3 or 4 viewports matching particular monitors. So I really don't have a solution but would recommend to test various options and select the best one. - Test single card dual monitor output vs dual card sli dual monitor vs dual card / dual monitor. I remember that after this test we realized it does not make sense to buy second card which is practically not used. SLI mode seemed to not bring more performence in our scenarios (this may vary for you of course). So we realized that unless we do not want to use more than 2 monitors we will not buy another card. And even with more monitors it would make sense to buy powerful card as primary and weak one as secondary adapter because it will be practically used as passthrough for graphics rendered on first one. For Surround mode it may be neccessary to use the same cards though, (don't remember exactly). Above problem only affects GeForces. Quadros provide extension which can be used to assign GPU to window. h ttp://developer.download.nvidia.com/opengl/specs/WGL_nv_gpu_affinity.txt Unfortuantely NVidia chose to not provide it for GeForces. I also believe that Radeons have introduced similar extension a year or two ago. - Do above tests with NVidia surround. - Try playing with NVidia control panel settings (threading optimization / swap method) And certainly must have options are: - Aero off / fullscreen mode to avoid DWM quirks HTH, Wojtek Lewandowski 2012/5/20 Frederic Bouvier < fredlis...@free.fr > Paul, I see the same issue with 3.1.2 Regards, -Fred - Mail original - De: "Frederic Bouvier" < fredlis...@free.fr > À: "OpenSceneGraph Users" < osg-users@lists.openscenegraph.org > Envoyé: Dimanche 20 Mai 2012 10:10:42 Objet: Re: [osg-users] Multiple GPU/monitor issue on Windows 7/NVidia Hi Paul, I should have stated that I am using OSG 3.0.1. Is there a fix in a development release ? Regards, -Fred - Mail original - De: "Paul Martz" < pma...@skew-matrix.com > I thought this was an old issue already fixed. Are you saying this is still occurring on the current OSG trunk? What versions of OSG have you tested? -Paul On 5/19/2012 9:03 AM, Frederic Bouvier wrote: > Hi, > > I am pretty sure it has been discussed before, but I am unable to retrieve > the > right thread, so ... > > I have a dual card setup, each driving a single monitor. When I start > osgViewer, > the viewer span on both screen, an initial image is displayed on both too, > but > only the primary display is updated when I change the camera view with the > mouse. Clicking on the frozen screen and then on the live screen update the > image on the frozen screen but only for one frame. > > I have the last WHDL NVidia driver. Cards are 2 GF GTX470 and I tried with > and > without SLI enabled. The same problem occurs in a multiscreen setup of > FlightGear. > > Any idea ? > >
Re: [osg-users] Ideas about a resource system, and deferred rendering framework
I was going to raise that point. Flightgear has for some years now a system where designers can express their statesets in XML files called effects. A statesets is called a "Pass" in FG (or a FG Pass is implemented with a stateset). You can add multiple passes in a Technique, allowing you to redraw the same geometry with multiple statesets (including render bins details). An effect file gathers multiple techniques that have a predicate, based on supported extensions and internal FG switches, which is evaluated at run time. The multiple techniques allow us to render the water or the urban areas differently based on user preferences and GPU capabilities. Beside that effect system, we introduced a deferred renderer called 'Rembrandt' (currently still experimental but it will be present in the next release in August) where the different stages of the renderer are also described in XML. In that XML we can add rendering buffers (textures for RTT), specify rendering orders and assign effects to stages. The default pipeline has boom and ambient occlusion that can be switched on and off at run time. If you have any question, you can consult the wiki page or ask Regards, -Fred - Mail original - De: Sergey Kurdakov Hi Wang, might be not quite a significant point, but osg based Flightgear has a ongoing Project Rembrandt http://wiki.flightgear.org/Project_Rembrandt it has some similar things done, so could serve for inspiration. Regards Sergey ___ 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] Render depth into texture with 32 bits
Hi, sourceFormat and sourceType are used if you read back the texture in CPU memory. To ease my debug in gDebugger, I use sourceType=GL_FLOAT It doesn't change how the fbo works, but I can read floats between 0 and 1 in the debugger. Regards, -Fred - Mail original - De: "Sergey Polischuk" À: "OpenSceneGraph Users" Envoyé: Mercredi 4 Juillet 2012 12:57:14 Objet: Re: [osg-users] Render depth into texture with 32 bits Hi I think if you render to fbo bit depth depends of internal texture format, in case of rendering to framebuffer idk. Cheers. 04.07.2012, 14:30, "Martin Groer" : > Hello Sergey, > > thanks, it works! :-) > > Should I change the number of depth buffer bits? GL_DEPTH_BITS is 24, so I > think it doesn't make sense to save this into 32 bit. Or is this independent > if the GL_DEPTH_BITS? > > Cheers > > Martin > > Original-Nachricht > >> Datum: Wed, 04 Jul 2012 14:13:11 +0400 >> Von: Sergey Polischuk >> An: OpenSceneGraph Users >> Betreff: Re: [osg-users] Render depth into texture with 32 bits >> Hi, Martin >> >> try this: >> >> texture2D->setSourceFormat(GL_DEPTH_COMPONENT); >> texture2D->setInternalFormat(GL_DEPTH_COMPONENT32); >> texture2D->setSourceType(GL_UNSIGNED_INT); >> >> Cheers, >> Sergey. >> >> 04.07.2012, 14:06, "Martin Groer" : >>> Hello, >>> >>> how many bits are used by the GL_DEPTH_COMPONENT? I want to render the >> depth buffer value into a texture and use the internal texture format >> GL_DEPTH_COMPONENT. I would like use 24 or 32 bits for this value so I try >> GL_DEPTH_COMPONENT24 and GL_DEPTH_COMPONENT32 as internal format, but the >> rendering doesn't work. Only the GL_DEPTH_COMPONENT works, but I don't know >> how >> many bits are used. Is the number of bits depending on the Z-Buffer? My >> Z-Buffer use 24 bits. >>> Following the error message of GL_DEPTH_COMPONENT24: >>> - >>> Using host libthread_db library "/lib64/libthread_db.so.1". >>> RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd6 >>> Warning: FrameBufferObject: could not create the FBO >>> RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x0 >>> Warning: FrameBufferObject: could not create the FBO >>> RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x0 >>> FRAGMENT glCompileShader "" FAILED >>> FRAGMENT glCompileShader "" FAILED >>> glLinkProgram "" FAILED >>> >>> Cheers >>> >>> Martin >>> ___ >>> 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 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 and .NET in Windows 7 x64
Hi, > The code works when compiling for x86 under Win7 x64. The problem is when > compiling for x64. Maybe a stupid question, but do you link with x64 version of OSG libraries ? Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Separate rendering of renderbins
Hi Sebastian, The full code is here: https://gitorious.org/fg/flightgear/blobs/next/src/Viewer/renderer.cxx#line704 I don't move renderbin-items but whole renderbins from a renderbin list to another. It seems to me that render bins contains state graphs and render leafs, so moving a render bin (or deleting one as I do now) moves or deletes associated states. Note: I now delete states associated to transparent bins generated by the geometry pass because I have a second pass (the light pass) where I draw these transparent object a second time. The code that do the move before was there : https://gitorious.org/fg/flightgear/commit/c1137f371d1bc7c36ca6ba77420e63a96b443bb8 By the way, version 2.8 of Flightgear will be released on August 17th. It contains the deferred renderer codenamed 'Rembrandt' Regards, -Fred - Mail original - De: "Sebastian Messerschmidt" À: "OpenSceneGraph Users" Cc: "Frederic Bouvier" Envoyé: Lundi 30 Juillet 2012 18:31:23 Objet: Re: [osg-users] Separate rendering of renderbins Hello Fred, I know it's been a while, but right now I really want to solve this issue. Can you give me hint on this one? The problem seems to be, that moving the renderbin-items doesn't seem to move the associated state with them. I.e. they are not rendered in the camera I attach them too. cheers Sebastian > Hello, > > I've tried the approach but it didn't quite give me the results. > As proposed I've installed the 2 cullcallbacks and moved the > transparent bin from one camera to the other. After debugging I also > saw that the transparent bin of the second camera is indeed rendered, > but somehow I think all state associated with it is messed up. E.g. > the geometry is supposed to use a special shader, which is bound to > the second camera, but it seems it is never executed. > Any further hints? > > cheers > Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Separate rendering of renderbins
> Hello Fred, > > > > Hi Sebastian, > > > > The full code is here: > > https://gitorious.org/fg/flightgear/blobs/next/src/Viewer/renderer.cxx#line704 > > I don't move renderbin-items but whole renderbins from a renderbin list to > > another. It seems to me > > that render bins contains state graphs and render leafs, so moving a render > > bin (or deleting one as > > I do now) moves or deletes associated states. > Okay, I used the code snippet you provided me and strangely i had to use > getCurrentRenderStage to get anything (instead of getRenderStage) > osgUtil::RenderStage* renderStage = cv->getCurrentRenderStage(); > So I more or less sticked to your code. I guess I'm doing something > fundamentally different with my camera setup (I'm not using > slave-cameras for instance) The master camera has nothing to render (except the GUI and the HUD). The 3d is done in slaves, and they don't use the master scene graph, only their own scene graph. > > Note: I now delete states associated to transparent bins generated by the > > geometry pass because > > I have a second pass (the light pass) where I draw these transparent object > > a second time. The > > code that do the move before was there : > > https://gitorious.org/fg/flightgear/commit/c1137f371d1bc7c36ca6ba77420e63a96b443bb8 > > > > By the way, version 2.8 of Flightgear will be released on August 17th. It > > contains the deferred > > renderer codenamed 'Rembrandt' > Okay, but this means you have to traverse the whole graph again, right? > That's exactly what I want to prevent. > My problem is a extremely spanned graph with (too) many leafes, so at > least for opaque/transparent rendering I want to avoid some costs (which > are in the order of milliseconds). The graph is traversed a second time to render lights using node masks. Initially I wanted to render only lights but as they are embedded in models, the graph is traversed again and I had the side effect of redrawing transparent objects a second time, with bogus transparency. This is only the result of my incompetence, but I found easier to cancel rendering of transparent object in the first pass. So, for now, transparent render bins are removed from cv->getRenderStage()->getRenderBinList() . That removes all the states associated to transparent geometry. One thing to note is that Rembrandt requires from modelers that they register their transparent objects by explicitly setting the render bin. If not, all objects are directed by default to the opaque render bin and alpha tested. > > I guess I'll checkout project Rembrandt again and see what you are doing > differently. > By the way: Very nice work there! Thank you Regards, -Fred > > cheers > Sebastian > > > > Regards, > > -Fred > > > > - Mail original - > > De: "Sebastian Messerschmidt" > > À: "OpenSceneGraph Users" > > Cc: "Frederic Bouvier" > > Envoyé: Lundi 30 Juillet 2012 18:31:23 > > Objet: Re: [osg-users] Separate rendering of renderbins > > > > Hello Fred, > > > > I know it's been a while, but right now I really want to solve this > > issue. Can you give me hint on this one? > > The problem seems to be, that moving the renderbin-items doesn't seem to > > move the associated state with them. I.e. they are not rendered in the > > camera I attach them too. > > > > cheers > > Sebastian > >> Hello, > >> > >> I've tried the approach but it didn't quite give me the results. > >> As proposed I've installed the 2 cullcallbacks and moved the > >> transparent bin from one camera to the other. After debugging I also > >> saw that the transparent bin of the second camera is indeed rendered, > >> but somehow I think all state associated with it is messed up. E.g. > >> the geometry is supposed to use a special shader, which is bound to > >> the second camera, but it seems it is never executed. > >> Any further hints? > >> > >> cheers > >> Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rev 13092 broke osgViewerFLTK
Hi Robert, I was reported a problem in fgrun (the flightgear launcher) where camera manipulation in the aircraft viewer is broken using OSG trunk, on Linux, but I was able to reproduce it on Windows too. This video explain the problem : http://youtu.be/xN1hTGte1EM After bisecting, I found that revision 13092 was the culprit. Then I managed to reproduce the problem using osgViewerFLTK. I had to make this change in order to generate the makefile BTW : Index: examples/CMakeLists.txt === --- examples/CMakeLists.txt (revision 13092) +++ examples/CMakeLists.txt (working copy) @@ -216,7 +216,7 @@ ENDIF() -IF (FLTK_FOUND AND FT_GL_LIBRARY) +IF (FLTK_FOUND AND FLTK_GL_LIBRARY) ADD_SUBDIRECTORY(osgviewerFLTK) ENDIF() I compared the behaviour with the one in osgViewerGLUT that works, but wasn't able to detect a significant difference. Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rev 13092 broke osgViewerFLTK
Hi Robert,
rev 13092 is a change in osgViewer::Viewer only. Your comment was :
Moved the frame() event into the event traversal after then events and their
state have been accumulated.
In the end, this whole block disappeared :
if (_eventQueue.valid())
{
osgGA::GUIEventAdapter* eventState =
getEventQueue()->getCurrentEventState();
if (getCamera()->getViewport())
{
osg::Viewport* viewport = getCamera()->getViewport();
eventState->setInputRange( viewport->x(), viewport->y(),
viewport->x() + viewport->width(), viewport->y() + viewport->height());
}
else
{
eventState->setInputRange(-1.0, -1.0, 1.0, 1.0);
}
_eventQueue->frame( getFrameStamp()->getReferenceTime() );
}
Any hint why this block should have to be removed ? Does it means it has to be
done at the application level ?
Regards,
-Fred
- Mail original -
De: Robert Osfield
Hi Frederic,
I've applied your fix to the CMakeLists.txt and installed FLTK on my
system and see the error with the camera manipulator. My guess there
is scale issue with the window coordinates and probably something is
missing from the example that should be passing on parameters to
osgViewer. I have plenty of others tasks on my plate so I'll defer to
others for tracking down this issue.
Cheers,
Robert.
On 6 September 2012 09:27, Frederic Bouvier wrote:
> Hi Robert,
>
> I was reported a problem in fgrun (the flightgear launcher) where camera
> manipulation in the aircraft viewer is broken using OSG trunk, on Linux, but
> I was able to reproduce it on Windows too. This video explain the problem :
> http://youtu.be/xN1hTGte1EM
>
> After bisecting, I found that revision 13092 was the culprit. Then I managed
> to reproduce the problem using osgViewerFLTK. I had to make this change in
> order to generate the makefile BTW :
>
>
> Index: examples/CMakeLists.txt
> ===
> --- examples/CMakeLists.txt (revision 13092)
> +++ examples/CMakeLists.txt (working copy)
> @@ -216,7 +216,7 @@
>
> ENDIF()
>
> -IF (FLTK_FOUND AND FT_GL_LIBRARY)
> +IF (FLTK_FOUND AND FLTK_GL_LIBRARY)
> ADD_SUBDIRECTORY(osgviewerFLTK)
> ENDIF()
>
>
>
> I compared the behaviour with the one in osgViewerGLUT that works, but wasn't
> able to detect a significant difference.
>
> Regards,
> -Fred
> ___
> 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] Rev 13092 broke osgViewerFLTK
Well, restoring this block at the new frame call location fix the issue :
Index: src/osgViewer/Viewer.cpp
===
--- src/osgViewer/Viewer.cpp(revision 13092)
+++ src/osgViewer/Viewer.cpp(working copy)
@@ -797,6 +797,20 @@
}
}
+
+if (_eventQueue.valid())
+{
+osgGA::GUIEventAdapter* eventState =
getEventQueue()->getCurrentEventState();
+if (getCamera()->getViewport())
+{
+osg::Viewport* viewport = getCamera()->getViewport();
+eventState->setInputRange( viewport->x(), viewport->y(),
viewport->x() + viewport->width(), viewport->y() + viewport->height());
+}
+else
+{
+eventState->setInputRange(-1.0, -1.0, 1.0, 1.0);
+}
+}
_eventQueue->frame( getFrameStamp()->getReferenceTime() );
Regards,
-Fred
- Mail original -
De: "Frederic Bouvier"
À: "OpenSceneGraph Users"
Envoyé: Jeudi 6 Septembre 2012 14:55:12
Objet: Re: [osg-users] Rev 13092 broke osgViewerFLTK
Hi Robert,
rev 13092 is a change in osgViewer::Viewer only. Your comment was :
Moved the frame() event into the event traversal after then events and their
state have been accumulated.
In the end, this whole block disappeared :
if (_eventQueue.valid())
{
osgGA::GUIEventAdapter* eventState =
getEventQueue()->getCurrentEventState();
if (getCamera()->getViewport())
{
osg::Viewport* viewport = getCamera()->getViewport();
eventState->setInputRange( viewport->x(), viewport->y(),
viewport->x() + viewport->width(), viewport->y() + viewport->height());
}
else
{
eventState->setInputRange(-1.0, -1.0, 1.0, 1.0);
}
_eventQueue->frame( getFrameStamp()->getReferenceTime() );
}
Any hint why this block should have to be removed ? Does it means it has to be
done at the application level ?
Regards,
-Fred
- Mail original -
De: Robert Osfield
Hi Frederic,
I've applied your fix to the CMakeLists.txt and installed FLTK on my
system and see the error with the camera manipulator. My guess there
is scale issue with the window coordinates and probably something is
missing from the example that should be passing on parameters to
osgViewer. I have plenty of others tasks on my plate so I'll defer to
others for tracking down this issue.
Cheers,
Robert.
On 6 September 2012 09:27, Frederic Bouvier wrote:
> Hi Robert,
>
> I was reported a problem in fgrun (the flightgear launcher) where camera
> manipulation in the aircraft viewer is broken using OSG trunk, on Linux, but
> I was able to reproduce it on Windows too. This video explain the problem :
> http://youtu.be/xN1hTGte1EM
>
> After bisecting, I found that revision 13092 was the culprit. Then I managed
> to reproduce the problem using osgViewerFLTK. I had to make this change in
> order to generate the makefile BTW :
>
>
> Index: examples/CMakeLists.txt
> ===
> --- examples/CMakeLists.txt (revision 13092)
> +++ examples/CMakeLists.txt (working copy)
> @@ -216,7 +216,7 @@
>
> ENDIF()
>
> -IF (FLTK_FOUND AND FT_GL_LIBRARY)
> +IF (FLTK_FOUND AND FLTK_GL_LIBRARY)
> ADD_SUBDIRECTORY(osgviewerFLTK)
> ENDIF()
>
>
>
> I compared the behaviour with the one in osgViewerGLUT that works, but wasn't
> able to detect a significant difference.
>
> Regards,
> -Fred
> ___
> 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rev 13092 broke osgViewerFLTK
Robert,
I don't revert the code. I moved the setInputRange block where you put
_eventQueue->frame( getFrameStamp()->getReferenceTime() );
What I don't see is if the block removal was intended or worked by accident on
most viewer and was unnoticed.
Regards,
-Fred
- Mail original -
De: "Robert Osfield"
À: "OpenSceneGraph Users"
Envoyé: Jeudi 6 Septembre 2012 15:16:01
Objet: Re: [osg-users] Rev 13092 broke osgViewerFLTK
Hi Fredric,
I made the changes to Viewer.cpp w.r.t generation of the frame event
to avoid a bug where the frame event would get the last frames X,Y,
button and key modifier settings rather than the current frames
settings, so I moved the frame generation till later.
I'm guess that the removal of the explict settings of the eventState
InputRange is probably the most likely cause for the difference with
the FLTK viewer rather than just the move of the frame disaptch till
later.
The curious thing is that why doesn't the standard OSG viewer and
other viewers exhibit the same bug as the FLTK one. Perhaps there is
some difference in how the different viewers set up/pass on the
original window dimensions. I think the correct fix will probably be
along these lines.
Just reverting the code as you have done will re-introduce a bug so is
not appropriate.
Robert.
On 6 September 2012 14:10, Frederic Bouvier wrote:
> Well, restoring this block at the new frame call location fix the issue :
>
> Index: src/osgViewer/Viewer.cpp
> ===
> --- src/osgViewer/Viewer.cpp(revision 13092)
> +++ src/osgViewer/Viewer.cpp(working copy)
> @@ -797,6 +797,20 @@
>
> }
> }
> +
> +if (_eventQueue.valid())
> +{
> +osgGA::GUIEventAdapter* eventState =
> getEventQueue()->getCurrentEventState();
> +if (getCamera()->getViewport())
> +{
> +osg::Viewport* viewport = getCamera()->getViewport();
> +eventState->setInputRange( viewport->x(), viewport->y(),
> viewport->x() + viewport->width(), viewport->y() + viewport->height());
> +}
> +else
> +{
> +eventState->setInputRange(-1.0, -1.0, 1.0, 1.0);
> + }
> +}
>
> _eventQueue->frame( getFrameStamp()->getReferenceTime() );
>
>
>
>
> Regards,
> -Fred
>
> - Mail original -
> De: "Frederic Bouvier"
> À: "OpenSceneGraph Users"
> Envoyé: Jeudi 6 Septembre 2012 14:55:12
> Objet: Re: [osg-users] Rev 13092 broke osgViewerFLTK
>
> Hi Robert,
>
> rev 13092 is a change in osgViewer::Viewer only. Your comment was :
>
> Moved the frame() event into the event traversal after then events and their
> state have been accumulated.
>
> In the end, this whole block disappeared :
>
>
> if (_eventQueue.valid())
> {
> osgGA::GUIEventAdapter* eventState =
> getEventQueue()->getCurrentEventState();
> if (getCamera()->getViewport())
> {
> osg::Viewport* viewport = getCamera()->getViewport();
> eventState->setInputRange( viewport->x(), viewport->y(),
> viewport->x() + viewport->width(), viewport->y() + viewport->height());
> }
> else
> {
> eventState->setInputRange(-1.0, -1.0, 1.0, 1.0);
> }
>
> _eventQueue->frame( getFrameStamp()->getReferenceTime() );
> }
>
>
>
>
>
> Any hint why this block should have to be removed ? Does it means it has to
> be done at the application level ?
>
> Regards,
> -Fred
>
> - Mail original -
> De: Robert Osfield
>
> Hi Frederic,
>
> I've applied your fix to the CMakeLists.txt and installed FLTK on my
> system and see the error with the camera manipulator. My guess there
> is scale issue with the window coordinates and probably something is
> missing from the example that should be passing on parameters to
> osgViewer. I have plenty of others tasks on my plate so I'll defer to
> others for tracking down this issue.
>
> Cheers,
> Robert.
>
> On 6 September 2012 09:27, Frederic Bouvier wrote:
>> Hi Robert,
>>
>> I was reported a problem in fgrun (the flightgear launcher) where camera
>> manipulation in the aircraft viewer is broken using OSG trunk, on Linux, but
>> I was able to reproduce it on Windows too. This video explain the problem :
>> http://youtu.be/xN1hTGte1EM
>>
>> After bisecting, I found that revision 13092 was the culprit. Then I managed
>> to reproduce the problem using osgViewerFLTK. I had to make this change in
>> order to gen
Re: [osg-users] Rev 13092 broke osgViewerFLTK
Hi Robert,
I confirm that the FLTK example (did not test the FOX one) works as expected
with r13136.
And, more importantly for me ;-) , the fgrun program works too.
Thank you very much
Regards,
-Fred
- Mail original -
De: "Robert Osfield"
À: "OpenSceneGraph Users"
Envoyé: Vendredi 7 Septembre 2012 11:35:30
Objet: Re: [osg-users] Rev 13092 broke osgViewerFLTK
Hi Frederic,
On 6 September 2012 15:02, Frederic Bouvier wrote:
> I don't revert the code. I moved the setInputRange block where you put
> _eventQueue->frame( getFrameStamp()->getReferenceTime() );
> What I don't see is if the block removal was intended or worked by accident
> on most viewer and was unnoticed.
I didn't include the setInputRange code when I refactor the frame
event generation as I thought it was now redundant. It turns out the
testing I did wasn't quite extensive enough though... when I was
testing out camera manipulator switching this morning I came across a
bug when going from trackball to flight or drive manipulators where
the camera would slide off to the right even without any mouse
movement. Turns out that it was the same input scale issue and adding
back in the setInputScale fixes it. I still still think it suggests
something else where isn't setting things correctly, I'll leave this
investigation for another day though. I've just applied the below
change.
Could you try our svn/trunk and let me know if the FOX example is now
working OK again?
Cheers,
Robert.
$ svn diff
Index: Viewer.cpp
===
--- Viewer.cpp (revision 13124)
+++ Viewer.cpp (working copy)
@@ -798,6 +798,17 @@
}
}
+// pass on the coorindates of the main camera to make sure the
frame event is scaled appropriately.
+if (getCamera()->getViewport())
+{
+osg::Viewport* viewport = getCamera()->getViewport();
+eventState->setInputRange( viewport->x(), viewport->y(),
viewport->x() + viewport->width(), viewport->y() +
viewport->height());
+}
+else
+{
+eventState->setInputRange(-1.0, -1.0, 1.0, 1.0);
+}
+
_eventQueue->frame( getFrameStamp()->getReferenceTime() );
___
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] Please test svn/trunk in prep for 3.1.3 developer release
Trunk build OK with MSVC 2012, at least for the plugins I am able to resolve dependencies. Regards, -Fred - Mail original - De: "Robert Osfield" À: "OpenSceneGraph Users" Envoyé: Vendredi 7 Septembre 2012 11:28:11 Objet: [osg-users] Please test svn/trunk in prep for 3.1.3 developerrelease Hi All, I plan to tag a developer release this afternoon, but before I do I'd like some feedback from testing out in the community to make sure that it's building a running OK. This dev release won't contain all the submissions that have accumulated over the last couple of months, if you one that is pending please be patient. After taking things easy w.r.t open source dev over the summer I'm now steadily going through submissions, it's quite a backlog so it'll take me a few weeks to review them all. During this period I plan to keep making dev releases rather than wait till all submissions have been processed. If you feel a submission had been missed out/overlooked please don't be shy in checking up on progress on it, sometimes submissions I've actually responded to and await a response that hasn't forth coming so it's worth checking up just in case there is something else I need from the submission. Thanks you help in test :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerfltk doesnt appear in solution
Hi Peterakos, See the small patch in this message : http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg58476.html (Included in OSG 3.1.3 BTW) Regards, -Fred - Mail original - De: "Peterakos" À: "OpenSceneGraph Users" Envoyé: Samedi 8 Septembre 2012 13:39:49 Objet: [osg-users] osgviewerfltk doesnt appear in solution Hello. I use CMake to create the openscenegraph solution Even though i set the fltk paths paths, the osgviewerfltk project doesnt appear in solution. Here are the values i set in parameters: FLTK_GL_LIBRARY: fltk 1-3-0/lib/fltkgl.lib FLTK_INCLUDE_DIR: fltk 1-3-0/include FLTK_LIBRARY: fltk 1-3-0/lib/fltk.lib What else do i have to do ? thnx. ___ 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] Ideas about a resource system, and deferred rendering framework
Hi Jeremy, De: "Jeremy Moles" > > I'm testing this out, but you appear to have left noise_tex.jpg out of > the zip. :) You should be able to use this one : https://gitorious.org/fg/fgdata/blobs/master/Textures/noise_tex.jpg ;-) Regards, -Fred ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
