Re: [osg-users] Transparency on a drawable
Hi Ulrich
thanks for help.
I use/try this code for the moment :
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat =
(osg::Material*)state-getAttribute(osg::StateAttribute::MATERIAL);
if(!mat) {
mat = new osg::Material;
}
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
state-setAttributeAndModes(mat,osg::StateAttribute::ON);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
But nothing appear transparent...
Regards,
Vincent
2008/7/12 Ulrich Hertlein [EMAIL PROTECTED]:
Vincent Bourdier wrote:
I do exactly the same things, on Nodes...
stateset-setMode(GL_BLEND, osg::StateAttribute::OVERRIDE |
osg::StateAttribute::ON );
stateset-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
Are you sure you're doing this last line? It's not in the code snippet you
posted initially...
Cheers,
/ulrich
double opacity = 0.1;
osg::StateSet* state = mygometry-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|
osg::StateAttribute::OVERRIDE);
osg::Material* mat = (osg::Material*)state-getAttribute
(osg::StateAttribute::MATERIAL);
if(!mat) {
mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, opacity);
state-setAttributeAndModes(mat,osg::StateAttribute::ON);
}
___
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] KD-Tree Performance Challenge....
Hi Robert, Thanks for your eMail. First of all i like to do a review of the current kdTree code, w.r.t. the build method. As we know form the publications about kdTree based Real Time Ray Tracer the build method and some heuristics are more important than the traversal. May the sah heuristic will boost our kdTree, if this would be true, and the build methode is still efficient in time and memory i will change directly the current kd-Tree code. /adrian 2008/7/14 Robert Osfield [EMAIL PROTECTED]: Hi Adrian, On Mon, Jul 14, 2008 at 9:38 PM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: i would like to merge my kdTree code with osg::KdTree. hopely it will work, but it's not as easy as it sound :-) (my code, you still know :-) ) Might I suggest implemting a KdTree subclass rather than modifying KdTree itself, at least during these initial stages of KdTree support. Please remember that not only does the KdTree have to be efficient to intersect with, it must as be efficient to build, be memory efficient and be easily maintainable - the last part is important as I'm the guy who has to support the code, and sometimes code submitted is a bit like a hit and run accident... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency on a drawable
Hi Vincent,
I see you still havent found a solution. So here I send you a complete example
of transpareny.
Its a modification of the Viewer example from the Qucik start guide.
It loads up a cow and overrides the alpha to 0.1.
Hope you can start from there.
Dimi
// Viewer Example, A minimal OSG viewer
#include osgDB/WriteFile
#include osg/Notify
#include osgViewer/Viewer
#include osgDB/ReadFile
#include osg/MatrixTransform
#include osg/Geode
#include osg/Geometry
#include osg/StateSet
#include osg/StateAttribute
#include osg/CullFace
#include osg/Point
#include osg/Light
#include osg/LightSource
#include osg/BlendFunc
#include osg/Material
#include osg/PolygonMode
#include osg/Notify
int
main( int, char ** )
{
// Create a Viewer.
osgViewer::Viewer viewer;
// Load a model and add it to the Viewer.
osg::ref_ptrosg::Node nde = osgDB::readNodeFile( cow.osg );
// Create StateSet and Material
osg::StateSet* state2 = nde-getOrCreateStateSet();
osg::ref_ptrosg::Material mat2 = new osg::Material;
// Set alpha to 0.1
mat2-setAlpha(osg::Material::FRONT_AND_BACK, 0.1);
state2-setAttributeAndModes( mat2.get() , osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
// Turn on blending
osg::BlendFunc* bf = new osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state2-setAttributeAndModes(bf);
viewer.setSceneData(nde.get());
if (!viewer.getSceneData())
{
osg::notify( osg::FATAL ) Unable to load data file. Exiting.
std::endl;
return 1;
}
// Display, and main loop.
return viewer.run();
}
- Original Message
From: Vincent Bourdier [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tuesday, July 15, 2008 9:04:23 AM
Subject: Re: [osg-users] Transparency on a drawable
Hi Ulrich
thanks for help.
I use/try this code for the moment :
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat =
(osg::Material*)state-getAttribute(osg::StateAttribute::MATERIAL);
if(!mat) {
mat = new osg::Material;
}
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
state-setAttributeAndModes(mat,osg::StateAttribute::ON);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
But nothing appear transparent...
Regards,
Vincent
2008/7/12 Ulrich Hertlein [EMAIL PROTECTED]:
Vincent Bourdier wrote:
I do exactly the same things, on Nodes...
stateset-setMode(GL_BLEND, osg::StateAttribute::OVERRIDE |
osg::StateAttribute::ON );
stateset-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
Are you sure you're doing this last line? It's not in the code snippet you
posted initially...
Cheers,
/ulrich
double opacity = 0.1;
osg::StateSet* state = mygometry-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|
osg::StateAttribute::OVERRIDE);
osg::Material* mat = (osg::Material*)state-getAttribute
(osg::StateAttribute::MATERIAL);
if(!mat) {
mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, opacity);
state-setAttributeAndModes(mat,osg::StateAttribute::ON);
}
___
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] Transparency on a drawable
Hi
Yes, no solutions seems to work on my problem.
Because all the propositions concern nodes, I permit to remember that I am
looking at a way to set alpha level on a osg::Geometry ...
On node I already have a method using material : set alpha channel, and it
works good... But on my geometry nothing look to work good...
This is all my geometry creator code :
osg::ref_ptrosg::Geometry builtGeometry(){
double alpha = 0.1;
osg::Vec4 grey(0.4,0.4,0.4,1.0);
osg::Vec4 yellow(1.0,1.0,0.0,1.0);
osg::Geometry* g = new osg::Geometry;
osg::Vec3Array* vertices= new osg::Vec3Array();
osg::Vec3Array* normals= new osg::Vec3Array();
osg::Vec4Array* colors= new osg::Vec4Array();
normals-push_back(osg::Vec3(0,0,1));
colors-push_back(grey);
//
//QUAD
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist, _offset));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist, _offset));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset));
if(!_empty)
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4));
else
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,0,4));
//-
//LINE
vertices-push_back(osg::Vec3(0.0, 1.0, _offset));
vertices-push_back(osg::Vec3(0.0, _dist, _offset));
colors-push_back(grey);
g-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::LINES,4,2));
//
//LINE_LOOP
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset/2.0));
colors-push_back(yellow);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,6,4));
g-setNormalArray(normals);
g-setVertexArray(vertices);
g-setColorArray(colors);
g-setNormalBinding(osg::Geometry::BIND_OVERALL);
g-setColorBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
g-setDataVariance(osg::Object::DYNAMIC);
//TRANSPARENCY
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::BlendFunc* bf = new osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state-setAttributeAndModes(bf);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
g-setStateSet(state);
return g;
}
Thanks for your help.
Regards,
Vincent.
2008/7/15 dimi christop [EMAIL PROTECTED]:
Hi Vincent,
I see you still havent found a solution. So here I send you a complete
example of transpareny.
Its a modification of the Viewer example from the Qucik start guide.
It loads up a cow and overrides the alpha to 0.1.
Hope you can start from there.
Dimi
// Viewer Example, A minimal OSG viewer
#include osgDB/WriteFile
#include osg/Notify
#include osgViewer/Viewer
#include osgDB/ReadFile
#include osg/MatrixTransform
#include osg/Geode
#include osg/Geometry
#include osg/StateSet
#include osg/StateAttribute
#include osg/CullFace
#include osg/Point
#include osg/Light
#include osg/LightSource
#include osg/BlendFunc
#include osg/Material
#include osg/PolygonMode
#include osg/Notify
int
main( int, char ** )
{
// Create a Viewer.
osgViewer::Viewer viewer;
// Load a model and add it to the Viewer.
osg::ref_ptrosg::Node nde = osgDB::readNodeFile( cow.osg );
// Create StateSet and Material
osg::StateSet* state2 = nde-getOrCreateStateSet();
osg::ref_ptrosg::Material mat2 = new osg::Material;
// Set alpha to 0.1
mat2-setAlpha(osg::Material::FRONT_AND_BACK, 0.1);
state2-setAttributeAndModes( mat2.get() , osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
// Turn on blending
osg::BlendFunc* bf = new osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state2-setAttributeAndModes(bf);
viewer.setSceneData(nde.get());
if (!viewer.getSceneData())
{
osg::notify( osg::FATAL ) Unable to load data file. Exiting.
std::endl;
return 1;
}
// Display, and main loop.
return viewer.run();
}
- Original Message
From: Vincent Bourdier [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tuesday, July 15, 2008 9:04:23 AM
Subject: Re: [osg-users] Transparency on a drawable
Hi Ulrich
thanks for
Re: [osg-users] Transparency on a drawable
Vincent Bourdier wrote:
Hi
Yes, no solutions seems to work on my problem.
Because all the propositions concern nodes, I permit to remember that I
am looking at a way to set alpha level on a osg::Geometry ...
On node I already have a method using material : set alpha channel, and
it works good... But on my geometry nothing look to work good...
This is all my geometry creator code :
osg::ref_ptrosg::Geometry builtGeometry(){
double alpha = 0.1;
osg::Vec4 grey(0.4,0.4,0.4,1.0);
osg::Vec4 yellow(1.0,1.0,0.0,1.0);
What happens if you put alpha for the fourth value in your color?
-Paul
osg::Geometry* g = new osg::Geometry;
osg::Vec3Array* vertices= new osg::Vec3Array();
osg::Vec3Array* normals= new osg::Vec3Array();
osg::Vec4Array* colors= new osg::Vec4Array();
normals-push_back(osg::Vec3(0,0,1));
colors-push_back(grey);
//
//QUAD
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset));
if(!_empty)
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4));
else
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,0,4));
//-
//LINE
vertices-push_back(osg::Vec3(0.0, 1.0, _offset));
vertices-push_back(osg::Vec3(0.0, _dist, _offset));
colors-push_back(grey);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINES,4,2));
//
//LINE_LOOP
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset/2.0));
colors-push_back(yellow);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,6,4));
g-setNormalArray(normals);
g-setVertexArray(vertices);
g-setColorArray(colors);
g-setNormalBinding(osg::Geometry::BIND_OVERALL);
g-setColorBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
g-setDataVariance(osg::Object::DYNAMIC);
//TRANSPARENCY
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::BlendFunc* bf = new
osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state-setAttributeAndModes(bf);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
g-setStateSet(state);
return g;
}
Thanks for your help.
Regards,
Vincent.
2008/7/15 dimi christop [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Hi Vincent,
I see you still havent found a solution. So here I send you a
complete example of transpareny.
Its a modification of the Viewer example from the Qucik start guide.
It loads up a cow and overrides the alpha to 0.1.
Hope you can start from there.
Dimi
// Viewer Example, A minimal OSG viewer
#include osgDB/WriteFile
#include osg/Notify
#include osgViewer/Viewer
#include osgDB/ReadFile
#include osg/MatrixTransform
#include osg/Geode
#include osg/Geometry
#include osg/StateSet
#include osg/StateAttribute
#include osg/CullFace
#include osg/Point
#include osg/Light
#include osg/LightSource
#include osg/BlendFunc
#include osg/Material
#include osg/PolygonMode
#include osg/Notify
int
main( int, char ** )
{
// Create a Viewer.
osgViewer::Viewer viewer;
// Load a model and add it to the Viewer.
osg::ref_ptrosg::Node nde = osgDB::readNodeFile( cow.osg );
// Create StateSet and Material
osg::StateSet* state2 = nde-getOrCreateStateSet();
osg::ref_ptrosg::Material mat2 = new osg::Material;
// Set alpha to 0.1
mat2-setAlpha(osg::Material::FRONT_AND_BACK, 0.1);
state2-setAttributeAndModes( mat2.get() ,
osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE);
// Turn on blending
osg::BlendFunc* bf = new
osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
Re: [osg-users] Transparency on a drawable
Hi Paul.
Nothing changes with color's alpha changed...
2008/7/15 Paul Speed [EMAIL PROTECTED]:
Vincent Bourdier wrote:
Hi
Yes, no solutions seems to work on my problem.
Because all the propositions concern nodes, I permit to remember that I am
looking at a way to set alpha level on a osg::Geometry ...
On node I already have a method using material : set alpha channel, and it
works good... But on my geometry nothing look to work good...
This is all my geometry creator code :
osg::ref_ptrosg::Geometry builtGeometry(){
double alpha = 0.1;
osg::Vec4 grey(0.4,0.4,0.4,1.0);
osg::Vec4 yellow(1.0,1.0,0.0,1.0);
What happens if you put alpha for the fourth value in your color?
-Paul
osg::Geometry* g = new osg::Geometry;
osg::Vec3Array* vertices= new osg::Vec3Array();
osg::Vec3Array* normals= new osg::Vec3Array();
osg::Vec4Array* colors= new osg::Vec4Array();
normals-push_back(osg::Vec3(0,0,1));
colors-push_back(grey);
//
//QUAD
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset));
if(!_empty)
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4));
else
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,0,4));
//-
//LINE
vertices-push_back(osg::Vec3(0.0, 1.0, _offset));
vertices-push_back(osg::Vec3(0.0, _dist, _offset));
colors-push_back(grey);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINES,4,2));
//
//LINE_LOOP
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset/2.0));
colors-push_back(yellow);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,6,4));
g-setNormalArray(normals);
g-setVertexArray(vertices);
g-setColorArray(colors);
g-setNormalBinding(osg::Geometry::BIND_OVERALL);
g-setColorBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
g-setDataVariance(osg::Object::DYNAMIC);
//TRANSPARENCY
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::BlendFunc* bf = new
osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state-setAttributeAndModes(bf);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
g-setStateSet(state);
return g;
}
Thanks for your help.
Regards,
Vincent.
2008/7/15 dimi christop [EMAIL PROTECTED] mailto:
[EMAIL PROTECTED]:
Hi Vincent,
I see you still havent found a solution. So here I send you a
complete example of transpareny.
Its a modification of the Viewer example from the Qucik start guide.
It loads up a cow and overrides the alpha to 0.1.
Hope you can start from there.
Dimi
// Viewer Example, A minimal OSG viewer
#include osgDB/WriteFile
#include osg/Notify
#include osgViewer/Viewer
#include osgDB/ReadFile
#include osg/MatrixTransform
#include osg/Geode
#include osg/Geometry
#include osg/StateSet
#include osg/StateAttribute
#include osg/CullFace
#include osg/Point
#include osg/Light
#include osg/LightSource
#include osg/BlendFunc
#include osg/Material
#include osg/PolygonMode
#include osg/Notify
int
main( int, char ** )
{
// Create a Viewer.
osgViewer::Viewer viewer;
// Load a model and add it to the Viewer.
osg::ref_ptrosg::Node nde = osgDB::readNodeFile( cow.osg );
// Create StateSet and Material
osg::StateSet* state2 = nde-getOrCreateStateSet();
osg::ref_ptrosg::Material mat2 = new osg::Material;
// Set alpha to 0.1
mat2-setAlpha(osg::Material::FRONT_AND_BACK, 0.1);
state2-setAttributeAndModes( mat2.get() ,
osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE);
// Turn on blending
osg::BlendFunc* bf = new
Re: [osg-users] Problem setting a skydome
Alberto, skydome-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR). a class osg::Camera inherits from Sorry - missed a step. Put a Camera in above your skydome. A solution that comes to my mind is to use a pair of cameras, one rendering the skydome with the setting you said, DO_NOT_COMPUTE_NEAR_FAR, and the other rendering the rest of the scene. Exactly. That's what I do (although I control a bunch of other stuff in the camera, like projection matrix, in order to avoid the later issues). David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] empty scene after resize
I just wanted to let you know how I solved my problem: it seems that one has to avoid sending the resize events to OSG when the new size has zero area, that is, the width or height are == 0. Basically I just put the condition if ( width * height ) in the Qt's resize event handler before dispatching the resize event to OSG. Cheers, Michele On Mon, Jul 14, 2008 at 11:08 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Michele, This most likely will be because the viewport is going to 0,0,0,0 size and messing up projection matrix. I'm afraid I don't have an straight forward solutions to this - it most likely will require so special catch code to handle this problem case. Robert. On Mon, Jul 14, 2008 at 10:05 PM, Michele Bosi [EMAIL PROTECTED] wrote: I am sure this is a known problem, but looking on the archives didn't help, maybe I didn't come up with the right keywords, anyway... I am using OSG 2.4 (but the problem was already there since OSG 2.0) under both Win XP and Linux, with the Qt4 wrapper and when I resize the window to zero width or height and then restore it the content of the scene disappears (my program has 3d views that can be temprarily hidden/restored). This behaviour seem not to be related to the driver but to OSG since with OSG-based programs I get the same problem with nVidias as well as with ATIs, while other non-OSG-based programs don't show this problem. I suspect that with a zero-area viewport something breaks into the culling mechanism or some division by zero mixes up some OSG internal state or matrix. Does anyone know how to fix or work around this? do I have to reset something once I detect a non-zero area viewport in my resize event handler? Thanks, Michele ___ 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] FindNodeVisitor Operation?
Hi All,
I have an model composing of different part of component in .3ds format. I
am trying to traverse in these part of component and translate them. As like
as
http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/FindingNodessample'
I want to control part of component with findnodevisitor but I don't
know how can I translate them.
for example in FindingNode sample translating is doing with
if (turretDOF)
{
turretDOF-setCurrentHPR( osg::Vec3(-3.14159/4.0,0.0,0.0) );
}
This t72-tank.flt model's turret component is osgSim::DOFTransform format
and it could translated with setCurrentHPR command, but my components is not
in this format.
I can get a Geode node from model. The abstract osg model is below;
--
Group {
name GL_6000_v22.3DS
nodeMask 0x
cullingActive TRUE
num_children 7
MatrixTransform {
name 3DSPIVOTPOINT: Rotate
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
-1 -0 -0 -0
-0 1 -3.25841e-007 -0
-0 3.25841e-007 1 -0
0 -1.65228e-008 0.377998 1
}
num_children 1
MatrixTransform {
name 3DSPIVOTPOINT: Translate pivotpoint to (world) origin
nodeMask 0x
cullingActive TRUE
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
9.33344 2.61793e-006 -6.68031 1
}
num_children 1
Geode {
name 1_planetar
nodeMask 0x
cullingActive TRUE
num_drawables 5
Geometry {
DataVariance STATIC
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
Material {
name Material #5
ColorMode OFF
ambientColor 0.176471 0.176471 0.176471 1
diffuseColor 0.176471 0.176471 0.176471 1
specularColor 0.431059 0.431059 0.431059 0.48
emissionColor 0 0 0 1
shininess 16.64
}
}
.
etc.
--
How should I do for translating or rotating part of components of model like
turret or gun movement at Tank sample code? And Should I get Geode node or
Geometry node? Which one should I handle?
Thanks so much,
Best Regards.
ümit Uzun
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FindNodeVisitor Operation?
Hi Ümit, osg::DOFTransform is a subclass of the more general osg::MatrixTransform. If I'm reading the intention of the model right, you have 2 MatrixTransform nodes - named *3DSPIVOTPOINT: Rotate* and *3DSPIVOTPOINT: Translate pivotpoint to (world) origin* above some geometry *1_planetar*. (Although your top level group has 6 other unlisted children as well). If you want to move/rotate/translate 1_planetar, use the NodeVisitor to find one of your two MatrixTransform nodes, and then set the transform's matrix yourself (via setMatrix(osg::Matrix myMatrix)). You will need to fill in the values of the matrix yourself based on what you want to do, but there are many many ways of doing this (makeRotate, makeTranslate, makeLookAt etc.) Alternatively, if you really want to use DOFTransform type methods, you could dynamic_cast the found MatrixTransform to a DOFTransform. Hope that helps, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New feature : osgconv --plugins and --formats ReaderWriter::supported*() API
On Tue, Jul 15, 2008 at 3:15 AM, Paul Martz [EMAIL PROTECTED] wrote: This looks like it was a pain in the butt. Thanks for adding this interface. Is there any way we can get the supported entry point info that osgio -csv was capable of displaying? (You know, a plugin says it supports format ABC, but does that mean it can read ABC as a Node? Or write it as an Image? An Object? Etc.) I think this would be best done by just passing in test strings to the plugin as you did in osgio. There shouldn't be any need to actual create files though. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency on a drawable
Hi Vincent, odd... could you save the scene and post it? /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ArchiveStatus defined in osgDB/Archive
Hi Biv, Since Archive inherits from ReaderWriter, the Archive::ArchiveStatus is the same thing as ReaderWriter::ArchiveStatus. I guess it's possibly slightly less confusing to have the functions use ReaderWriter::ArchiveStatus, but there's not much in it. Robert. On Mon, Jul 14, 2008 at 10:39 PM, Gerrick Bivins [EMAIL PROTECTED] wrote: Hello All, Should the following lines in osgDB/Archive /** Open an archive for reading or writing.*/ OSGDB_EXPORT Archive* openArchive(const std::string filename, Archive::ArchiveStatus status, unsigned int indexBlockSizeHint=4096); /** Open an archive for reading or writing.*/ OSGDB_EXPORT Archive* openArchive(const std::string filename, Archive::ArchiveStatus status, unsigned int indexBlockSizeHint,ReaderWriter::Options* options); actually be : /** Open an archive for reading or writing.*/ OSGDB_EXPORT Archive* openArchive(const std::string filename, ReaderWriter::ArchiveStatus status, unsigned int indexBlockSizeHint=4096); /** Open an archive for reading or writing.*/ OSGDB_EXPORT Archive* openArchive(const std::string filename, ReaderWriter::ArchiveStatus status, unsigned int indexBlockSizeHint,ReaderWriter::Options* options); biv ___ 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] Update Optimization
Hi John, On Tue, Jul 15, 2008 at 2:48 AM, John Burgess [EMAIL PROTECTED] wrote: I've tried the KdTree but my update traversal rate is still the same as before. Below is my code snippet to enable KdTree, am I doing the right thing? osgDB::Registry::instance()-setBuildKdTreesHint(osgDB::ReaderWriter::Options::BUILD_KDTREES); // Load the terrain osg::Node* _terrain = osgDB::readNodeFile(terrainFile); You have to use osgUtil::IntersectionVisitor + LineSegmentIntersector to take advantage of the new KdTree intersections, the old (and deprecated) osgUtil::IntersectVisitor does not support KdTree intersection. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency on a drawable
Sure This is my Billboard node which won't set its geometry to transparent. thanks for help. Regards, Vincent 2008/7/15 Ulrich Hertlein [EMAIL PROTECTED]: Hi Vincent, odd... could you save the scene and post it? /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org node_debug.osg Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KD-Tree Performance Challenge....
Hi Adrian, On Tue, Jul 15, 2008 at 8:15 AM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: Thanks for your eMail. First of all i like to do a review of the current kdTree code, w.r.t. the build method. As we know form the publications about kdTree based Real Time Ray Tracer the build method and some heuristics are more important than the traversal. May the sah heuristic will boost our kdTree, if this would be true, and the build methode is still efficient in time and memory i will change directly the current kd-Tree code. The surface area heuristic might provide a little improvement on pure KdTree intersection performance - but at a cost of building. Please remember that it's intended that KdTree will be built on the fly, such as when paging in databases, you absolutely don't want to cost of build to be greater than the cost reduction in intersection that it provides - if you are paging lots of data all the time, and only doing a moderate number of intersections per frame the balance far from pure in favour of optimizing the final KdTree traversal. Another factor in this is that the actual scene graph traversal is currently more costly then the KdTree traversal, so doubling the speed of the KdTree traversal won't come close to doubling the speed of intersection, it might only have a 5% improvement. So its really important to benchmark all aspect in the context that most users will use it. Going for more sophisticated build techniques make do more overall harm for some users types of usage models than others - your benchmark is far from the most common usage that users will put intersection traversal through. The OSG is not a ray tracing engine, its a general purpose scene graph that uses OpenGL for rendering, and just happens to support intersections to help users out. Given this context, I'm not about to merge new algorithms in place of the existing ones if they impact on build performance. There is no harm in having multiple KdTree implementations, the design is intended for this. If you want to extend it go ahead, if the implementation ticks all the boxes then I'll consider merging it as the default. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] empty scene after resize
Hi Michele, We should probably add such as catch higher up in the OSG. I'm spinning half a dozen plates at this end so would appreciate if you could chase this up. Robert. On Tue, Jul 15, 2008 at 9:36 AM, Michele Bosi [EMAIL PROTECTED] wrote: I just wanted to let you know how I solved my problem: it seems that one has to avoid sending the resize events to OSG when the new size has zero area, that is, the width or height are == 0. Basically I just put the condition if ( width * height ) in the Qt's resize event handler before dispatching the resize event to OSG. Cheers, Michele On Mon, Jul 14, 2008 at 11:08 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Michele, This most likely will be because the viewport is going to 0,0,0,0 size and messing up projection matrix. I'm afraid I don't have an straight forward solutions to this - it most likely will require so special catch code to handle this problem case. Robert. On Mon, Jul 14, 2008 at 10:05 PM, Michele Bosi [EMAIL PROTECTED] wrote: I am sure this is a known problem, but looking on the archives didn't help, maybe I didn't come up with the right keywords, anyway... I am using OSG 2.4 (but the problem was already there since OSG 2.0) under both Win XP and Linux, with the Qt4 wrapper and when I resize the window to zero width or height and then restore it the content of the scene disappears (my program has 3d views that can be temprarily hidden/restored). This behaviour seem not to be related to the driver but to OSG since with OSG-based programs I get the same problem with nVidias as well as with ATIs, while other non-OSG-based programs don't show this problem. I suspect that with a zero-area viewport something breaks into the culling mechanism or some division by zero mixes up some OSG internal state or matrix. Does anyone know how to fix or work around this? do I have to reset something once I detect a non-zero area viewport in my resize event handler? Thanks, Michele ___ 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] Transparency on a drawable
This is because when you set alpha to the vertices and attach also an material
and a blending function you have to setColorMode (AMBIENT_DIFFUSE) on the
material.
Dimi
- Original Message
From: Vincent Bourdier [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tuesday, July 15, 2008 11:09:23 AM
Subject: Re: [osg-users] Transparency on a drawable
Hi Paul.
Nothing changes with color's alpha changed...
2008/7/15 Paul Speed [EMAIL PROTECTED]:
Vincent Bourdier wrote:
Hi
Yes, no solutions seems to work on my problem.
Because all the propositions concern nodes, I permit to remember that I am
looking at a way to set alpha level on a osg::Geometry ...
On node I already have a method using material : set alpha channel, and it
works good... But on my geometry nothing look to work good...
This is all my geometry creator code :
osg::ref_ptrosg::Geometry builtGeometry(){
double alpha = 0.1;
osg::Vec4 grey(0.4,0.4,0.4,1.0);
osg::Vec4 yellow(1.0,1.0,0.0,1.0);
What happens if you put alpha for the fourth value in your color?
-Paul
osg::Geometry* g = new osg::Geometry;
osg::Vec3Array* vertices= new osg::Vec3Array();
osg::Vec3Array* normals= new osg::Vec3Array();
osg::Vec4Array* colors= new osg::Vec4Array();
normals-push_back(osg::Vec3(0,0,1));
colors-push_back(grey);
//
//QUAD
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset));
if(!_empty)
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4));
else
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,0,4));
//-
//LINE
vertices-push_back(osg::Vec3(0.0, 1.0, _offset));
vertices-push_back(osg::Vec3(0.0, _dist, _offset));
colors-push_back(grey);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINES,4,2));
//
//LINE_LOOP
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset/2.0));
colors-push_back(yellow);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,6,4));
g-setNormalArray(normals);
g-setVertexArray(vertices);
g-setColorArray(colors);
g-setNormalBinding(osg::Geometry::BIND_OVERALL);
g-setColorBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
g-setDataVariance(osg::Object::DYNAMIC);
//TRANSPARENCY
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::BlendFunc* bf = new
osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state-setAttributeAndModes(bf);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
g-setStateSet(state);
return g;
}
Thanks for your help.
Regards,
Vincent.
2008/7/15 dimi christop [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
Hi Vincent,
I see you still havent found a solution. So here I send you a
complete example of transpareny.
Its a modification of the Viewer example from the Qucik start guide.
It loads up a cow and overrides the alpha to 0.1.
Hope you can start from there.
Dimi
// Viewer Example, A minimal OSG viewer
#include osgDB/WriteFile
#include osg/Notify
#include osgViewer/Viewer
#include osgDB/ReadFile
#include osg/MatrixTransform
#include osg/Geode
#include osg/Geometry
#include osg/StateSet
#include osg/StateAttribute
#include osg/CullFace
#include osg/Point
#include osg/Light
#include osg/LightSource
#include osg/BlendFunc
#include osg/Material
#include osg/PolygonMode
#include osg/Notify
int
main( int, char ** )
{
// Create a Viewer.
osgViewer::Viewer viewer;
// Load a model and add it to the Viewer.
osg::ref_ptrosg::Node nde = osgDB::readNodeFile( cow.osg );
// Create StateSet and Material
osg::StateSet* state2 = nde-getOrCreateStateSet();
osg::ref_ptrosg::Material mat2 = new osg::Material;
Re: [osg-users] Transparency on a drawable
Hi Dimi,
this is my code :
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
mat-setColorMode(osg::Material::AMBIENT_AND_DIFFUSE);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::BlendFunc* bf = new osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state-setAttributeAndModes(bf);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
g-setStateSet(state);
there is no difference at all...
thanks for help.
Vincent.
2008/7/15 dimi christop [EMAIL PROTECTED]:
This is because when you set alpha to the vertices and attach also an
material
and a blending function you have to setColorMode (AMBIENT_DIFFUSE) on the
material.
Dimi
- Original Message
From: Vincent Bourdier [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tuesday, July 15, 2008 11:09:23 AM
Subject: Re: [osg-users] Transparency on a drawable
Hi Paul.
Nothing changes with color's alpha changed...
2008/7/15 Paul Speed [EMAIL PROTECTED]:
Vincent Bourdier wrote:
Hi
Yes, no solutions seems to work on my problem.
Because all the propositions concern nodes, I permit to remember that I
am looking at a way to set alpha level on a osg::Geometry ...
On node I already have a method using material : set alpha channel, and
it works good... But on my geometry nothing look to work good...
This is all my geometry creator code :
osg::ref_ptrosg::Geometry builtGeometry(){
double alpha = 0.1;
osg::Vec4 grey(0.4,0.4,0.4,1.0);
osg::Vec4 yellow(1.0,1.0,0.0,1.0);
What happens if you put alpha for the fourth value in your color?
-Paul
osg::Geometry* g = new osg::Geometry;
osg::Vec3Array* vertices= new osg::Vec3Array();
osg::Vec3Array* normals= new osg::Vec3Array();
osg::Vec4Array* colors= new osg::Vec4Array();
normals-push_back(osg::Vec3(0,0,1));
colors-push_back(grey);
//
//QUAD
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset));
if(!_empty)
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4));
else
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,0,4));
//-
//LINE
vertices-push_back(osg::Vec3(0.0, 1.0, _offset));
vertices-push_back(osg::Vec3(0.0, _dist, _offset));
colors-push_back(grey);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINES,4,2));
//
//LINE_LOOP
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset/2.0));
colors-push_back(yellow);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,6,4));
g-setNormalArray(normals);
g-setVertexArray(vertices);
g-setColorArray(colors);
g-setNormalBinding(osg::Geometry::BIND_OVERALL);
g-setColorBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
g-setDataVariance(osg::Object::DYNAMIC);
//TRANSPARENCY
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::BlendFunc* bf = new
osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state-setAttributeAndModes(bf);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
g-setStateSet(state);
return g;
}
Thanks for your help.
Regards,
Vincent.
2008/7/15 dimi christop [EMAIL PROTECTED] mailto:
[EMAIL PROTECTED]:
Hi Vincent,
I see you still havent found a solution. So here I send you a
complete example of transpareny.
Its a modification of the Viewer example from the Qucik start guide.
It loads up a cow and overrides the alpha to 0.1.
Hope you can start from there.
Re: [osg-users] Transparency on a drawable
Ok,
I fixed your osg file so that it displays varrying tranparency (top
transparent, bottom opaque).
I assume this is what you wanted.
Do an diff on the files and see what you did wrong You set the colors per
primitive and not per vertex.
- Original Message
From: Vincent Bourdier [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tuesday, July 15, 2008 1:19:23 PM
Subject: Re: [osg-users] Transparency on a drawable
Hi Dimi,
this is my code :
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
mat-setColorMode(osg::Material::AMBIENT_AND_DIFFUSE);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::BlendFunc* bf = new osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state-setAttributeAndModes(bf);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
g-setStateSet(state);
there is no difference at all...
thanks for help.
Vincent.
2008/7/15 dimi christop [EMAIL PROTECTED]:
This is because when you set alpha to the vertices and attach also an material
and a blending function you have to setColorMode (AMBIENT_DIFFUSE) on the
material.
Dimi
- Original Message
From: Vincent Bourdier [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tuesday, July 15, 2008 11:09:23 AM
Subject: Re: [osg-users] Transparency on a drawable
Hi Paul.
Nothing changes with color's alpha changed...
2008/7/15 Paul Speed [EMAIL PROTECTED]:
Vincent Bourdier wrote:
Hi
Yes, no solutions seems to work on my problem.
Because all the propositions concern nodes, I permit to remember that I am
looking at a way to set alpha level on a osg::Geometry ...
On node I already have a method using material : set alpha channel, and it
works good... But on my geometry nothing look to work good...
This is all my geometry creator code :
osg::ref_ptrosg::Geometry builtGeometry(){
double alpha = 0.1;
osg::Vec4 grey(0.4,0.4,0.4,1.0);
osg::Vec4 yellow(1.0,1.0,0.0,1.0);
What happens if you put alpha for the fourth value in your color?
-Paul
osg::Geometry* g = new osg::Geometry;
osg::Vec3Array* vertices= new osg::Vec3Array();
osg::Vec3Array* normals= new osg::Vec3Array();
osg::Vec4Array* colors= new osg::Vec4Array();
normals-push_back(osg::Vec3(0,0,1));
colors-push_back(grey);
//
//QUAD
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset));
if(!_empty)
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4));
else
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,0,4));
//-
//LINE
vertices-push_back(osg::Vec3(0.0, 1.0, _offset));
vertices-push_back(osg::Vec3(0.0, _dist, _offset));
colors-push_back(grey);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINES,4,2));
//
//LINE_LOOP
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset/2.0));
colors-push_back(yellow);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,6,4));
g-setNormalArray(normals);
g-setVertexArray(vertices);
g-setColorArray(colors);
g-setNormalBinding(osg::Geometry::BIND_OVERALL);
g-setColorBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
g-setDataVariance(osg::Object::DYNAMIC);
//TRANSPARENCY
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::BlendFunc* bf = new
osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state-setAttributeAndModes(bf);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
g-setStateSet(state);
Re: [osg-users] Update Optimization
Hi Robert, Thanks for the advice, after using KdTree and LineSegmentIntersector, my update traversal rate reduce from 700ms to 60ms. Regards, John - Original Message From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, July 15, 2008 5:33:35 PM Subject: Re: [osg-users] Update Optimization Hi John, On Tue, Jul 15, 2008 at 2:48 AM, John Burgess [EMAIL PROTECTED] wrote: I've tried the KdTree but my update traversal rate is still the same as before. Below is my code snippet to enable KdTree, am I doing the right thing? osgDB::Registry::instance()-setBuildKdTreesHint(osgDB::ReaderWriter::Options::BUILD_KDTREES); // Load the terrain osg::Node* _terrain = osgDB::readNodeFile(terrainFile); You have to use osgUtil::IntersectionVisitor + LineSegmentIntersector to take advantage of the new KdTree intersections, the old (and deprecated) osgUtil::IntersectVisitor does not support KdTree intersection. 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] Update Optimization
Ho Johm, On Tue, Jul 15, 2008 at 11:33 AM, John Burgess [EMAIL PROTECTED] wrote: Thanks for the advice, after using KdTree and LineSegmentIntersector, my update traversal rate reduce from 700ms to 60ms. Much better, but still not good enough... How to get the time lower will depend upon what exactly is the new bottleneck, but this is something you'll need to look into by profiling the code at your end. There are high level things you could do as well, such as doing a round robin update of your objects, or caching the intersection data so that you reusing some of the traversal data between frames. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency on a drawable
Thanks a lot !
I did some changes to have the same osg file, and it work very good now !!!
It seems to be a mix of different settings.
thanks for your help.
Regards,
Vincent.
2008/7/15 dimi christop [EMAIL PROTECTED]:
Ok,
I fixed your osg file so that it displays varrying tranparency (top
transparent, bottom opaque).
I assume this is what you wanted.
Do an diff on the files and see what you did wrong You set the colors
per primitive and not per vertex.
- Original Message
From: Vincent Bourdier [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tuesday, July 15, 2008 1:19:23 PM
Subject: Re: [osg-users] Transparency on a drawable
Hi Dimi,
this is my code :
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
mat-setColorMode(osg::Material::AMBIENT_AND_DIFFUSE);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
osg::BlendFunc* bf = new osg::BlendFunc(osg::BlendFunc::SRC_ALPHA,
osg::BlendFunc::ONE_MINUS_SRC_ALPHA );
state-setAttributeAndModes(bf);
state-setRenderingHint(osg::StateSet::TRANSPARENT_BIN);
state-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
g-setStateSet(state);
there is no difference at all...
thanks for help.
Vincent.
2008/7/15 dimi christop [EMAIL PROTECTED]:
This is because when you set alpha to the vertices and attach also an
material
and a blending function you have to setColorMode (AMBIENT_DIFFUSE) on the
material.
Dimi
- Original Message
From: Vincent Bourdier [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tuesday, July 15, 2008 11:09:23 AM
Subject: Re: [osg-users] Transparency on a drawable
Hi Paul.
Nothing changes with color's alpha changed...
2008/7/15 Paul Speed [EMAIL PROTECTED]:
Vincent Bourdier wrote:
Hi
Yes, no solutions seems to work on my problem.
Because all the propositions concern nodes, I permit to remember that I
am looking at a way to set alpha level on a osg::Geometry ...
On node I already have a method using material : set alpha channel, and
it works good... But on my geometry nothing look to work good...
This is all my geometry creator code :
osg::ref_ptrosg::Geometry builtGeometry(){
double alpha = 0.1;
osg::Vec4 grey(0.4,0.4,0.4,1.0);
osg::Vec4 yellow(1.0,1.0,0.0,1.0);
What happens if you put alpha for the fourth value in your color?
-Paul
osg::Geometry* g = new osg::Geometry;
osg::Vec3Array* vertices= new osg::Vec3Array();
osg::Vec3Array* normals= new osg::Vec3Array();
osg::Vec4Array* colors= new osg::Vec4Array();
normals-push_back(osg::Vec3(0,0,1));
colors-push_back(grey);
//
//QUAD
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset));
if(!_empty)
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4));
else
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,0,4));
//-
//LINE
vertices-push_back(osg::Vec3(0.0, 1.0, _offset));
vertices-push_back(osg::Vec3(0.0, _dist, _offset));
colors-push_back(grey);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINES,4,2));
//
//LINE_LOOP
vertices-push_back(osg::Vec3( _width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, _height + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3(-_width/2.0, 0.0 + _dist,
_offset/2.0));
vertices-push_back(osg::Vec3( _width/2.0, 0.0 + _dist,
_offset/2.0));
colors-push_back(yellow);
g-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP,6,4));
g-setNormalArray(normals);
g-setVertexArray(vertices);
g-setColorArray(colors);
g-setNormalBinding(osg::Geometry::BIND_OVERALL);
g-setColorBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET);
g-setDataVariance(osg::Object::DYNAMIC);
//TRANSPARENCY
osg::StateSet* state = g-getOrCreateStateSet();
state-setMode(GL_BLEND,osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
osg::Material* mat = new osg::Material;
mat-setAlpha(osg::Material::FRONT_AND_BACK, alpha);
state-setAttributeAndModes(mat,osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);
[osg-users] OSG developers Australia? Melbourne?
All, Seeking OSG developers Australia to participate in developer study... I am undertaking a PhD in UML based 3D Software Visualisation at RMIT, Melbourne, Australia. As part of that I wish to investigate 3D software visualisation for use by OpenSceneGraph developers. My methodology is user centred, which means I need to first do a user task study to document how things are currently done, the issues developers have and whether (in theory) 3D software visualisation could help. If there are any OSG developers in Melbourne, Australia (or close 1000Km), that don't mind someone bugging them for a few hours while they work, please drop me an email (paul dot mcintosh at internetscooter dot com). Note: UML usage is not required and all levels of experience from student to professional is sort. Cheers, Paul -- Paul McIntosh www.internetscooter.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FindNodeVisitor Operation?
Hi David, Firstly thanks for reply. I actually want to handle part of model components and make some operation on them. I have tried findNodeVisitor sample for my model. My model has 7 children node and all of them are geode node. But I have 8 MatrixTransform node which are handle only 4 of them, so I can't handle some part of model. When I control the number of founded node with, findNodeVisitor findNode(3DSPIVOTPOINT: Translate pivotpoint to (world) origin); tankThreeGroup-accept(findNode); std::vectorosg::Node* nodeList = findNode.getNodeList(); int lenght=nodeList.size(); std::coutlenght : lenghtstd::endl; The output is 'lenght : 8' What can I do now? Should I create MatrixTransform nodes for the other unhandled nodes while traversing in the model? Or Can I handle other 3 nodes different way? You can download the model from here.( http://www.fileden.com/files/2007/9/10/1423182/GL_6000_v22.3DS) And you can use `osgconv GL_6000_v22.3DS GL_6000_v22.osg` then open GL_6000_v22.osg with notepad. Thanks so much. Best Regards. Ümit Uzun 2008/7/15 David Spilling [EMAIL PROTECTED]: Hi Ümit, osg::DOFTransform is a subclass of the more general osg::MatrixTransform. If I'm reading the intention of the model right, you have 2 MatrixTransform nodes - named *3DSPIVOTPOINT: Rotate* and *3DSPIVOTPOINT: Translate pivotpoint to (world) origin* above some geometry *1_planetar*. (Although your top level group has 6 other unlisted children as well). If you want to move/rotate/translate 1_planetar, use the NodeVisitor to find one of your two MatrixTransform nodes, and then set the transform's matrix yourself (via setMatrix(osg::Matrix myMatrix)). You will need to fill in the values of the matrix yourself based on what you want to do, but there are many many ways of doing this (makeRotate, makeTranslate, makeLookAt etc.) Alternatively, if you really want to use DOFTransform type methods, you could dynamic_cast the found MatrixTransform to a DOFTransform. Hope that helps, David ___ 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] Render to Texture
I'm attempting to render to a texture and then dump the rendered texture to a file (every frame), but I'm having trouble. I've attempted to use the osgprerender example (using the --image option), and replaced the MyCameraPostDrawCallback::operator() to have a osgDB::writeImageFile(*_image, fileName); where fileName is a .tif file (or .jpg file). When I look at the .tif file using the Linux display program, I get some funny banded image. What am I doing wrong? Is there a more efficient way to get access to the rendered image? Must I allocate an image array to the texture to access the image? Paul P. ___ 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, make sure the image writer can handle your image format. Bands usually mean an alignment error in the data the writer expects. E.g. expects binary input data to be RGB, but the data is RGBA. .jpg does not support alpha I think. Try .png jp [EMAIL PROTECTED] wrote: I'm attempting to render to a texture and then dump the rendered texture to a file (every frame), but I'm having trouble. I've attempted to use the osgprerender example (using the --image option), and replaced the MyCameraPostDrawCallback::operator() to have a osgDB::writeImageFile(*_image, fileName); where fileName is a .tif file (or .jpg file). When I look at the .tif file using the Linux display program, I get some funny banded image. What am I doing wrong? Is there a more efficient way to get access to the rendered image? Must I allocate an image array to the texture to access the image? Paul P. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget Remaining Issues
- The anti-aliased look of the fonts is really nice in most cases, but when trying to render small fonts it would be nice if you could disable it. Basically, I'd like to get the sharp look of the DefaultFont using the FreeType plugin. Just to reinforce the above point, we used the freetype library to generate OpenGL screen fonts here and found that for font sizes 12 Disabling anti-aliasing really improved the clarity of the font. So much so we made it automatically default to removing the AA when size below a threshold were set. I think this would be a great tweak to your work. Regards, Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Farshid Lashkari Sent: 14 July 2008 23:08 To: OpenSceneGraph Users Subject: Re: [osg-users] osgWidget Remaining Issues Hi Jeremy, I've also spent a lot of time trying to get crisp fonts rendered in OSG. Here are some things I have noticed: - The width/height of the orthographic projection matrix should match the width/height of the viewport being rendered to. - The font x,y position should be rounded to the nearest integer. Fractional positions will cause blurring. - Ideally the osgText node should not be underneath a Transform node that has scaling. Use the font resolution to adjust the size of the text. - You should use left aligned text. Using center aligned text causes blurring in some cases. If I need a font to be centered I manually compute the bounding box and position it to appear centered while still being left aligned internally. - The anti-aliased look of the fonts is really nice in most cases, but when trying to render small fonts it would be nice if you could disable it. Basically, I'd like to get the sharp look of the DefaultFont using the FreeType plugin. I'm still using OSG 1.2, so some of this might have changed. If you have any other advice on getting crisp fonts I'd be interested to know about it. I've also needed the ability to get the position of a specific glyph. However, I only needed the x position, so I just cropped the text to the glyph I needed, retrieved the bounding box, then restored the previous text. Hope this was helpful. -Farshid On Mon, Jul 14, 2008 at 1:45 PM, Jeremy Moles [EMAIL PROTECTED] wrote: As you've probably noticed, osgWidget development has been extremely stagnant of late. This is somewhat due to my lack of personal time, but in large part is due to a small number of remaining hurdles that I do not have a good solution to. Robert has sent me a few e-mails, and I've been encouraged to bring these issues up here for discussion. Hopefully, with the next release pending, we can work out solutions for these--even if they don't make it into the next release. :) My MAIN concerns at the moment are font-related. It's unfortunate that you have someone like me writing this NodeKit, because a different person probably wouldn't care as much. However, I am an absolute font crackhead, and I will settle for nothing less than the very best font quality possible using OSS. The following are some of the things I'm encountering with osgText as it exists in SVN; any and all input is welcome. 1. [ Font Clarity ] -- Getting crisp, consistent, arbitrarily-sized 2D fonts using osgText is proving very difficult. I have posted many times in the past on this, and have had varying amounts of success using the responses given. However, to this date, I cannot get a version of OSG--patched or otherwise--that will provide the font quality I'm used to seeing. I really wish I could give more info, or more in-depth technical details, but unfortunately my knowledge of the subject doesn't allow me to describe my observations any more intelligently. Robert accepted my osgfont example into SVN, so I would encourage anyone curious to take a look at that and run it with an invocation such as the following: # osgfont fonts/arial.ttf 10 11 12 13 14 15 You'll notice that at some sizes and locations, the text appears crisp and sharp. You'll also notice that at other places the text is blurry and smudged. Why this occurs I can't be sure, but I'll need to be able to identify those situations in which it does so that I can avoid them. 2. [ Low-level Font API ] -- In order to create a proper Input widget, I will need a low-level API for interfacing with the individual text elements (glyphs, characters, or whatever you refer to them as). At the minimum I will need a way to access the individual width, height, and baseline offset. I'm not quite sure how best to accomplish this, nor will I claim to be capable enough to hack osgText's current implementation and add it myself. However, there's no way I can personally conceive of to create an editable osgText object without knowing exactly what (preferrably integer) coordinates a
Re: [osg-users] FindNodeVisitor Operation?
Ümit, Firstly, do you need to add MatrixTransforms above all your geodes, or just the ones that have them now? You have a couple of strategies. The first one is to modify your model so it has uniquely named _MatrixTransforms_ above every geode. At the moment they are all called the same thing, so you end up finding 8 nodes when you look for a particular name. I don't know much about 3DS, so if it were up to me I would probably do it by hand editing the OSG file. However, this clearly impacts your art path (because updates to your model will always involve some hand editing). There is probably a way of persuading 3DS to name transforms... anybody? The second one is more programmatic. Your geodes are, at least, all uniquely named. You can search fo a geode, and then look for it's parent. If it's parent is a MatrixTransform, then you have your node. e.g. (lots of checks omitted) findNodeVisitor findNode(1_planetar); tankThreeGroup-accept(findNode); std::vectorosg::Node* nodeList = findNode.getNodeList(); osg::Node* node = nodeList[0]; // no check on size of list osg::MatrixTransform* tf = dynamic_castosg::MatrixTransform(node-getParent(0)); // no check on whether there is more than one parent if(tf!=NULL) // do stuff This route is hard to generalise. For example, there's no check on whether any geodes share a MatrixTransform as a parent - in which case strange things will happen later. Also if the parent isn't a MatrixTransform, you'll want to add one as a child to said parent, and move the geode across to be a child of the MatrixTransform via addChild, removeChild etc., which is a bit trickier. It will come down to how 3DStudio works in the end, I think, and what you can persuade it to output so that your approach can be generalised. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ArchiveStatus defined in osgDB/Archive
Hey Robert, I ran into issues while working on osgSwig Cmake files for Java. While trying to compile the java classes, javac complained about not knowing what Archive::ArchiveStatus was. I changed it locally to be ReaderWriter status and got by those javac compile errors. biv On 7/15/08 4:29 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Biv, Since Archive inherits from ReaderWriter, the Archive::ArchiveStatus is the same thing as ReaderWriter::ArchiveStatus. I guess it's possibly slightly less confusing to have the functions use ReaderWriter::ArchiveStatus, but there's not much in it. Robert. On Mon, Jul 14, 2008 at 10:39 PM, Gerrick Bivins [EMAIL PROTECTED] wrote: Hello All, Should the following lines in osgDB/Archive /** Open an archive for reading or writing.*/ OSGDB_EXPORT Archive* openArchive(const std::string filename, Archive::ArchiveStatus status, unsigned int indexBlockSizeHint=4096); /** Open an archive for reading or writing.*/ OSGDB_EXPORT Archive* openArchive(const std::string filename, Archive::ArchiveStatus status, unsigned int indexBlockSizeHint,ReaderWriter::Options* options); actually be : /** Open an archive for reading or writing.*/ OSGDB_EXPORT Archive* openArchive(const std::string filename, ReaderWriter::ArchiveStatus status, unsigned int indexBlockSizeHint=4096); /** Open an archive for reading or writing.*/ OSGDB_EXPORT Archive* openArchive(const std::string filename, ReaderWriter::ArchiveStatus status, unsigned int indexBlockSizeHint,ReaderWriter::Options* options); biv ___ 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] ArchiveStatus defined in osgDB/Archive
On Tue, Jul 15, 2008 at 2:03 PM, Gerrick Bivins [EMAIL PROTECTED] wrote: Hey Robert, I ran into issues while working on osgSwig Cmake files for Java. While trying to compile the java classes, javac complained about not knowing what Archive::ArchiveStatus was. I changed it locally to be ReaderWriter status and got by those javac compile errors. That's a concrete enough of reason for change, now checked into SVN. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ArchiveStatus defined in osgDB/Archive
Thanks! Now if only the rest were that easy!!! ;) biv On 7/15/08 8:43 AM, Robert Osfield [EMAIL PROTECTED] wrote: On Tue, Jul 15, 2008 at 2:03 PM, Gerrick Bivins [EMAIL PROTECTED] wrote: Hey Robert, I ran into issues while working on osgSwig Cmake files for Java. While trying to compile the java classes, javac complained about not knowing what Archive::ArchiveStatus was. I changed it locally to be ReaderWriter status and got by those javac compile errors. That's a concrete enough of reason for change, now checked into SVN. 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] FindNodeVisitor Operation?
Hi David, Thanks for your useful help. I will try to create new TransformMatrixes for unhandled geodes. First method can create so many problem. Programmatic way is more understandable. Maybe, after I create MatrixTransformes and collect all components then I can save .osg format the model with arranged type, and then I can read this .osg model instead of collection the parent-child status every time :) Best Regards, Ümit Uzun 2008/7/15 David Spilling [EMAIL PROTECTED]: Ümit, Firstly, do you need to add MatrixTransforms above all your geodes, or just the ones that have them now? You have a couple of strategies. The first one is to modify your model so it has uniquely named _MatrixTransforms_ above every geode. At the moment they are all called the same thing, so you end up finding 8 nodes when you look for a particular name. I don't know much about 3DS, so if it were up to me I would probably do it by hand editing the OSG file. However, this clearly impacts your art path (because updates to your model will always involve some hand editing). There is probably a way of persuading 3DS to name transforms... anybody? The second one is more programmatic. Your geodes are, at least, all uniquely named. You can search fo a geode, and then look for it's parent. If it's parent is a MatrixTransform, then you have your node. e.g. (lots of checks omitted) findNodeVisitor findNode(1_planetar); tankThreeGroup-accept(findNode); std::vectorosg::Node* nodeList = findNode.getNodeList(); osg::Node* node = nodeList[0]; // no check on size of list osg::MatrixTransform* tf = dynamic_castosg::MatrixTransform(node-getParent(0)); // no check on whether there is more than one parent if(tf!=NULL) // do stuff This route is hard to generalise. For example, there's no check on whether any geodes share a MatrixTransform as a parent - in which case strange things will happen later. Also if the parent isn't a MatrixTransform, you'll want to add one as a child to said parent, and move the geode across to be a child of the MatrixTransform via addChild, removeChild etc., which is a bit trickier. It will come down to how 3DStudio works in the end, I think, and what you can persuade it to output so that your approach can be generalised. David ___ 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] Using OsgViewerMFC to load a sphere
Hi All, I am a beginner of OSG. I used OsgViewerMFC to load a sphere into the scene, but it displays as an ellipsoid. The radius doesn't seem to be equal in two orthotropic axes. I find that it may be related to the width and height of the view window when initializing. The following codes are from OsgViewerMFC: ::GetWindowRect(m_hWnd, rect); . traits-x = 0; traits-y = 0; traits-width = rect.right - rect.left; traits-height = rect.bottom - rect.top; . osg::GraphicsContext* gc = osg::GraphicsContext::createGraphicsContext(traits.get()); How to solve this? Thanks for your advices in advance. Tang ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Looking for tips on importing osgWidget
Hi All, svn experts I need you!! I'm now ready to pull in Jeremy Moles work on osgWidget, and have tried: cd OpenSceneGraph/include svn copy http://osgwidget.googlecode.com/svn/trunk/include/osgWidget/ . Now this copies the files into my local copy, but reports the message: svn: Source URL 'http://osgwidget.googlecode.com/svn/trunk/include/osgWidget' is from foreign repository; leaving it as a disjoint WC What I was hoping was that svn would be clever enough to allow me to import the files and histories directly into the OSG's svn repository. I've done some searches on this topic on web and haven't really come up with anything that really tells me whether I'm doing is possible and if it is, how to go about it. Is there some option in svn that I'm missing? The easy fix that I know of would be to export the files from osgwidget.googlecode.com and then import these into the OSG. I know this will work, but it'll loose all the history. Thoughts? Suggestons? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for tips on importing osgWidget
On Tue, 2008-07-15 at 15:42 +0100, Robert Osfield wrote: Hi All, svn experts I need you!! I'm now ready to pull in Jeremy Moles work on osgWidget, and have tried: cd OpenSceneGraph/include svn copy http://osgwidget.googlecode.com/svn/trunk/include/osgWidget/ . Now this copies the files into my local copy, but reports the message: svn: Source URL 'http://osgwidget.googlecode.com/svn/trunk/include/osgWidget' is from foreign repository; leaving it as a disjoint WC What I was hoping was that svn would be clever enough to allow me to import the files and histories directly into the OSG's svn repository. I've done some searches on this topic on web and haven't really come up with anything that really tells me whether I'm doing is possible and if it is, how to go about it. Is there some option in svn that I'm missing? The easy fix that I know of would be to export the files from osgwidget.googlecode.com and then import these into the OSG. I know this will work, but it'll loose all the history. You would lose the history, but this may not be too big of a deal, really. I've been good about keeping the CHANGELOG up to date, but my commit messages are hardly worth preserving. As a matter of fact, I had always assumed you would import it from a local un-SVN'ified version, and that my horrible SVN log messages would go away. :) Thoughts? Suggestons? 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] Using image maps with materials
I have seen some examples, somewhere I think, where you could have one texture on the lit side of an object and then have another texture on the dark side. I am thinking of the earth where you could see lights in cities on the dark side. Did I really see that somewhere or is that my imagination? I have heard of using fragment shaders and it is something I would like to learn more about. Where can I find out about how to use multi-pass technique and/or register? On Tue, Jul 15, 2008 at 12:13 AM, Ulrich Hertlein [EMAIL PROTECTED] wrote: Hello Rick, [EMAIL PROTECTED] wrote: Is there a way to use image maps with some of the other material properties, like emission or specular or diffuse? I am working on ... how to use a reflection map, so I think I am ok there. Any way to use a map to define the emission, specularity, and diffuse amounts across a surface? There's no easy way to specify the material component that a texture should affect (such as emissive, specular) in plain OpenGL. The way to go these days is a fragment shader. You could also use a multi-pass technique to apply another texture. (Maybe register combiners offer something useful but I'm not sure about that.) Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Rick Check us out at http://fringe-online.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Linux Journal / OSG
In our company's advertisement the August edition of Linux Journal you'll see a picture of my laptop running OpenSceneGraph applications. :) It's nothing too special, but if any of you guys get LJ let me know if you can spot them... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for tips on importing osgWidget
Hi, El Martes 15 Julio 2008ES 16:42:12 Robert Osfield escribió: Is there some option in svn that I'm missing? Generally joining two repositories require to do some administration work with the svnadmin tools. First you would get the dump file of the osgWidget repository with svnadmin dump. Then you would insert the osgWidgets dump file into OSG repository with svnadmin load. The disadvantage is that osgWidgets will be put at the root of the repository. To place it anywhere, a common recommendation on SVN lists is to replace file paths into the dump file (with sed or similar) before uploading to the new server. It's not an automatic procedure but it's not very complicated either. Hope that helps, Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for tips on importing osgWidget
On Tue, Jul 15, 2008 at 3:44 PM, Jeremy Moles [EMAIL PROTECTED] wrote: You would lose the history, but this may not be too big of a deal, really. I've been good about keeping the CHANGELOG up to date, but my commit messages are hardly worth preserving. As a matter of fact, I had always assumed you would import it from a local un-SVN'ified version, and that my horrible SVN log messages would go away. :) We'll if you happy to see the history not reproduced then I'll just go ahead an do an import, I guess the googlecode SVN will still be around if do need to go hunting an old rev of some class. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for tips on importing osgWidget
Hi Alberto, Thanks for the explanation. It sounds like there a few steps extra in doing the full import of histories, given that Jeremy is up for a straight import minus histories I'll go this route for an easy life. Robert. On Tue, Jul 15, 2008 at 4:06 PM, Alberto Luaces [EMAIL PROTECTED] wrote: Hi, El Martes 15 Julio 2008ES 16:42:12 Robert Osfield escribió: Is there some option in svn that I'm missing? Generally joining two repositories require to do some administration work with the svnadmin tools. First you would get the dump file of the osgWidget repository with svnadmin dump. Then you would insert the osgWidgets dump file into OSG repository with svnadmin load. The disadvantage is that osgWidgets will be put at the root of the repository. To place it anywhere, a common recommendation on SVN lists is to replace file paths into the dump file (with sed or similar) before uploading to the new server. It's not an automatic procedure but it's not very complicated either. Hope that helps, Alberto ___ 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] Using OsgViewerMFC to load a sphere
Hi and welcome to OSG. You need to make sure your viewport and projection matrix have equivalent aspect ratios. The best way to do this in MFC is to use the viewport dimensions that your using (traits-width, traits-height) and then change your projection matrix to match that aspect ratio. -Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of TANG Fangqin Sent: Tuesday, July 15, 2008 10:34 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Using OsgViewerMFC to load a sphere Hi All, I am a beginner of OSG. I used OsgViewerMFC to load a sphere into the scene, but it displays as an ellipsoid. The radius doesn't seem to be equal in two orthotropic axes. I find that it may be related to the width and height of the view window when initializing. The following codes are from OsgViewerMFC: ::GetWindowRect(m_hWnd, rect); ... traits-x = 0; traits-y = 0; traits-width = rect.right - rect.left; traits-height = rect.bottom - rect.top; ... osg::GraphicsContext* gc = osg::GraphicsContext::createGraphicsContext(traits.get()); How to solve this? Thanks for your advices in advance. Tang ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget Remaining Issues
On Tue, Jul 15, 2008 at 5:41 AM, Kim C Bale [EMAIL PROTECTED] wrote: Just to reinforce the above point, we used the freetype library to generate OpenGL screen fonts here and found that for font sizes 12 Disabling anti-aliasing really improved the clarity of the font. So much so we made it automatically default to removing the AA when size below a threshold were set. Thanks for the advice Kim. Did you have to modify the source for the freetype plugin to disable AA? I can't find where this is an option? -Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgWidget now checked into OSG SVN trunk
Hi All, I have just completed the import of Jeremy Moles osgWidget library into OpenSceneGraph SVN trunk. I merged with relatively few changes - mainly just CMakeLists.txt file changes and move of imager/scripts/shaders out into OpenSceneGraph-Data SVN trunk. We need to come up with some new imagery files for the osgwidget examples so that we know we know the full history/license of them, as I've only placed the ones in OpenSceneGraph-Data that are original. We might be able to just reuse existing OpenSceneGraph-Data for these examples. There are also fonts references in the osgwidgets examples that I don't have in OpenSceneGraph-Data so we'll need to enumerate these and then replace/add them into OpenSceneGraph-Data where appropriate. Now osgWidget's is in OSG SVN it'll be exposed to much more testing across platforms so there is certainly potential for build problems. Picking these up early will allow us to fix them in plenty of time for 2.6 so I'd very much appreciate testing across as many platforms as people have access to. Just in case build issues do come about then you can disable the build of osgWidget via the BUILD_OSGWIDGET Cmake variable, this currently defaults to ON. If everything builds fine across all platforms then I'll drop build option to keep things simple. Thanks in advance for you assistance on testing. Once it looks like things are building across all our main platforms I'll go ahead and tag another dev release. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
Running ccmake I get: --- CMake Error: Error in cmake code at /home/cubicool/sources/svn-OpenSceneGraph/examples/CMakeLists.txt:152: Parse error. Expected a command name, got right paren with text ). The end of a CMakeLists file was reached with an IF statement that was not closed properly. Within the directory: /home/cubicool/sources/svn-OpenSceneGraph/examples The arguments are: DYNAMIC_OPENSCENEGRAPH The end of a CMakeLists file was reached with an IF statement that was not closed properly. Within the directory: /home/cubicool/sources/svn-OpenSceneGraph/examples The arguments are: BUILD_OSGWIDGET --- ...which I was able to fix by using the attached diff. I didn't figure it was a big enough issue to warrant a full-protocol submission for now... On Tue, 2008-07-15 at 17:58 +0100, Robert Osfield wrote: Hi All, I have just completed the import of Jeremy Moles osgWidget library into OpenSceneGraph SVN trunk. I merged with relatively few changes - mainly just CMakeLists.txt file changes and move of imager/scripts/shaders out into OpenSceneGraph-Data SVN trunk. We need to come up with some new imagery files for the osgwidget examples so that we know we know the full history/license of them, as I've only placed the ones in OpenSceneGraph-Data that are original. We might be able to just reuse existing OpenSceneGraph-Data for these examples. There are also fonts references in the osgwidgets examples that I don't have in OpenSceneGraph-Data so we'll need to enumerate these and then replace/add them into OpenSceneGraph-Data where appropriate. Now osgWidget's is in OSG SVN it'll be exposed to much more testing across platforms so there is certainly potential for build problems. Picking these up early will allow us to fix them in plenty of time for 2.6 so I'd very much appreciate testing across as many platforms as people have access to. Just in case build issues do come about then you can disable the build of osgWidget via the BUILD_OSGWIDGET Cmake variable, this currently defaults to ON. If everything builds fine across all platforms then I'll drop build option to keep things simple. Thanks in advance for you assistance on testing. Once it looks like things are building across all our main platforms I'll go ahead and tag another dev release. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Index: ../examples/CMakeLists.txt === --- ../examples/CMakeLists.txt (revision 8588) +++ ../examples/CMakeLists.txt (working copy) @@ -149,7 +149,7 @@ ADD_SUBDIRECTORY(osgviewerCocoa) ENDIF(APPLE) -IF (BUILD_OSGWIDGET)) +IF (BUILD_OSGWIDGET) ADD_SUBDIRECTORY(osgwidgetaddremove) ADD_SUBDIRECTORY(osgwidgetbox) ADD_SUBDIRECTORY(osgwidgetcanvas) @@ -163,7 +163,7 @@ ADD_SUBDIRECTORY(osgwidgetstyled) ADD_SUBDIRECTORY(osgwidgettable) ADD_SUBDIRECTORY(osgwidgetversion) -ADD_SUBDIRECTORY(osgwidgetwindow +ADD_SUBDIRECTORY(osgwidgetwindow) ENDIF(BUILD_OSGWIDGET) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
Sorry about this, typo on editing a CMakeLists.txt, I've now made the fix and checked it in, I presume it'll be the same as yours. On Tue, Jul 15, 2008 at 6:33 PM, Jeremy Moles [EMAIL PROTECTED] wrote: Running ccmake I get: --- CMake Error: Error in cmake code at /home/cubicool/sources/svn-OpenSceneGraph/examples/CMakeLists.txt:152: Parse error. Expected a command name, got right paren with text ). The end of a CMakeLists file was reached with an IF statement that was not closed properly. Within the directory: /home/cubicool/sources/svn-OpenSceneGraph/examples The arguments are: DYNAMIC_OPENSCENEGRAPH The end of a CMakeLists file was reached with an IF statement that was not closed properly. Within the directory: /home/cubicool/sources/svn-OpenSceneGraph/examples The arguments are: BUILD_OSGWIDGET --- ...which I was able to fix by using the attached diff. I didn't figure it was a big enough issue to warrant a full-protocol submission for now... On Tue, 2008-07-15 at 17:58 +0100, Robert Osfield wrote: Hi All, I have just completed the import of Jeremy Moles osgWidget library into OpenSceneGraph SVN trunk. I merged with relatively few changes - mainly just CMakeLists.txt file changes and move of imager/scripts/shaders out into OpenSceneGraph-Data SVN trunk. We need to come up with some new imagery files for the osgwidget examples so that we know we know the full history/license of them, as I've only placed the ones in OpenSceneGraph-Data that are original. We might be able to just reuse existing OpenSceneGraph-Data for these examples. There are also fonts references in the osgwidgets examples that I don't have in OpenSceneGraph-Data so we'll need to enumerate these and then replace/add them into OpenSceneGraph-Data where appropriate. Now osgWidget's is in OSG SVN it'll be exposed to much more testing across platforms so there is certainly potential for build problems. Picking these up early will allow us to fix them in plenty of time for 2.6 so I'd very much appreciate testing across as many platforms as people have access to. Just in case build issues do come about then you can disable the build of osgWidget via the BUILD_OSGWIDGET Cmake variable, this currently defaults to ON. If everything builds fine across all platforms then I'll drop build option to keep things simple. Thanks in advance for you assistance on testing. Once it looks like things are building across all our main platforms I'll go ahead and tag another dev release. Cheers, 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
Hello Robert, Regarding osgWidget's examples, should their CMakeLists.txt files use the SETUP_EXAMPLE() macro as do all the other OSG examples? I would assume so since this will make things more consistent. If so I can help convert them to use this macro. Also, do we want osgwidgetversion as an example? Since osgWidget is now part of core OSG, should it have its own version? J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
Looks like there's a small spelling error in the style plugin placeholder; it's calling itself: osgdb_osgwisget :) On Tue, 2008-07-15 at 18:39 +0100, Robert Osfield wrote: Sorry about this, typo on editing a CMakeLists.txt, I've now made the fix and checked it in, I presume it'll be the same as yours. On Tue, Jul 15, 2008 at 6:33 PM, Jeremy Moles [EMAIL PROTECTED] wrote: Running ccmake I get: --- CMake Error: Error in cmake code at /home/cubicool/sources/svn-OpenSceneGraph/examples/CMakeLists.txt:152: Parse error. Expected a command name, got right paren with text ). The end of a CMakeLists file was reached with an IF statement that was not closed properly. Within the directory: /home/cubicool/sources/svn-OpenSceneGraph/examples The arguments are: DYNAMIC_OPENSCENEGRAPH The end of a CMakeLists file was reached with an IF statement that was not closed properly. Within the directory: /home/cubicool/sources/svn-OpenSceneGraph/examples The arguments are: BUILD_OSGWIDGET --- ...which I was able to fix by using the attached diff. I didn't figure it was a big enough issue to warrant a full-protocol submission for now... On Tue, 2008-07-15 at 17:58 +0100, Robert Osfield wrote: Hi All, I have just completed the import of Jeremy Moles osgWidget library into OpenSceneGraph SVN trunk. I merged with relatively few changes - mainly just CMakeLists.txt file changes and move of imager/scripts/shaders out into OpenSceneGraph-Data SVN trunk. We need to come up with some new imagery files for the osgwidget examples so that we know we know the full history/license of them, as I've only placed the ones in OpenSceneGraph-Data that are original. We might be able to just reuse existing OpenSceneGraph-Data for these examples. There are also fonts references in the osgwidgets examples that I don't have in OpenSceneGraph-Data so we'll need to enumerate these and then replace/add them into OpenSceneGraph-Data where appropriate. Now osgWidget's is in OSG SVN it'll be exposed to much more testing across platforms so there is certainly potential for build problems. Picking these up early will allow us to fix them in plenty of time for 2.6 so I'd very much appreciate testing across as many platforms as people have access to. Just in case build issues do come about then you can disable the build of osgWidget via the BUILD_OSGWIDGET Cmake variable, this currently defaults to ON. If everything builds fine across all platforms then I'll drop build option to keep things simple. Thanks in advance for you assistance on testing. Once it looks like things are building across all our main platforms I'll go ahead and tag another dev release. Cheers, 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 ___ 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] osgWidget now checked into OSG SVN trunk
On Tue, 2008-07-15 at 19:41 +0100, Robert Osfield wrote: Hi Jeremy, On Tue, Jul 15, 2008 at 6:50 PM, Jeremy Moles [EMAIL PROTECTED] wrote: Looks like there's a small spelling error in the style plugin placeholder; it's calling itself: I haven't merged the style plugin, I'll leave a merge of this plugin for when it has some functionality to offer. The less extra stuff we have in SVN before we do 2.6 the better. Ah, I misspoke; I meant the regular osgdb export plugin. 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] osgWidget now checked into OSG SVN trunk
On Tue, 2008-07-15 at 14:27 -0400, Jean-Sébastien Guay wrote: Hello Robert, Jeremy, Thanks in advance for you assistance on testing. Once it looks like things are building across all our main platforms I'll go ahead and tag another dev release. Builds on Windows Vista, VS8 here, with the previously posted fixes and the changed osgwidget example CMakeLists.txt files. I'm getting some errors in the osgWidget examples which I didn't get when osgWidget was separate from OSG though: osgwidgetbox doesn't display anything There should be two windows (this is an attempt at using CompositeViewer). As you can see, I fail. :) osgwidgetshader can't find the shaders, even if I updated the OpenSceneGraph-Data from SVN and they're there... In osgwidgetnotebook, when clicking on a tab, I get osgWidget: Window [notebook] couldn't find the Widget [Tab_0] in it's object list. There are some remaining focus list bugs I'm working on... but the behavior seems correct (i.e. the correct tab becomes active). On startup, osgwidgetmenu gives osgWidget: Window [Menu_Pick me!] can't call resizeAdd() with the values -72 and 0 osgWidget: Window [Menu_Pick me!] can't call resizeAdd() with the values -72 and 0 osgWidget: Window [Menu_Pick me!] can't call resizeAdd() with the values -72 and 0 osgWidget: Window [Menu_Pick me!] can't call resizeAdd() with the values -72 and 0 osgWidget: Window [Menu_Grarar!?!] can't call resizeAdd() with the values -64 and 0 osgWidget: Window [Menu_Pick me!] can't call resizeAdd() with the values -72 and 0 osgWidget: Window [Menu_Grarar!?!] can't call resizeAdd() with the values -64 and 0 (apart from the font not found messages) and there is no menu on screen. Finally, and this is something that bugged me before but should probably be fixed now that osgWidget is part of core OSG: it seems like the osgWidget examples set some values for the window (viewer.setUpViewInWindow(0, 0, 1280, 1024);) whereas they should just use the normal viewer and let the user set OSG_WINDOW, or --window, or whatever themselves. On Windows, particularly, using setUpViewInWindow(0, 0, 1280, 1024) gives a window whose extents go out of the screen, so the top of the graphics window is chopped off... Ah, interesting. I always figured I was doing folks a favor by hard-coding a small size, but code can certainly be added to have it behave as you suggest. The key is to make sure that the orthographic camera is properly resized properly, which should be done by the ResizeHandler object. Let me know if there is any more testing I can do. The next step once we fix these issues is probably to get a few screenshots to make sure the output is correct w.r.t. what you expect. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KD-Tree Performance Challenge....
Hi Adrian, On Tue, Jul 15, 2008 at 7:44 PM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: I played with the osg::KDtree.cpp and did a review. then after thinking a while how we can reduce the number of flops, i found one first optimisation we should do. the ray or just a line with starting point s and ending point e is during the whole intersection test static, so we can precalculate the direction and also the inverse direction and store this information in dir / invdir. 1-KdTree.cpp the performance win is about 10-12% ** should be check in ** If you feel its appropriate to check in could you please post to osg-submissions. we can assume that we can get in general a very bad posed problem. assume that we have a scene with n triangles and each triangle has exactly the same center point. Very bad geometry but then we can never seperate them, so we will get a kdTree with max number of levels. i assumed, if there is a split with too less seperation behaviour, we do just a 50-50 split. may this isn't yet the best idea, but i helps. Um well if someone has this extreme example of worst possible triangle set up then there apps is screwed up anyway so if KdTree doesn't perform perfect well then too bad, garbage in garbage out. Is see no reason to go trying to catch silly cases. In the case of the current implement such a silly case would just under up with a single branch down to the max level number of division, there wouldn't be any side branches. You wouldn't see any division, so you wouldn't get a performance improvement, but then the cost of traversing down the levels will be trivial anyway. It's basically a non issue. But i know we should talk about this, because the kdTree should be as small as possible with best performance in building and intersection check ,... not only line / ray. As long as it works well in the vast majority of cases I'm happy. One could try and gun for best performance, but you are almost certainly wasting most of your time in developing. As I've said before the KdTree traversal isn't the bottleneck on normal IntersectionVisitor traversal its the actual scene graph traversal - this is where the bottleneck is which is the most important to address. As for other intersection types, for 2.6 I'm happy with what we have. We can add other intersections types on a need be basis. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
Hi Jeremy, Ah, interesting. I always figured I was doing folks a favor by hard-coding a small size, but code can certainly be added to have it behave as you suggest. Well, I (and most people with 19 inch monitors) have 1280x1024 native resolution, so your window should fill the whole screen, but it's the 0,0 that actually causes problems. On Windows, if you give (x,y) = (0,0), then the top of the window frame is outside the screen so you can't drag it to move it! I always found that weird. In any case, an OSG example should just use the default viewer.run() and let the environment variables / command-line args determine how the window should look. And it will actually be less code... Remove that setUpViewInWindow line :-) The key is to make sure that the orthographic camera is properly resized properly, which should be done by the ResizeHandler object. The ortho camera should be sized appropriately for the screen anyways, shouldn't it? I thought that was default OSG behavior... J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
On Tue, 2008-07-15 at 15:04 -0400, Jean-Sébastien Guay wrote: Hi Jeremy, Ah, interesting. I always figured I was doing folks a favor by hard-coding a small size, but code can certainly be added to have it behave as you suggest. Well, I (and most people with 19 inch monitors) have 1280x1024 native resolution, so your window should fill the whole screen, but it's the 0,0 that actually causes problems. On Windows, if you give (x,y) = (0,0), then the top of the window frame is outside the screen so you can't drag it to move it! I always found that weird. In any case, an OSG example should just use the default viewer.run() and let the environment variables / command-line args determine how the window should look. And it will actually be less code... Remove that setUpViewInWindow line :-) The key is to make sure that the orthographic camera is properly resized properly, which should be done by the ResizeHandler object. The ortho camera should be sized appropriately for the screen anyways, shouldn't it? I thought that was default OSG behavior... I do not believe so; or at least, it's behavior is consistent with what we're each talking about, which man not be the same thing. From my experience, if you have a 1024x768 orthographic camera-in-camera setup for your HUD, and then you make the window fullscreen, the orthographic camera still has a resolution of 1024x768, even though your new dimensions are 1280x1024. With a UI, you really need to have constnt awareness of your absolute pixel width and height, even if your code doesn't directly use it. It's all up to the ResizeHandler though; if you wanted to ALWAYS work in some coordinate space like 1024x768, it should be possible just by using (or perhaps not even using) a different ResizeHandler. The one I created in ViewerEventHandler, however, tries to make sure the WindowManager object always knows the exact pixel dimensions of the View. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
Hi JS and Jeremy, On Tue, Jul 15, 2008 at 8:14 PM, Jeremy Moles [EMAIL PROTECTED] wrote: From my experience, if you have a 1024x768 orthographic camera-in-camera setup for your HUD, and then you make the window fullscreen, the orthographic camera still has a resolution of 1024x768, even though your new dimensions are 1280x1024. With a UI, you really need to have constnt awareness of your absolute pixel width and height, even if your code doesn't directly use it. It's all up to the ResizeHandler though; if you wanted to ALWAYS work in some coordinate space like 1024x768, it should be possible just by using (or perhaps not even using) a different ResizeHandler. The one I created in ViewerEventHandler, however, tries to make sure the WindowManager object always knows the exact pixel dimensions of the View. Camera in a Viewer will get resized automatically, by Camera's in the scene graph won't be. An event callback on such cameras might be able to catch resizes. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
Hi Jeremy, On Tue, Jul 15, 2008 at 7:46 PM, Jeremy Moles [EMAIL PROTECTED] wrote: There are some remaining focus list bugs I'm working on... We have a BugResolution page on the wiki, I'd suggest putting outstanding bugs on here, we can then work out which ones will be possible to resolve before 2.6 and what ones will have to be tackled after. Later this evening I'll add general OSG bugs that I haven't resolved yet. http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/BugResolution Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
On Tue, 2008-07-15 at 20:19 +0100, Robert Osfield wrote: Hi JS and Jeremy, On Tue, Jul 15, 2008 at 8:14 PM, Jeremy Moles [EMAIL PROTECTED] wrote: From my experience, if you have a 1024x768 orthographic camera-in-camera setup for your HUD, and then you make the window fullscreen, the orthographic camera still has a resolution of 1024x768, even though your new dimensions are 1280x1024. With a UI, you really need to have constnt awareness of your absolute pixel width and height, even if your code doesn't directly use it. It's all up to the ResizeHandler though; if you wanted to ALWAYS work in some coordinate space like 1024x768, it should be possible just by using (or perhaps not even using) a different ResizeHandler. The one I created in ViewerEventHandler, however, tries to make sure the WindowManager object always knows the exact pixel dimensions of the View. Camera in a Viewer will get resized automatically, by Camera's in the scene graph won't be. An event callback on such cameras might be able to catch resizes. Yeah, that's exactly what osgWidget::ResizeHandler does now with the RESIZE event... 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] osgWidget now checked into OSG SVN trunk
Hi Jeremy, It's all up to the ResizeHandler though; if you wanted to ALWAYS work in some coordinate space like 1024x768, it should be possible just by using (or perhaps not even using) a different ResizeHandler. The one I created in ViewerEventHandler, however, tries to make sure the WindowManager object always knows the exact pixel dimensions of the View. The question is will it be automatic? If, for a HUD, you always want to have pixel-exact mapping, then it should be automatic and not depend on what size the user sets his window to. I'll leave the details to you, as you're much better placed to understand what's involved. All I'm saying is that osgViewer supports users setting environment variables or passing command-line arguments to control how the window appears, and I think that in examples, these should not be overridden by hard-coding a window position/size. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
Hi Jeremy, J-S, Robert, I just updated to the latest and greatest (r8597), and the new osgWidget code is throwing the following errors when I try to compile: 64Bit Linux, RHEL4, gcc3.4.6 src/osgWidget/Window.cpp: In member function `bool osgWidget::Window::EmbeddedWindow::setWindow(osgWidget::Window*)': include/osgWidget/Widget:67: error: `osgWidget::Window*osgWidget::Widget::_parent' is private src/osgWidget/Window.cpp:118: error: within this context include/osgWidget/Widget:67: error: `osgWidget::Window*osgWidget::Widget::_parent' is private src/osgWidget/Window.cpp:118: error: within this context include/osgWidget/Widget:112: error: `osgWidget::WindowManager* osgWidget::Widget::_getWindowManager() const' is private src/osgWidget/Window.cpp:120: error: within this context include/osgWidget/Widget:112: error: `osgWidget::WindowManager* osgWidget::Widget::_getWindowManager() const' is private src/osgWidget/Window.cpp:120: error: within this context src/osgWidget/Window.cpp: In member function `void osgWidget::Window::_removeFromGeode(osgWidget::Widget*)': src/osgWidget/Window.cpp:413: warning: converting of negative value `-0x1' to `unsigned int' gmake[3]: *** [src/osgWidget/CMakeFiles/osgWidget.dir/Window.o] Error 1 gmake[3]: Leaving directory `BUILD/Linux/x86_64' gmake[2]: *** [src/osgWidget/CMakeFiles/osgWidget.dir/all] Error 2 gmake[2]: Leaving directory `BUILD/Linux/x86_64' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `BUILD/Linux/x86_64' gmake: *** [build] Error 2 The following minor modifications seem to resolve the errors. Is this an acceptable modification? #if 0 // SVN r8597 if(_parent) parented(_parent); WindowManager* wm = _getWindowManager(); #else // My modifications: if (getParent()) parented(getParent()); WindowManager* wm = getWindowManager(); #endif Thanks, Justin P.S. Other than that, the source tree seems to be building fine ... 44% done ... will update after coffee :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, July 15, 2008 3:21 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgWidget now checked into OSG SVN trunk Hi Jeremy, It's all up to the ResizeHandler though; if you wanted to ALWAYS work in some coordinate space like 1024x768, it should be possible just by using (or perhaps not even using) a different ResizeHandler. The one I created in ViewerEventHandler, however, tries to make sure the WindowManager object always knows the exact pixel dimensions of the View. The question is will it be automatic? If, for a HUD, you always want to have pixel-exact mapping, then it should be automatic and not depend on what size the user sets his window to. I'll leave the details to you, as you're much better placed to understand what's involved. All I'm saying is that osgViewer supports users setting environment variables or passing command-line arguments to control how the window appears, and I think that in examples, these should not be overridden by hard-coding a window position/size. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget now checked into OSG SVN trunk
Hi Justin, My guess is that we can probably relax the use of private: in this context. I've moved the private sections into the protected section, and re-ordered the class interface so that the public section is first, along the lines of the rest of the OSG. An svn update will provide this change. Could you test this out. Thanks, Robert. On Tue, Jul 15, 2008 at 8:49 PM, Vican, Justin E. [EMAIL PROTECTED] wrote: Hi Jeremy, J-S, Robert, I just updated to the latest and greatest (r8597), and the new osgWidget code is throwing the following errors when I try to compile: 64Bit Linux, RHEL4, gcc3.4.6 src/osgWidget/Window.cpp: In member function `bool osgWidget::Window::EmbeddedWindow::setWindow(osgWidget::Window*)': include/osgWidget/Widget:67: error: `osgWidget::Window*osgWidget::Widget::_parent' is private src/osgWidget/Window.cpp:118: error: within this context include/osgWidget/Widget:67: error: `osgWidget::Window*osgWidget::Widget::_parent' is private src/osgWidget/Window.cpp:118: error: within this context include/osgWidget/Widget:112: error: `osgWidget::WindowManager* osgWidget::Widget::_getWindowManager() const' is private src/osgWidget/Window.cpp:120: error: within this context include/osgWidget/Widget:112: error: `osgWidget::WindowManager* osgWidget::Widget::_getWindowManager() const' is private src/osgWidget/Window.cpp:120: error: within this context src/osgWidget/Window.cpp: In member function `void osgWidget::Window::_removeFromGeode(osgWidget::Widget*)': src/osgWidget/Window.cpp:413: warning: converting of negative value `-0x1' to `unsigned int' gmake[3]: *** [src/osgWidget/CMakeFiles/osgWidget.dir/Window.o] Error 1 gmake[3]: Leaving directory `BUILD/Linux/x86_64' gmake[2]: *** [src/osgWidget/CMakeFiles/osgWidget.dir/all] Error 2 gmake[2]: Leaving directory `BUILD/Linux/x86_64' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `BUILD/Linux/x86_64' gmake: *** [build] Error 2 The following minor modifications seem to resolve the errors. Is this an acceptable modification? #if 0 // SVN r8597 if(_parent) parented(_parent); WindowManager* wm = _getWindowManager(); #else // My modifications: if (getParent()) parented(getParent()); WindowManager* wm = getWindowManager(); #endif Thanks, Justin P.S. Other than that, the source tree seems to be building fine ... 44% done ... will update after coffee :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, July 15, 2008 3:21 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgWidget now checked into OSG SVN trunk Hi Jeremy, It's all up to the ResizeHandler though; if you wanted to ALWAYS work in some coordinate space like 1024x768, it should be possible just by using (or perhaps not even using) a different ResizeHandler. The one I created in ViewerEventHandler, however, tries to make sure the WindowManager object always knows the exact pixel dimensions of the View. The question is will it be automatic? If, for a HUD, you always want to have pixel-exact mapping, then it should be automatic and not depend on what size the user sets his window to. I'll leave the details to you, as you're much better placed to understand what's involved. All I'm saying is that osgViewer supports users setting environment variables or passing command-line arguments to control how the window appears, and I think that in examples, these should not be overridden by hard-coding a window position/size. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] osgWidget now checked into OSG SVN trunk
Robert, I've got a patch incoming fixing all of the data problems and what-have-you. I'll also attach a zipfile of the new stuff for OpenSceneGraph-Data, which is all safe to use and redistribute. On Tue, 2008-07-15 at 17:58 +0100, Robert Osfield wrote: Hi All, I have just completed the import of Jeremy Moles osgWidget library into OpenSceneGraph SVN trunk. I merged with relatively few changes - mainly just CMakeLists.txt file changes and move of imager/scripts/shaders out into OpenSceneGraph-Data SVN trunk. We need to come up with some new imagery files for the osgwidget examples so that we know we know the full history/license of them, as I've only placed the ones in OpenSceneGraph-Data that are original. We might be able to just reuse existing OpenSceneGraph-Data for these examples. There are also fonts references in the osgwidgets examples that I don't have in OpenSceneGraph-Data so we'll need to enumerate these and then replace/add them into OpenSceneGraph-Data where appropriate. Now osgWidget's is in OSG SVN it'll be exposed to much more testing across platforms so there is certainly potential for build problems. Picking these up early will allow us to fix them in plenty of time for 2.6 so I'd very much appreciate testing across as many platforms as people have access to. Just in case build issues do come about then you can disable the build of osgWidget via the BUILD_OSGWIDGET Cmake variable, this currently defaults to ON. If everything builds fine across all platforms then I'll drop build option to keep things simple. Thanks in advance for you assistance on testing. Once it looks like things are building across all our main platforms I'll go ahead and tag another dev release. Cheers, 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] osgWidget now checked into OSG SVN trunk
On Tue, 2008-07-15 at 16:29 -0400, Vican, Justin E. wrote: Hi Robert, That did the trick. Everything in r8598 builds fine (Linux RHEL4, 64Bit, gcc3.4.6). All of the osgWidget example applications build and run without crashing, but I am getting warnings/errors about missing files/images. I think Jeremy is sending some submissions for the OpenSceneGraph-Data repository, so these issues will probably be resolved once they are in. These are now submitted; however, its awaiting moderator approval for being too big. :) Thanks, Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Tuesday, July 15, 2008 3:59 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgWidget now checked into OSG SVN trunk Hi Justin, My guess is that we can probably relax the use of private: in this context. I've moved the private sections into the protected section, and re-ordered the class interface so that the public section is first, along the lines of the rest of the OSG. An svn update will provide this change. Could you test this out. Thanks, Robert. On Tue, Jul 15, 2008 at 8:49 PM, Vican, Justin E. [EMAIL PROTECTED] wrote: Hi Jeremy, J-S, Robert, I just updated to the latest and greatest (r8597), and the new osgWidget code is throwing the following errors when I try to compile: 64Bit Linux, RHEL4, gcc3.4.6 src/osgWidget/Window.cpp: In member function `bool osgWidget::Window::EmbeddedWindow::setWindow(osgWidget::Window*)': include/osgWidget/Widget:67: error: `osgWidget::Window*osgWidget::Widget::_parent' is private src/osgWidget/Window.cpp:118: error: within this context include/osgWidget/Widget:67: error: `osgWidget::Window*osgWidget::Widget::_parent' is private src/osgWidget/Window.cpp:118: error: within this context include/osgWidget/Widget:112: error: `osgWidget::WindowManager* osgWidget::Widget::_getWindowManager() const' is private src/osgWidget/Window.cpp:120: error: within this context include/osgWidget/Widget:112: error: `osgWidget::WindowManager* osgWidget::Widget::_getWindowManager() const' is private src/osgWidget/Window.cpp:120: error: within this context src/osgWidget/Window.cpp: In member function `void osgWidget::Window::_removeFromGeode(osgWidget::Widget*)': src/osgWidget/Window.cpp:413: warning: converting of negative value `-0x1' to `unsigned int' gmake[3]: *** [src/osgWidget/CMakeFiles/osgWidget.dir/Window.o] Error 1 gmake[3]: Leaving directory `BUILD/Linux/x86_64' gmake[2]: *** [src/osgWidget/CMakeFiles/osgWidget.dir/all] Error 2 gmake[2]: Leaving directory `BUILD/Linux/x86_64' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `BUILD/Linux/x86_64' gmake: *** [build] Error 2 The following minor modifications seem to resolve the errors. Is this an acceptable modification? #if 0 // SVN r8597 if(_parent) parented(_parent); WindowManager* wm = _getWindowManager(); #else // My modifications: if (getParent()) parented(getParent()); WindowManager* wm = getWindowManager(); #endif Thanks, Justin P.S. Other than that, the source tree seems to be building fine ... 44% done ... will update after coffee :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, July 15, 2008 3:21 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgWidget now checked into OSG SVN trunk Hi Jeremy, It's all up to the ResizeHandler though; if you wanted to ALWAYS work in some coordinate space like 1024x768, it should be possible just by using (or perhaps not even using) a different ResizeHandler. The one I created in ViewerEventHandler, however, tries to make sure the WindowManager object always knows the exact pixel dimensions of the View. The question is will it be automatic? If, for a HUD, you always want to have pixel-exact mapping, then it should be automatic and not depend on what size the user sets his window to. I'll leave the details to you, as you're much better placed to understand what's involved. All I'm saying is that osgViewer supports users setting environment variables or passing command-line arguments to control how the window appears, and I think that in examples, these should not be overridden by hard-coding a window position/size. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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
Re: [osg-users] KD-Tree Performance Challenge....
2008/7/15 Robert Osfield [EMAIL PROTECTED]: Hi Adrian, On Tue, Jul 15, 2008 at 7:44 PM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: I played with the osg::KDtree.cpp and did a review. then after thinking a while how we can reduce the number of flops, i found one first optimisation we should do. the ray or just a line with starting point s and ending point e is during the whole intersection test static, so we can precalculate the direction and also the inverse direction and store this information in dir / invdir. 1-KdTree.cpp the performance win is about 10-12% ** should be check in ** If you feel its appropriate to check in could you please post to osg-submissions. :-) we can assume that we can get in general a very bad posed problem. assume that we have a scene with n triangles and each triangle has exactly the same center point. Very bad geometry but then we can never seperate them, so we will get a kdTree with max number of levels. i assumed, if there is a split with too less seperation behaviour, we do just a 50-50 split. may this isn't yet the best idea, but i helps. Um well if someone has this extreme example of worst possible triangle set up then there apps is screwed up anyway so if KdTree doesn't perform perfect well then too bad, garbage in garbage out. Is see no reason to go trying to catch silly cases. In the case of the current implement such a silly case would just under up with a single branch down to the max level number of division, there wouldn't be any side branches. You wouldn't see any division, so you wouldn't get a performance improvement, but then the cost of traversing down the levels will be trivial anyway. It's basically a non issue. But i know we should talk about this, because the kdTree should be as small as possible with best performance in building and intersection check ,... not only line / ray. As long as it works well in the vast majority of cases I'm happy. One could try and gun for best performance, but you are almost certainly wasting most of your time in developing. As I've said before the KdTree traversal isn't the bottleneck on normal IntersectionVisitor traversal its the actual scene graph traversal - this is where the bottleneck is which is the most important to address. As for other intersection types, for 2.6 I'm happy with what we have. We can add other intersections types on a need be basis. correct :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to take a picture of my scene?
eee!! I did it ! I m doing videos with the code of osghelp page and ffmepg on linux . tomorrow I put the code here using an osg::Camera thank you guys ! no more tears :D ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
