Re: [osg-users] Orient a node to face another

[Paul Leopard]

Hi,

Sorry for the delay ... That worked perfectly

Thank you!

Cheers,
Paul


things are more like they are now than they have ever been before

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76814#76814





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Updating a PositionAttitudeTransform node from another PositionAttitudeTransform node

[Voerman, L.]

I'm not sure what you are trying to accomplish, maybe a
custom osg::Node::ComputeBoundingSphereCallback can help;
osg::Node::setComputeBoundingSphereCallback(cb) will call a custom callback
when a node or it's children changes.
Laurens.

On Wed, Oct 9, 2019 at 3:41 PM Dan johansson 
wrote:

> Hi!
>
> Thanks for the reply, i understand the issue. I'm not really understanding
> why this isn't built in automatically though. This simple code seemed to do
> the trick even with multiple Pat's chained
>
>
> Code:
>
> osg::NodePathList fullNodePath = node2->getParentalNodePaths();
> osg::NodePath lastNodePath = fullNodePath.at(fullNodePath.size() - 1);
>
> osg::Matrixd lastNodePositionMatrix =
> osg::computeLocalToWorld(lastNodePath);
> osg::Vec3f lastNodePosition = lastNodePositionMatrix.getTrans();
>
> node2->setPosition(lastNodePosition);
>
>
>
>
> Is there a good way to add a callback to this update that is _not_ on
> every render but rather when the specific Pat have been
> moved/rotated/scaled?
>
> Regards Dan
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=76812#76812
>
>
>
>
>
> ___
> 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] Updating a PositionAttitudeTransform node from another PositionAttitudeTransform node

[Dan johansson]

Hi!

Thanks for the reply, i understand the issue. I'm not really understanding why 
this isn't built in automatically though. This simple code seemed to do the 
trick even with multiple Pat's chained


Code:

osg::NodePathList fullNodePath = node2->getParentalNodePaths();
osg::NodePath lastNodePath = fullNodePath.at(fullNodePath.size() - 1);

osg::Matrixd lastNodePositionMatrix = osg::computeLocalToWorld(lastNodePath);
osg::Vec3f lastNodePosition = lastNodePositionMatrix.getTrans();

node2->setPosition(lastNodePosition);




Is there a good way to add a callback to this update that is _not_ on every 
render but rather when the specific Pat have been moved/rotated/scaled?

Regards Dan

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76812#76812





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Updating a PositionAttitudeTransform node from another PositionAttitudeTransform node

[Voerman, L.]

Hi Dan,
I think your expectations are off. pose2 gets the postition from the node2
matrix, not the world postition.
to retrieve the world position you need to have a nodepath, so you can
call osg::computeLocalToWorld( fullNodePath );
In your case this might be just the product for the node1 matix and node2
matrix.
Laurens.

On Wed, Oct 9, 2019 at 10:26 AM Dan johansson 
wrote:

> Hi,
>
> I've ran into a seemingly easy problem that i have failed to find an
> answer for. I've simplified the problem here to quickly describe my
> question. I'm setting a Pat node as parent to another Pat node and re
> positioning it. The updated position is not translated to the child and i
> wonder why this behavior occurs. Any help on the issue is welcome.
>
>
>
>
>
>
> Code:
>
>
> osg::ref_ptr node1 = new
> osg::PositionAttitudeTransform;
> osg::ref_ptr node2 = new
> osg::PositionAttitudeTransform;
>
> node1->setDataVariance(osg::Object::DYNAMIC);
> node2->setDataVariance(osg::Object::DYNAMIC);
>
> node1->setPosition((osg::Vec3f(0.f,0.f,0.f)));
> node2->setPosition((osg::Vec3f(0.f,0.f,0.f)));
>
> node1->addChild(node2.get());
> node1->setPosition(osg::Vec3f(10.f,10.f,10.f));
>
> osg::Vec3f pose2 = node2->getPosition();
>
> //pose2 is still at (0,0,0)
>
>
>
>
>
>
> //Regards Dan
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=76810#76810
>
>
>
>
>
> ___
> 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] Updating a PositionAttitudeTransform node from another PositionAttitudeTransform node

[Dan johansson]

Hi,

I've ran into a seemingly easy problem that i have failed to find an answer 
for. I've simplified the problem here to quickly describe my question. I'm 
setting a Pat node as parent to another Pat node and re positioning it. The 
updated position is not translated to the child and i wonder why this behavior 
occurs. Any help on the issue is welcome.






Code:


osg::ref_ptr node1 = new 
osg::PositionAttitudeTransform;
osg::ref_ptr node2 = new 
osg::PositionAttitudeTransform;

node1->setDataVariance(osg::Object::DYNAMIC);
node2->setDataVariance(osg::Object::DYNAMIC);

