Re: [osg-users] PositionAttitudeTransform operation order
Hi Robert, I would not have asked if the effect I see is not consistent with what I can understand from the code. In fact, as I wrote, I see translations done before rotations setting position and attitude on the same PAT node. Anyway there maust be a reason why scale is implemented so that it affects rotation and transaltion values. It sounds correct than that I had to add another PAT as child node to avoid rotation and translation scaling. I guess there are many other scenarios in which the scale must affect rotation and translation instead. Cheers, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60934#60934 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PositionAttitudeTransform operation order
HI Gianni, The PositionAttitudeTransform code is fine, been used for many years without problems. As to your own perceptions/expectations, well if they don't tally with the implementation of PositionAttitudeTransform then you can always implement your own subclass from osg::Transform and implement your own transform. The osg::Transform base class exists solely to make it possible to provide custom behaviours for transforms. Robert. On 3 September 2014 09:29, Gianni Ambrosio g.ambrosio+...@gmail.com wrote: Hi Robert, I would not have asked if the effect I see is not consistent with what I can understand from the code. In fact, as I wrote, I see translations done before rotations setting position and attitude on the same PAT node. Anyway there maust be a reason why scale is implemented so that it affects rotation and transaltion values. It sounds correct than that I had to add another PAT as child node to avoid rotation and translation scaling. I guess there are many other scenarios in which the scale must affect rotation and translation instead. Cheers, Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60934#60934 ___ 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] create a OSG wiki: (it was OpenSceneGraph Oculus Rift integration )
I think making it two projects could be an advantage, specially if the docs are large, because you can check out the source code without having to transfer tons of data for doc-files, which might not be locally used by many. Any cons? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60936#60936 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [forum] Set color for the black lines of a shapefile model
Hi, I'm a new user needing to load a simple shapefile with a set of geographical lines into my scene. By default its lines are black, while I need to turn them to white. Looking around in the web and on this forum, I found how to change line thickness usign an LineWidth object set to the model node, but no information on how change line color of a only-lines model. The Material object seems to not do the job: Code: osg::ref_ptrosg::Node modelNode = osgDB::readNodeFile(shapefilename); osg::ref_ptrosg::Material nodeMaterial = new osg::Material; nodeMaterial-setDiffuse (osg::Material::FRONT_AND_BACK, osg::Vec4(1.0, 1.0, 1.0, 1.0)); modelNode-getOrCreateStateSet()-setAttributeAndModes(nodeMaterial, osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE); What do you suggest to do? Thank you! Cheers, Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60882#60882 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PositionAttitudeTransform operation order
Hi Robert,
I'm sorry, for sure PositionAttitudeTransform code is fine but I would just
like to know why I see things in a different way.
I built an example starting from osgviewerQt example, where I just removed
useless viewers in the composite viewer and created an ad-hoc scene.
I'm attaching the code and a screen shot.
Basically I have a CrossAxes class that inherits from
osg::PositionAttitudeTransform. I create an osg::Gorup as root node. Then I add
two objects of type CrossAxes as children: the bigger one is not rotated nor
translated, so I guess this is the global/world reference; the second smaller
one is translated of 10.0 along X axis and rotated of pi/2 around Z-axis. From
my point of view the smaller coordinate system is first translated of 10.0
along X-axis and then rotated around Z axis of pi/2 wrt the global. If the
second cross axes had been rotated first and then translated (i.e. translated
wrt the rotated system) it would have been placed in a different position: with
the origin along Y-axis of the global reference frame (=the bigger cross axes
object).
Please don't blame me but what's wrong in what I say?
Cheers,
Gianni
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=60937#60937
// osg
#include osg/AutoTransform
#include osg/Geometry
#include osg/Camera
#include osg/Geode
#include osg/LineWidth
#include osgText/Text
// local
#include CrossAxes.h
//-
CrossAxes::CrossAxes(double iLength)
: length(iLength)
{
addChild(createAxesGeometry(length));
addChild(createAxesLabels(length));
}
//-
CrossAxes::~CrossAxes()
{
}
//-
osg::Geode* CrossAxes::createAxesGeometry(double iLength)
{
osg::Geode* geode = new osg::Geode;
// Turn of lighting for line and set line width.
osg::LineWidth* lineWidth = new osg::LineWidth(2);
geode-getOrCreateStateSet()-setAttributeAndModes(lineWidth,
osg::StateAttribute::ON);
geode-getOrCreateStateSet()-setMode(GL_LIGHTING, osg::StateAttribute::OFF);
geode-addDrawable(createXAxis(iLength));
geode-addDrawable(createYAxis(iLength));
geode-addDrawable(createZAxis(iLength));
return geode;
}
//-
osg::Geometry* CrossAxes::createArrow(const osg::Matrixd iTransform, const
osg::Vec4 iColor, double iLength)
{
osg::Geometry* geometry = new osg::Geometry;
#if 1
double pyramidBaseZ = iLength/3.0*2.0;
double outerBaseRadius = iLength/9.0;
osg::Vec3Array* vertices = new osg::Vec3Array(7);
(*vertices)[0].set(iTransform.preMult(osg::Vec3d(outerBaseRadius, 0.0,
pyramidBaseZ)));
(*vertices)[1].set(iTransform.preMult(osg::Vec3d(0.0, outerBaseRadius,
pyramidBaseZ)));
(*vertices)[2].set(iTransform.preMult(osg::Vec3d(-outerBaseRadius, 0.0,
pyramidBaseZ)));
(*vertices)[3].set(iTransform.preMult(osg::Vec3d(0.0, -outerBaseRadius,
pyramidBaseZ)));
(*vertices)[4].set(iTransform.preMult(osg::Vec3d(0.0, 0.0, iLength)));
(*vertices)[5].set(iTransform.preMult(osg::Vec3d(0.0, 0.0, iLength)));
(*vertices)[6].set(iTransform.preMult(osg::Vec3d(0.0, 0.0, 0.0)));
osg::UByteArray* indices = new osg::UByteArray(20);
(*indices)[0]=0; (*indices)[1]=1; (*indices)[2]=4;
(*indices)[3]=1; (*indices)[4]=2; (*indices)[5]=4;
(*indices)[6]=2; (*indices)[7]=3; (*indices)[8]=4;
(*indices)[9]=3; (*indices)[10]=0; (*indices)[11]=4;
(*indices)[12]=1; (*indices)[13]=0; (*indices)[14]=3;
(*indices)[15]=2; (*indices)[16]=1; (*indices)[17]=3;
(*indices)[18]=5;
(*indices)[19]=6;
geometry-setVertexArray(vertices);
geometry-setVertexIndices(indices);
osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(iColor);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_OVERALL);
geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::TRIANGLES,
0, indices-size()-2));
geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::LINES,
indices-size()-2, 2));
#else
double pyramidBaseZ = iLength/3.0*2.0;
double outerBaseRadius = iLength/9.0;
osg::Vec3Array* vertices = new osg::Vec3Array(7);
(*vertices)[0].set(iTransform.preMult(osg::Vec3d(outerBaseRadius, 0.0,
pyramidBaseZ)));
(*vertices)[1].set(iTransform.preMult(osg::Vec3d(0.0, outerBaseRadius,
pyramidBaseZ)));
(*vertices)[2].set(iTransform.preMult(osg::Vec3d(-outerBaseRadius, 0.0,
pyramidBaseZ)));
(*vertices)[3].set(iTransform.preMult(osg::Vec3d(0.0, -outerBaseRadius,
pyramidBaseZ)));
(*vertices)[4].set(iTransform.preMult(osg::Vec3d(0.0, 0.0, iLength)));
(*vertices)[5].set(iTransform.preMult(osg::Vec3d(0.0, 0.0, iLength)));
(*vertices)[6].set(iTransform.preMult(osg::Vec3d(0.0, 0.0, 0.0)));
Re: [osg-users] First time render hiccup
Hi Nick Per You have to reduce the amount of data transferred by the driver to the card. I have been dealing with the same issue and the solution that worked for me is to chop the data to smaller chunks and/or spread the GL compile phase into more frames . To spread the number of GL compile call in case of the OpenSceneGraph you have to modify it a bit to do this task. By the way the solution Nick mentioned works only if you have enough of resources. Once your per frame data are bigger then the HW resources available, the driver will do its own magic that causes the occasional jerky movement/frame freezes. Have fun! Vaclav On 09/02/14 12:06, Trajce Nikolov NICK wrote: Hi Per, this is a trick from the old days from scenegraph managers like Quantum3D OpenGVS. What they did to avoid this they preloaded the models at the very beginning to let OpenGL compile objects and then used in the scene. Maybe you can do the same way Nick On Tue, Sep 2, 2014 at 2:03 PM, Cary, Karl A. karl.a.c...@leidos.com mailto:karl.a.c...@leidos.com wrote: We have been having the same issue and haven't found a solution yet either, though it hasn't been our main priority yet. I will be following any responses closely and will contribute if I can. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, September 02, 2014 8:01 AM To: OpenSceneGraph Users Subject: Re: [osg-users] First time render hiccup Hi Per, Stalls like you describe are typically when the graphics driver has to compile new OpenGL objects. There are range of things that can cause compilation to be slow, I haven't to head off line right now so will have to leave you with that hint... Robert. On 2 September 2014 12:27, Per Nordqvist nordqv...@gmail.com mailto:nordqv...@gmail.com wrote: Hi all, Another open-ended question I'm afraid, but maybe someone has seen this before: I sometimes see hiccups (rendering pauses) in my driving simulation, I noticed it only happens with some vehicles, and only when they appear in the frustum for the first time. I wonder how to minimize this effect. Clues: -Once the model has been displayed there is no more hiccup. -Differerent models produce different hiccup delays (consistently) -Hiccup problem does not scale with .ive size or nr of polygons -In bad cases I can see the osgstats cull part go to zero for about 1 sec. -Using ProxyNode makes no difference. Suggestions? Some caching options I can try? Anything nasty to look for in the .ive models? (Most are 3DS format made by 3rd party, converted with osgconv, sorry I can't share them) I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same problem.) Thanks! /Per ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- trajce nikolov nick ___ 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] First time render hiccup
Hi Vaclav, it's good to hear I'm not alone with this problem. It took me a while to understand it's nature so I could describe it here. You are right of course, once the HW memory is out, I'm back in trouble. For incremental compilation I found two examples: osganalysis and osgthreadedterrain. Maybe they could serve as a starter if Nicks solution is not enough one day. Or I just buy a bigger card ;-) Cheers /Per On 3 September 2014 20:56, Vaclav Bilek vabi-...@centrum.cz wrote: Hi Nick Per You have to reduce the amount of data transferred by the driver to the card. I have been dealing with the same issue and the solution that worked for me is to chop the data to smaller chunks and/or spread the GL compile phase into more frames . To spread the number of GL compile call in case of the OpenSceneGraph you have to modify it a bit to do this task. By the way the solution Nick mentioned works only if you have enough of resources. Once your per frame data are bigger then the HW resources available, the driver will do its own magic that causes the occasional jerky movement/frame freezes. Have fun! Vaclav On 09/02/14 12:06, Trajce Nikolov NICK wrote: Hi Per, this is a trick from the old days from scenegraph managers like Quantum3D OpenGVS. What they did to avoid this they preloaded the models at the very beginning to let OpenGL compile objects and then used in the scene. Maybe you can do the same way Nick On Tue, Sep 2, 2014 at 2:03 PM, Cary, Karl A. karl.a.c...@leidos.com wrote: We have been having the same issue and haven't found a solution yet either, though it hasn't been our main priority yet. I will be following any responses closely and will contribute if I can. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, September 02, 2014 8:01 AM To: OpenSceneGraph Users Subject: Re: [osg-users] First time render hiccup Hi Per, Stalls like you describe are typically when the graphics driver has to compile new OpenGL objects. There are range of things that can cause compilation to be slow, I haven't to head off line right now so will have to leave you with that hint... Robert. On 2 September 2014 12:27, Per Nordqvist nordqv...@gmail.com wrote: Hi all, Another open-ended question I'm afraid, but maybe someone has seen this before: I sometimes see hiccups (rendering pauses) in my driving simulation, I noticed it only happens with some vehicles, and only when they appear in the frustum for the first time. I wonder how to minimize this effect. Clues: -Once the model has been displayed there is no more hiccup. -Differerent models produce different hiccup delays (consistently) -Hiccup problem does not scale with .ive size or nr of polygons -In bad cases I can see the osgstats cull part go to zero for about 1 sec. -Using ProxyNode makes no difference. Suggestions? Some caching options I can try? Anything nasty to look for in the .ive models? (Most are 3DS format made by 3rd party, converted with osgconv, sorry I can't share them) I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same problem.) Thanks! /Per ___ 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 -- trajce nikolov nick ___ osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] Warped scene with two sets of Geodes
Hi Robert,
I found out what the Problem was—it *was* my code :-)
In particular, it looks like mixing doubles and floats is very bad.
Pretty much everything is a float except for the vertex array of a street.
If I change that to float and convert the Points to Vec3 instead of
Vec3d, then everything is good.
Do you understand why this is a problem though?
Thanks,
–Ben
On Tue, Sep 2, 2014 at 12:01 PM, Ben Morgan nee...@gmail.com wrote:
Hi Robert,
thanks for your reply. I'm kinda new in the OSG/OpenGL field, so I'm
thankful for all the help and advice I can get.
The goal of the project I'm working on is to develop algorithms for
street label positioning on an active route. So I have a street
network, a pointer that moves along a route in the network and a
camera that follows the pointer, and then I have a bunch of labels
that I position and move around. (I think I might have written
something in this mailing list two years ago.)
I never thought that it could be anything other than a mistake of my
own. The problem occurs on the following configurations:
Thinkpad T420 with i5 CPU/Graphics Card (Intel HD3000 I think)
Arch Linux 3.16.1
OSG version 3.2.1
OSG version 3.0.1
G++ version 4.9.1
Intel Video Driver version 2.99.914
Intel DRI Software version 10.2.6
Thinkpad T60 with Radeon Graphics Card
(I only did this quickly, so I don't have all the details)
Arch Linux 3.16.1
OSG version 3.2.1
G++ version 4.9.1
I tried another program that I knew was working two years ago on this
computer, and it has a similar issue (though different) now—the
pointer is just not there. Additionally, the osgText labels are not
showing up either.
The past few days since your response, I also worked on getting it to
compile on Windows 7, with Visual Studio 12. (FYI: I had to add an
#include algorithm to osgText/Glyph.cpp for it to compile, otherwise
it didn't see min/max.) I'll write again after I finish that.
Is there a better way to represent the street network? Should I have a
Group containing a bunch of street lines and then apply color and line
width at that level? Or do I store the street lines all in a single
Geode?
I updated (and simplified) the source code listing to include the
pointer drawing code—perhaps the problem lies there? (I also changed
the street network to contain a bunch of drawables inside a single
Geode. Is it better that way? Or am I going a completely wrong
direction with that?)
Thanks again for your help!
–Ben
PS: And here is the updated source code (also updated at StackOverflow):
// My libraries:
#include asl/util/color.h
using namespace asl;
#include straph/point.h
#include straph/straph.h
using namespace straph;
// Standard and OSG libraries:
#include utility
#include boost/tuple/tuple.hpp // tie
using namespace std;
#include osg/ref_ptr
#include osg/Array
#include osg/Geometry
#include osg/Geode
#include osg/Group
#include osg/LineWidth
using namespace osg;
#include osgUtil/Tessellator
#include osgViewer/Viewer
using namespace osgViewer;
/*
* Just FYI: A Polyline looks like this:
*
* typedef std::vectorPoint Polyline;
*
* And a Point basically is a simple struct:
*
* struct Point {
* double x;
* double y;
* };
*/
inline osg::Vec3d toVec3d(const straph::Point p, double elevation=0.0)
{
return osg::Vec3d(p.x, p.y, elevation);
}
Geometry* createStreet(const straph::Polyline path)
{
ref_ptrVec3dArray array (new Vec3dArray(path.size()));
for (unsigned i = 0; i path.size(); ++i) {
(*array)[i] = toVec3d(path[i]);
}
Geometry* geom = new Geometry;
geom-setVertexArray(array.get());
geom-addPrimitiveSet(new osg::DrawArrays(GL_LINE_STRIP, 0,
array-size()));
return geom;
}
Geode* load_streets()
{
unique_ptrStraph graph = read_shapefile(mexico/roads, 6);
Geode* root = new Geode();
boost::graph_traitsstraph::Straph::edge_iterator ei, ee;
for (boost::tie(ei, ee) = edges(*graph); ei != ee; ++ei) {
const straph::Segment s = (*graph)[*ei];
root-addDrawable(createStreet(s.polyline));
}
return root;
}
Geode* createPointer(double width, const Color body_color)
{
float f0 = 0.0f;
float f3 = 3.0f;
float f1 = 1.0f * width;
float f2 = 2.0f * width;
// Create vertex array
ref_ptrVec3Array vertices (new Vec3Array(4));
(*vertices)[0].set( f0 , f0, f0 );
(*vertices)[1].set( -f1/f3, -f1/f3 , f0 );
(*vertices)[2].set( f0 , f2/f3 , f0 );
(*vertices)[3].set( f1/f3, -f1/f3 , f0 );
// Build the geometry object
