Hi Robert, I am very thankful for every hint, really. These hints are really valuable for optimization. And I found the issue, it was pre/post multiply order of the matrices. I was to avoid the calculus from the nodepath and use the ModelView matrix already available in the CullVisitor. Here is the snippet for someone who might face the same issue:
osg::Matrixd inverseViewMatrix = getCurrentCamera()->getInverseViewMatrix(); osg::Matrixd modelViewMatrix = (*getModelViewMatrix()); osg::Matrixd worldMatrix = osg::computeLocalToWorld(getNodePath()); osg::Matrixd worldMatrix2 = modelViewMatrix * inverseViewMatrix; worldMatrix is equal to worldMatrix2 .. It was really the order of the matrices. I was under impression it is the same as in GLSL Thanks a bunch again! Cheers, Nick On Thu, Nov 3, 2016 at 2:59 PM, Robert Osfield <[email protected]> wrote: > I don't have time to dive deeply in user projects, I can do quick > scans of email and provide quick replies where possible. In terms of > optimization I'd say avoiding the inverse matrix might be useful. > Using the Matrix.postMultTrans/preMultTrans would also be another > optimization step you could use. The use of the UserValue looks like > it won't be thread safe or even safe n the presence of multiple cull > traversals. > > On 3 November 2016 at 11:40, Trajce Nikolov NICK > <[email protected]> wrote: > > Thanks Robert, > > > > I am aware of it, it is already used in my second snippet. Here it is: > (is > > it done properly?) > > > > void MyCullVisitor::apply(osg::LightSource& node) > > { > > > > osg::Matrixd inverseViewMatrix = > > osg::Matrixd::inverse(getCurrentCamera()->getViewMatrix()); > > osg::Matrixd worldMatrix = inverseViewMatrix * > (*getModelViewMatrix()); > > > > osg::Vec3d pos(node.getLight()->getPosition().x(), > > node.getLight()->getPosition().y(), node.getLight()->getPosition().z()); > > worldMatrix = osg::Matrixd::translate(pos) * worldMatrix; > > > > node.setUserValue("WorldMatrix", worldMatrix); > > if (node.getLight()->getLightNum() == 0) > > { > > osgUtil::CullVisitor::apply(node); > > } > > } > > > > > > On Thu, Nov 3, 2016 at 9:14 AM, Robert Osfield <[email protected] > > > > wrote: > >> > >> Hi Nick, > >> > >> The osgUtil::CullVisitor has the maintains a stack of ModelViewMatrix > >> that it accumulates through the the scene graph traversal, you should > >> just need to get the top of this stack using > >> cullVisitor->getModelViewMatrix(). > >> > >> Robert. > >> > >> On 2 November 2016 at 22:25, Trajce Nikolov NICK > >> <[email protected]> wrote: > >> > Hi Community, > >> > > >> > I am trying to optimize the rendering. Getting huge update numbers. > >> > > >> > The story is this: > >> > My scene has huge number of lights, some are static (streetlights) > some > >> > dynamic (a car). The lighting engine needs the World matrix of a > >> > LightSource > >> > and the ViewMatrix (which is the same as the World inverse just with > >> > some > >> > extra rotation). In my code after the update before the rendering > >> > traversal > >> > I am updating these matrices each frame and I am about to place this > >> > code in > >> > my custom CullVisitor (which traverse the scene anyway but only the > >> > active > >> > children). > >> > > >> > Here is my approach at the moment: list of light entities and here is > >> > how I > >> > am computing these: > >> > http://pastebin.com/0A64sc7Y > >> > Simply getting the NodePath and computing the world matrix from this > >> > node > >> > path. This seams to be costly > >> > > >> > I am after wiser optimization, to place this in my CullVistor: Here is > >> > the > >> > snippet: > >> > http://pastebin.com/6dQnih8N > >> > > >> > These snippets are simple and I would like to ask if this is more > proper > >> > way, which it seams to me since I will gain more performance by > updating > >> > only the culled and active nodes. Also the math in the cull visitor. > >> > > >> > Thanks a lot for any hints, ideas. As always :-) > >> > > >> > Cheers, > >> > Nick > >> > > >> > -- > >> > trajce nikolov nick > >> > > >> > _______________________________________________ > >> > osg-users mailing list > >> > [email protected] > >> > > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users- > openscenegraph.org > >> > > >> _______________________________________________ > >> osg-users mailing list > >> [email protected] > >> http://lists.openscenegraph.org/listinfo.cgi/osg-users- > openscenegraph.org > > > > > > > > > > -- > > trajce nikolov nick > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-users- > openscenegraph.org > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- trajce nikolov nick
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