node1->setPosition((osg::Vec3f(0.f,0.f,0.f)));
node2->setPosition((osg::Vec3f(0.f,0.f,0.f)));

node1->addChild(node2.get());
node1->setPosition(osg::Vec3f(10.f,10.f,10.f));

osg::Vec3f pose2 = node2->getPosition();

//pose2 is still at (0,0,0)






//Regards Dan

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=76810#76810





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] multiple matrix transfromations cause severe slowness in performance

[Robert Osfield]

Hi Gianluca,

It should be possible to have thousands of transforms in your scene graph
and still get good frame rates.  The only thing that jumps to mind right
now, is could you be doing the test with a debug build?

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Crash on some machines while rendering a progressive line strip

[Robert Osfield]

Hi Rakesh,

I don't think we can provide much direct insight, you have the whole
application and data to test against, while we just have a snippet without
any wider information.  The crash could be caused by anything.

The best we can do is recommend tools/strategies to reproduce the crash or
pick up on race conditions.  I only work under Linux these days and use
valgrind --tool=helgrind to pick up on threading issues, this works pretty
well for catching obscure difficult to catch in testing problems.  I'm sure
there will be similar tools under Windows, but can't provide any guidance
on this as I'm not a Windows user.

The other thing you could look at is changing the way you are implementing
things.  Personally when handling this type of user interaction ->
generation of scene graph in real-time I accumulate the user input in a
thread safe queue then read from this in the update/event traversal, this
then updates the scene graph in a synchronous way avoiding any threading
issues.

The OSG also allows you create custom events and inject them in the
viewer's EventQueue.  The osc plugin implements a custom event approach,
with it providing a custom osgGA::Device that provide interface that the
viewer can use to poll the device.  You needn't go this approach, and may
just way over complicate the task, but for certain types of apps being able
to decouple the device and events makes it easier mix and match devices and
event handling.

Robert.


On Fri, 4 Oct 2019 at 19:24, Rakesh Prasad  wrote:

