Re: [osg-users] Deep coping models with skeltons fail with osg 3.2.0
Hi Bjorn,
I have just had a look at the example code you provided and it reproduces
the issue you see on my system which is the a good result as it means I'll
be able to confirm a fix once one is found.
I am not the author of osgAnimation so not best placed to debug it - I am
in not too dissimilar situation as yourself, looking at code to understand
the exact mechanism of what is intended and what might be going wrong.
From the perspective as project lead I don't recall any submissions that
are likely candidates for causing this regression, Cedric Pinsion the
author of osgAnimation does have write permission to osgAnimation so may
have checked something in too. Looking at svn logs I haven't found
anything that could be a likely candidate.
As step in investigation I added some write methods into your code so we
can have a look at the resulting scene graphs before and after the clone
and the cloned one looks like it has entries duplicated. Perhaps a double
copy is going on somewhere. The code now looks like:
#include osgViewer/Viewer
#include osgDB/ReadFile
int main( int argc, char** argv ) {
osg::ArgumentParser arguments(argc,argv);
// Load model containing animation
osg::ref_ptrosgDB::ReaderWriter::Options options = new
osgDB::ReaderWriter::Options;
options-setDatabasePath(C:/OpenSceneGraph-data);
osg::ref_ptrosg::Node nathanNode =
osgDB::readNodeFile(nathan.osg, options);
// Make a copy of node with skeleton
osg::ref_ptrosg::Group copiedNode =
osg::clone(nathanNode-asGroup(), osg::CopyOp::DEEP_COPY_ALL);
osgDB::writeNodeFile(*nathanNode,original.osg);
osgDB::writeNodeFile(*copiedNode,copied.osg);
osgViewer::Viewer viewer(arguments);
viewer.setSceneData(copiedNode);
viewer.run();
}
A diff between shows that geometry and state is duplicated that you
normally don't won't to clone, in production code I'd recommend sharing as
much as the scene graph as possible especially the leaves like geometry and
state. The bit that looks suspicious to me is that the UpdateBone contents
look to have part that are duplicated in the cloned version.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deep coping models with skeltons fail with osg 3.2.0
Hi Bjorn, I have tracked down the bug to the osgAnimation::StackedTransform doing a double copy of the container. I have removed the double copy and now your example code works fine. I have checked in the fix to svn/trunk and OSG-3.2 branch so it'll be part of the 3.2.1 release when I make it. Could you please test my fix out. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector numerical imprecisions
Hi All,
I have just checked into svn/trunk the following changes to better handle
numerical precisions issues with the clamping of the line segment to the
bounding box in LineSegmentIntersector.cpp. These changes are compatible
with being merged with the OSG-3.2 branch and hence could be part of the up
coming OSG-3.2.1 stable release, however, as these changes still
experimental I feel that we need to do some more testing against real user
data before I do this merge. I have also removed the user definable
epsilon from osgUtil::Intersector as if the new code works fine users won't
need to play with adjusting it.
~/OpenSceneGraph$ svn diff
Index: include/osgUtil/IntersectionVisitor
===
--- include/osgUtil/IntersectionVisitor (revision 13735)
+++ include/osgUtil/IntersectionVisitor (working copy)
@@ -53,8 +53,7 @@
Intersector(CoordinateFrame cf=MODEL):
_coordinateFrame(cf),
_intersectionLimit(NO_LIMIT),
-_disabledCount(0),
-_epsilon(1e-4) {}
+_disabledCount(0) {}
void setCoordinateFrame(CoordinateFrame cf) { _coordinateFrame =
cf; }
@@ -85,19 +84,11 @@
inline bool reachedLimit() { return _intersectionLimit ==
LIMIT_ONE containsIntersections(); }
-/** Set Epsilon value, where supported is used in numerical
comparisons to workaround number precisions issues.*/
-inline void setEpsilon(double epsilon) { _epsilon = epsilon; }
-
-/** Get Epsilon value.*/
-inline double getEpsilon() const { return _epsilon; }
-
protected:
CoordinateFrame _coordinateFrame;
IntersectionLimit _intersectionLimit;
unsigned int _disabledCount;
-double_epsilon;
-
};
Index: src/osgUtil/LineSegmentIntersector.cpp
===
--- src/osgUtil/LineSegmentIntersector.cpp (revision 13735)
+++ src/osgUtil/LineSegmentIntersector.cpp (working copy)
@@ -244,7 +244,6 @@
osg::ref_ptrLineSegmentIntersector lsi = new
LineSegmentIntersector(_start, _end);
lsi-_parent = this;
lsi-_intersectionLimit = this-_intersectionLimit;
-lsi-_epsilon = this-_epsilon;
return lsi.release();
}
@@ -279,7 +278,6 @@
osg::ref_ptrLineSegmentIntersector lsi = new
LineSegmentIntersector(_start * inverse, _end * inverse);
lsi-_parent = this;
lsi-_intersectionLimit = this-_intersectionLimit;
-lsi-_epsilon = this-_epsilon;
return lsi.release();
}
@@ -486,18 +484,11 @@
osg::Vec3d bb_min(bbInput._min);
osg::Vec3d bb_max(bbInput._max);
-// expand the extents of the bounding box by the epsilon to prevent
numerical errors resulting in misses.
-bb_min.x() -= _epsilon;
-bb_min.y() -= _epsilon;
-bb_min.z() -= _epsilon;
-bb_max.x() += _epsilon;
-bb_max.y() += _epsilon;
-bb_max.z() += _epsilon;
+double epsilon = 1e-13;
// compate s and e against the xMin to xMax range of bb.
if (s.x()=e.x())
{
-
// trivial reject of segment wholely outside.
if (e.x()bb_min.x()) return false;
if (s.x()bb_max.x()) return false;
@@ -505,13 +496,15 @@
if (s.x()bb_min.x())
{
// clip s to xMin.
-s = s+(e-s)*(bb_min.x()-s.x())/(e.x()-s.x());
+double r = (bb_min.x()-s.x())/(e.x()-s.x()) - epsilon;
+if (r0.0) s = s + (e-s)*r;
}
if (e.x()bb_max.x())
{
// clip e to xMax.
-e = s+(e-s)*(bb_max.x()-s.x())/(e.x()-s.x());
+double r = (bb_max.x()-s.x())/(e.x()-s.x()) + epsilon;
+if (r1.0) e = s+(e-s)*r;
}
}
else
@@ -521,21 +514,22 @@
if (e.x()bb_min.x())
{
-// clip s to xMin.
-e = s+(e-s)*(bb_min.x()-s.x())/(e.x()-s.x());
+// clip e to xMin.
+double r = (bb_min.x()-e.x())/(s.x()-e.x()) - epsilon;
+if (r0.0) e = e + (s-e)*r;
}
if (s.x()bb_max.x())
{
-// clip e to xMax.
-s = s+(e-s)*(bb_max.x()-s.x())/(e.x()-s.x());
+// clip s to xMax.
+double r = (bb_max.x()-e.x())/(s.x()-e.x()) + epsilon;
+if (r1.0) s = e + (s-e)*r;
}
}
// compate s and e against the yMin to yMax range of bb.
if (s.y()=e.y())
{
-
// trivial reject of segment wholely outside.
if (e.y()bb_min.y()) return false;
if (s.y()bb_max.y()) return false;
@@ -543,13 +537,15 @@
if (s.y()bb_min.y())
{
// clip s to yMin.
-s = s+(e-s)*(bb_min.y()-s.y())/(e.y()-s.y());
+double r = (bb_min.y()-s.y())/(e.y()-s.y()) - epsilon;
+if (r0.0) s = s + (e-s)*r;
}
if (e.y()bb_max.y())
{
// clip e to yMax.
-e =
Re: [osg-users] Deep coping models with skeltons fail with osg 3.2.0
Hi Robert, I have checked out your change to StackedTransform and I can confirm that the change solves the problem for both my simple example and our main codebase. Also the osganimationhardware example seems to be working as before 3.2.0. Thanks for your help! Best regards, Björn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56056#56056 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector numerical imprecisions
Hi Robert, This is perhaps un-related, but in a previous project, I've experienced intersections numerical precision problems with big scenes, and I've switched to the double precision line segment intersector taken fomr osgEarth source code. Maybe swiching from float precision to double precision could also help dealing wih the problem described in this thread ? Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56057#56057 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deep coping models with skeltons fail with osg 3.2.0
Hi Björn, On 2 September 2013 11:08, Björn Blissing bjorn.bliss...@vti.se wrote: I have checked out your change to StackedTransform and I can confirm that the change solves the problem for both my simple example and our main codebase. Also the osganimationhardware example seems to be working as before 3.2.0. Good to hear it's all working. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector numerical imprecisions
Hi Aurelien, On 2 September 2013 11:22, Aurelien Albert aurelien.alb...@alyotech.frwrote: This is perhaps un-related, but in a previous project, I've experienced intersections numerical precision problems with big scenes, and I've switched to the double precision line segment intersector taken fomr osgEarth source code. Maybe swiching from float precision to double precision could also help dealing wih the problem described in this thread ? The intersection code that was picked as a numerical precision problem in this thread was already done with all doubles - the code promotes the bounding box floats to doubles, and the LineSegmentIntersector end points are already in doubles. The area that the code changes I made today don't effect is the lower level linesegment to triangle intersections that are presently still done with floats. The triangle intersection code currently work in floats simply for performance reasons. I think the ideal way to tackle this is have an option that selects a different triangle intersection functor depending upon a hint set up the intersector. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::notify crash, not thread safe
HI David, I have compiled your test code with the attached CmakeLists.txt and can confirm I get the crash on my Kubuntu 13.04 + 64bit system. With running gdb: (gdb) run 48 100 2 2 The stack track I'm getting is: *** Error in `/home/robert/Contributors/DavidFries/threadednotify': double free or corruption (top): 0x7fffd8000b40 *** *** Error in `/home/robert/Contributors/DavidFries/threadednotify[New Thread 0x7fffe0ff9700 (LWP 6024)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x70ee7700 (LWP 6017)] 0x76dee037 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) where #0 0x76dee037 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x76df1698 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x76e2b5ab in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x76e37a46 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x7742f2a9 in std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::overflow(int) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x77433976 in std::basic_streambufchar, std::char_traitschar ::xsputn(char const*, long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x77426b83 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x77427dc4 in std::ostreambuf_iteratorchar, std::char_traitschar std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::_M_insert_intlong(std::ostreambuf_iteratorchar, std::char_traitschar , std::ios_base, char, long) const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #8 0x77427f2d in std::num_putchar, std::ostreambuf_iteratorchar, std::char_traitschar ::do_put(std::ostreambuf_iteratorchar, std::char_traitschar , std::ios_base, char, long) const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #9 0x7742adf6 in std::ostream std::ostream::_M_insertlong(long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #10 0x0040299a in Spam::run (this=0x60d9b8) at /home/robert/Contributors/DavidFries/ThreadedNotify.cpp:88 #11 0x7769c7d0 in OpenThreads::ThreadPrivateActions::StartThread(void*) () from /home/robert/OpenSceneGraph/lib/libOpenThreads.so.14 #12 0x76ba1f8e in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #13 0x76eb0e1d in clone () from /lib/x86_64-linux-gnu/libc.so.6 This suggests the ostream being shared between threads is not thread safe. I don't believe it's the Notify.cpp code itself that is directly causing the problem, rather it looks to be that ostream implementation is the problem. Solving may not be easy without having a ostream per thread. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to set-up an FBO in osg for android with opengl-es 2.0
Sure, anyone interested in the solution can ask me via personal message. Best, Deniz Trajce Nikolov NICK wrote: maybe you post your finding so other from the community will benefit ;-) Nick On Sun, Sep 1, 2013 at 9:11 PM, deniz diktas () wrote: I have been able to find a work-around to solve it. thanks, deniz -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56047#56047 (http://forum.openscenegraph.org/viewtopic.php?p=56047#56047) ___ osg-users mailing list () http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org) -- trajce nikolov nick -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56074#56074 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
