Re: [osg-users] Picking bug?
2009/12/4 Fred Smith osgfo...@tevs.eu Nope, it still doesn't work. Not my lucky day... Hi Fred, I've attached my modified version of LineSegmentIntersector.cpp if you want to try that. It's from 2.8.2 but it should be ok with most recent versions. If that doesn't work for you, you'll need to roll a version which does more robust floating point comparison: http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm -- http://www.ssTk.co.uk LineSegmentIntersector.cpp 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] Picking bug?
It seems to be working pretty well for me with this change, thanks! Do you guys think this could be integrated into 2.9.6 or maybe a later version? I understand you are considering the integration of this feature as a runtime option. Thanks again for all your input, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21023#21023 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking bug?
Thanks for your reply.
I tried modifying LineSegmentIntersector.cpp in osgUtil but it didn't work.
I went all the way and changed everything to use doubles, eg.:
Code:
inline void operator () (const osg::Vec3 _v1,const osg::Vec3
_v2,const osg::Vec3 _v3, bool treatVertexDataAsTemporary)
{
// Create local osg::Vec3d copies
osg::Vec3d v1(_v1.x(), _v1.y(), _v1.z());
osg::Vec3d v2(_v2.x(), _v2.y(), _v2.z());
osg::Vec3d v3(_v3.x(), _v3.y(), _v3.z());
[...]
if (treatVertexDataAsTemporary)
{
_intersections.insert(std::pairconst
float,TriangleIntersection(r,TriangleIntersection(_index-1,normal,(float)r1,0,(float)r2,0,(float)r3,0)));
}
else
{
_intersections.insert(std::pairconst
float,TriangleIntersection(r,TriangleIntersection(_index-1,normal,(float)r1,_v1,(float)r2,_v2,(float)r3,_v3)));
}
}
I turned all floats into doubles, 0.0f's into 0.0's, all osg::Vec3's into
osg::Vec3d's...
I still get the same behavior.
Can you please be a bit more specific regarding other alternatives I have?
(bounding box, pick ray clipping...)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20886#20886
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking bug?
Hi,
have you checked what the members of the TriangleIntersection struct
are? I think you must make them double too, this it where we had
problems in some of our code.
jp
Fred Smith wrote:
Thanks for your reply.
I tried modifying LineSegmentIntersector.cpp in osgUtil but it didn't work.
I went all the way and changed everything to use doubles, eg.:
Code:
inline void operator () (const osg::Vec3 _v1,const osg::Vec3 _v2,const
osg::Vec3 _v3, bool treatVertexDataAsTemporary)
{
// Create local osg::Vec3d copies
osg::Vec3d v1(_v1.x(), _v1.y(), _v1.z());
osg::Vec3d v2(_v2.x(), _v2.y(), _v2.z());
osg::Vec3d v3(_v3.x(), _v3.y(), _v3.z());
[...]
if (treatVertexDataAsTemporary)
{
_intersections.insert(std::pairconst
float,TriangleIntersection(r,TriangleIntersection(_index-1,normal,(float)r1,0,(float)r2,0,(float)r3,0)));
}
else
{
_intersections.insert(std::pairconst
float,TriangleIntersection(r,TriangleIntersection(_index-1,normal,(float)r1,_v1,(float)r2,_v2,(float)r3,_v3)));
}
}
I turned all floats into doubles, 0.0f's into 0.0's, all osg::Vec3's into
osg::Vec3d's...
I still get the same behavior.
Can you please be a bit more specific regarding other alternatives I have?
(bounding box, pick ray clipping...)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20886#20886
___
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] Picking bug?
2009/12/4 J.P. Delport jpdelp...@csir.co.za Hi, have you checked what the members of the TriangleIntersection struct are? I think you must make them double too, this it where we had problems in some of our code. jp Opps, yes they need changing as well. -- http://www.ssTk.co.uk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking bug?
Hi Fred, Simon, I turned all floats into doubles, 0.0f's into 0.0's, all osg::Vec3's into osg::Vec3d's... I still get the same behavior. Simon, why don't you submit your code changes (perhaps with a CMake switch to change the internal data type used between float and double at compile time, kind of like OSG_USE_FLOAT_BOUNDINGBOX / OSG_USE_FLOAT_BOUNDINGSPHERE... I'm sure if this is a common problem people will be glad to have it in the main OSG code base, only a CMake switch away... And then it will be easy to compare performance between the two and perhaps make the double version default if there is little/no performance difference... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] Picking bug?
Hi J-S, Fred, Simon, This topic has arisen previously on osg-submissions, and my recommendation then was that support for double maths through the intersection code shouldn't be a compile option, but an runtime option, this way the ABI wouldn't change and you could enable it when you needed it. I still believe this is the correct route. As for whether it'll address that issues Fred is seeing I can't say. Cheers, Robert. On Fri, Dec 4, 2009 at 2:04 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Fred, Simon, I turned all floats into doubles, 0.0f's into 0.0's, all osg::Vec3's into osg::Vec3d's... I still get the same behavior. Simon, why don't you submit your code changes (perhaps with a CMake switch to change the internal data type used between float and double at compile time, kind of like OSG_USE_FLOAT_BOUNDINGBOX / OSG_USE_FLOAT_BOUNDINGSPHERE... I'm sure if this is a common problem people will be glad to have it in the main OSG code base, only a CMake switch away... And then it will be easy to compare performance between the two and perhaps make the double version default if there is little/no performance difference... J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com 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] Picking bug?
Hi Robert, This topic has arisen previously on osg-submissions, and my recommendation then was that support for double maths through the intersection code shouldn't be a compile option, but an runtime option, this way the ABI wouldn't change and you could enable it when you needed it. I still believe this is the correct route. Hm, so are you suggesting osgUtil::LineSegmentIntersectord and associated *d classes, like we have osg::Vec3f and osg::Vec3d? Or add double versions of the methods in these classes? Basically, use the same classes but duplicate some methods in them or duplicate the classes altogether? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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] Picking bug?
2009/12/4 Fred Smith osgfo...@tevs.eu
Thanks for all your answers.
Hitting a little bit of a problem in my understanding of the source code.
If I change TriangleIntersection to use Vec3d and not Vec3:
Code:
TriangleIntersection(unsigned int index, const osg::Vec3d normal,
double r1, const osg::Vec3d* v1, double r2, const osg::Vec3d* v2, double r3,
const osg::Vec3d* v3):
_index(index),
_normal(normal),
_r1(r1),
_v1(v1),
_r2(r2),
_v2(v2),
_r3(r3),
_v3(v3) {}
You're changing the wrong bit. You want the next struct down
TriangleIntersector
struct TriangleIntersector
{
osg::Vec3 _s; change these
osg::Vec3 _d;
float _length;
int _index;
float _ratio;
bool_hit;
--
http://www.ssTk.co.uk
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking bug?
Nope, it still doesn't work. Not my lucky day... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20917#20917 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking bug?
The picking problem can be reproduced with the following OSG content,
containing only 2 triangles:
Code:
Geode {
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_0
DataVariance STATIC
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawElementsUInt TRIANGLES 6
{
0 1 2 3 4 5
}
}
VertexArray Vec3Array 6
{
5455 -1704.02 1112.38
5455 -1607.33 1317.42
5455 -1691.17 1088.37
5457.5 -1608.46 1304.84
5457.5 -1704.02 1112.38
5457.5 -1691.17 1088.37
}
NormalBinding PER_VERTEX
NormalArray Vec3Array 6
{
-1 0 0
-1 0 0
-1 0 0
1 0 0
1 0 0
1 0 0
}
}
}
Refer to the attached picture for how to reproduce the issue.
Again, balls represent intersection points, lines are normal vectors.
The ball showing up on the right triangle is unexpected - I picked the left
triangle.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20798#20798
attachment: picking_bug.PNG___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking bug?
Hi Fred,
I'm not sure what to make of the results or what you are expecting.
The IntersectionVistor/LineSegmentIntersector should return multiple
intersection, one for each intersection between any triangle and the
line segment - so if there a two overlapping triangles I would expect
two intersections.
You don't say how you are doing picking with this model, so I'm not
sure how the model can help others recreate what you are seeing.
Robert.
On Thu, Dec 3, 2009 at 10:21 AM, Fred Smith osgfo...@tevs.eu wrote:
The picking problem can be reproduced with the following OSG content,
containing only 2 triangles:
Code:
Geode {
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
UniqueID Geometry_0
DataVariance STATIC
useDisplayList TRUE
useVertexBufferObjects FALSE
PrimitiveSets 1
{
DrawElementsUInt TRIANGLES 6
{
0 1 2 3 4 5
}
}
VertexArray Vec3Array 6
{
5455 -1704.02 1112.38
5455 -1607.33 1317.42
5455 -1691.17 1088.37
5457.5 -1608.46 1304.84
5457.5 -1704.02 1112.38
5457.5 -1691.17 1088.37
}
NormalBinding PER_VERTEX
NormalArray Vec3Array 6
{
-1 0 0
-1 0 0
-1 0 0
1 0 0
1 0 0
1 0 0
}
}
}
Refer to the attached picture for how to reproduce the issue.
Again, balls represent intersection points, lines are normal vectors.
The ball showing up on the right triangle is unexpected - I picked the left
triangle.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20798#20798
___
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] Picking bug?
Hi, On one occasion I don't get two intersections, only one. That's the problem. I expect two intersections. One for the first triangle, one for the second. I get only one, for the second triangle, even though I picked the left triangle. You can easily reproduce this with the OSG file I listed. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20825#20825 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking bug?
2009/12/3 Fred Smith osgfo...@tevs.eu Hi, On one occasion I don't get two intersections, only one. That's the problem. I expect two intersections. One for the first triangle, one for the second. I get only one, for the second triangle, even though I picked the left triangle. You can easily reproduce this with the OSG file I listed. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20825#20825 This bug is due to the geometry being 2D and the actual intersection being calculated w/ floats. If you need a quick and dirty fix, you can change the code in void TriangleIntersector::operator () (...) [[ src\osgUtil\LineSegmentIntersector.cpp ]] To use doubles instead. I was going to make a submission for that, but I've been busy and this issue may benefit from a bit of discussion, rather than just changing the code to use doubles. Basically it boils down the fact that when the geometry is entirely 2d, there is some code in bool LineSegmentIntersector::intersectAndClip(...) which expands the bounding box, leaving it just 1e-4 across in the thin direction. When you have vertices out at larger coordinates ( ~4000) the intersection code starts hitting numeric precision problems. So you can either go with doubles, change the size of the expansion of the bounding box (and then hit precision issues again at some point in the future), add some sort of approximate floating point compare code or maybe don't clip the pick ray to the bounding box when there is 2D geometry. -- http://www.ssTk.co.uk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking bug?
robertosfield wrote: Hi Fred, I would be inclined to think this is more of an issue of expectation rather than a bug in computeIntersections/LineSegmentIntersector. The code is such that save for numerical precision issues it will work exactly the same for all triangles, so if it works once then it's likely to work all the time, and if it fails once it'll fail all the time. The code has been in place for quite a while so I would expect it to be working OK otherwise we'd have heard lots of more reports of problems. Most likely answer is simply that the winding of the triangles you are intersecting resulting in the normals that it's reporting. Please not face normals derived from the triangles themselves can be and usually are different than vertex normals at the corners of the triangles - they can even be pointing in different directions as vertex normals are specified at geometry creation time and needn't bare any connection to the faces. Thanks. I figured out how picking works with respect to the vertex ordering. However I do see unexpected behavior with some of our larger models, whereby the first intersection is not returned. I double checked and the vertex ordering is fine. Problems show up within the same triangle. I can consistently repro this bug with very large models I can't give away for analysis unfortunately. I can however try to find a small repro with a file in the examples folder or, as suggested by J.P., I can try changing the picking precision in the source code. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20744#20744 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking bug?
Hi Fred, I would be inclined to think this is more of an issue of expectation rather than a bug in computeIntersections/LineSegmentIntersector. The code is such that save for numerical precision issues it will work exactly the same for all triangles, so if it works once then it's likely to work all the time, and if it fails once it'll fail all the time. The code has been in place for quite a while so I would expect it to be working OK otherwise we'd have heard lots of more reports of problems. Most likely answer is simply that the winding of the triangles you are intersecting resulting in the normals that it's reporting. Please not face normals derived from the triangles themselves can be and usually are different than vertex normals at the corners of the triangles - they can even be pointing in different directions as vertex normals are specified at geometry creation time and needn't bare any connection to the faces. Robert. On Mon, Nov 30, 2009 at 6:24 PM, Fred Thegreat fclaux@gmail.com wrote: Hi, I'm trying to do picking by using computeIntersections. Please find the attached picture (skydome). Balls represent intersection points, lines represent normal vectors. Whenever I try to pick the top of the dome (not the inside), I get a correct intersection point but the normal vector is wrong. When I pick from the inside the yellow lines go downwards, as expected. I have noticed other strange behaviors with more complex models. Sometimes, the first intersection point/normal vector pair is not returned. Other times, the intersection point and/or the normal vector is wrong. We're using OSG 2.8.1 but I tested a recent version and experienced the same issue. Is this a known bug? Thanks, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20605#20605 Attachments: http://forum.openscenegraph.org//files/skydome_picking_problem_195.png ___ 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] Picking bug?
Hi Fred, have a look at this thread: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.cvs/4868/focus=4876 I'm not sure what the current float vs double in the intersection code path is like, but maybe you can try do some mods and see... jp Fred Thegreat wrote: Hi, I'm trying to do picking by using computeIntersections. Please find the attached picture (skydome). Balls represent intersection points, lines represent normal vectors. Whenever I try to pick the top of the dome (not the inside), I get a correct intersection point but the normal vector is wrong. When I pick from the inside the yellow lines go downwards, as expected. I have noticed other strange behaviors with more complex models. Sometimes, the first intersection point/normal vector pair is not returned. Other times, the intersection point and/or the normal vector is wrong. We're using OSG 2.8.1 but I tested a recent version and experienced the same issue. Is this a known bug? Thanks, Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20605#20605 Attachments: http://forum.openscenegraph.org//files/skydome_picking_problem_195.png ___ 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