> Hi,
> I have a code which renders a progressive line strip. When the line strip
> is unmasked to display it crashes on some machines. I use osg 3.6.4 with
> MFC Visual Studio 2019 with V142. The same problem was observed on osg
> 3.4.0 with MFC and Visual Studio 2013 v120. I am completely clueless as why
> it would crash since its not on my machine. I dont have the crash stack and
> other variable values. I have some observations.I will list my code and try
> to explain as best as possible.
> I migrated from osg 3.4.0 hoping 3.6.4 will resolve the issue.
>
> createHUDClubHdPts is called to create the scenegraph with the arrays.
> After which every frame AddCurPtToHandClubPath is called. This function
> updates the point in the array. As the frames are rendered a line that
> progressed based on the coordinates is displayed.  The render target is a
> MFC MDI client window. The render frames are called from a thread of class
> OpenThreads::Thread
>
> While trying to debug the issue using logs.  I found that when the
> numPtsinHandClubPath value goes to 199 it crashes. We can see that the
> array size is 2000.  Everytime it used to crash after 200 values were
> updated into the coordinate vector and color vector.
>
> It has never crashed on two of my machines so I dont have the stack and
> variable values. Few remote machines it has crashed.
> Do let me know if there is any query or clarity required.
> ...
>
> Thank you!
>
> Cheers,
> Rakesh
>
> Code:
>
> //following variables are defined in COSGViewer
> osg::MatrixTransform* mtClubHandPath;
> osg::ref_ptr osgGeodeHandClubPath;
> unsigned int MaxPtsInHandCLubPath;
> osg::ref_ptr geomHandPath;
> osg::ref_ptr geomClubPath;
> osg::ref_ptr coordsHandPath;
> osg::ref_ptr coordsClubPath;
> osg::ref_ptr coloursHandPath;
> osg::ref_ptr coloursClubPath;
> osg::ref_ptr drawArrayHandPath;
> osg::ref_ptr drawArrayClubPath;
>
>
> osg::MatrixTransform* COSGViewer::createHUDClubHdPts(int X0, int Y0, int
> X1, int Y1, int textYOffset)
> {
> mtClubHandPath = new osg::MatrixTransform();
> osg::Matrix m;
> m.makeTranslate(0, 0, 0);
> mtClubHandPath->setMatrix(m);
>
> RECT rect;
> ::GetWindowRect(m_hWnd, );
>
>
> osg::ref_ptr linesGeom = new osg::Geometry();
> osgGeodeHandClubPath = new osg::Geode();
>
> osg::ref_ptr stateset =
> osgGeodeHandClubPath->getOrCreateStateSet();
>
> stateset->setMode(GL_LIGHTING, osg::StateAttribute::OFF);
> stateset->setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF);
>
> osg::ref_ptr linewidth = new osg::LineWidth();
> linewidth->setWidth(4.0f);
> stateset->setAttributeAndModes(linewidth, osg::StateAttribute::ON);
>
> unsigned int n_points = 2000;
> MaxPtsInHandCLubPath = n_points;
> numPtsinHandClubPath = 0;
> geomHandPath = new osg::Geometry();
> geomClubPath = new osg::Geometry();
>
> coordsHandPath = new osg::Vec3Array;// (n_points);
> coordsClubPath = new osg::Vec3Array;// (n_points);
> coloursHandPath = new osg::Vec4Array;// (n_points);
> coloursClubPath = new osg::Vec4Array;// (n_points);
>
>
> for (unsigned int j = 0; j < n_points; ++j) {
>
> coordsHandPath->push_back(osg::Vec3(0, 0, 0));
> 

Re: [osg-users] R: R: multiple matrix transfromations cause severe slowness in performance

[Voerman, L.]

Maybe the datavariance on your drawables is not set to static?
Laurens.

On Wed, Oct 9, 2019 at 9:27 AM Gianluca Natale 
wrote:

> Hi Chris,
>
> first of all, thanks for helping.
>
>
>
> Each of those 200 objects is simply the shape of an arrow (basically a
> cone and a cylinder), whose geometry takes no more than 100 vertices.
> The drawable that renders each arrow is a custom drawable that I derived
> from osg::drawable, where I’ve overridden the drawImplementation.
> Internally my drawable allocates a VBO for the geometry, and sends it
> directly to OpenGL for rendering in drawImplementation.
> My drawable provides a consistent bounding box that OSG uses to cull the
> drawable when outside of the viewing volume.
> Each drawable is inserted in a geode, that in its turn is attached to an
> autotransform matrix, because I need those shapes to be rendered at
> constant size on screen (70 pixels).
> So, it is OSG that during rendering traversal computes the scale factors
> of that autotransform, to keep the constant size.
>
> Note that I’m not using shaders at the moment, but still the ffp.
>
>
>
> At the beginning I had thought that my drawImplementation was the
> bottleneck in redrawing, but even if I comment its code completely
> (making drawImplementation an empty function), still the redraw takes a
> considerable time.
> It looks like most of the time was taken to traverse the scenegraph, apply
> the transformation and culling the drawables.
>
>
>
> I’m still investigating, and trying to isolate the issue.
>
>
>
> Thanks,
>
> Gianluca
>
>
>
> *Da:* osg-users  *Per conto
> di *Chris Hanson
> *Inviato:* martedì 8 ottobre 2019 15:51
> *A:* OpenSceneGraph Users 
> *Oggetto:* Re: [osg-users] R: multiple matrix transfromations cause
> severe slowness in performance
>
>
>
> I believe most computations you could imagine doing could be performed in
> the vertex shader during draw rather than by the CPU during cull.
>
>
>
> To describe more we'd need a better idea of what those 200 objects are,
> how they behave, what they represent, and how auto transform is being used.
>
>
>
> On Tue, Oct 8, 2019 at 7:36 AM Gianluca Natale 
> wrote:
>
> As I said, I’d like to use auto-transformations for those 200 objects, so
> I need 200 transformations for sure, and those transformations are updated
> by OSG at rendering time.
>
> So, the transformation has to be computed by OSG out of my vertex shader.
> Am I wrong?
>
>
>
> *Da:* osg-users  *Per conto
> di *Chris Hanson
> *Inviato:* martedì 8 ottobre 2019 14:42
> *A:* OpenSceneGraph Users 
> *Oggetto:* Re: [osg-users] multiple matrix transfromations cause severe
> slowness in performance
>
>
>
> Can you find a way to perform the transform on each object in a vertex
> shader and not have a unique state have to be calculated for each of the
> 200 objects?
>
>
>
> On Tue, Oct 8, 2019 at 6:20 AM Gianluca Natale 
> wrote:
>
> Hi all,
>
> I have a performance issue in my scenegraph that I cannot completely
> understand.
>
> My scenegraph is made by a main matrix transform, with these 2 children:
>
>- One geode that renders a big object on screen (the geometry in the
>drawable can take up to several thousands vertices);
>- One group node that in its turn has 200 children, each made by a
>matrix transform and a geode. The drawable in each of those geodes is very
>simple (no more than 100 vertices)
>
> It seems that this configuration allows me to have at most 50 fps.
>
> I feel that this should be rendered much faster.
>
>
>
> So I made some experiment. If I remove the 200 matrix transform attached
> to the group node I mentioned above,
> and directly apply the transformations to the vertices of the geometries
> in the 200 drawables of the small objects, performance improves a lot, till
> 100 fps.
> I investigatd a bit inside OSG code (I’m using OG ver.3.4.1), and
> apparently the only overhead due to the additional matrix transformations
> is a call to glLoadMatrix (I’m using the old ffp).
> How can you explain such an improvement?
>
> My real problem is that I would like to replace the 200 matrix
> transfromations with 200 auto-transform matrices, since I’d like those
> small objects to keep constant size on screen.
>
> But if I do that, I cannot remove the 200 transformations at all, and I’ll
> end up with a bad performance.
>
> Any idea about what I can try to make rendering of my scenegraph faster?
>
>
>
> Thanks,
>
> Gianluca
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>
>
>
>
> --
>
> Chris 

[osg-users] R: R: multiple matrix transfromations cause severe slowness in performance

[Gianluca Natale]

Hi Chris,
first of all, thanks for helping.

Each of those 200 objects is simply the shape of an arrow (basically a cone and 
a cylinder), whose geometry takes no more than 100 vertices.
The drawable that renders each arrow is a custom drawable that I derived from 
osg::drawable, where I’ve overridden the drawImplementation.
Internally my drawable allocates a VBO for the geometry, and sends it directly 
to OpenGL for rendering in drawImplementation.
My drawable provides a consistent bounding box that OSG uses to cull the 
drawable when outside of the viewing volume.
Each drawable is inserted in a geode, that in its turn is attached to an 
autotransform matrix, because I need those shapes to be rendered at constant 
size on screen (70 pixels).
So, it is OSG that during rendering traversal computes the scale factors of 
that autotransform, to keep the constant size.
Note that I’m not using shaders at the moment, but still the ffp.

At the beginning I had thought that my drawImplementation was the bottleneck in 
redrawing, but even if I comment its code completely
(making drawImplementation an empty function), still the redraw takes a 
considerable time.
It looks like most of the time was taken to traverse the scenegraph, apply the 
transformation and culling the drawables.

I’m still investigating, and trying to isolate the issue.

Thanks,
Gianluca

Da: osg-users  Per conto di Chris 
Hanson
Inviato: martedì 8 ottobre 2019 15:51
A: OpenSceneGraph Users 
Oggetto: Re: [osg-users] R: multiple matrix transfromations cause severe 
slowness in performance

I believe most computations you could imagine doing could be performed in the 
vertex shader during draw rather than by the CPU during cull.

To describe more we'd need a better idea of what those 200 objects are, how 
they behave, what they represent, and how auto transform is being used.

On Tue, Oct 8, 2019 at 7:36 AM Gianluca Natale 
mailto:nat...@europe.altair.com>> wrote:
As I said, I’d like to use auto-transformations for those 200 objects, so I 
need 200 transformations for sure, and those transformations are updated by OSG 
at rendering time.
So, the transformation has to be computed by OSG out of my vertex shader. Am I 
wrong?

Da: osg-users 
mailto:osg-users-boun...@lists.openscenegraph.org>>
 Per conto di Chris Hanson
Inviato: martedì 8 ottobre 2019 14:42
A: OpenSceneGraph Users 
mailto:osg-users@lists.openscenegraph.org>>
Oggetto: Re: [osg-users] multiple matrix transfromations cause severe slowness 
in performance

Can you find a way to perform the transform on each object in a vertex shader 
and not have a unique state have to be calculated for each of the 200 objects?

On Tue, Oct 8, 2019 at 6:20 AM Gianluca Natale 
mailto:nat...@europe.altair.com>> wrote:
Hi all,
I have a performance issue in my scenegraph that I cannot completely understand.
My scenegraph is made by a main matrix transform, with these 2 children:

  *   One geode that renders a big object on screen (the geometry in the 
drawable can take up to several thousands vertices);
  *   One group node that in its turn has 200 children, each made by a matrix 
transform and a geode. The drawable in each of those geodes is very simple (no 
more than 100 vertices)
It seems that this configuration allows me to have at most 50 fps.
I feel that this should be rendered much faster.

So I made some experiment. If I remove the 200 matrix transform attached to the 
group node I mentioned above,
and directly apply the transformations to the vertices of the geometries in the 
200 drawables of the small objects, performance improves a lot, till 100 fps.
I investigatd a bit inside OSG code (I’m using OG ver.3.4.1), and apparently 
the only overhead due to the additional matrix transformations is a call to 
glLoadMatrix (I’m using the old ffp).
How can you explain such an improvement?

My real problem is that I would like to replace the 200 matrix transfromations 
with 200 auto-transform matrices, since I’d like those small objects to keep 
constant size on screen.
But if I do that, I cannot remove the 200 transformations at all, and I’ll end 
up with a bad performance.
Any idea about what I can try to make rendering of my scenegraph faster?

Thanks,
Gianluca
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


--
Chris 'Xenon' Hanson, omo sanza lettere. 
xe...@alphapixel.com