Re: [osg-users] Tesselator and output primitives
Hi Albert, I've answered the same question on this list a few weeks ago. A search in the archives should get you to it. And yes, it's possible, natively. Luc De : "Aurelien Albert" A : osg-users@lists.openscenegraph.org Date: 10/10/2012 20:29 Objet : [osg-users] Tesselator and output primitives Envoyé par : osg-users-boun...@lists.openscenegraph.org Hi, I use tesselator to generate a geometry from a LINE_LOOP primitive. The tesselator output give me a TRIANGLES_FAN primitive which seems to be correct. Now I would like to get the tesselator output as TRIANGLES primitive. Is there anyway to control the primitive type built by the tesselator ? Or is there any OSG tool function / visitor that can convert TRIANGLES_FAN to TRIANGLES ? Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50551#50551 ___ 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] Cullingproblems with double used for BV.
Hi Anders,
Even with default settings the culling will be done with doubles, with
any floats being cast into doubles before tests against the view
frustum planes rather than from doubles down to floats.
I'm curious what makes you think the problem is culling. Could it be
clipping? Could it be small feature culling?
Robert,
On 10 October 2012 13:43, Anders Backman wrote:
> Hi all.
>
> Using OSG 3.0.1 under windows.
>
> A problem that we have experienced now and then without understanding the
> source of it, is that we get culling problems for scenes where objects are
> rendered far from origo.
>
>
> By default, OSG use float for representing bounding boxes, spheres etc.
> I believe I comment on this quite a few years ago related to some other
> project we were working on. So the support for double representation in BV:s
> was added.
>
> However, we still seem to have problems.
>
> Assume you want to do some rendering using ECEF coordinates, where 0,0,0 is
> at the center of the earth.
> Then you might end up with values around 6371014 meters. This is obviously
> not possible to represent in high enough precision for float.
>
> What we have been doing to avoid the culling problems is to explicitly use
> an inverse matrix which brings the coordinates used for rendering down to
> origo and multiply all transforms with this matrix.
>
> This give us problem, where in some specific camera views, some of the
> rendered (long cylinders) are suddenly culled away, moving closer/away will
> bring them back. I will try to reduce this to an OSG example...
>
>
> What we would LIKE to do, is to have a MatrixTransform with this inverse
> matrix. But this was not working before (with float BV:s), and even now with
> the cmake settings below:
>
>
> //Set to ON to build OpenSceneGraph with float BoundingBox instead
> // of double.
> OSG_USE_FLOAT_BOUNDINGBOX:BOOL=OFF
>
> //Set to ON to build OpenSceneGraph with float BoundingSphere instead
> // of double.
> OSG_USE_FLOAT_BOUNDINGSPHERE:BOOL=OFF
>
> //Set to ON to build OpenSceneGraph with float Matrix instead of
> // double.
> OSG_USE_FLOAT_MATRIX:BOOL=OFF
>
> //Set to ON to build OpenSceneGraph with float Plane instead of
> // double.
> OSG_USE_FLOAT_PLANE:BOOL=OFF
>
>
> We still see culling problems.
> However, I have not been able to break it down to a simple example
> demonstrating THIS problem.
>
> But the example below sure show some problems where for some reason, the
> coordinates are converted to float somewhere in the pipeline. Im using Vec3D
> for representing the vertices, the inverse transform is in double precision.
> Still, I get some weird rendering due to this.
>
>
> Is there anyone else rendering objects far away from origo that have a
> success-story to share?
>
> #define X_VAL 6371014
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
>
>
> osg::Node* createScene()
> {
> // create the Geode (Geometry Node) to contain all our osg::Geometry
> objects.
> osg::Geode* geode = new osg::Geode();
>
>
> // create LINES
> {
> // create Geometry object to store all the vertices and lines primitive.
> osg::Geometry* linesGeom = new osg::Geometry();
>
> // this time we'll preallocate the vertex array to the size we
> // need and then simple set them as array elements, 8 points
> // makes 4 line segments.
> osg::Vec3dArray* vertices = new osg::Vec3dArray(8);
> (*vertices)[0].set(X_VAL-1.13704, -2.15188e-09, 0.40373);
> (*vertices)[1].set(X_VAL-0.856897, -2.15188e-09, 0.531441);
> (*vertices)[2].set(X_VAL-0.889855, -2.15188e-09, 0.444927);
> (*vertices)[3].set(X_VAL-0.568518, -2.15188e-09, 0.40373);
> (*vertices)[4].set(X_VAL-1.00933, -2.15188e-09, 0.370773);
> (*vertices)[5].set(X_VAL-0.716827, -2.15188e-09, 0.292498);
> (*vertices)[6].set(X_VAL-1.07936, 9.18133e-09, 0.317217);
> (*vertices)[7].set(X_VAL-0.700348, 9.18133e-09, 0.362533);
>
>
> // pass the created vertex array to the points geometry object.
> linesGeom->setVertexArray(vertices);
>
> // set the colors as before, plus using the above
> osg::Vec4Array* colors = new osg::Vec4Array;
> colors->push_back(osg::Vec4(1.0f,1.0f,0.0f,1.0f));
> linesGeom->setColorArray(colors);
> linesGeom->setColorBinding(osg::Geometry::BIND_OVERALL);
>
> // set the normal in the same way color.
> osg::Vec3Array* normals = new osg::Vec3Array;
> normals->push_back(osg::Vec3(0.0f,-1.0f,0.0f));
> linesGeom->setNormalArray(normals);
> linesGeom->setNormalBinding(osg::Geometry::BIND_OVERALL);
>
> // This time we simply use primitive, and hardwire the number of coords
> to use
> // since we know up front,
> linesGeom->addPrimitiveSet(new
> osg::DrawArrays(osg::PrimitiveSet::LINES,0,8));
>
>
> // add the points geometry to the geode.
> geode->addDrawable(linesGeom);
> }
Re: [osg-users] Change render target from FBO to frame buffer
Hi Kenzo,
I wouldn't implement this type of management by reassigning a single
osg::Camera with different setting but use a different Camera. I
would also leave alone the master Camera and instead prefer to
add/remove slave Cameras.
My guess to why you haven't been able to do what you want is the
rendering backend data structure that is assigned to the osg::Camera
to manage the the data accumulated during the cull traversal and which
is that traversed in the draw traversal. The osg::Camera methods
relating to this data structure is:
/** Set the Rendering cache that is used for cached objects
associated with rendering of subgraphs.*/
void setRenderingCache(osg::Object* rc) { _renderingCache = rc; }
/** Get the Rendering cache that is used for cached objects
associated with rendering of subgraphs.*/
osg::Object* getRenderingCache() { return _renderingCache.get(); }
Perhaps resetting this RenderCache to 0 would do the trick.
Robert.
On 10 October 2012 22:12, Kenzo Lespagnol wrote:
> Hi,
>
> I'm trying to disable a render-to-texture by removing the slave cameras, used
> for the RTT, and by restoring the main camera. But it seems I'm not able to
> restore my main camera to render into the frame buffer again.
>
> I set the main camera to render to texture by following:
>
> Code:
> mOrginalRenderTargetImpl = mInputCamera->getRenderTargetImplementation();
> mInputCamera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT,
> osg::Camera::PIXEL_BUFFER_RTT);
> mInputCamera->attach(mAttachedBufferComponent, mSceneTexture.get(), 0, 0,
> false, antialiasing, antialiasing);
>
>
>
> And I'm restoring by this:
>
> Code:
> mInputCamera->setRenderTargetImplementation(mOrginalRenderTargetImpl);
> mInputCamera->detach(mAttachedBufferComponent);
>
>
>
> Is something I missed?
>
> Thanks.
> Kenzo
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=50555#50555
>
>
>
>
>
> ___
> 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] Cullingproblems with double used for BV.
The problem illustrated in this example is most certainly not related to
culling.
Could it be just that OpenGL handles the vertices as float?, so you
enter 6371014 as a value for a float which means that all precision is lost.
Rendering something which is a few meters on that scale, will just be
rendered incorrectly.
So having a transform at the rootnode, bringing transformation back to
origo does not help in that case.
Small feature culling is disabled.
Our main problem, which I havent been able to reduce to an osg-only-app,
show the effect of "culling artefact" in that a cylinder can be rendered at
some camera angle, but disappears at others. So its very sensitive to the
camera view...
In this case, we basically transform the coordinates (6371014) with an
inverse matrix (-6371014,0,0) to bring the vertex coordinate down close to
origo, and then give that to OSG. But even here, we get this strange
artefact of some cylinders (being generated using OSG shapes) sometimes
disappears from the view. Backing the camera one inch, and they pop back.
Its easy to generate a video, harder to isolate the problem.
Because if I save the whole scenegraph down to a osgx file, the problem is
gone.
Might be a precision problem with the xml based file (as there are just a
few decimals there for vertices/transformations).
Will try to dump to a binary too.
/A
On Thu, Oct 11, 2012 at 10:24 AM, Robert Osfield
wrote:
> Hi Anders,
>
> Even with default settings the culling will be done with doubles, with
> any floats being cast into doubles before tests against the view
> frustum planes rather than from doubles down to floats.
>
> I'm curious what makes you think the problem is culling. Could it be
> clipping? Could it be small feature culling?
>
> Robert,
>
> On 10 October 2012 13:43, Anders Backman wrote:
> > Hi all.
> >
> > Using OSG 3.0.1 under windows.
> >
> > A problem that we have experienced now and then without understanding the
> > source of it, is that we get culling problems for scenes where objects
> are
> > rendered far from origo.
> >
> >
> > By default, OSG use float for representing bounding boxes, spheres etc.
> > I believe I comment on this quite a few years ago related to some other
> > project we were working on. So the support for double representation in
> BV:s
> > was added.
> >
> > However, we still seem to have problems.
> >
> > Assume you want to do some rendering using ECEF coordinates, where 0,0,0
> is
> > at the center of the earth.
> > Then you might end up with values around 6371014 meters. This is
> obviously
> > not possible to represent in high enough precision for float.
> >
> > What we have been doing to avoid the culling problems is to explicitly
> use
> > an inverse matrix which brings the coordinates used for rendering down to
> > origo and multiply all transforms with this matrix.
> >
> > This give us problem, where in some specific camera views, some of the
> > rendered (long cylinders) are suddenly culled away, moving closer/away
> will
> > bring them back. I will try to reduce this to an OSG example...
> >
> >
> > What we would LIKE to do, is to have a MatrixTransform with this inverse
> > matrix. But this was not working before (with float BV:s), and even now
> with
> > the cmake settings below:
> >
> >
> > //Set to ON to build OpenSceneGraph with float BoundingBox instead
> > // of double.
> > OSG_USE_FLOAT_BOUNDINGBOX:BOOL=OFF
> >
> > //Set to ON to build OpenSceneGraph with float BoundingSphere instead
> > // of double.
> > OSG_USE_FLOAT_BOUNDINGSPHERE:BOOL=OFF
> >
> > //Set to ON to build OpenSceneGraph with float Matrix instead of
> > // double.
> > OSG_USE_FLOAT_MATRIX:BOOL=OFF
> >
> > //Set to ON to build OpenSceneGraph with float Plane instead of
> > // double.
> > OSG_USE_FLOAT_PLANE:BOOL=OFF
> >
> >
> > We still see culling problems.
> > However, I have not been able to break it down to a simple example
> > demonstrating THIS problem.
> >
> > But the example below sure show some problems where for some reason, the
> > coordinates are converted to float somewhere in the pipeline. Im using
> Vec3D
> > for representing the vertices, the inverse transform is in double
> precision.
> > Still, I get some weird rendering due to this.
> >
> >
> > Is there anyone else rendering objects far away from origo that have a
> > success-story to share?
> >
> > #define X_VAL 6371014
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> >
> >
> > osg::Node* createScene()
> > {
> > // create the Geode (Geometry Node) to contain all our osg::Geometry
> > objects.
> > osg::Geode* geode = new osg::Geode();
> >
> >
> > // create LINES
> > {
> > // create Geometry object to store all the vertices and lines
> primitive.
> > osg::Geometry* linesGeom = new osg::Geometry();
> >
> > // this time we'll preallocate
Re: [osg-users] Cullingproblems with double used for BV.
Hi Anders, On 11 October 2012 11:02, Anders Backman wrote: > The problem illustrated in this example is most certainly not related to > culling So... the subject line and previous dsicussion is rather misleading. > Could it be just that OpenGL handles the vertices as float? OpenGL drivers/hardware have traditionally all been in floats so even when we pass double matrices and vertices they are cast down to floats. Modern hardware can now handle doubles and whether this is accessed via standard OpenGL will be driver dependent. >, so you enter > 6371014 as a value for a float which means that all precision is lost. > Rendering something which is a few meters on that scale, will just be > rendered incorrectly. This is a pretty standard issue with precision. The way that one deals with this OpenGL precision issue with OSG applications is two fold: 1) The OSG accumulates the camera view and model matrices using double maths to retain precsion as long as possible before passing the final modelview matrix to OpenGL. 2) Create a scene graph that uses a transform node that places a subgraph in it's final world position (i.e. in ECEF) with the subgraph having a local origin so that the vertices in geometry leaves all have relatively small X,Y,Z values. This combination is how tools like VirtualPlanetBuilder and NodeKits like osgEarth all manage the scene graph to deliver reliable, precision issue free rendering of whole earth databases. This approach has been disucssed many times in the OSG community so have a look through the archives. Cheers, Robert. > So having a transform at the rootnode, bringing transformation back to origo > does not help in that case. > > Small feature culling is disabled. > > > Our main problem, which I havent been able to reduce to an osg-only-app, > show the effect of "culling artefact" in that a cylinder can be rendered at > some camera angle, but disappears at others. So its very sensitive to the > camera view... > In this case, we basically transform the coordinates (6371014) with an > inverse matrix (-6371014,0,0) to bring the vertex coordinate down close to > origo, and then give that to OSG. But even here, we get this strange > artefact of some cylinders (being generated using OSG shapes) sometimes > disappears from the view. Backing the camera one inch, and they pop back. > Its easy to generate a video, harder to isolate the problem. > Because if I save the whole scenegraph down to a osgx file, the problem is > gone. > Might be a precision problem with the xml based file (as there are just a > few decimals there for vertices/transformations). > Will try to dump to a binary too. > > /A > > > On Thu, Oct 11, 2012 at 10:24 AM, Robert Osfield > wrote: >> >> Hi Anders, >> >> Even with default settings the culling will be done with doubles, with >> any floats being cast into doubles before tests against the view >> frustum planes rather than from doubles down to floats. >> >> I'm curious what makes you think the problem is culling. Could it be >> clipping? Could it be small feature culling? >> >> Robert, >> >> On 10 October 2012 13:43, Anders Backman wrote: >> > Hi all. >> > >> > Using OSG 3.0.1 under windows. >> > >> > A problem that we have experienced now and then without understanding >> > the >> > source of it, is that we get culling problems for scenes where objects >> > are >> > rendered far from origo. >> > >> > >> > By default, OSG use float for representing bounding boxes, spheres etc. >> > I believe I comment on this quite a few years ago related to some other >> > project we were working on. So the support for double representation in >> > BV:s >> > was added. >> > >> > However, we still seem to have problems. >> > >> > Assume you want to do some rendering using ECEF coordinates, where 0,0,0 >> > is >> > at the center of the earth. >> > Then you might end up with values around 6371014 meters. This is >> > obviously >> > not possible to represent in high enough precision for float. >> > >> > What we have been doing to avoid the culling problems is to explicitly >> > use >> > an inverse matrix which brings the coordinates used for rendering down >> > to >> > origo and multiply all transforms with this matrix. >> > >> > This give us problem, where in some specific camera views, some of the >> > rendered (long cylinders) are suddenly culled away, moving closer/away >> > will >> > bring them back. I will try to reduce this to an OSG example... >> > >> > >> > What we would LIKE to do, is to have a MatrixTransform with this inverse >> > matrix. But this was not working before (with float BV:s), and even now >> > with >> > the cmake settings below: >> > >> > >> > //Set to ON to build OpenSceneGraph with float BoundingBox instead >> > // of double. >> > OSG_USE_FLOAT_BOUNDINGBOX:BOOL=OFF >> > >> > //Set to ON to build OpenSceneGraph with float BoundingSphere instead >> > // of double. >> > OSG_USE_FLOAT_BOUNDINGSPHERE:BOOL=OFF >> > >> > //Set to ON to build Open
Re: [osg-users] Tesselator and output primitives
Thanks, the IndexMeshVisitor does exactly what I need. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50563#50563 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] pdb install
Thanks Mathieu, I'm trying your modifications. Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50566#50566 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] pdb install
Hi Mathieu, unfortunately I get the error: CMake Error at src/osg/cmake_install.cmake:40 (FILE): file INSTALL cannot find "C:/Documents and Settings/gambr/Local Settings/Temp/tmpm-mnkd/OpenSceneGraph-2.9.14/bin/osg75-osgd.pdb". while the pdb is in: C:\Documents and Settings\gambr\Local Settings\Temp\tmpm-mnkd\OpenSceneGraph-2.9.14\src\osg\osg75-osgd.pdb Any idea? Regards, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50567#50567 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] FBO and source formats
Hello. First of all sorry if the next question is dumb but i couldnt find it anywhere. I use camera->attach(osg::Camera::COLOR_BUFFER0, textureColor); in my program. It works only if the texture's source format is GL_RGBA. As i read in setSourceFormat's comment: Sets the external source image format Is FBO considered image ? As it seems i dont have to use setSourceType for the texture. But the default source type for the texture is 0. Why is it working ? Thank you for your time. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Change render target from FBO to frame buffer
Hi Robert,
Thanks for your quick answer.
> I wouldn't implement this type of management by reassigning a single
> osg::Camera with different setting but use a different Camera. I
> would also leave alone the master Camera and instead prefer to
> add/remove slave Cameras.
>From your answer I understand that I should have a slave camera which render
>the scene to texture and then doing my post processing from this slave camera.
>To disable my post-process I should only remove slave cameras.
By this mean I'm not modifying my master camera (which render to framebuffer)
but what I have is a black screen.
Am I using osg correctly?
> My guess to why you haven't been able to do what you want is the
> rendering backend data structure that is assigned to the osg::Camera
> to manage the the data accumulated during the cull traversal and which
> is that traversed in the draw traversal. The osg::Camera methods
> relating to this data structure is:
>
> /** Set the Rendering cache that is used for cached objects
> associated with rendering of subgraphs.*/
> void setRenderingCache(osg::Object* rc) { _renderingCache = rc; }
>
> /** Get the Rendering cache that is used for cached objects
> associated with rendering of subgraphs.*/
> osg::Object* getRenderingCache() { return _renderingCache.get(); }
>
> Perhaps resetting this RenderCache to 0 would do the trick.
Also I had tested to set rendering cache to 0, but it doesn't work. My main
camera seems not using rendering cache as it is already set to 0.
Thanks,
Kenzo
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=50569#50569
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
