[osg-users] Problem with 2D and 3D text in the same scene
Greetings,
I am experiencing problems rendering osgText::Text and osgText::Text3D
in the same scene. I have boiled it down to a nice bite-size chunk of
code which I have attached. I am running version 2.8.
Is this a bug?
Frank
#include osgViewer/Viewer
#include osg/Group
#include osg/Camera
#include osgText/Font
#include osgText/Text
#include osgText/Text3D
#if 1
// Can't see 3D text when both 2D and 3D use the same font...
char const * FontFile3D = fonts/arial.ttf;
char const * FontFile2D = fonts/arial.ttf;
#else
// but when they are different, things work fine.
char const * FontFile3D = fonts/arial.ttf;
char const * FontFile2D = fonts/times.ttf;
#endif
osg::ref_ptr osg::Node Create2DText()
{
osg::ref_ptr osg::Camera pCamera = new osg::Camera();
pCamera-setReferenceFrame( osg::Transform::ABSOLUTE_RF );
pCamera-setViewport( 0, 0, 800, 800 );
pCamera-setProjectionMatrixAsOrtho2D( 0, 800, 0, 800 );
pCamera-setViewMatrix( osg::Matrix::identity() );
pCamera-setClearMask( GL_DEPTH_BUFFER_BIT );
pCamera-getOrCreateStateSet()-setMode( GL_LIGHTING, osg::StateAttribute::OFF );
osg::ref_ptr osg::Geode pGeode = new osg::Geode();
pCamera-addChild( pGeode.get() );
osg::ref_ptr osgText::Text pText = new osgText::Text;
pText-setFont( FontFile2D );
pText-setColor( osg::Vec4( 1.0f, 1.0f, 1.0f, 1.0f ) );
pText-setCharacterSize( 42.0 );
pText-setPosition( osg::Vec3( 100.0, 100.0 ,0.0f ) );
pText-setText( 2D text );
pGeode-addDrawable( pText );
return pCamera.get();
}
osg::ref_ptr osg::Node Create3DText()
{
osg::ref_ptr osg::Geode pGeode = new osg::Geode;
float characterSize = 1.0f;
float characterDepth = characterSize*0.2f;
osg::ref_ptr osgText::Text3D pText = new osgText::Text3D();
pText-setFont( FontFile3D );
pText-setCharacterSize( characterSize );
pText-setCharacterDepth( characterDepth );
pText-setPosition( osg::Vec3( 0.0f, 0.0f, 0.0f ) );
pText-setDrawMode( osgText::Text3D::TEXT );
pText-setAxisAlignment( osgText::Text3D::XZ_PLANE );
pText-setText( 3D Text );
pGeode-addDrawable( pText );
osg::ref_ptr osg::Group pRoot = new osg::Group();
pRoot-addChild( pGeode );
return pRoot.get();
}
int main( int argc, char * argv[] )
{
osgViewer::Viewer viewer;
osg::ref_ptr osg::Group pGroup = new osg::Group();
pGroup-addChild( Create2DText() );
pGroup-addChild( Create3DText() );
viewer.setSceneData( pGroup );
viewer.run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sketchup rendering
You should also take a look at http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter15.html and the osgdepthpeeling example. Looks like its close to what you want. Frank On Fri, Feb 06, 2009 at 10:45:35AM +0100, Serge Lages wrote: Thanks Guillaume, The page you've spotted give nearly the same result as osgFX::Cartoon, what I would like is to have all the edged (when adjacent 2 faces are not coplanar) visible. I'll try to make something mixing this effect with something more custom to try to achieve it. On Thu, Feb 5, 2009 at 8:13 PM, Poirier, Guillaume guillaume.poir...@nrc-cnrc.gc.ca wrote: Hi Serge, You could probably achieve that look with flat shading (maybe some color quantization) combined with edge / silhouettes / creases extraction. Check out something like http://postulate.org/silhouette.php From: osg-users-boun...@lists.openscenegraph.org on behalf of Serge Lages Sent: Thu 2/5/2009 1:29 PM To: OpenSceneGraph Users Subject: [osg-users] Sketchup rendering Hi all, I would like to have some advices on how to render a scene with the same look and feel than Sketchup (very bright, black edges... I've attached a screenshot showing it). I looked at the Cartoon effect into osgFX but the result is really not the same. Any ideas on how to achieve it ? -- Serge Lages http://www.tharsis-software.com http://www.tharsis-software.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering double-sided surfaces.
For sure the best thing to do would be to process the incoming data as suggested. However, you might be able to get OpenGL to do what you want by setting all material properties for both sides of the polygon and enabling two sided lighting. Something like this. osg::ref_ptr osg::LightModel pLightModel = new osg::LightModel(); pLightModel-setTwoSided( true ); pState-setAttributeAndModes( pLightModel.get(), osg::StateAttribute::ON ); osg::ref_ptrosg::Material pMaterial = new osg::Material(); pMaterial-setColorMode( osg::Material::DIFFUSE ); pMaterial-setAmbient( osg::Material::FRONT_AND_BACK, osg::Vec4( 0.0, 0.0, 0.0, 1.0 ) ); pMaterial-setSpecular( osg::Material::FRONT_AND_BACK, osg::Vec4( 1.0, 1.0, 1.0, 1.0 ) ); pMaterial-setShininess( osg::Material::FRONT_AND_BACK, 64.0f ); pState-setAttributeAndModes( pMaterial.get(), osg::StateAttribute::ON ); I have never tried this for data like you have but it seems to me like it should work. Frank On Mon, Jan 26, 2009 at 04:21:41PM +0100, alessandro terenzi wrote: Problem is that the models that come to my application are already prepared by people that do not (and unfortunately won't) think about normals issues, so maybe the best thing to do would be to really render both front and back faces, I'm not an expert, but the only approach I can think is to double the geometry so to have both faces, but it would be really a waste (not to mention performace problems that may arise..and other unexpected visualization problems I cannot think of..) Regards. Alessandro On Mon, Jan 26, 2009 at 1:37 PM, Tomlinson, Gordon gtomlin...@overwatch.textron.com wrote: your triangles all need to be wound the same way (anticlockwise by default for OSG Opengl), whether or not your normal's are correct The easiest fix would be to ensure that your modeling package sets up correct normal's before you get to OSG Assuming your triangles are wound the same way ( if not you will have to fix that ) try using the SmoothingVistor on the data see include\osgUtil\SmoothingVisitor *Gordon* __ *Gordon Tomlinson* *Product Manager 3D **Email * : gtomlinson @ overwatch.textron.com __ *(C): (+1) 571-265-2612 (W)**: (+1) 703-437-7651* Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - *Master Tambo Tetsura* -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *alessandro terenzi *Sent:* Monday, January 26, 2009 7:09 AM *To:* OpenSceneGraph Users *Subject:* [osg-users] Rendering double-sided surfaces. Sometimes my application has to load models that have normals not always oriented in the same coherent way, so it is not always possible to say that a surface is oriented in a way or in another and my renderings do not look correct. I'd like to fix this problem in some way...so I was thinking about rendering both front and back faces, but how do I ask OSG do this? Or perhaps, is there another way/technique to achive the same result? (ie. orient a surface in a coherent way: all faces inward XOR outward) Thank you. Alessandro ___ 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] Problem with 2D scene
I have commented out those lines in svn revision: 9171. The problem with
2D scenes I reported is gone and everything else seems to work as it did
before.
If you would like, I would be happy to write a regression test.
Frank
On Sun, Nov 16, 2008 at 11:41:10AM +, Robert Osfield wrote:
Hi Frank,
Good detective work. I hadn't thought about this tiny little
optimization in the updateCalculatedNearFar. This optimization only
makes sense of perspective projections, and if fact could probably be
safely removed completely for all types of projection matrices.
Could you comment out the lines:
if (d_far0.0)
{
// whole object behind the eye point so discard
return false;
}
From CullVisitor::updateCalculatedNearFar and see how you get on. If
that works fine then we'll need to look at a fix in svn.
Robert.
On Fri, Nov 14, 2008 at 9:05 PM, [EMAIL PROTECTED] wrote:
osgUtil/CullVisitor.cpp line 644-645:
// whole object behind the eye point so discard
return false;
Perhaps its not called culling in this case but my code hits this return
statement and as a result, the drawable is not added to the StateGraphList
in
RenderBin. OpenGL is never given a chance to clip.
Frank
On Fri, Nov 14, 2008 at 08:22:31PM +, Robert Osfield wrote:
Hi Frank,
If culling is switched off then culling is off, the eye point will
make no difference.
What difference you moving the eye point will be in the clipping due
to the position of near/far plane.
Robert.
On Fri, Nov 14, 2008 at 8:09 PM, [EMAIL PROTECTED] wrote:
I think I figured it out. It looks like even with culling turned off,
nodes that are behind the eye point are culled. See
osgUtil/CullVisitor.cpp line 645.
I now calculate the view matrix as follows.
osg::Matrixd matrix = osg::Matrixd::translate( -center );
matrix.postMultRotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 ) ) );
matrix.postMultTranslate( osg::Vec3d( 0.0, 0.0, -0.5 ) );
Adding the last translation transform to push the nodes away from the
eye point made the problem go away.
Is this a bug?
Frank
On Thu, Nov 13, 2008 at 11:38:14AM -0500, [EMAIL PROTECTED] wrote:
Hi Robert,
Thanks for the quick response. That was a good suggestion. However it
looks like that is not the problem. All of my nodes live on the z=0.0
plane and my projection matrix is
osg::Matrixd::ortho( -aspectRatio, aspectRatio, -1.0, 1.0, -1.0, 1.0 )
I have attached a small code sample that exhibits the problem.
Frank
On Thu, Nov 13, 2008 at 04:24:37PM +, Robert Osfield wrote:
Hi Frank,
My best guess is that your projection matrix isn't wide enough to
encompass your scene and near/far clipping is clipping out the
fragments. This may well look like culling, often users do mistake
clipping with culling so chase up the wrong part of the pipeline.
Robert.
On Thu, Nov 13, 2008 at 4:18 PM, [EMAIL PROTECTED] wrote:
Greetings osg community,
I'm have written a custom MatrixManipulator for a 2D scene and I am
experiencing a strange problem. As I pan and zoom around, some of
the
nodes in the scene disappear abruptly as if they are being culled
inappropriately. However, disabling culling has no effect.
The behavior is erratic and unpredictable which smells to me like
I'm on
the border of a floating point inequality. I have discovered two
ways
that seem to make the problem go away.
One:
One of the transformations I use to construct the view matrix is
osg::Matrixd::rotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 )
) )
If I replace that with
osg::Matrixd::scale( osg::Vec3d( 1.0, -1.0, 1.0 ) )
the problem seems to go away.
Two:
All of the nodes in my seen that exhibit this problem have a 2D
bounding box. i.e.
osg::BoundingBox const bb = pGeode-getBoundingBox();
assert( bb.zMax() - bb.zMin() 1e-5 );
If I give the nodes some depth so that the above assert would fail,
the problem seems to go away.
I suspect that these are not actual solutions. In any case, I would
like
to understand what is happening under the covers. Any ideas?
Frank
___
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
#include osg/Geode
#include osg/Geometry
#include osgViewer/Viewer
#include iostream
#include cassert
osg::ref_ptr
Re: [osg-users] Problem with 2D scene
I think I figured it out. It looks like even with culling turned off,
nodes that are behind the eye point are culled. See
osgUtil/CullVisitor.cpp line 645.
I now calculate the view matrix as follows.
osg::Matrixd matrix = osg::Matrixd::translate( -center );
matrix.postMultRotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 ) ) );
matrix.postMultTranslate( osg::Vec3d( 0.0, 0.0, -0.5 ) );
Adding the last translation transform to push the nodes away from the
eye point made the problem go away.
Is this a bug?
Frank
On Thu, Nov 13, 2008 at 11:38:14AM -0500, [EMAIL PROTECTED] wrote:
Hi Robert,
Thanks for the quick response. That was a good suggestion. However it
looks like that is not the problem. All of my nodes live on the z=0.0
plane and my projection matrix is
osg::Matrixd::ortho( -aspectRatio, aspectRatio, -1.0, 1.0, -1.0, 1.0 )
I have attached a small code sample that exhibits the problem.
Frank
On Thu, Nov 13, 2008 at 04:24:37PM +, Robert Osfield wrote:
Hi Frank,
My best guess is that your projection matrix isn't wide enough to
encompass your scene and near/far clipping is clipping out the
fragments. This may well look like culling, often users do mistake
clipping with culling so chase up the wrong part of the pipeline.
Robert.
On Thu, Nov 13, 2008 at 4:18 PM, [EMAIL PROTECTED] wrote:
Greetings osg community,
I'm have written a custom MatrixManipulator for a 2D scene and I am
experiencing a strange problem. As I pan and zoom around, some of the
nodes in the scene disappear abruptly as if they are being culled
inappropriately. However, disabling culling has no effect.
The behavior is erratic and unpredictable which smells to me like I'm on
the border of a floating point inequality. I have discovered two ways
that seem to make the problem go away.
One:
One of the transformations I use to construct the view matrix is
osg::Matrixd::rotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 ) ) )
If I replace that with
osg::Matrixd::scale( osg::Vec3d( 1.0, -1.0, 1.0 ) )
the problem seems to go away.
Two:
All of the nodes in my seen that exhibit this problem have a 2D
bounding box. i.e.
osg::BoundingBox const bb = pGeode-getBoundingBox();
assert( bb.zMax() - bb.zMin() 1e-5 );
If I give the nodes some depth so that the above assert would fail,
the problem seems to go away.
I suspect that these are not actual solutions. In any case, I would like
to understand what is happening under the covers. Any ideas?
Frank
___
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
#include osg/Geode
#include osg/Geometry
#include osgViewer/Viewer
#include iostream
#include cassert
osg::ref_ptr osg::Node CreateGraph()
{
osg::ref_ptr osg::Geode pGeode= new osg::Geode();
osg::ref_ptr osg::Geometry pGeometry = new osg::Geometry();
pGeode-addDrawable( pGeometry.get() );
// Vertices
osg::ref_ptr osg::Vec3Array pVerts = new osg::Vec3Array( 4 );
(*pVerts)[ 0 ] = osg::Vec3( 0.0, 0.0, 0.0 );
(*pVerts)[ 1 ] = osg::Vec3( 1.0, 0.0, 0.0 );
(*pVerts)[ 2 ] = osg::Vec3( 1.0, 1.0, 0.0 );
(*pVerts)[ 3 ] = osg::Vec3( 0.0, 1.0, 0.0 ); // dosen't work
//(*pVerts)[ 3 ] = osg::Vec3( 0.0, 1.0, 0.1 ); // works as expected
pGeometry-setVertexArray( pVerts.get() );
pGeometry-addPrimitiveSet( new osg::DrawArrays( osg::PrimitiveSet::QUADS,
0, 4 ) );
osg::ref_ptr osg::Vec4Array pColors = new osg::Vec4Array( 4 );
(*pColors)[ 0 ] = osg::Vec4( 1.0f, 1.0f, 1.0f, 1.0f );
(*pColors)[ 1 ] = osg::Vec4( 1.0f, 0.0f, 0.0f, 1.0f );
(*pColors)[ 2 ] = osg::Vec4( 0.0f, 1.0f, 0.0f, 1.0f );
(*pColors)[ 3 ] = osg::Vec4( 0.0f, 0.0f, 1.0f, 1.0f );
pGeometry-setColorArray( pColors.get() );
pGeometry-setColorBinding( osg::Geometry::BIND_PER_VERTEX );
osg::ref_ptr osg::StateSet pState = pGeode-getOrCreateStateSet();
pState-setMode( GL_LIGHTING, osg::StateAttribute::OFF );
osg::BoundingBox const bb = pGeode-getBoundingBox();
std::cout
BoundingBox = (
bb.xMin() ,
bb.yMin() ,
bb.zMin() ,
bb.xMax() ,
bb.yMax() ,
bb.zMax() )
std::endl;
return pGeode.get();
}
int main( int argc, char * argv[] )
{
int const x = 100;
int const y = 100;
int const w = 800;
int const h = 800;
osg::ref_ptr osg::GraphicsContext::Traits pTraits = new
osg::GraphicsContext::Traits();
pTraits-x= x;
pTraits-y= y;
pTraits-width= w;
pTraits-height =
Re: [osg-users] Problem with 2D scene
osgUtil/CullVisitor.cpp line 644-645:
// whole object behind the eye point so discard
return false;
Perhaps its not called culling in this case but my code hits this return
statement and as a result, the drawable is not added to the StateGraphList in
RenderBin. OpenGL is never given a chance to clip.
Frank
On Fri, Nov 14, 2008 at 08:22:31PM +, Robert Osfield wrote:
Hi Frank,
If culling is switched off then culling is off, the eye point will
make no difference.
What difference you moving the eye point will be in the clipping due
to the position of near/far plane.
Robert.
On Fri, Nov 14, 2008 at 8:09 PM, [EMAIL PROTECTED] wrote:
I think I figured it out. It looks like even with culling turned off,
nodes that are behind the eye point are culled. See
osgUtil/CullVisitor.cpp line 645.
I now calculate the view matrix as follows.
osg::Matrixd matrix = osg::Matrixd::translate( -center );
matrix.postMultRotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 ) ) );
matrix.postMultTranslate( osg::Vec3d( 0.0, 0.0, -0.5 ) );
Adding the last translation transform to push the nodes away from the
eye point made the problem go away.
Is this a bug?
Frank
On Thu, Nov 13, 2008 at 11:38:14AM -0500, [EMAIL PROTECTED] wrote:
Hi Robert,
Thanks for the quick response. That was a good suggestion. However it
looks like that is not the problem. All of my nodes live on the z=0.0
plane and my projection matrix is
osg::Matrixd::ortho( -aspectRatio, aspectRatio, -1.0, 1.0, -1.0, 1.0 )
I have attached a small code sample that exhibits the problem.
Frank
On Thu, Nov 13, 2008 at 04:24:37PM +, Robert Osfield wrote:
Hi Frank,
My best guess is that your projection matrix isn't wide enough to
encompass your scene and near/far clipping is clipping out the
fragments. This may well look like culling, often users do mistake
clipping with culling so chase up the wrong part of the pipeline.
Robert.
On Thu, Nov 13, 2008 at 4:18 PM, [EMAIL PROTECTED] wrote:
Greetings osg community,
I'm have written a custom MatrixManipulator for a 2D scene and I am
experiencing a strange problem. As I pan and zoom around, some of the
nodes in the scene disappear abruptly as if they are being culled
inappropriately. However, disabling culling has no effect.
The behavior is erratic and unpredictable which smells to me like I'm
on
the border of a floating point inequality. I have discovered two ways
that seem to make the problem go away.
One:
One of the transformations I use to construct the view matrix is
osg::Matrixd::rotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 ) ) )
If I replace that with
osg::Matrixd::scale( osg::Vec3d( 1.0, -1.0, 1.0 ) )
the problem seems to go away.
Two:
All of the nodes in my seen that exhibit this problem have a 2D
bounding box. i.e.
osg::BoundingBox const bb = pGeode-getBoundingBox();
assert( bb.zMax() - bb.zMin() 1e-5 );
If I give the nodes some depth so that the above assert would fail,
the problem seems to go away.
I suspect that these are not actual solutions. In any case, I would
like
to understand what is happening under the covers. Any ideas?
Frank
___
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
#include osg/Geode
#include osg/Geometry
#include osgViewer/Viewer
#include iostream
#include cassert
osg::ref_ptr osg::Node CreateGraph()
{
osg::ref_ptr osg::Geode pGeode= new osg::Geode();
osg::ref_ptr osg::Geometry pGeometry = new osg::Geometry();
pGeode-addDrawable( pGeometry.get() );
// Vertices
osg::ref_ptr osg::Vec3Array pVerts = new osg::Vec3Array( 4 );
(*pVerts)[ 0 ] = osg::Vec3( 0.0, 0.0, 0.0 );
(*pVerts)[ 1 ] = osg::Vec3( 1.0, 0.0, 0.0 );
(*pVerts)[ 2 ] = osg::Vec3( 1.0, 1.0, 0.0 );
(*pVerts)[ 3 ] = osg::Vec3( 0.0, 1.0, 0.0 ); // dosen't work
//(*pVerts)[ 3 ] = osg::Vec3( 0.0, 1.0, 0.1 ); // works as expected
pGeometry-setVertexArray( pVerts.get() );
pGeometry-addPrimitiveSet( new osg::DrawArrays(
osg::PrimitiveSet::QUADS, 0, 4 ) );
osg::ref_ptr osg::Vec4Array pColors = new osg::Vec4Array( 4 );
(*pColors)[ 0 ] = osg::Vec4( 1.0f, 1.0f, 1.0f, 1.0f );
(*pColors)[ 1 ] = osg::Vec4( 1.0f, 0.0f, 0.0f, 1.0f );
(*pColors)[ 2 ] = osg::Vec4( 0.0f, 1.0f, 0.0f, 1.0f );
(*pColors)[ 3 ] = osg::Vec4( 0.0f, 0.0f, 1.0f, 1.0f );
pGeometry-setColorArray( pColors.get() );
[osg-users] Problem with 2D scene
Greetings osg community, I'm have written a custom MatrixManipulator for a 2D scene and I am experiencing a strange problem. As I pan and zoom around, some of the nodes in the scene disappear abruptly as if they are being culled inappropriately. However, disabling culling has no effect. The behavior is erratic and unpredictable which smells to me like I'm on the border of a floating point inequality. I have discovered two ways that seem to make the problem go away. One: One of the transformations I use to construct the view matrix is osg::Matrixd::rotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 ) ) ) If I replace that with osg::Matrixd::scale( osg::Vec3d( 1.0, -1.0, 1.0 ) ) the problem seems to go away. Two: All of the nodes in my seen that exhibit this problem have a 2D bounding box. i.e. osg::BoundingBox const bb = pGeode-getBoundingBox(); assert( bb.zMax() - bb.zMin() 1e-5 ); If I give the nodes some depth so that the above assert would fail, the problem seems to go away. I suspect that these are not actual solutions. In any case, I would like to understand what is happening under the covers. Any ideas? Frank ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with 2D scene
Hi Robert,
Thanks for the quick response. That was a good suggestion. However it
looks like that is not the problem. All of my nodes live on the z=0.0
plane and my projection matrix is
osg::Matrixd::ortho( -aspectRatio, aspectRatio, -1.0, 1.0, -1.0, 1.0 )
I have attached a small code sample that exhibits the problem.
Frank
On Thu, Nov 13, 2008 at 04:24:37PM +, Robert Osfield wrote:
Hi Frank,
My best guess is that your projection matrix isn't wide enough to
encompass your scene and near/far clipping is clipping out the
fragments. This may well look like culling, often users do mistake
clipping with culling so chase up the wrong part of the pipeline.
Robert.
On Thu, Nov 13, 2008 at 4:18 PM, [EMAIL PROTECTED] wrote:
Greetings osg community,
I'm have written a custom MatrixManipulator for a 2D scene and I am
experiencing a strange problem. As I pan and zoom around, some of the
nodes in the scene disappear abruptly as if they are being culled
inappropriately. However, disabling culling has no effect.
The behavior is erratic and unpredictable which smells to me like I'm on
the border of a floating point inequality. I have discovered two ways
that seem to make the problem go away.
One:
One of the transformations I use to construct the view matrix is
osg::Matrixd::rotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 ) ) )
If I replace that with
osg::Matrixd::scale( osg::Vec3d( 1.0, -1.0, 1.0 ) )
the problem seems to go away.
Two:
All of the nodes in my seen that exhibit this problem have a 2D
bounding box. i.e.
osg::BoundingBox const bb = pGeode-getBoundingBox();
assert( bb.zMax() - bb.zMin() 1e-5 );
If I give the nodes some depth so that the above assert would fail,
the problem seems to go away.
I suspect that these are not actual solutions. In any case, I would like
to understand what is happening under the covers. Any ideas?
Frank
___
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
#include osg/Geode
#include osg/Geometry
#include osgViewer/Viewer
#include iostream
#include cassert
osg::ref_ptr osg::Node CreateGraph()
{
osg::ref_ptr osg::Geode pGeode= new osg::Geode();
osg::ref_ptr osg::Geometry pGeometry = new osg::Geometry();
pGeode-addDrawable( pGeometry.get() );
// Vertices
osg::ref_ptr osg::Vec3Array pVerts = new osg::Vec3Array( 4 );
(*pVerts)[ 0 ] = osg::Vec3( 0.0, 0.0, 0.0 );
(*pVerts)[ 1 ] = osg::Vec3( 1.0, 0.0, 0.0 );
(*pVerts)[ 2 ] = osg::Vec3( 1.0, 1.0, 0.0 );
(*pVerts)[ 3 ] = osg::Vec3( 0.0, 1.0, 0.0 ); // dosen't work
//(*pVerts)[ 3 ] = osg::Vec3( 0.0, 1.0, 0.1 ); // works as expected
pGeometry-setVertexArray( pVerts.get() );
pGeometry-addPrimitiveSet( new osg::DrawArrays( osg::PrimitiveSet::QUADS, 0, 4 ) );
osg::ref_ptr osg::Vec4Array pColors = new osg::Vec4Array( 4 );
(*pColors)[ 0 ] = osg::Vec4( 1.0f, 1.0f, 1.0f, 1.0f );
(*pColors)[ 1 ] = osg::Vec4( 1.0f, 0.0f, 0.0f, 1.0f );
(*pColors)[ 2 ] = osg::Vec4( 0.0f, 1.0f, 0.0f, 1.0f );
(*pColors)[ 3 ] = osg::Vec4( 0.0f, 0.0f, 1.0f, 1.0f );
pGeometry-setColorArray( pColors.get() );
pGeometry-setColorBinding( osg::Geometry::BIND_PER_VERTEX );
osg::ref_ptr osg::StateSet pState = pGeode-getOrCreateStateSet();
pState-setMode( GL_LIGHTING, osg::StateAttribute::OFF );
osg::BoundingBox const bb = pGeode-getBoundingBox();
std::cout
BoundingBox = (
bb.xMin() ,
bb.yMin() ,
bb.zMin() ,
bb.xMax() ,
bb.yMax() ,
bb.zMax() )
std::endl;
return pGeode.get();
}
int main( int argc, char * argv[] )
{
int const x = 100;
int const y = 100;
int const w = 800;
int const h = 800;
osg::ref_ptr osg::GraphicsContext::Traits pTraits = new osg::GraphicsContext::Traits();
pTraits-x= x;
pTraits-y= y;
pTraits-width= w;
pTraits-height = h;
pTraits-windowDecoration = true;
pTraits-doubleBuffer = true;
pTraits-sharedContext= 0;
osg::ref_ptr osg::GraphicsContext pContext =
osg::GraphicsContext::createGraphicsContext( pTraits.get() );
assert( pContext.valid() );
osgViewer::Viewer viewer;
viewer.getCamera()-setGraphicsContext( pContext.get() );
viewer.getCamera()-setClearColor( osg::Vec4( 0.0, 0.0, 0.0, 1.0 ) );
viewer.getCamera()-setViewport( new osg::Viewport( 0, 0, w, h ) );
viewer.getCamera()-setGraphicsContext( pContext.get() );
viewer.getCamera()-setCullingMode( osg::CullSettings::NO_CULLING );
double const aspectRatio = double(w)/double(h);
//osg::Matrixd ortho = osg::Matrixd::ortho2D( -aspectRatio,
