Re: [osg-users] LineSegmentIntersector

[OpenSceneGraph Users]

In my case its Perspective.


I was able to work around the problem by using a PolyTope intersector with 
a 1x1 rectangle. That worked perfectly.

On Tuesday, April 14, 2020 at 11:56:24 PM UTC-7, OpenSceneGraph Users wrote:
>
> Hi Andrew,
>
> When you say you have a isometric view, to be clear, you mean you have an 
> orthographic projection of the scene?  The OSG itself support orthographic 
> projection via the osg::Camera's ProjectionMatrix, the intersection.  It 
> can only account for this if the IntersectionVisitor knows about it's 
> setting.  
>
> Have you tried the osgViewer::View(er)::computeIntersections(..) method?
>
> This method knows about the View's Camera so can account for it's 
> projection matrix.
>
> Robert.
>
> On Tue, 14 Apr 2020 at 23:35, OpenSceneGraph Users <
> osg-...@lists.openscenegraph.org > wrote:
>
>> Hi,
>> I am having a lot of problems with picking with LineSegmentIntersector in 
>> OSG 3.6.5.
>>
>> I have reduced the problem to a a simple cube, center 0.5,0.5,0.5 with a 
>> boundingSphere radius of 1.2142
>>
>> I create the intersection with ( x , y are screen coordinates)
>>
>> picker=new osgUtil::LineSegmentIntersector ( osgUtil::Intersector::WINDOW
>> , x, y );
>> osgUtil::IntersectionVisitor iv ( picker );
>> getCamera()->accept ( iv );
>>
>>
>>
>> When I am "close" to the model geometry in an isometric view ( the cube 
>> fills,say, 50% of the screen), this works perfectly. I get the exact 
>> intersections coordinates I expect.
>>
>> When I "pull the camera back" from the geometry and the object is much 
>> smaller on the screen, the intersections fail.
>>
>> After much debugging, the problem is that the intersector fails the test 
>> of the intersection of the line with the bounding sphere of my model 
>> geometry
>>
>> Specifically I send up in
>>
>> bool LineSegmentIntersector::intersects(const osg::BoundingSphere& bs)
>>
>>
>> The BoundingSphere is in "model space" , and correct, but the _start and 
>> _end points used in the calculation are incorrect to intersect the sphere 
>> in model space and so the intersection fails.
>>
>> _start {_v=0x01ba7308d300 {13.227287349450325, -2.9785854231569449, -
>> 5.5167534692525066} }
>> _end {_v=0x01ba7308d318 {11.072576448741074, -5.1332963238661939, -
>> 7.6714332827528793} }
>>
>> Any ideas what is going on. It seems although the vector of start and end 
>> is the correct vector ( or the "closer" picking would not work), something 
>> is wrong in the transformation into model space.
>>
>> Thx
>> Andrew
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "OpenSceneGraph Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to osg-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osg-users/4fa21208-3ee7-45d7-a9cf-42a4b8a45d52%40googlegroups.com
>>  
>> 
>> .
>> ___
>> osg-users mailing list
>> osg-...@lists.openscenegraph.org 
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/440a9e5d-63e3-40d0-abed-490ca18a311d%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector

[OpenSceneGraph Users]

Hi Andrew,

When you say you have a isometric view, to be clear, you mean you have an
orthographic projection of the scene?  The OSG itself support orthographic
projection via the osg::Camera's ProjectionMatrix, the intersection.  It
can only account for this if the IntersectionVisitor knows about it's
setting.

Have you tried the osgViewer::View(er)::computeIntersections(..) method?

This method knows about the View's Camera so can account for it's
projection matrix.

Robert.

On Tue, 14 Apr 2020 at 23:35, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi,
> I am having a lot of problems with picking with LineSegmentIntersector in
> OSG 3.6.5.
>
> I have reduced the problem to a a simple cube, center 0.5,0.5,0.5 with a
> boundingSphere radius of 1.2142
>
> I create the intersection with ( x , y are screen coordinates)
>
> picker=new osgUtil::LineSegmentIntersector ( osgUtil::Intersector::WINDOW,
> x, y );
> osgUtil::IntersectionVisitor iv ( picker );
> getCamera()->accept ( iv );
>
>
>
> When I am "close" to the model geometry in an isometric view ( the cube
> fills,say, 50% of the screen), this works perfectly. I get the exact
> intersections coordinates I expect.
>
> When I "pull the camera back" from the geometry and the object is much
> smaller on the screen, the intersections fail.
>
> After much debugging, the problem is that the intersector fails the test
> of the intersection of the line with the bounding sphere of my model
> geometry
>
> Specifically I send up in
>
> bool LineSegmentIntersector::intersects(const osg::BoundingSphere& bs)
>
>
> The BoundingSphere is in "model space" , and correct, but the _start and
> _end points used in the calculation are incorrect to intersect the sphere
> in model space and so the intersection fails.
>
> _start {_v=0x01ba7308d300 {13.227287349450325, -2.9785854231569449, -
> 5.5167534692525066} }
> _end {_v=0x01ba7308d318 {11.072576448741074, -5.1332963238661939, -
> 7.6714332827528793} }
>
> Any ideas what is going on. It seems although the vector of start and end
> is the correct vector ( or the "closer" picking would not work), something
> is wrong in the transformation into model space.
>
> Thx
> Andrew
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSceneGraph Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/4fa21208-3ee7-45d7-a9cf-42a4b8a45d52%40googlegroups.com
> 
> .
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.84341.1586933770.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.84341.1586933770.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

[osg-users] LineSegmentIntersector

[OpenSceneGraph Users]

Hi,
I am having a lot of problems with picking with LineSegmentIntersector in 
OSG 3.6.5.

I have reduced the problem to a a simple cube, center 0.5,0.5,0.5 with a 
boundingSphere radius of 1.2142

I create the intersection with ( x , y are screen coordinates)

picker=new osgUtil::LineSegmentIntersector ( osgUtil::Intersector::WINDOW, x
, y );
osgUtil::IntersectionVisitor iv ( picker );
getCamera()->accept ( iv );



When I am "close" to the model geometry in an isometric view ( the cube 
fills,say, 50% of the screen), this works perfectly. I get the exact 
intersections coordinates I expect.

When I "pull the camera back" from the geometry and the object is much 
smaller on the screen, the intersections fail.

After much debugging, the problem is that the intersector fails the test of 
the intersection of the line with the bounding sphere of my model geometry

Specifically I send up in

bool LineSegmentIntersector::intersects(const osg::BoundingSphere& bs)


The BoundingSphere is in "model space" , and correct, but the _start and 
_end points used in the calculation are incorrect to intersect the sphere 
in model space and so the intersection fails.

_start {_v=0x01ba7308d300 {13.227287349450325, -2.9785854231569449, -
5.5167534692525066} }
_end {_v=0x01ba7308d318 {11.072576448741074, -5.1332963238661939, -
7.6714332827528793} }

Any ideas what is going on. It seems although the vector of start and end 
is the correct vector ( or the "closer" picking would not work), something 
is wrong in the transformation into model space.

Thx
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/4fa21208-3ee7-45d7-a9cf-42a4b8a45d52%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector and MatrixTransform nodes

[OpenSceneGraph Users]

Hi Andrew,

On Thu, 6 Feb 2020 at 18:11, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> This is an old issue that appears to still be in 3.6.3
> It appears that if any geometry is under a MatrixTransform node then
> osg::LineSegmentIntersector fails to intersect properly with this
> geometry.  I am not using scaling in the matrix transform.The only solution
> is to manually transform the geometry and not use any MatrixTransforms.
>

This should work fine, perhaps you doing something inappropriate.
Could you provide an example that illustrates the problem?

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

[osg-users] LineSegmentIntersector and MatrixTransform nodes

[OpenSceneGraph Users]

This is an old issue that appears to still be in 3.6.3
It appears that if any geometry is under a MatrixTransform node then
osg::LineSegmentIntersector fails to intersect properly with this
geometry.  I am not using scaling in the matrix transform.The only solution
is to manually transform the geometry and not use any MatrixTransforms.

Thx
Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.69113.1581012041.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.69113.1581012041.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

Re: [osg-users] LineSegmentIntersector and MODEL Frame

[OpenSceneGraph Users]

I found the problem, and it was mine. It helps if I attach my root node to 
the scene BEFORE I try to insect with it. ;)

On Monday, February 3, 2020 at 1:04:10 PM UTC-5, Nonsanity wrote:
>
> Thanks. I had thought to apply the visitor to the scene, but GetScene() 
> didn't have Accept(). With your confirmation that using the scene was 
> correct, I found that viewer.getSceneData()->accept( iv ) did exist.
>
> However, calling that line just results in a segfault. The rest of the 
> code is the same as before. I'm going to search to see if I'm doing 
> something obviously wrong, but in case I got the above line incorrect, I 
> wanted to post my failed results here for further comment.
>
>
> On Monday, February 3, 2020 at 3:06:33 AM UTC-5, OpenSceneGraph Users 
> wrote:
>>
>> Hi Chris,
>> I guess you want the scene to accept the IntersectionVisitor, not the 
>> camera.
>> Laurens.
>>
>> On Sat, Feb 1, 2020 at 1:18 PM OpenSceneGraph Users <
>> osg-...@lists.openscenegraph.org> wrote:
>>
>>> I have a scene built with a few objects loaded, the most pertinent one 
>>> being a large plane surface centered at the origin. I want to cast a ray 
>>> from a particular point at a particular angle inside the scene and get a 
>>> list of everything it intersects—both the point of intersection and the 
>>> Node object. Most examples of using intersectors involve picking from the 
>>> window, so I haven't seen exactly what I wanted. But from what I've read, 
>>> the following should at least be close:
>>>
>>> Vec3d start( 0.0, 0.0, 100.0 );
>>> Vec3d end( 0.0, 0.0, -100.0 );
>>> ref_ptr intsec = new LineSegmentIntersector( 
>>> Intersector::MODEL, start, end );
>>> IntersectionVisitor iv( intsec.get() );
>>> viewer.getCamera()->accept( iv );
>>> cout << intsec->containsIntersections() << endl;
>>>
>>> My start and end points in this snippet are well above and well below 
>>> the surface object. So that plane object should definitely be intersected 
>>> by a line running between them. However the containsIntersections function 
>>> always returns false.
>>>
>>> Immediately after making this preliminary test pick, the program calls 
>>> viewer.run() so I know everything is arranged as expected in the scene. So 
>>> my guess is that I'm missunderstanding how the visitor works. Perhaps the 
>>> accept() function is not what I should be using to execute the intersector?
>>>
>>>  ~ Chris
>>>
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "OpenSceneGraph Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to osg-...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/osg-users/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com
>>>  
>>> 
>>> .
>>> ___
>>> osg-users mailing list
>>> osg-...@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/c000c686-2aa4-410f-902d-33e95248450c%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector and MODEL Frame

[OpenSceneGraph Users]

Thanks. I had thought to apply the visitor to the scene, but GetScene() 
didn't have Accept(). With your confirmation that using the scene was 
correct, I found that viewer.getSceneData()->accept( iv ) did exist.

However, calling that line just results in a segfault. The rest of the code 
is the same as before. I'm going to search to see if I'm doing something 
obviously wrong, but in case I got the above line incorrect, I wanted to 
post my failed results here for further comment.


On Monday, February 3, 2020 at 3:06:33 AM UTC-5, OpenSceneGraph Users wrote:
>
> Hi Chris,
> I guess you want the scene to accept the IntersectionVisitor, not the 
> camera.
> Laurens.
>
> On Sat, Feb 1, 2020 at 1:18 PM OpenSceneGraph Users <
> osg-...@lists.openscenegraph.org > wrote:
>
>> I have a scene built with a few objects loaded, the most pertinent one 
>> being a large plane surface centered at the origin. I want to cast a ray 
>> from a particular point at a particular angle inside the scene and get a 
>> list of everything it intersects—both the point of intersection and the 
>> Node object. Most examples of using intersectors involve picking from the 
>> window, so I haven't seen exactly what I wanted. But from what I've read, 
>> the following should at least be close:
>>
>> Vec3d start( 0.0, 0.0, 100.0 );
>> Vec3d end( 0.0, 0.0, -100.0 );
>> ref_ptr intsec = new LineSegmentIntersector( 
>> Intersector::MODEL, start, end );
>> IntersectionVisitor iv( intsec.get() );
>> viewer.getCamera()->accept( iv );
>> cout << intsec->containsIntersections() << endl;
>>
>> My start and end points in this snippet are well above and well below the 
>> surface object. So that plane object should definitely be intersected by a 
>> line running between them. However the containsIntersections function 
>> always returns false.
>>
>> Immediately after making this preliminary test pick, the program calls 
>> viewer.run() so I know everything is arranged as expected in the scene. So 
>> my guess is that I'm missunderstanding how the visitor works. Perhaps the 
>> accept() function is not what I should be using to execute the intersector?
>>
>>  ~ Chris
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "OpenSceneGraph Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to osg-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osg-users/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com
>>  
>> 
>> .
>> ___
>> osg-users mailing list
>> osg-...@lists.openscenegraph.org 
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/36f90789-908b-452a-b629-19c7bd55d43a%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector and MODEL Frame

[OpenSceneGraph Users]

Hi Chris,
I guess you want the scene to accept the IntersectionVisitor, not the
camera.
Laurens.

On Sat, Feb 1, 2020 at 1:18 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> I have a scene built with a few objects loaded, the most pertinent one
> being a large plane surface centered at the origin. I want to cast a ray
> from a particular point at a particular angle inside the scene and get a
> list of everything it intersects—both the point of intersection and the
> Node object. Most examples of using intersectors involve picking from the
> window, so I haven't seen exactly what I wanted. But from what I've read,
> the following should at least be close:
>
> Vec3d start( 0.0, 0.0, 100.0 );
> Vec3d end( 0.0, 0.0, -100.0 );
> ref_ptr intsec = new LineSegmentIntersector(
> Intersector::MODEL, start, end );
> IntersectionVisitor iv( intsec.get() );
> viewer.getCamera()->accept( iv );
> cout << intsec->containsIntersections() << endl;
>
> My start and end points in this snippet are well above and well below the
> surface object. So that plane object should definitely be intersected by a
> line running between them. However the containsIntersections function
> always returns false.
>
> Immediately after making this preliminary test pick, the program calls
> viewer.run() so I know everything is arranged as expected in the scene. So
> my guess is that I'm missunderstanding how the visitor works. Perhaps the
> accept() function is not what I should be using to execute the intersector?
>
>  ~ Chris
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSceneGraph Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com
> 
> .
> ___
> 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] LineSegmentIntersector and MODEL Frame

[OpenSceneGraph Users]

I have a scene built with a few objects loaded, the most pertinent one 
being a large plane surface centered at the origin. I want to cast a ray 
from a particular point at a particular angle inside the scene and get a 
list of everything it intersects—both the point of intersection and the 
Node object. Most examples of using intersectors involve picking from the 
window, so I haven't seen exactly what I wanted. But from what I've read, 
the following should at least be close:

Vec3d start( 0.0, 0.0, 100.0 );
Vec3d end( 0.0, 0.0, -100.0 );
ref_ptr intsec = new LineSegmentIntersector( 
Intersector::MODEL, start, end );
IntersectionVisitor iv( intsec.get() );
viewer.getCamera()->accept( iv );
cout << intsec->containsIntersections() << endl;

My start and end points in this snippet are well above and well below the 
surface object. So that plane object should definitely be intersected by a 
line running between them. However the containsIntersections function 
always returns false.

Immediately after making this preliminary test pick, the program calls 
viewer.run() so I know everything is arranged as expected in the scene. So 
my guess is that I'm missunderstanding how the visitor works. Perhaps the 
accept() function is not what I should be using to execute the intersector?

 ~ Chris



-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector::intersect + performance

[Guy Volckaert]

Excellent. I tested it and everything seems to work as expected. Thanks for the 
quick response. 

BTW: I'm also investigating a way to somehow "cache" the last drawable that we 
intersected with (terrain only). If this works, it could prove to be a 
significant performance gain in  situations where we simulate ground vehicles 
or lifeforms (for example), since their speed is relatively slow and the 
probably of intersecting the same geometry at the next frame is very high. My 
objective is to try to intersect with the cached drawable first, and there's no 
intersection then fallback to intersecting the entire terrain.

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





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

Re: [osg-users] LineSegmentIntersector::intersect + performance

[Robert Osfield]

HI Guy,

On Tue, 26 Jun 2018 at 20:10, Robert Osfield  wrote:
> As for the creation or the Settings object on the heap, as it's a
> local new/delete and operation within a single thread it is probably
> safe to replace with an object on the stack.

I have implemented this and checked it into the 3.6 branch.  Could you
test this?

   
https://github.com/openscenegraph/OpenSceneGraph/commit/cbcf7015bba30020c4a6427a9d5f926641dc4096

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

Re: [osg-users] LineSegmentIntersector::intersect + performance

[Robert Osfield]

Hi Guy,

Just how many separate LineSegmentIntersection and  Drawables are you
trying to intersect with?

As for the creation or the Settings object on the heap, as it's a
local new/delete and operation within a single thread it is probably
safe to replace with an object on the stack.

Robert.
On Tue, 26 Jun 2018 at 19:06, Volckaert, Guy (CA - MTS)
 wrote:
>
> Hi,
>
> I recently upgraded to the OSG v3.6.1 and I noticed that the new 
> LineSegmentIntersector has changed significantly compared to v3.4.0. As I was 
> reviewing the changes, I noticed that the LineSegmentIntersector now 
> allocates an instance of LineSegmentIntersectorUtils::Settings every time the 
> IntersectionVisitor intercepts a drawable.
>
> From a purely efficiency standpoint, I was wondering if we could do better. 
> Intersection were relatively slow in the past and now it seems that we made 
> even slower. That being said, I'm pretty sure there's a valid reason for why 
> it was done this way. Before I look at alternative solutions, I was wondering 
> if anyone could share for reasons.
>
> Below is a snip-it of the function:
>
> void LineSegmentIntersector::intersect(osgUtil::IntersectionVisitor& iv, 
> osg::Drawable* drawable,
>const osg::Vec3d& s, const osg::Vec3d& 
> e)
> {
> if (reachedLimit()) return;
>
> osg::ref_ptr settings = new 
> LineSegmentIntersectorUtils::Settings; // << HERE 
> settings->_lineSegIntersector = this;
> settings->_iv = 
> settings->_drawable = drawable;
> settings->_limitOneIntersection = (_intersectionLimit == 
> LIMIT_ONE_PER_DRAWABLE || _intersectionLimit == LIMIT_ONE);
>
> osg::Geometry* geometry = drawable->asGeometry();
> if (geometry)
> {
> settings->_vertices = 
> dynamic_cast(geometry->getVertexArray());
> }
>
> osg::KdTree* kdTree = iv.getUseKdTreeWhenAvailable() ? 
> dynamic_cast(drawable->getShape()) : 0;
>
> if (getPrecisionHint()==USE_DOUBLE_CALCULATIONS)
> {
> 
> osg::TemplatePrimitiveFunctor  double> > intersector;
> intersector.set(s,e, settings.get());
>
> if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0));
> else drawable->accept(intersector);
> }
> else
> {
> 
> osg::TemplatePrimitiveFunctor  float> > intersector;
> intersector.set(s,e, settings.get());
>
> if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0));
> else drawable->accept(intersector);
> }
> }
>
> Regards,
>
> Guy Volckaert, ing.
> Snr Software Engineer
>
> Meggitt Training Systems (Quebec) Inc.
> Systèmes d'entraînement Meggitt (Québec) Inc.
> 6140 Henri Bourassa West
> Montreal, Quebec, H4R 3A6
> Canada
>
> Tel: 1 (514) 339 9938 Ext 617
> Fax: 1 (514) 339 2641
> Cell: 1 (514) 928-5641
> email: guy.volcka...@meggitt.com
> url; www.meggitt.com
> skype: guy.volckaert
>
> Svp. Considérez l'environnement avant d'imprimer
> Please consider the environment before printing this e-mail.
>
>
> 
>
>
> This e-mail may contain proprietary information and/or copyright material. 
> This e-mail is intended for the use of the addressee only. Any unauthorized 
> use may be unlawful. If you receive this e-mail by mistake, please advise the 
> sender immediately by using the reply facility in your e-mail software.
>
> Information contained in and/or attached to this document may be subject to 
> export control regulations of the European Community, USA, or other 
> countries. Each recipient of this document is responsible to ensure that 
> usage and/or transfer of any information contained in this document complies 
> with all relevant export control regulations. If you are in any doubt about 
> the export control restrictions that apply to this information, please 
> contact the sender immediately.
>
> Be aware that Meggitt may monitor incoming and outgoing e-mails to ensure 
> compliance with the Meggitt IT Use policy.
>
> ___
> 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] LineSegmentIntersector::intersect + performance

[Volckaert, Guy (CA - MTS)]

Hi,

I recently upgraded to the OSG v3.6.1 and I noticed that the new 
LineSegmentIntersector has changed significantly compared to v3.4.0. As I was 
reviewing the changes, I noticed that the LineSegmentIntersector now allocates 
an instance of LineSegmentIntersectorUtils::Settings every time the 
IntersectionVisitor intercepts a drawable.

>From a purely efficiency standpoint, I was wondering if we could do better. 
>Intersection were relatively slow in the past and now it seems that we made 
>even slower. That being said, I'm pretty sure there's a valid reason for why 
>it was done this way. Before I look at alternative solutions, I was wondering 
>if anyone could share for reasons.

Below is a snip-it of the function:

void LineSegmentIntersector::intersect(osgUtil::IntersectionVisitor& iv, 
osg::Drawable* drawable,
   const osg::Vec3d& s, const osg::Vec3d& e)
{
if (reachedLimit()) return;

osg::ref_ptr settings = new 
LineSegmentIntersectorUtils::Settings; // << HERE 
settings->_lineSegIntersector = this;
settings->_iv = 
settings->_drawable = drawable;
settings->_limitOneIntersection = (_intersectionLimit == 
LIMIT_ONE_PER_DRAWABLE || _intersectionLimit == LIMIT_ONE);

osg::Geometry* geometry = drawable->asGeometry();
if (geometry)
{
settings->_vertices = 
dynamic_cast(geometry->getVertexArray());
}

osg::KdTree* kdTree = iv.getUseKdTreeWhenAvailable() ? 
dynamic_cast(drawable->getShape()) : 0;

if (getPrecisionHint()==USE_DOUBLE_CALCULATIONS)
{

osg::TemplatePrimitiveFunctor > intersector;
intersector.set(s,e, settings.get());

if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0));
else drawable->accept(intersector);
}
else
{

osg::TemplatePrimitiveFunctor > intersector;
intersector.set(s,e, settings.get());

if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0));
else drawable->accept(intersector);
}
}

Regards,

Guy Volckaert, ing.
Snr Software Engineer

Meggitt Training Systems (Quebec) Inc.
Systèmes d'entraînement Meggitt (Québec) Inc.
6140 Henri Bourassa West
Montreal, Quebec, H4R 3A6
Canada

Tel: 1 (514) 339 9938 Ext 617
Fax: 1 (514) 339 2641
Cell: 1 (514) 928-5641
email: guy.volcka...@meggitt.com
url; www.meggitt.com
skype: guy.volckaert

Svp. Considérez l'environnement avant d'imprimer
Please consider the environment before printing this e-mail.





This e-mail may contain proprietary information and/or copyright material. This 
e-mail is intended for the use of the addressee only. Any unauthorized use may 
be unlawful. If you receive this e-mail by mistake, please advise the sender 
immediately by using the reply facility in your e-mail software.

Information contained in and/or attached to this document may be subject to 
export control regulations of the European Community, USA, or other countries. 
Each recipient of this document is responsible to ensure that usage and/or 
transfer of any information contained in this document complies with all 
relevant export control regulations. If you are in any doubt about the export 
control restrictions that apply to this information, please contact the sender 
immediately.

Be aware that Meggitt may monitor incoming and outgoing e-mails to ensure 
compliance with the Meggitt IT Use policy.

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

Re: [osg-users] LineSegmentIntersector doesn't give accurate Coordinates

[Jochen Schwitzer]

Hi,

fixed the issue. I was using a defect Drawer. Thanks anyway

Thank you!

Cheers,
Jochen

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





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

Re: [osg-users] LineSegmentIntersector doesn't give accurate Coordinates

[Jochen Schwitzer]

Hi Robert,

thanks for your quick response.

so here's what I'm doing:


Code:

if (viewer)
{
returnValue =
ReactOnLCSPointClick(
*viewer, i_eventAdapter.getX(), i_eventAdapter.getY());
}




I tried as well with getXnormalized() and Intersector::PROJECTION but then it 
was even more far off


Code:
osg::ref_ptr intersector = new 
osgUtil::LineSegmentIntersector(
osgUtil::Intersector::WINDOW, i_clickXCoordinate, i_clickYCoordinate);

osgUtil::IntersectionVisitor iv(intersector.get());

iv.setTraversalMask(~0x1);

io_viewer.getCamera()->accept(iv);

 osgUtil::LineSegmentIntersector::Intersections intersections = 
intersector->getIntersections();

for (osgUtil::LineSegmentIntersector::Intersections::const_iterator i = 
intersections.begin();
i != intersections.end(); ++i)
{
if (nodePath.back()->getName() == "xxx")
{

osg::Vec3 lcsIntersectPoint = i->getLocalIntersectPoint();
float x = lcsIntersectPoint.x()
float y = lcsIntersectPoint.y();
returnValue = true;
break;
}
}



I draw a point at the coordinates i get in the end

Thank you!

Cheers,
Jochen

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




Attachments: 
http://forum.openscenegraph.org//files/capture_252.png


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

Re: [osg-users] LineSegmentIntersector doesn't give accurate Coordinates

[Robert Osfield]

Hi Jochen,

There is too many unknowns about what you are doing for us to be provide
any specific advice as to what is going wrong.

It could be that your are passing in the mouse coords incorrectly.  It
could be that you are interpreting the intersections coordinates
incorrectly.  It could be that you are inserting your visual markers
incorrectly.  It could be some other random thing that you are doing wrong.

As when doing know anything specific about your code there is nothing we
can do to help at this point.  You best next step would be to post some of
the code you are using to set up the intersection, to place your visual
markers and a screen shot of what is happening.

Cheers,
Robert.

On Thu, 21 Jun 2018 at 11:44, Jochen Schwitzer <
fasoldma63...@th-nuernberg.de> wrote:

> Hi,
>
> I am trying to get the local coordinates of my mouse in a 2D scene, when
> the mouse is clicked.
>
> I draw a transparent terrain and use the LineSegmentIntersector with the
> Mouse Coordinates to get the LocalIntersectionPoint and draw this point
> then.
>
> However, when I click, the point is always at some place else. Always
> relative to the mouse position but the distance varies when I zoom in or
> out.
>
> Can anybody help me? What am I missing?
>
> Thank you!
>
> Cheers,
> Jochen
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74098#74098
>
>
>
>
>
> ___
> 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] LineSegmentIntersector NaN warnings on zero-scaled nodes.

[Robert Osfield]

HI Jannik,

I haven't had a look at the modified example yet, it's the weekend so I'm
just briefly online.  Quick thoughts are:

  inverting a zero'd matrix will naturally lead to an invalid matrix.

My inclination is that the case where a zero matrix could be produced is a
special case that needs to be caught higher up in the calling methods
rather than try and implement so lower level workaround.

The actual concept behind the transformations that are being done of the
line segment is transform into the coordinate frame of a subgraph and then
trimming it so that you only test the extents that intersect that subgaph's
bounding volume.  If a bounding volume is invalid then you can't do this
test and clip.

For a zero radius bounding sphere, such as a sub-graph that contains just a
single point then this is a special case - the line segment would have to
exactly pass through the centre of the bounding sphere.  One approach this
might be to always increase the radius of the sphere by an epsilon so it;'s
not non zero and do the test and clip against this.  epsilon's are already
used elsewhere in LineSegmentIntersector,  I need to get back to me family
now so can't look further into the topic.

Robert.



On 21 November 2015 at 16:02, Jannik Heller  wrote:

> Hi,
>
> The LineSegmentIntersector creates NaN warnings when applied to a node
> with zero scale. I've attached a 3 line change to osgintersection.cpp to
> reproduce the issue.
>
> The NaN's first pop up when OSG tries to invert a zero matrix here:
> https://github.com/openscenegraph/osg/blob/master/src/osgUtil/LineSegmentIntersector.cpp#L294
>
> Check with the following code snippet:
>
> Code:
>
> osg::Matrix zero(0,0,0,0, 0,0,0,0, 0,0,0,0, 0,0,0,1);
>
> if (zero.invert(zero))
> std::cout << "inverted " << zero << std::endl;
>
>
>
> invert() returns true but the inverted matrix is
>
> inverted {
> -nan -nan -nan 0
> -nan -nan -nan 0
> -nan -nan -nan 0
> nan nan nan 1
> }
>
> This looks like a bug in the Matrix invert function.
>
> However even if the matrix was still zero instead of NaN, there is another
> issue here:
>
> osg::ref_ptr lsi = new
> LineSegmentIntersector(_start * matrix, _end * matrix);
>
> Multiplying a vec3 with a zero matrix will cause NaN's, because there is
> an 1.0 / (mat * vec ...) in the Matrix::preMult(Vec3) function.
>
> Not sure on the best way to fix this. Should we add explicit checks for
> zero scaled matrices in the LineSegmentIntersector, or fix the Matrix and
> Vec classes so they don't produce NaN's under any circumstances for
> (borderline) valid input? The latter seems the cleaner fix but would have a
> performance impact all over OSG.
>
> Thank you!
>
> Cheers,
> Jannik
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65720#65720
>
>
>
>
> ___
> 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] LineSegmentIntersector NaN warnings on zero-scaled nodes.

[Jannik Heller]

Hi,

The LineSegmentIntersector creates NaN warnings when applied to a node with 
zero scale. I've attached a 3 line change to osgintersection.cpp to reproduce 
the issue.

The NaN's first pop up when OSG tries to invert a zero matrix here: 
https://github.com/openscenegraph/osg/blob/master/src/osgUtil/LineSegmentIntersector.cpp#L294

Check with the following code snippet:

Code:

osg::Matrix zero(0,0,0,0, 0,0,0,0, 0,0,0,0, 0,0,0,1);

if (zero.invert(zero))
std::cout << "inverted " << zero << std::endl;



invert() returns true but the inverted matrix is 

inverted {
-nan -nan -nan 0 
-nan -nan -nan 0 
-nan -nan -nan 0 
nan nan nan 1 
}

This looks like a bug in the Matrix invert function.

However even if the matrix was still zero instead of NaN, there is another 
issue here:

osg::ref_ptr lsi = new 
LineSegmentIntersector(_start * matrix, _end * matrix);

Multiplying a vec3 with a zero matrix will cause NaN's, because there is an 1.0 
/ (mat * vec ...) in the Matrix::preMult(Vec3) function.

Not sure on the best way to fix this. Should we add explicit checks for zero 
scaled matrices in the LineSegmentIntersector, or fix the Matrix and Vec 
classes so they don't produce NaN's under any circumstances for (borderline) 
valid input? The latter seems the cleaner fix but would have a performance 
impact all over OSG.

Thank you!

Cheers,
Jannik

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



/* OpenSceneGraph example, osgintersection.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 

#include 
#include 

#include 
#include 
#include 

#include 

struct MyReadCallback : public osgUtil::IntersectionVisitor::ReadCallback
{
#if 0
virtual osg::Node* readNodeFile(const std::string& filename)
{
return osgDB::readRefNodeFile(filename).release();
}
#endif
virtual osg::ref_ptr readNodeFile(const std::string& filename)
{
return osgDB::readRefNodeFile(filename);
}
};


int main(int argc, char **argv)
{
// use an ArgumentParser object to manage the program arguments.
osg::ArgumentParser arguments(,argv);

osg::ref_ptr scene = osgDB::readRefNodeFiles(arguments);

if (!scene)
{
std::cout<<"No model loaded, please specify a valid model on the command line."<addChild(scene);
transform->setScale(osg::Vec3f(0,0,0));
transform->setCullingActive(false);


std::cout<<"Intersection "<getBound();

scene = transform;


bool useIntersectorGroup = true;
bool useLineOfSight = true;

//osg::CoordinateSystemNode* csn = dynamic_cast(scene.get());
//osg::EllipsoidModel* em = csn ? csn->getEllipsoidModel() : 0;

if (useLineOfSight)
{

osg::Vec3d start = bs.center() + osg::Vec3d(0.0,bs.radius(),0.0);
osg::Vec3d end = bs.center() - osg::Vec3d(0.0, bs.radius(),0.0);
osg::Vec3d deltaRow( 0.0, 0.0, bs.radius()*0.01);
osg::Vec3d deltaColumn( bs.radius()*0.01, 0.0, 0.0);

osgSim::LineOfSight los;

#if 1
unsigned int numRows = 20;
unsigned int numColumns = 20;
osgSim::HeightAboveTerrain hat;
hat.setDatabaseCacheReadCallback(los.getDatabaseCacheReadCallback());

for(unsigned int r=0; rtick();

Re: [osg-users] LineSegmentIntersector bug?

[Robert Osfield]

HI ? Could you sign your post so we know how to address you :-)

From the description of the problem it looks likely to be a precision issue
where the line segment aligns right along the edge between two triangles
with neither triangle passing the test.

In the svn/trunk version of the OSG there is a
IntersectionVisitor::setPrecisionHint(PrecisionHint hint) method that you
can use to hint to the intersectors to use double maths.  The
LineSegmentIntersector supports this.

Could you try this out to see if it helps?
Robert.

On 5 October 2014 09:51, weijianggood weijiangg...@163.com wrote:


 Hi,
 When i use LineSegmentIntersector in the following code.
 there must be 8 lines. but after I run the code, only 7 lines exist.

 [image: Lines.png]

  int main( int argc, char** argv ){

 float height = 5.f;

 osg::ref_ptrosg::TessellationHints hints;
 hints = new osg::TessellationHints;
 hints-setDetailRatio(0.5f);
 hints-setCreateBody(true);
 hints-setCreateBottom(false);
 hints-setCreateTop(false);
 osg::ref_ptrosg::Geode mynode = new osg::Geode;

 osg::ref_ptrosg::ShapeDrawable drawable = new 
 osg::ShapeDrawable(new 
 osg::Cylinder(osg::Vec3(0.0f,0.0f,0.0f),1.0f,height),hints);

 osg::ref_ptrosg::ShapeDrawable drawable2 = new 
 osg::ShapeDrawable(new 
 osg::Cylinder(osg::Vec3(0.0f,0.0f,0.0f),4.0f,height),hints);

 mynode-addDrawable(drawable.get());// geom.get() or gemo. 
 both are ok.
 mynode-addDrawable(drawable2.get());

 osg::ref_ptrosg::Group root = new osg::Group;
 root-addChild(mynode.get() );
 float angle = 0.0;
 float angleDelta = 2.0f*osg::PI/8;

 for(int i=0; i8;i++){
 float c = cosf(angle);
 float s = sinf(angle);

 osg::ref_ptrosgUtil::LineSegmentIntersector intersector = 
 new osgUtil::LineSegmentIntersector( osg::Vec3(0.0f,0.0f,0.0f),  
 osg::Vec3(10.0f*c,10.0f*s,0.0f) );

 osgUtil::IntersectionVisitor iv( intersector.get() );
 mynode-accept( iv );

 if ( intersector-containsIntersections() )
 {
 osgUtil::LineSegmentIntersector::Intersections

 intersections = 
 intersector-getIntersections();

 std::cout intersection size 
 intersections.size()std::endl;

 osg::ref_ptrosg::Geode  geode=new osg::Geode;
 osg::ref_ptrosg::Geometry geom=new osg::Geometry;

 osg::ref_ptrosg::Vec3Array v3a=new osg::Vec3Array;

 osg::ref_ptrosg::Vec4Array colors = new 
 osg::Vec4Array;
 colors-push_back( osg::Vec4(1.0, 0.0, 0.0, 1.0) );


 
 osgUtil::LineSegmentIntersector::Intersections::iterator itr;

 for ( itr = intersections.begin(); itr != 
 intersections.end(); ++itr ) {

 std::cout  X  
 itr-getWorldIntersectPoint().x()

   Y   
 itr-getWorldIntersectPoint().y()

   Z  
 itr-getWorldIntersectPoint().z();
 if(itr == intersections.begin())

 v3a-push_back( 
 itr-getWorldIntersectPoint());

 }
 itr--;

 v3a-push_back( 
 itr-getWorldIntersectPoint());
 std::coutstd::endl;
 geom-setVertexArray(v3a);
 geom-setColorArray(colors.get() );
 geom-setColorBinding(osg::Geometry::BIND_OVERALL);
 for(int k=0; kv3a-size(); k++){

 std::coutvectex: v3a-at(k).x() 
 v3a-at(k).y() v3a-at(k).z();
 }
 std::coutstd::endl;

 geom-addPrimitiveSet(new 
 osg::DrawArrays(osg::PrimitiveSet::LINES,0,v3a-size()));
 geode-addDrawable(geom);
 root-addChild(geode);
 }else{
 std::coutno intersection for i=istd::endl;

 std::coutx intersector-getStart().x() y 
 intersector-getStart().y() z intersector-getStart().z()std::endl;

 std::coutx intersector-getEnd().x() y 
 intersector-getEnd().y() z intersector-getEnd().z()std::endl;
 }
 angle+=angleDelta;
 }
 osgViewer::Viewer viewer;
 viewer.setSceneData(root.get());
 viewer.addEventHandler(new osgViewer::WindowSizeHandler);
 return viewer.run();

 }

 Thanks.

 --


 ___
 osg-users mailing list
 

Re: [osg-users] LineSegmentIntersector bug?

[weijianggood]

Hello, Robert,

Thank you for the suggestion.
Currently, I am using osg3.0.1, intersector does not have the function 
setPrecisionHint.
So I download the newest  version of osg from svn, then compile it.

Finally,
I add  the following line into my test code:
intersector-setPrecisionHint(osgUtil::Intersector::PrecisionHint::USE_DOUBLE_CALCULATIONS);
 
It worked. Woo!  
Thanks again.

Rubby








From: Robert Osfield
Date: 2014-10-06 16:22
To: OpenSceneGraph Users
Subject: Re: [osg-users] LineSegmentIntersector bug?
HI ? Could you sign your post so we know how to address you :-)


From the description of the problem it looks likely to be a precision issue 
where the line segment aligns right along the edge between two triangles with 
neither triangle passing the test.


In the svn/trunk version of the OSG there is a 
IntersectionVisitor::setPrecisionHint(PrecisionHint hint) method that you can 
use to hint to the intersectors to use double maths.  The 
LineSegmentIntersector supports this.


Could you try this out to see if it helps?

Robert.



On 5 October 2014 09:51, weijianggood weijiangg...@163.com wrote:


Hi,
When i use LineSegmentIntersector in the following code.
there must be 8 lines. but after I run the code, only 7 lines exist.



int main( int argc, char** argv ){

float height = 5.f;

osg::ref_ptrosg::TessellationHints hints;
hints = new osg::TessellationHints;
hints-setDetailRatio(0.5f);
hints-setCreateBody(true);
hints-setCreateBottom(false);
hints-setCreateTop(false);
osg::ref_ptrosg::Geode mynode = new osg::Geode;
osg::ref_ptrosg::ShapeDrawable drawable = new osg::ShapeDrawable(new 
osg::Cylinder(osg::Vec3(0.0f,0.0f,0.0f),1.0f,height),hints);
osg::ref_ptrosg::ShapeDrawable drawable2 = new osg::ShapeDrawable(new 
osg::Cylinder(osg::Vec3(0.0f,0.0f,0.0f),4.0f,height),hints);
mynode-addDrawable(drawable.get());// geom.get() or gemo. both 
are ok. 
mynode-addDrawable(drawable2.get());

osg::ref_ptrosg::Group root = new osg::Group;
root-addChild(mynode.get() );
float angle = 0.0;
float angleDelta = 2.0f*osg::PI/8;

for(int i=0; i8;i++){  
float c = cosf(angle);
float s = sinf(angle);
osg::ref_ptrosgUtil::LineSegmentIntersector intersector = new 
osgUtil::LineSegmentIntersector( osg::Vec3(0.0f,0.0f,0.0f),  
osg::Vec3(10.0f*c,10.0f*s,0.0f) );

osgUtil::IntersectionVisitor iv( intersector.get() );
mynode-accept( iv );

if ( intersector-containsIntersections() )
{
osgUtil::LineSegmentIntersector::Intersections
intersections = 
intersector-getIntersections();
std::cout intersection size 
intersections.size()std::endl;

osg::ref_ptrosg::Geode  geode=new osg::Geode;
osg::ref_ptrosg::Geometry geom=new osg::Geometry;
osg::ref_ptrosg::Vec3Array v3a=new osg::Vec3Array;
osg::ref_ptrosg::Vec4Array colors = new 
osg::Vec4Array;
colors-push_back( osg::Vec4(1.0, 0.0, 0.0, 1.0) );


osgUtil::LineSegmentIntersector::Intersections::iterator itr;
for ( itr = intersections.begin(); itr != 
intersections.end(); ++itr ) {
std::cout  X  
itr-getWorldIntersectPoint().x()
  Y   
itr-getWorldIntersectPoint().y()
  Z  
itr-getWorldIntersectPoint().z();
if(itr == intersections.begin())
v3a-push_back( 
itr-getWorldIntersectPoint());

}
itr--;
v3a-push_back( itr-getWorldIntersectPoint());
std::coutstd::endl;
geom-setVertexArray(v3a);
geom-setColorArray(colors.get() );
geom-setColorBinding(osg::Geometry::BIND_OVERALL);
for(int k=0; kv3a-size(); k++){
std::coutvectex: v3a-at(k).x() 
v3a-at(k).y() v3a-at(k).z();
}
std::coutstd::endl;
geom-addPrimitiveSet(new 
osg::DrawArrays(osg::PrimitiveSet::LINES,0,v3a-size()));
geode-addDrawable(geom);
root-addChild(geode);
}else{
std::coutno intersection for i=istd::endl;
std::coutx intersector-getStart().x() y 
intersector-getStart().y() z intersector-getStart().z()std::endl;
std::coutx intersector

[osg-users] LineSegmentIntersector bug?

[weijianggood]

Hi,
When i use LineSegmentIntersector in the following code.
there must be 8 lines. but after I run the code, only 7 lines exist.



int main( int argc, char** argv ){

float height = 5.f;

osg::ref_ptrosg::TessellationHints hints;
hints = new osg::TessellationHints;
hints-setDetailRatio(0.5f);
hints-setCreateBody(true);
hints-setCreateBottom(false);
hints-setCreateTop(false);
osg::ref_ptrosg::Geode mynode = new osg::Geode;
osg::ref_ptrosg::ShapeDrawable drawable = new osg::ShapeDrawable(new 
osg::Cylinder(osg::Vec3(0.0f,0.0f,0.0f),1.0f,height),hints);
osg::ref_ptrosg::ShapeDrawable drawable2 = new osg::ShapeDrawable(new 
osg::Cylinder(osg::Vec3(0.0f,0.0f,0.0f),4.0f,height),hints);
mynode-addDrawable(drawable.get());// geom.get() or gemo. both 
are ok. 
mynode-addDrawable(drawable2.get());

osg::ref_ptrosg::Group root = new osg::Group;
root-addChild(mynode.get() );
float angle = 0.0;
float angleDelta = 2.0f*osg::PI/8;

for(int i=0; i8;i++){  
float c = cosf(angle);
float s = sinf(angle);
osg::ref_ptrosgUtil::LineSegmentIntersector intersector = new 
osgUtil::LineSegmentIntersector( osg::Vec3(0.0f,0.0f,0.0f),  
osg::Vec3(10.0f*c,10.0f*s,0.0f) );

osgUtil::IntersectionVisitor iv( intersector.get() );
mynode-accept( iv );

if ( intersector-containsIntersections() )
{
osgUtil::LineSegmentIntersector::Intersections
intersections = 
intersector-getIntersections();
std::cout intersection size 
intersections.size()std::endl;

osg::ref_ptrosg::Geode  geode=new osg::Geode;
osg::ref_ptrosg::Geometry geom=new osg::Geometry;
osg::ref_ptrosg::Vec3Array v3a=new osg::Vec3Array;
osg::ref_ptrosg::Vec4Array colors = new 
osg::Vec4Array;
colors-push_back( osg::Vec4(1.0, 0.0, 0.0, 1.0) );


osgUtil::LineSegmentIntersector::Intersections::iterator itr;
for ( itr = intersections.begin(); itr != 
intersections.end(); ++itr ) {
std::cout  X  
itr-getWorldIntersectPoint().x()
  Y   
itr-getWorldIntersectPoint().y()
  Z  
itr-getWorldIntersectPoint().z();
if(itr == intersections.begin())
v3a-push_back( 
itr-getWorldIntersectPoint());

}
itr--;
v3a-push_back( itr-getWorldIntersectPoint());
std::coutstd::endl;
geom-setVertexArray(v3a);
geom-setColorArray(colors.get() );
geom-setColorBinding(osg::Geometry::BIND_OVERALL);
for(int k=0; kv3a-size(); k++){
std::coutvectex: v3a-at(k).x() 
v3a-at(k).y() v3a-at(k).z();
}
std::coutstd::endl;
geom-addPrimitiveSet(new 
osg::DrawArrays(osg::PrimitiveSet::LINES,0,v3a-size()));
geode-addDrawable(geom);
root-addChild(geode);
}else{
std::coutno intersection for i=istd::endl;
std::coutx intersector-getStart().x() y 
intersector-getStart().y() z intersector-getStart().z()std::endl;
std::coutx intersector-getEnd().x() y 
intersector-getEnd().y() z intersector-getEnd().z()std::endl;
}
angle+=angleDelta;
}
osgViewer::Viewer viewer;
viewer.setSceneData(root.get());
viewer.addEventHandler(new osgViewer::WindowSizeHandler);
return viewer.run();

}

Thanks.___
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

[Robert Osfield]

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] LineSegmentIntersector numerical imprecisions

[Aurelien Albert]

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] LineSegmentIntersector numerical imprecisions

[Robert Osfield]

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] LineSegmentIntersector numerical imprecisions

[PCJohn]

Hi Robert,

if I understand you correctly, you proposed the idea to not expand bounding 
box, but to lengthen the line segment. I feel it as more complicated as I am 
not convinced that it will not tend to more numerical problems. On small 
slopes close to the edge, you may easily hit different side of bounding box and 
on nearly parallel lines get hit with the side even if there is none, 
resulting with wrong line clipping. Lenghtening the segment might not fix these 
numerical problems.

For me, bounding box size increase is simple and robust solution. Some expert 
might consider all the details of LineSegmentIntersector implementation, local 
coordiante system and all the precision that box and line is using and prove 
that there will be no problems. If somebody is interested to put a time to 
this, I would welcome it. For myself as I lack the time and lengthening of 
line segment would probably not bring any noticeable performance difference, 
thus bounding box size increase is for me quick and robust solution.

This is my conclusion. I am not saying it is the best, etc., but it should 
work. More ideas?

(Sorry for late answer, I was under heavy work load for two days and one 
night.)
John


On Tuesday 20 of August 2013 11:12:53 Robert Osfield wrote:
 Hi John,
 
 I'm a bit confused as what to further explain.  For precision purposes it's
 the math operations done to clamp the line segment to the bounding box that
 is important.  The maths operations bascially use the length of the line
 segment in each axis and the distance from each face to the start point.
 An epsilon based on the largest of this values is probably the thing to go
 for, although one might simply simply it and us the length in each axis of
 the linesegment otherwise you'd need to introduce if()else blocks that are
 relatively expensive for the processor to handle.
 
 Robert.
 
 On 20 August 2013 10:33, PCJohn pec...@fit.vutbr.cz wrote:
  Hi Robert,
  
  I have lost in your reasoning. Let me go back to be sure we understand
  each
  other.
  
   The bounding box based epsilon will likely fail when the size of the box
  
  is
  
   very small compared to the length of the line segment.
  
  I came to conclusion that size of bounding box does not matter. Even the
  lenght of line segment does not matter. I came to this by considering that
  box
  and the line segment (both of size 10, f.ex.) might not be close to
  [0,0,0],
  but they may be translated 1e7 far away. In such case, even epsilon of 1
  would
  not change the size of box or line because it is bellow the numerical
  precision of float that already holds value 10'000'000 and it is not
  possible
  to append 1. Even although we want to enlarge it by 10% (from 10 to 11),
  we
  can not do it because of high value the float is carrying. Thus, size of
  line
  and box does not matter. What matters is the absolute float value, that is
  10'000'000 in this case, so epsilon should be 10'000'000 * 1e-5 = 100.
  
  If I am wrong in something, please point it out to move our discussion
  forward. If you have some other approach in mind, please, do the same.
  
  I am looking purely for the good solution acceptable for you and OSG.
  
  John
  
  On Tuesday 20 of August 2013 06:54:21 Robert Osfield wrote:
**
We could use Robert's idea to get start and end points. From them, we
  
  can
  
get the biggest value for epsilon as well that would provide better
epsilon. It should be smaller in most cases, but still big enough to
always
work correctly. I just had doubts small bounding box [-1,-1,-1, 1,1,1]
  
  and
  
start [2,0,0] and end point [1e7,0,0]. In this case, epsilon will be
computed from end point 1e7 by multiplying 1e-5 with the result 100.
  
  Thus,
  
bounding box will grow to [-101,-101,-101, 101,101,101], making false
collision with start point [2,0,0]. Later computation in
LineSegmentIntersector will remove the collision, but it costs
computational time.

After the consideration, my inclination is towards bounding box
choosen
epsilon (as opposite to start and end point based epsilon), as the
user
may
tend to set high values for end points just to pick through the whole
scene
or to create fake ray, although not sure if I not overlooked
something.
   
   The bounding box based epsilon will likely fail when the size of the box
  
  is
  
   very small compared to the length of the line segment.  It's better to
   be
   conservative with this type of operation.  If we get the computation
  
  right
  
   then we should be able to reduce the size of the epsilon considerably.
  
  ___
  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

Re: [osg-users] LineSegmentIntersector numerical imprecisions

[Robert Osfield]

Hi John,

I wasn't thinking of expanding the line segment, rather expanding the
bounding box just with a epsilon scaled by the line segment length.

However, you confusion about what I was thinking has given me an idea -
perhaps the best thing to do is do the intersection against the original
bounding box then pull the intersection point on the line segment back
towards the original end points just a little.  In essence this is exactly
what expanding the bounding box always did, but rather than put the epsilon
into the bounding box, we just put it into the ratio that is used to
compute the near start and and end points, as a ratio is used when
computing the distance there won't be any need to scale the epsilon too.

So the code:

   // clip s to xMin.
s = s+(e-s)*(bb_min.x()-s.x())/(e.x()-s.x());


Would change to something like:

s = s+(e-s)*((bb_min.x()-s.x())/(e.x()-s.x())-epsilon);

One would need to add a check to make sure the ratio computed isn't less
than the epsilon though, you wouldn't want the start and end points
migrating outwards.

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

[PCJohn]

Hi Robert,

after this new idea, I am starting to ask myself, what are the cases for which 
we need epsilon?

- when the line segment accidentally misses bbox while triangle intersection 
routines would indicate intersection (can this happen?)
- when clipping puts the start or end point inside the bbox, thus triangles 
on the bbox surface might be omitted from the intersection

If only the second point is the case, your proposed solution could handle this 
quite well.

Once again, we have probably different opinion about computing epsilon. If I 
understand it right, you want to make epsilon something line 
lineSegmentLenght*1e-5, am I right, or once again I do not understand your 
idea? (By epsilon I mean the space distance that you shift the start or end.)

I am writing it because lineSegmentLength is unrelated to the float precision 
of newly computed start and end. Thus, computation based on lineSegmentLength 
would fail in many cases. If we have newly computed start close to the 
[0,0,0], we have high precision and epsilon should be very small, otherwise we 
waste float precision. And if newly computed start is [1e10, 1e10, 1e10], then 
epsilon must be quite big to move such point, otherwise missing intersections 
may occur. Unfortunately, computer floating arithmetic is strange and 1e10 + 
1e2 = 1e10 .

Correct me if I am not right.
John


On Thursday 22 of August 2013 10:17:57 Robert Osfield wrote:
 Hi John,
 
 I wasn't thinking of expanding the line segment, rather expanding the
 bounding box just with a epsilon scaled by the line segment length.
 
 However, you confusion about what I was thinking has given me an idea -
 perhaps the best thing to do is do the intersection against the original
 bounding box then pull the intersection point on the line segment back
 towards the original end points just a little.  In essence this is exactly
 what expanding the bounding box always did, but rather than put the epsilon
 into the bounding box, we just put it into the ratio that is used to
 compute the near start and and end points, as a ratio is used when
 computing the distance there won't be any need to scale the epsilon too.
 
 So the code:
 
// clip s to xMin.
 s = s+(e-s)*(bb_min.x()-s.x())/(e.x()-s.x());
 
 
 Would change to something like:
 
 s = s+(e-s)*((bb_min.x()-s.x())/(e.x()-s.x())-epsilon);
 
 One would need to add a check to make sure the ratio computed isn't less
 than the epsilon though, you wouldn't want the start and end points
 migrating outwards.
 
 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

[PCJohn]

Hi Robert and Alistair,

I gave it another long thought and found one more idea. Let me show it on 
example of 
bounding box of bb_max.[x,y,z] set to 1'000'000 and bb_min.[x,y,z] set to 
999'999. I such 
case, the size of bounding box does not matter and distance of start and end 
neither 
(unfortunately) as both are about 1.0. By multiplication of 1e-5, we get pretty 
small number 
that would not change bounding box in any way if substracted or added to any 
component 
of bounding box.

I admit that this is not well designed scene but it shows the precision problem 
as it is, if I am 
not mistaken. In my opinion, we should just take the biggest number of all 
bounding box 
float values while ignoring the sign. Then, we multiply the biggest value by 
1e-5 to get 
epsilon. This should provide the value big enough value to move all the sides 
of the bounding 
box while computations based on bounding box size does not always serve this 
purpose.

We could use Robert's idea to get start and end points. From them, we can get 
the biggest 
value for epsilon as well that would provide better epsilon. It should be 
smaller in most 
cases, but still big enough to always work correctly. I just had doubts small 
bounding box 
[-1,-1,-1, 1,1,1] and start [2,0,0] and end point [1e7,0,0]. In this case, 
epsilon will be 
computed from end point 1e7 by multiplying 1e-5 with the result 100. Thus, 
bounding box 
will grow to [-101,-101,-101, 101,101,101], making false collision with start 
point [2,0,0]. 
Later computation in LineSegmentIntersector will remove the collision, but it 
costs 
computational time.

After the consideration, my inclination is towards bounding box choosen epsilon 
(as opposite 
to start and end point based epsilon), as the user may tend to set high values 
for end points 
just to pick through the whole scene or to create fake ray, although not sure 
if I not 
overlooked something.

Does it seems reasonable? Some more ideas?

John



On Monday 19 of August 2013 08:50:46 Robert Osfield wrote:


Hi John et. al,



I too am not too happy with the approach of a fixed epilson, adding the ability 
for the user to 
set this value isn't much better.



Scaling the epsilon by the size of the bounding box may be an improvement but 
I'm not yet 
convinced it's the best approach.  The epsilon is there is account for 
numerical precision 
issues associated with the mathematical functions being performed.  

The maths in this case is clamping the present line segment start and end 
points to the 
bounding box, here the distance of the sides from the start and the start to 
the end point 
along each axis is what will determine the size of the values and the range of 
the numerical 
errors that are likely.  The largest value is likely to be the length of the 
line segment so might 
be the best distance to use as the scale.

Thoughts?Robert.







On 19 August 2013 06:38, PCJohn pec...@fit.vutbr.cz[1] wrote:


Hi Robert,

there was recently a commit concerning epsilon in LineSegmentIntersectorthat is 
now 
carried as class member. I can imagine motivation behind, but Ibelive there is 
a better 
approach to the problem.

If the motivation is just to allow the setting bigger epsilon for biggerobjects 
(too small 
epsilon, recently statically assigned to 1e-5, will notaffect big bounding 
boxes because of 
limited float resolution. I belive, thiswas the motivation behind the change 
for the person 
who submitted the patch.)

The correct solution in my opinion would be to make epsilon depend on size 
ofbounding box 
of the intersected object:

// extend bounding box a little bit to avoid floating point imprecisions
double epsilon = 
(bb_max-bb_min).length() * 1e-5;bb_min.x() -= epsilon;bb_min.y() -= 
epsilon;bb_min.z() 
-= epsilon;bb_max.x() += epsilon;bb_max.y() += epsilon;bb_max.z() 
+= epsilon;

This should work in all cases, for both - small and big objects. 
Hard-codingepsilon, even when 
giving the user the ability to change it, is not correctway in my opinion, as 
there may be very 
small objects (requiring smallepsilon) together with big objects (requiring big 
epsilon) in the 
scene. Wecan give the user the callback to adjust the epsilon for each visited 
objectin the 
scene, but I do not belive this is the best approach.___
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

[Robert Osfield]

Hi John,


On 20 August 2013 06:09, PCJohn pec...@fit.vutbr.cz wrote:

 **
 We could use Robert's idea to get start and end points. From them, we can
 get the biggest value for epsilon as well that would provide better
 epsilon. It should be smaller in most cases, but still big enough to always
 work correctly. I just had doubts small bounding box [-1,-1,-1, 1,1,1] and
 start [2,0,0] and end point [1e7,0,0]. In this case, epsilon will be
 computed from end point 1e7 by multiplying 1e-5 with the result 100. Thus,
 bounding box will grow to [-101,-101,-101, 101,101,101], making false
 collision with start point [2,0,0]. Later computation in
 LineSegmentIntersector will remove the collision, but it costs
 computational time.



 After the consideration, my inclination is towards bounding box choosen
 epsilon (as opposite to start and end point based epsilon), as the user may
 tend to set high values for end points just to pick through the whole scene
 or to create fake ray, although not sure if I not overlooked something.


The bounding box based epsilon will likely fail when the size of the box is
very small compared to the length of the line segment.  It's better to be
conservative with this type of operation.  If we get the computation right
then we should be able to reduce the size of the epsilon considerably.

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

[PCJohn]

Hi Robert,

I have lost in your reasoning. Let me go back to be sure we understand each 
other.

 The bounding box based epsilon will likely fail when the size of the box is
 very small compared to the length of the line segment.  

I came to conclusion that size of bounding box does not matter. Even the 
lenght of line segment does not matter. I came to this by considering that box 
and the line segment (both of size 10, f.ex.) might not be close to [0,0,0], 
but they may be translated 1e7 far away. In such case, even epsilon of 1 would 
not change the size of box or line because it is bellow the numerical 
precision of float that already holds value 10'000'000 and it is not possible 
to append 1. Even although we want to enlarge it by 10% (from 10 to 11), we 
can not do it because of high value the float is carrying. Thus, size of line 
and box does not matter. What matters is the absolute float value, that is 
10'000'000 in this case, so epsilon should be 10'000'000 * 1e-5 = 100.

If I am wrong in something, please point it out to move our discussion 
forward. If you have some other approach in mind, please, do the same.

I am looking purely for the good solution acceptable for you and OSG.

John


On Tuesday 20 of August 2013 06:54:21 Robert Osfield wrote:
  **
  We could use Robert's idea to get start and end points. From them, we can
  get the biggest value for epsilon as well that would provide better
  epsilon. It should be smaller in most cases, but still big enough to
  always
  work correctly. I just had doubts small bounding box [-1,-1,-1, 1,1,1] and
  start [2,0,0] and end point [1e7,0,0]. In this case, epsilon will be
  computed from end point 1e7 by multiplying 1e-5 with the result 100. Thus,
  bounding box will grow to [-101,-101,-101, 101,101,101], making false
  collision with start point [2,0,0]. Later computation in
  LineSegmentIntersector will remove the collision, but it costs
  computational time.
  
  After the consideration, my inclination is towards bounding box choosen
  epsilon (as opposite to start and end point based epsilon), as the user
  may
  tend to set high values for end points just to pick through the whole
  scene
  or to create fake ray, although not sure if I not overlooked something.
 
 The bounding box based epsilon will likely fail when the size of the box is
 very small compared to the length of the line segment.  It's better to be
 conservative with this type of operation.  If we get the computation right
 then we should be able to reduce the size of the epsilon considerably.


___
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

[Robert Osfield]

Hi John,

I'm a bit confused as what to further explain.  For precision purposes it's
the math operations done to clamp the line segment to the bounding box that
is important.  The maths operations bascially use the length of the line
segment in each axis and the distance from each face to the start point.
An epsilon based on the largest of this values is probably the thing to go
for, although one might simply simply it and us the length in each axis of
the linesegment otherwise you'd need to introduce if()else blocks that are
relatively expensive for the processor to handle.

Robert.



On 20 August 2013 10:33, PCJohn pec...@fit.vutbr.cz wrote:

 Hi Robert,

 I have lost in your reasoning. Let me go back to be sure we understand each
 other.

  The bounding box based epsilon will likely fail when the size of the box
 is
  very small compared to the length of the line segment.

 I came to conclusion that size of bounding box does not matter. Even the
 lenght of line segment does not matter. I came to this by considering that
 box
 and the line segment (both of size 10, f.ex.) might not be close to
 [0,0,0],
 but they may be translated 1e7 far away. In such case, even epsilon of 1
 would
 not change the size of box or line because it is bellow the numerical
 precision of float that already holds value 10'000'000 and it is not
 possible
 to append 1. Even although we want to enlarge it by 10% (from 10 to 11), we
 can not do it because of high value the float is carrying. Thus, size of
 line
 and box does not matter. What matters is the absolute float value, that is
 10'000'000 in this case, so epsilon should be 10'000'000 * 1e-5 = 100.

 If I am wrong in something, please point it out to move our discussion
 forward. If you have some other approach in mind, please, do the same.

 I am looking purely for the good solution acceptable for you and OSG.

 John


 On Tuesday 20 of August 2013 06:54:21 Robert Osfield wrote:
   **
   We could use Robert's idea to get start and end points. From them, we
 can
   get the biggest value for epsilon as well that would provide better
   epsilon. It should be smaller in most cases, but still big enough to
   always
   work correctly. I just had doubts small bounding box [-1,-1,-1, 1,1,1]
 and
   start [2,0,0] and end point [1e7,0,0]. In this case, epsilon will be
   computed from end point 1e7 by multiplying 1e-5 with the result 100.
 Thus,
   bounding box will grow to [-101,-101,-101, 101,101,101], making false
   collision with start point [2,0,0]. Later computation in
   LineSegmentIntersector will remove the collision, but it costs
   computational time.
  
   After the consideration, my inclination is towards bounding box choosen
   epsilon (as opposite to start and end point based epsilon), as the user
   may
   tend to set high values for end points just to pick through the whole
   scene
   or to create fake ray, although not sure if I not overlooked something.
 
  The bounding box based epsilon will likely fail when the size of the box
 is
  very small compared to the length of the line segment.  It's better to be
  conservative with this type of operation.  If we get the computation
 right
  then we should be able to reduce the size of the epsilon considerably.


 ___
 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] LineSegmentIntersector numerical imprecisions

[PCJohn]

Hi Robert,

there was recently a commit concerning epsilon in LineSegmentIntersector
that is now carried as class member. I can imagine motivation behind, but I 
belive there is a better approach to the problem.

If the motivation is just to allow the setting bigger epsilon for bigger 
objects (too small epsilon, recently statically assigned to 1e-5, will not 
affect big bounding boxes because of limited float resolution. I belive, this 
was the motivation behind the change for the person who submitted the patch.)

The correct solution in my opinion would be to make epsilon depend on size of 
bounding box of the intersected object:

// extend bounding box a little bit to avoid floating point imprecisions
double epsilon = (bb_max-bb_min).length() * 1e-5;
bb_min.x() -= epsilon;
bb_min.y() -= epsilon;
bb_min.z() -= epsilon;
bb_max.x() += epsilon;
bb_max.y() += epsilon;
bb_max.z() += epsilon;

This should work in all cases, for both - small and big objects. Hard-coding 
epsilon, even when giving the user the ability to change it, is not correct 
way in my opinion, as there may be very small objects (requiring small 
epsilon) together with big objects (requiring big epsilon) in the scene. We 
can give the user the callback to adjust the epsilon for each visited object 
in the scene, but I do not belive this is the best approach.

I would very prefer to scale epsilon by the size of the object as this is how 
the floats change their precision. Bigger the object, bigger the value in 
float, 
smaller float precision, bigger the epsilon is needed. The precision of float 
is 
between 1e-7 to 1e-6, so multiplying the size of bounding box by 1e-5 should 
provide big enough increase of the bounding box to avoid numerical 
imprecisions.

Having to specify epsilon by programmer is making the things more difficult for 
him, as he should understand float problems and has to think about the 
precision value, while he usually just wants intersector to work correctly, 
not taking care about hardware precision limitations. Scaling the epsilon 
would do the work for him without giving him another parameter that may turn 
things wrong if not set properly.

Your opinion on this point?
I can create patch based on your suggestions.
John
___
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

[Alistair Baxter]

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of PCJohn
Sent: 19 August 2013 07:38
To: OpenSceneGraph Users
Subject: [osg-users] LineSegmentIntersector numerical imprecisions

 The correct solution in my opinion would be to make epsilon depend on size of 
 bounding box of the intersected object:

I'd support that strategy. The recent change doesn't really fix the problem 
that we had to locally alter the source to fix.



Alistair Baxter
Software Engineer


Our next public training event is in Houston, USA on 20th - 22nd August 2013 

For further information please visit www.mve.com/calendar
Midland Valley Exploration Ltd.
144 West George Street
Glasgow G2 2HG
United Kingdom
Tel: +44 (0) 141 332 2681
Fax:+44 (0) 141 332 6792
The structural geology experts 

___
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

[Robert Osfield]

Hi John et. al,

I too am not too happy with the approach of a fixed epilson, adding the
ability for the user to set this value isn't much better.

Scaling the epsilon by the size of the bounding box may be an improvement
but I'm not yet convinced it's the best approach.  The epsilon is there is
account for numerical precision issues associated with the mathematical
functions being performed.

The maths in this case is clamping the present line segment start and end
points to the bounding box, here the distance of the sides from the start
and the start to the end point along each axis is what will determine the
size of the values and the range of the numerical errors that are likely.
The largest value is likely to be the length of the line segment so might
be the best distance to use as the scale.

Thoughts?
Robert.





On 19 August 2013 06:38, PCJohn pec...@fit.vutbr.cz wrote:

 Hi Robert,

 there was recently a commit concerning epsilon in LineSegmentIntersector
 that is now carried as class member. I can imagine motivation behind, but I
 belive there is a better approach to the problem.

 If the motivation is just to allow the setting bigger epsilon for bigger
 objects (too small epsilon, recently statically assigned to 1e-5, will not
 affect big bounding boxes because of limited float resolution. I belive,
 this
 was the motivation behind the change for the person who submitted the
 patch.)

 The correct solution in my opinion would be to make epsilon depend on size
 of
 bounding box of the intersected object:

 // extend bounding box a little bit to avoid floating point
 imprecisions
 double epsilon = (bb_max-bb_min).length() * 1e-5;
 bb_min.x() -= epsilon;
 bb_min.y() -= epsilon;
 bb_min.z() -= epsilon;
 bb_max.x() += epsilon;
 bb_max.y() += epsilon;
 bb_max.z() += epsilon;

 This should work in all cases, for both - small and big objects.
 Hard-coding
 epsilon, even when giving the user the ability to change it, is not correct
 way in my opinion, as there may be very small objects (requiring small
 epsilon) together with big objects (requiring big epsilon) in the scene. We
 can give the user the callback to adjust the epsilon for each visited
 object
 in the scene, but I do not belive this is the best approach.

 I would very prefer to scale epsilon by the size of the object as this is
 how
 the floats change their precision. Bigger the object, bigger the value in
 float,
 smaller float precision, bigger the epsilon is needed. The precision of
 float is
 between 1e-7 to 1e-6, so multiplying the size of bounding box by 1e-5
 should
 provide big enough increase of the bounding box to avoid numerical
 imprecisions.

 Having to specify epsilon by programmer is making the things more
 difficult for
 him, as he should understand float problems and has to think about the
 precision value, while he usually just wants intersector to work correctly,
 not taking care about hardware precision limitations. Scaling the epsilon
 would do the work for him without giving him another parameter that may
 turn
 things wrong if not set properly.

 Your opinion on this point?
 I can create patch based on your suggestions.
 John
 ___
 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] LineSegmentIntersector gives incorrect results (intersections missing)

[Robert Osfield]

Hi Jaap,

In svn/trunk I've introduced the ability to set the Eplsion value to a
user specified value rather than the default of 1e-4, this may not be
an ideal solution though, I'd much rather have the code work with
defaults correctly.

The clipping of the line length to the bounding box is done to make it
more likely that intersection tests will be more rejected more quickly
so speeding up the intersections.  We could add an option to disable
this clipping and explore just much of an impact it has.

Scaling the epsilion by the size of the bounding box is a possibility,
but this would cause problems with small objects but with relatively
large xyz values.  One could possible have a constant and scaled
epsilon term to get round this.

A double version of the intersection functions wold be another possibility.

Robert.

On 16 May 2013 09:07, Jaap Glas jaap.g...@dgbes.com wrote:
 Dear Peter, Robert, and all.

 I would like to endorse Peter's remarks on the current implementation of
 the LineSegmentIntersector. We experience precisely the same problems when
 trying to pick on plane faces that coincide with the bounding box of the
 Drawable to which they belong. The simplest example is a drawable consisting
 of one triangle or quad aligning with the axes of the local coordinate frame.

 Like Peter, we are also dealing with co-ordinate values running into the
 thousands. The applied epsilon of 1e-4 in the intersectAndClip() function
 is too small in suchlike cases, especially if the TriangleIntersector keeps
 using floats at some places.

 For the moment, we circumvent the problem by overloading the computeBound()
 function of the Drawable and return a slightly bigger bounding box ourselves,
 but a more general solution would be better in the end.

 Like Peter, I also do not see why the intersectAndClip() function should
 cut off those parts of the line segment that are outside the bounding box.
 What is the computational benefit of this later on? I would expect it is
 sufficient to check whether the line segment is crossing the box or not,
 and neglect Drawables for which the answer is false.

 However, assuming that this clipping does serve a goal, then my choice
 would be not to assign the epsilon in the intersectAndClip() function
 an absolute value, but to make it relative to the bounding box size,
 for example by multiplying the current epsilon of 1e-4 with the diagonal
 length of the bounding box.


 Best regards,

 Jaap Glas

 dGB Earth Sciences
 Enschede, The Netherlands

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





 ___
 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] LineSegmentIntersector gives incorrect results (intersections missing)

[Jaap Glas]

Dear Peter, Robert, and all.

I would like to endorse Peter's remarks on the current implementation of
the LineSegmentIntersector. We experience precisely the same problems when  
trying to pick on plane faces that coincide with the bounding box of the
Drawable to which they belong. The simplest example is a drawable consisting
of one triangle or quad aligning with the axes of the local coordinate frame.   

Like Peter, we are also dealing with co-ordinate values running into the
thousands. The applied epsilon of 1e-4 in the intersectAndClip() function   
is too small in suchlike cases, especially if the TriangleIntersector keeps 
using floats at some places.

For the moment, we circumvent the problem by overloading the computeBound() 
function of the Drawable and return a slightly bigger bounding box ourselves,   
but a more general solution would be better in the end. 

Like Peter, I also do not see why the intersectAndClip() function should
cut off those parts of the line segment that are outside the bounding box.  
What is the computational benefit of this later on? I would expect it is
sufficient to check whether the line segment is crossing the box or not,
and neglect Drawables for which the answer is false.

However, assuming that this clipping does serve a goal, then my choice  
would be not to assign the epsilon in the intersectAndClip() function   
an absolute value, but to make it relative to the bounding box size,
for example by multiplying the current epsilon of 1e-4 with the diagonal
length of the bounding box. 


Best regards,   

Jaap Glas   

dGB Earth Sciences  
Enschede, The Netherlands

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





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

Re: [osg-users] LineSegmentIntersector gives incorrect results (intersections missing)

[Peter Bako]

Hello Robert.

I digged a bit into the OSG source code and I found out that its a precision 
problem. I use big models where the vertex coordinate values are 1000.
I don't know the exact process of the intersection search, but I assume that 
the lineSegment is clipped in the  

lineSegmentIntersector.cpp

Code:
bool LineSegmentIntersector::intersectAndClip(osg::Vec3d s, osg::Vec3d 
e,const osg::BoundingBox bbInput)

 
function to the values, where the lineSegment is slightly longer, than the 
bounding sphere of the geometry. 

Code:
 osg::Vec3d bb_min(bbInput._min);
osg::Vec3d bb_max(bbInput._max);

#if 1
double epsilon = 1e-4;
bb_min.x() -= epsilon;
bb_min.y() -= epsilon;
bb_min.z() -= epsilon;
bb_max.x() += epsilon;
bb_max.y() += epsilon;
bb_max.z() += epsilon;
#endif



There is an epsilon value, which is currently set to 1e-4. I would suggest to 
set it bigger (1e-2 f. ex.). If I change it to 1e-2, I don't get this problem 
anymore.

What is the exact reason of lineSegment clipping?

Thank you!

Cheers,
Peter
Code:




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





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

Re: [osg-users] LineSegmentIntersector gives incorrect results (intersections missing)

[Robert Osfield]

HI Peter,

I'm afraid I've not got enough time available to look into this
problem right now, hopefully others can dive in.  My suspicision is
that due to nuermical precision issues on constructing the linesegment
and/or intersecting this with the bonding volumes or meshes you aren't
always getting the intersections you expect.  A quick hack to test
this would be to rotate the mesh slightly so nothing is axis aligned -
this way the mesh won't be setting on the face of the bounding volume.
 If this hack does prove to address the problem then it points the
need of doing interesection testing with error bars that are larger
than the numberic precision errors.

Robert.

On 23 October 2012 09:21, Peter Bako osgfo...@tevs.eu wrote:
 I use the LineSegmentIntersector in my application to select planar faces. 
 The problem is that sometimes when I click on the face facing to you (check 
 the red Xes on the picture), I get no intersection of this face. I get only 
 an intersection on the face which is not visible from this view - the 
 bottom face.
 Then sometimes it happens, that the user wants to select a face, but an 
 invisible face is selected instead, but he doesn't know it because he 
 doesn't see it, even if its highlighted.

 i made this sample application to simulate my problem - when I click on the 
 positions where the red crosses are, normally I should get 2 intersections - 
 first the face where I drew the red crosses and then to bottom face which we 
 don't see. Sometimes, I get only the second (see the debug output on the 
 picture).

 I think this is a problem.

 Thank you!

 Cheers,
 Peter

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





 ___
 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] LineSegmentIntersector gives incorrect results (intersections missing)

[Peter Bako]

I use the LineSegmentIntersector in my application to select planar faces. The 
problem is that sometimes when I click on the face facing to you (check the 
red Xes on the picture), I get no intersection of this face. I get only an 
intersection on the face which is not visible from this view - the bottom 
face. 
Then sometimes it happens, that the user wants to select a face, but an 
invisible face is selected instead, but he doesn't know it because he doesn't 
see it, even if its highlighted.

i made this sample application to simulate my problem - when I click on the 
positions where the red crosses are, normally I should get 2 intersections - 
first the face where I drew the red crosses and then to bottom face which we 
don't see. Sometimes, I get only the second (see the debug output on the 
picture).

I think this is a problem.

Thank you!

Cheers,
Peter

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





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

Re: [osg-users] LineSegmentIntersector gives incorrect results (intersections missing)

[Robert Osfield]

Hi Peter,

I can't specifically say what you are seeing a problem, but it does
rather sound like a precision issue with projecting the mouse poistion
into clip space and then to world and final object coordinates.

Robert.

On 17 October 2012 14:19, Peter Bako osgfo...@tevs.eu wrote:
 Hi,

 I've got a problem with line segment intersector. Sometimes I get only one 
 intersection (on the bootom side of the table), while I should get two.
 Please check the screenshot.

 Do you have any idea why this happens? What should I do?
 STLFILE.stl (ZIPPED) is attached
 Thank you!

 Cheers,
 Peter

 Hold CTRL key to activate intersection output.
 This is the code I use:

 Code:
 #include stdafx.h
 #include osgViewer/Viewer
 #include osgDB/ReadFile
 #include osgUtil/LineSegmentIntersector


 class PickHandler : public osgGA::GUIEventHandler
 {
 public:

 virtual bool handle( const osgGA::GUIEventAdapter ea, 
 osgGA::GUIActionAdapter aa )
 {
 if ( ea.getEventType()!=osgGA::GUIEventAdapter::RELEASE ||
  ea.getButton()!=osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON ||
  !(ea.getModKeyMask()osgGA::GUIEventAdapter::MODKEY_CTRL) )
 return false;

 osgViewer::Viewer* viewer = dynamic_castosgViewer::Viewer*(aa);
 if ( viewer ){
 osg::ref_ptrosgUtil::LineSegmentIntersector intersector =
 new 
 osgUtil::LineSegmentIntersector(osgUtil::Intersector::WINDOW, ea.getX(), 
 ea.getY());
 osgUtil::IntersectionVisitor iv( intersector.get() );
 iv.setTraversalMask( ~0x1 );
 viewer-getCamera()-accept( iv );

 if ( intersector-containsIntersections() ){
 const 
 osgUtil::LineSegmentIntersector::Intersection result =
 *(intersector-getIntersections().begin());
 printf(Intersection count:%d. Coordinates: %.2f, %.2f, 
 %.2f\n,
 
 intersector-getIntersections().size(), 
 result.getWorldIntersectPoint().x(),result.getWorldIntersectPoint().y(),result.getWorldIntersectPoint().z());

 }
 }
 return false;
 }

 };

 int main( int argc, char** argv )
 {
 osg::ref_ptrosg::Node model1 = osgDB::readNodeFile( STLFILE.stl );
 osg::ref_ptrosg::Group root = new osg::Group;
 root-addChild( model1.get() );
 osg::ref_ptrPickHandler picker = new PickHandler;
 osgViewer::Viewer viewer;
 viewer.setSceneData( root.get() );
 viewer.addEventHandler( picker.get() );
 return viewer.run();
 }




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




 Attachments:
 http://forum.openscenegraph.org//files/intersection_errors_639.png
 http://forum.openscenegraph.org//files/stlfile_974.zip


 ___
 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] LineSegmentIntersector gives incorrect results (intersections missing)

[Peter Bako]

Hi,

I've got a problem with line segment intersector. Sometimes I get only one 
intersection (on the bootom side of the table), while I should get two. 
Please check the screenshot.

Do you have any idea why this happens? What should I do?
STLFILE.stl (ZIPPED) is attached
Thank you!

Cheers,
Peter

Hold CTRL key to activate intersection output.
This is the code I use:

Code:
#include stdafx.h
#include osgViewer/Viewer
#include osgDB/ReadFile
#include osgUtil/LineSegmentIntersector


class PickHandler : public osgGA::GUIEventHandler
{
public:
  
virtual bool handle( const osgGA::GUIEventAdapter ea, 
osgGA::GUIActionAdapter aa )
{
if ( ea.getEventType()!=osgGA::GUIEventAdapter::RELEASE ||
 ea.getButton()!=osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON ||
 !(ea.getModKeyMask()osgGA::GUIEventAdapter::MODKEY_CTRL) )
return false;

osgViewer::Viewer* viewer = dynamic_castosgViewer::Viewer*(aa);
if ( viewer ){
osg::ref_ptrosgUtil::LineSegmentIntersector intersector =
new 
osgUtil::LineSegmentIntersector(osgUtil::Intersector::WINDOW, ea.getX(), 
ea.getY());
osgUtil::IntersectionVisitor iv( intersector.get() );
iv.setTraversalMask( ~0x1 );
viewer-getCamera()-accept( iv );

if ( intersector-containsIntersections() ){
const 
osgUtil::LineSegmentIntersector::Intersection result =
*(intersector-getIntersections().begin());
printf(Intersection count:%d. Coordinates: %.2f, %.2f, 
%.2f\n, 
intersector-getIntersections().size(), 
result.getWorldIntersectPoint().x(),result.getWorldIntersectPoint().y(),result.getWorldIntersectPoint().z());

}
}
return false;
}

};

int main( int argc, char** argv )
{
osg::ref_ptrosg::Node model1 = osgDB::readNodeFile( STLFILE.stl );
osg::ref_ptrosg::Group root = new osg::Group;
root-addChild( model1.get() );
osg::ref_ptrPickHandler picker = new PickHandler;
osgViewer::Viewer viewer;
viewer.setSceneData( root.get() );
viewer.addEventHandler( picker.get() );
return viewer.run();
}




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




Attachments: 
http://forum.openscenegraph.org//files/intersection_errors_639.png
http://forum.openscenegraph.org//files/stlfile_974.zip


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

Re: [osg-users] LineSegmentIntersector question...

[Shayne Tueller]

Ok...so I upgraded to OSG 3.0.1 and tried this intersection limit test in my 
app (setIntersectionLimit())

I first tried LIMIT_ONE. Performance did improve over the NO_LIMIT case but I 
noticed that the number of intersections calculated were as high as 6 for some 
of the line segments. I would have expected just one intersection calculated. 
Why is more than one intersection being done in this case?

Next I tried LIMIT_NEAREST. This resulted in many more intersections 
calculated. Some segments got as high as 27 intersections. That would suggest 
that this option is calculating intersections and then sorting through to 
determine which one is closest to the line segment starting point?

I should point out that I'm intersecting my line segments with a terrain 
database...

-Shayne

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





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

Re: [osg-users] LineSegmentIntersector question...

[Farshid Lashkari]

Hi Shayne,

On Thu, Sep 13, 2012 at 10:32 AM, Shayne Tueller shayne.tuel...@hill.af.mil
 wrote:

 I first tried LIMIT_ONE. Performance did improve over the NO_LIMIT case
 but I noticed that the number of intersections calculated were as high as 6
 for some of the line segments. I would have expected just one intersection
 calculated. Why is more than one intersection being done in this case?


LIMIT_ONE should only report one intersection. Are you intersecting with
multiple line segments? Can you post the code you are using to setup the
intersector?


 Next I tried LIMIT_NEAREST. This resulted in many more intersections
 calculated. Some segments got as high as 27 intersections. That would
 suggest that this option is calculating intersections and then sorting
 through to determine which one is closest to the line segment starting
 point?


LIMIT_NEAREST can report many intersections. As I mentioned earlier, it is
more of a hint that you are only interested in the nearest hit. This allows
it to reject subgraphs early on before performing any intersections with
the actual mesh. However, in the worst case scenario where the scene is
traversed in farthest to closest order, then there will be no difference in
the number of hits between LIMIT_NEAREST and NO_LIMIT.

Cheers,
Farshid




I should point out that I'm intersecting my line segments with a terrain
 database...

 -Shayne

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





 ___
 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] LineSegmentIntersector question...

[Shayne Tueller]

Farshid,

I'm actually modifying the osgSim::LineOfSight class for my tests. I went into 
LineOfSight.cpp and modified the computeIntersections() method to support 
setIntersectionLimit() since there's currently no way to control this for the 
Line of Sight stuff in OSG. I added the call setIntersectionLimit() for each 
LineSegmentIntersector instanced in the computeIntersections() method. This 
was done at the top of the method where the iterator loop is for each entry of 
_LOSlist. I believe this is the correct way to do it...

I then called LineOfSight::computeIntersections() in my app to test it out 
against my terrain database.

I would include the actual code snippet but my email machine doesn't have the 
code on it so I hope that the above description of what I did makes sense...

It does make sense on how the LIMIT_NEAREST option works. Thanks for that 
explanation.

-Shayne

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





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

Re: [osg-users] LineSegmentIntersector question...

[Farshid Lashkari]

Hi Shayne,

Is each LineSegmentIntersector instance getting more than one intersection
result? Or is the total number of results among all intersectors more than
1? The limit is applied to each intersector instance, so the total number
of results should max out at the number of intersectors being used.

You can try applying the limit to the IntersectorGroup object as well, but
you might still get more than 1 result. However, I think the
IntersectorGroup::intersect method can be modified to break out of the
intersector iteration if the limit has been reached.

Cheers,
Farshid

On Thu, Sep 13, 2012 at 11:33 AM, Shayne Tueller shayne.tuel...@hill.af.mil
 wrote:

 Farshid,

 I'm actually modifying the osgSim::LineOfSight class for my tests. I went
 into LineOfSight.cpp and modified the computeIntersections() method to
 support setIntersectionLimit() since there's currently no way to control
 this for the Line of Sight stuff in OSG. I added the call
 setIntersectionLimit() for each LineSegmentIntersector instanced in the
 computeIntersections() method. This was done at the top of the method
 where the iterator loop is for each entry of _LOSlist. I believe this is
 the correct way to do it...

 I then called LineOfSight::computeIntersections() in my app to test it
 out against my terrain database.

 I would include the actual code snippet but my email machine doesn't have
 the code on it so I hope that the above description of what I did makes
 sense...

 It does make sense on how the LIMIT_NEAREST option works. Thanks for that
 explanation.

 -Shayne

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





 ___
 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] LineSegmentIntersector question...

[Shayne Tueller]

Farshid,

If I understand the code correctly, each intersector in the LOS code is 
associated with a start end pair defining the line segment. In other words, 
it's a 1 to 1 mapping. If I have 45 LOS queries, the code generates 45 
LineSegmentIntersectors. Each intersector in turn is added to an 
IntersectorGroup so that this one group contains 45 LineSegmentIntersectors. 
Perhaps Robert can chime in here to verify that this is the case.

When I retrieve the intersection count for EACH individual intersector, I'm 
getting the number of intersections  1. This seems incorrect for the LIMIT_ONE 
case. For this case, I would expect the number of intersections to be always 1 
(if a hit is found) for each intersector.

I will investigate the code further to see what is going on or what might be 
wrong...

-Shayne

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





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

[osg-users] LineSegmentIntersector question...

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

All,

 

I have a couple of questions regarding LineSegmentIntersector. 

 

I noticed that for a given line segment, it currently computes and
returns ALL intersections with a given geometry in the scene.

 

My questions are:

 

1)  Does it support a feature of detecting a hit and then
returning without the need to compute all the intersections? This would
be sort of like a visibility test.

2)  Does it have the ability to find the closest intersection
without the need to compute all the intersections? In other words, does
it step along from the starting point of the line segment until an
intersection is found and then bail out?

3)  If it doesn't support these features, is it possible to modify
the LineSegmentIntersector to support these?

 

I would think that having this capability would improve performance
where applicable.

 

Thanks for any input in advance...

 

-Shayne

 

 

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

Re: [osg-users] LineSegmentIntersector question...

[Farshid Lashkari]

Hi Shayne,

The base osgUtil::Intersector class supports setting the limits on
intersection results, using the setIntersectionLimit() method. The current
options are NO_LIMIT, LIMIT_ONE_PER_DRAWABLE, LIMIT_ONE, LIMIT_NEAREST.

On Tue, Sep 11, 2012 at 9:47 AM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:

 **1)  **Does it support a feature of detecting a “hit” and then
 returning without the need to compute all the intersections? This would be
 sort of like a visibility test.

Set the intersection limit to LIMIT_ONE

 

 **2)  **Does it have the ability to find the closest intersection
 without the need to compute all the intersections? In other words, does it
 step along from the starting point of the line segment until an
 intersection is found and then bail out?

Set the intersection limit to LIMIT_NEAREST. This mode could be optimized
more, but it will currently reject a subgraph if the nearest point of the
bounding sphere is further than the nearest hit. So it can still provide
significant savings in computation time.

Cheers,
Farshid


 

 **3)  **If it doesn’t support these features, is it possible to
 modify the LineSegmentIntersector to support these?

 ** **

 I would think that having this capability would improve performance where
 applicable.

 ** **

 Thanks for any input in advance…

 ** **

 -Shayne

 ** **

 ** **

 ___
 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] LineSegmentIntersector question...

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

Farshid,

Thanks much for the input and addressing my questions. That is good news
that the support is there.

I'm assuming the default is NO_LIMIT. Is this true?

Thanks,
-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Farshid
Lashkari
Sent: Tuesday, September 11, 2012 11:08 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] LineSegmentIntersector question...

Hi Shayne,

The base osgUtil::Intersector class supports setting the limits on
intersection results, using the setIntersectionLimit() method. The
current options are NO_LIMIT, LIMIT_ONE_PER_DRAWABLE, LIMIT_ONE,
LIMIT_NEAREST.

On Tue, Sep 11, 2012 at 9:47 AM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:

1)  Does it support a feature of detecting a hit and then
returning without the need to compute all the intersections? This would
be sort of like a visibility test.

Set the intersection limit to LIMIT_ONE



2)  Does it have the ability to find the closest
intersection without the need to compute all the intersections? In other
words, does it step along from the starting point of the line segment
until an intersection is found and then bail out?

Set the intersection limit to LIMIT_NEAREST. This mode could be
optimized more, but it will currently reject a subgraph if the nearest
point of the bounding sphere is further than the nearest hit. So it can
still provide significant savings in computation time.

Cheers,
Farshid
 



3)  If it doesn't support these features, is it possible to
modify the LineSegmentIntersector to support these?

 

I would think that having this capability would improve
performance where applicable.

 

Thanks for any input in advance...

 

-Shayne

 

 


___
osg-users mailing list
osg-users@lists.openscenegraph.org

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g




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

Re: [osg-users] LineSegmentIntersector question...

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

Just a follow on question to my previous email...

Is this functionality of setting limits on intersection results only
found in later versions of OSG? I'm currently using OSG 2.9.11 and I
can't find any support for this. I guess this would explain why I asked
the questions in the first place.

If true, I need to upgrade to a later version like 3.0.1...

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Tuesday, September 11, 2012 11:13 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] LineSegmentIntersector question...

Farshid,

Thanks much for the input and addressing my questions. That is good news
that the support is there.

I'm assuming the default is NO_LIMIT. Is this true?

Thanks,
-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Farshid
Lashkari
Sent: Tuesday, September 11, 2012 11:08 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] LineSegmentIntersector question...

Hi Shayne,

The base osgUtil::Intersector class supports setting the limits on
intersection results, using the setIntersectionLimit() method. The
current options are NO_LIMIT, LIMIT_ONE_PER_DRAWABLE, LIMIT_ONE,
LIMIT_NEAREST.

On Tue, Sep 11, 2012 at 9:47 AM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:

1)  Does it support a feature of detecting a hit and then
returning without the need to compute all the intersections? This would
be sort of like a visibility test.

Set the intersection limit to LIMIT_ONE



2)  Does it have the ability to find the closest
intersection without the need to compute all the intersections? In other
words, does it step along from the starting point of the line segment
until an intersection is found and then bail out?

Set the intersection limit to LIMIT_NEAREST. This mode could be
optimized more, but it will currently reject a subgraph if the nearest
point of the bounding sphere is further than the nearest hit. So it can
still provide significant savings in computation time.

Cheers,
Farshid
 



3)  If it doesn't support these features, is it possible to
modify the LineSegmentIntersector to support these?

 

I would think that having this capability would improve
performance where applicable.

 

Thanks for any input in advance...

 

-Shayne

 

 


___
osg-users mailing list
osg-users@lists.openscenegraph.org

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g




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

Re: [osg-users] LineSegmentIntersector question...

[Farshid Lashkari]

Hi Shayne,

Yes, the default is NO_LIMIT. I'm using it in version 2.9.12, but I think I
might have backported it from a newer version. Sounds like you'll need to
do an upgrade to get this feature.

Cheers,
Farshid

On Tue, Sep 11, 2012 at 10:25 AM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:

 Just a follow on question to my previous email...

 Is this functionality of setting limits on intersection results only
 found in later versions of OSG? I'm currently using OSG 2.9.11 and I
 can't find any support for this. I guess this would explain why I asked
 the questions in the first place.

 If true, I need to upgrade to a later version like 3.0.1...

 -Shayne

 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
 Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC
 Sent: Tuesday, September 11, 2012 11:13 AM
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] LineSegmentIntersector question...

 Farshid,

 Thanks much for the input and addressing my questions. That is good news
 that the support is there.

 I'm assuming the default is NO_LIMIT. Is this true?

 Thanks,
 -Shayne

 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Farshid
 Lashkari
 Sent: Tuesday, September 11, 2012 11:08 AM
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] LineSegmentIntersector question...

 Hi Shayne,

 The base osgUtil::Intersector class supports setting the limits on
 intersection results, using the setIntersectionLimit() method. The
 current options are NO_LIMIT, LIMIT_ONE_PER_DRAWABLE, LIMIT_ONE,
 LIMIT_NEAREST.

 On Tue, Sep 11, 2012 at 9:47 AM, Tueller, Shayne R Civ USAF AFMC 519
 SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:

 1)  Does it support a feature of detecting a hit and then
 returning without the need to compute all the intersections? This would
 be sort of like a visibility test.

 Set the intersection limit to LIMIT_ONE



 2)  Does it have the ability to find the closest
 intersection without the need to compute all the intersections? In other
 words, does it step along from the starting point of the line segment
 until an intersection is found and then bail out?

 Set the intersection limit to LIMIT_NEAREST. This mode could be
 optimized more, but it will currently reject a subgraph if the nearest
 point of the bounding sphere is further than the nearest hit. So it can
 still provide significant savings in computation time.

 Cheers,
 Farshid




 3)  If it doesn't support these features, is it possible to
 modify the LineSegmentIntersector to support these?



 I would think that having this capability would improve
 performance where applicable.



 Thanks for any input in advance...



 -Shayne






 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org

 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
 g




 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
 g
 ___
 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] LineSegmentIntersector question...

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

Farshid,

Thank you for your help...:)

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Farshid
Lashkari
Sent: Tuesday, September 11, 2012 11:28 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] LineSegmentIntersector question...

Hi Shayne,

Yes, the default is NO_LIMIT. I'm using it in version 2.9.12, but I
think I might have backported it from a newer version. Sounds like
you'll need to do an upgrade to get this feature.

Cheers,
Farshid


On Tue, Sep 11, 2012 at 10:25 AM, Tueller, Shayne R Civ USAF AFMC 519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:


Just a follow on question to my previous email...

Is this functionality of setting limits on intersection results
only
found in later versions of OSG? I'm currently using OSG 2.9.11
and I
can't find any support for this. I guess this would explain why
I asked
the questions in the first place.

If true, I need to upgrade to a later version like 3.0.1...


-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of

Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Tuesday, September 11, 2012 11:13 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] LineSegmentIntersector question...

Farshid,

Thanks much for the input and addressing my questions. That is
good news
that the support is there.

I'm assuming the default is NO_LIMIT. Is this true?

Thanks,
-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Farshid
Lashkari
Sent: Tuesday, September 11, 2012 11:08 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] LineSegmentIntersector question...

Hi Shayne,

The base osgUtil::Intersector class supports setting the limits
on
intersection results, using the setIntersectionLimit() method.
The
current options are NO_LIMIT, LIMIT_ONE_PER_DRAWABLE, LIMIT_ONE,
LIMIT_NEAREST.

On Tue, Sep 11, 2012 at 9:47 AM, Tueller, Shayne R Civ USAF AFMC
519
SMXS/MXDEC shayne.tuel...@hill.af.mil wrote:

1)  Does it support a feature of detecting a hit
and then
returning without the need to compute all the intersections?
This would
be sort of like a visibility test.

Set the intersection limit to LIMIT_ONE



2)  Does it have the ability to find the closest
intersection without the need to compute all the intersections?
In other
words, does it step along from the starting point of the line
segment
until an intersection is found and then bail out?

Set the intersection limit to LIMIT_NEAREST. This mode could be
optimized more, but it will currently reject a subgraph if the
nearest
point of the bounding sphere is further than the nearest hit. So
it can
still provide significant savings in computation time.

Cheers,
Farshid




3)  If it doesn't support these features, is it
possible to
modify the LineSegmentIntersector to support these?



I would think that having this capability would improve
performance where applicable.



Thanks for any input in advance...



-Shayne






___
osg-users mailing list
osg-users@lists.openscenegraph.org


http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.o
r g 




___
osg-users mailing list
osg-users@lists.openscenegraph.org

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

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g



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

Re: [osg-users] LineSegmentIntersector which objects are returned?

[Heiko Thiel]

Hi Robert,


robertosfield wrote:
 Secondly the intersections you get returned return the leaf node and
 drawable that is intersected along with the node path from the root of
 the intersection traversal down to the leaf node that was intersected.


you found my problem: I forgot that the demo access only the leaf node, so I 
can solve may problem by searching right node on nodePath.

But I can't use nodePath like expected. To play a little bit with the nodePath 
I wanted to print all names of nodes

So my first try was:

Code:
bool nodeFound = false;
for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr = 
intersections.begin(); hitr != intersections.end(); ++hitr)
{
  osg::NodePath path = hitr-nodePath;
  for(osg::NodePath::iterator hitNodeIt = path = hitr-nodePath.begin(); 
hitNodeIt != path = hitr-nodePath.end(); ++hitNodeIt)
  {
if (hitNodeIt-getName())
{
  nodeFound = true;
  std::cout  hitNodeIt-getName();
}
  }
  if (nodeFound) break;
}



Then I got:

 IntelliSense: Es ist keine passende benutzerdefinierte Konvertierung von  
 std::_Vector_const_iteratorstd::_Vector_valosg::Node *, 
 std::allocatorosg::Node * in 
 std::_Vector_iteratorstd::_Vector_valosg::Node *, 
 std::allocatorosg::Node * vorhanden.


So I tried this:

Code:
bool nodeFound = false;
for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr = 
intersections.begin(); hitr != intersections.end(); ++hitr)
{
  for(osg::NodePath::const_iterator hitNodeIt = hitr-nodePath.begin(); 
hitNodeIt != hitr-nodePath.end(); ++hitNodeIt)
  {
if (hitNodeIt-getName())
{
  nodeFound = true;
  std::cout  hitNodeIt-getName();
}
  }
  if (nodeFound) break;
}


But this won't compile too:

 error C2039: 'getName': Ist kein Element von 
 'std::_Vector_const_iterator_Myvec'
 error C2839: Ungültiger Rückgabetyp 'osg::Node *const *' für überladenen 
 Operator '-'
 IntelliSense: Der Ausdruck muss den Typ pointer-to-class aufweisen.
 


Any idea?

Heiko

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





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

Re: [osg-users] LineSegmentIntersector which objects are returned?

[Jean-Sébastien Guay]

Hello Heiko,


But this won't compile too:


error C2039: 'getName': Ist kein Element von 
'std::_Vector_const_iterator_Myvec'
error C2839: Ungültiger Rückgabetyp 'osg::Node *const *' für überladenen Operator 
'-'
IntelliSense: Der Ausdruck muss den Typ pointer-to-class aufweisen.


Any idea?


I think you just need to check the types of what you're using... 
hitNodeIt is an osg::NodePath::iterator. This expands to 
std::vectorosg::Node*::iterator (you are in Visual Studio, so you can 
press F12 with the cursor on osg::NodePath to see what type it really 
is, you'll see it's a typedef of std::vectorosg::Node* or something 
similar). So to be able to call getName() you need to do:


(*hitNodeIt)-getName()

Hope this helps,

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] LineSegmentIntersector which objects are returned?

[Heiko Thiel]

Hi,

you are right :). I tried this myself before and saw that VS show me 
nevertheless an error. But didnt seen that the error message changed (I had 
forgot the .empty() on comparism) ;)

Thank you!

Cheers,
Heiko

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





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

Re: [osg-users] LineSegmentIntersector which objects are returned?

[Robert Osfield]

Hi Heiko,

I'm afraid I can't work out what is going on from your description so
the best I can do is provide some general suggestions.

First up only polygonal meshes can be interested by
LineSegmentIntersector, so point clouds and lines will not return
intersections.

Secondly the intersections you get returned return the leaf node and
drawable that is intersected along with the node path from the root of
the intersection traversal down to the leaf node that was intersected.

Robert.

On Sun, Feb 6, 2011 at 11:12 PM, Heiko Thiel osgfo...@tevs.eu wrote:
 Hi,

 I have a simple question to LineSegmentIntersector: Which objects can be 
 intersect with the test ray?

 I ask because I have following problem: I have following osg tree:

 - Geode -Field
  - Node (Model loaded from disc) - Contains Name obj1 by Model (so not set 
 by my - don't want to presume that the name is everytime same)
  - Geode (single quad of the ground of terrain) - Name: Ground
   - Geometry (4 vertices)

 If I do now a klick I got following names returned: obj1, obj1, obj, ..., 
 Ground (Model is a Firetree - many intersections). But never the name 
 Field. So the problem is: I can't assume that the Model has name obj1. 
 That is why I think I must additional geode around it with an extra class, so 
 I can check with dynamic_cast if the test ray had found an interesting object 
 or not. But this don't work, if I dont get the Field-Geode returned.

 How to handle this problem? (osgPick-Demo is to simple to see a solution :( )

 Thank you!

 Cheers,
 Heiko

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





 ___
 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] LineSegmentIntersector which objects are returned?

[Heiko Thiel]

Hi,

I have a simple question to LineSegmentIntersector: Which objects can be 
intersect with the test ray?

I ask because I have following problem: I have following osg tree:

- Geode -Field
 - Node (Model loaded from disc) - Contains Name obj1 by Model (so not set 
by my - don't want to presume that the name is everytime same)
 - Geode (single quad of the ground of terrain) - Name: Ground
   - Geometry (4 vertices)

If I do now a klick I got following names returned: obj1, obj1, obj, ..., 
Ground (Model is a Firetree - many intersections). But never the name Field. 
So the problem is: I can't assume that the Model has name obj1. That is why I 
think I must additional geode around it with an extra class, so I can check 
with dynamic_cast if the test ray had found an interesting object or not. But 
this don't work, if I dont get the Field-Geode returned.

How to handle this problem? (osgPick-Demo is to simple to see a solution :( )

Thank you!

Cheers,
Heiko

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





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

Re: [osg-users] LineSegmentIntersector::Intersection contains no indexList

[Oliver Neumann]

Hi Robert,

thanks for the reply. I have used the ShapeDrawable as an example. My code uses 
nodes read from COLLADA models and it doesn't work there either (those nodes 
display just fine, with the texture on them, so I know uv mapping is also 
working).
I can't understand why the code allows the calculation of the correct 
intersection point, but not the reference of the Nodes. It seems to be an 
artificial limitation.

Greetings,
Oliver

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





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

Re: [osg-users] LineSegmentIntersector::Intersection contains no indexList

[Robert Osfield]

Hi Oliver,

There isn't much the osgUtil intersection code can do about temporary
data as created by ShapeDrawable.  ShapeDrawable is really just meant
for very simply usage, such as quick a dirty debugging, I don't
recommend it's general usage.

Robert.

On Tue, Jan 4, 2011 at 1:52 PM, Oliver Neumann z0...@yahoo.com wrote:
 Hi,

 I am trying to get uv coordinates and color of a point I found using the 
 LineSegmentIntersector. My problem is that the found intersection has no 
 indexList so I cannot use the code used in osgmovie.

 This short code example should boil down to the point:


 Code:

 osg::Box* b = new osg::Box( osg::Vec3d(0,0,0), 1.0f);
                        osg::Geode* g = new osg::Geode();
                        g-addDrawable( new osg::ShapeDrawable( b ) );
                        osg::ref_ptr osgUtil::LineSegmentIntersector lineSeg 
 = new osgUtil::LineSegmentIntersector(osg::Vec3d(0,-2,0), osg::Vec3d(0,0,0));
                        osgUtil::IntersectionVisitor 
 findIntersections(lineSeg.get());
                        g-accept(findIntersections);
                        osgUtil::LineSegmentIntersector::Intersection currHit 
 = lineSeg-getFirstIntersection();
                        osg::Vec3d intersecPnt = 
 currHit.getWorldIntersectPoint();
                        int vecArraySize = currHit.indexList.size();
                        int vecRatioSize =  currHit.ratioList.size();




 intersecPnt is correctly found, but vecArraySize and vecRatioSize is zero.

 I read through some layers of osg code and it seems my proble is the 
 treatVertexDataAsTemporary variable. It prevents at the end of 
 TriangleIntersector::operator () (part of LineSegmentIntersectorUtils in 
 linesegmentintersector.cpp) that the found three vertices used to compute the 
 intersection are inserted into the result as they are temporary.

 How do I get the correct uv coordinates in such a situation or how do I force 
 the inclusion of the needed vertices?

 Cheers,
 Oliver

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





 ___
 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] LineSegmentIntersector::Intersection contains no indexList

[Oliver Neumann]

Hi,

I am trying to get uv coordinates and color of a point I found using the 
LineSegmentIntersector. My problem is that the found intersection has no 
indexList so I cannot use the code used in osgmovie.

This short code example should boil down to the point:


Code:

osg::Box* b = new osg::Box( osg::Vec3d(0,0,0), 1.0f);
osg::Geode* g = new osg::Geode();
g-addDrawable( new osg::ShapeDrawable( b ) );  
osg::ref_ptr osgUtil::LineSegmentIntersector lineSeg 
= new osgUtil::LineSegmentIntersector(osg::Vec3d(0,-2,0), osg::Vec3d(0,0,0));
osgUtil::IntersectionVisitor 
findIntersections(lineSeg.get());
g-accept(findIntersections);
osgUtil::LineSegmentIntersector::Intersection currHit = 
lineSeg-getFirstIntersection();
osg::Vec3d intersecPnt = 
currHit.getWorldIntersectPoint();
int vecArraySize = currHit.indexList.size();
int vecRatioSize =  currHit.ratioList.size();




intersecPnt is correctly found, but vecArraySize and vecRatioSize is zero.

I read through some layers of osg code and it seems my proble is the 
treatVertexDataAsTemporary variable. It prevents at the end of 
TriangleIntersector::operator () (part of LineSegmentIntersectorUtils in 
linesegmentintersector.cpp) that the found three vertices used to compute the 
intersection are inserted into the result as they are temporary. 

How do I get the correct uv coordinates in such a situation or how do I force 
the inclusion of the needed vertices?

Cheers,
Oliver

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





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

[osg-users] LineSegmentIntersector...

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

All,

 

I have a question about LineSegmentIntersector. Does it always return all
intersections or does it have a feature that tells you whether or not you
got a hit or not? I have a need to use something for terrain masking from a
viewpoint to another location. In this case, all I want to know is if I hit
terrain or not. I don't care about where the hit is or how many hits there
are. It would certainly be more optimal to test for a single hit in this
case rather than computing ALL intersections along a line of sight.

 

Any feedback on this would be appreciated.

 

Thanks,

-Shayne



smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector...

[Tomlinson, Gordon]

In the past I would simply write my own 'LineSegementIntersector' to
return just a hit and simply use a node mask to just test against
terrain nodes, just subclass or make a copy of the current
'LineSegementIntersector' and just later what it returns and data it
collects etc 

 

 

Gordon Tomlinson

Product Manager 3d Technology  Project Wyvern

Overwatch(r)

An Operating Unit of Textron Systems

__
WARNING: Documents that can be viewed, printed or retrieved from this
E-Mail may contain technical data whose export is restricted by the Arms
Export Control Act (Title 22, U.S.C., Sec 2751, et seq,) or the Export
Administration Act of 1979, as amended, Title 50, U.S.C., App. 2401 et
seq. and which may not be exported, released or disclosed to non-U.S.
persons (i.e. persons who are not U.S. citizens or lawful permanent
residents [green card holders]) inside or outside the United States,
without first obtaining an export license.  Violations of these export
laws are subject to severe civil, criminal and administrative
penalties.

 

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Tuesday, August 24, 2010 1:13 PM
To: OpenSceneGraph Users
Subject: [osg-users] LineSegmentIntersector...

 

All,

 

I have a question about LineSegmentIntersector. Does it always return
all intersections or does it have a feature that tells you whether or
not you got a hit or not? I have a need to use something for terrain
masking from a viewpoint to another location. In this case, all I want
to know is if I hit terrain or not. I don't care about where the hit is
or how many hits there are. It would certainly be more optimal to test
for a single hit in this case rather than computing ALL intersections
along a line of sight...

 

Any feedback on this would be appreciated...

 

Thanks,

-Shayne

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

Re: [osg-users] LineSegmentIntersector...

[Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC]

I sort of figured that I might have to write my own. I just wanted to make
sure there wasn't already something out there before I pressed forward. It
probably might be a good thing to have in osgSim since terrain masking is a
heavily used feature in simulation environments...

Thanks for your input.

-Shayne

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tomlinson,
Gordon
Sent: Tuesday, August 24, 2010 11:37 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] LineSegmentIntersector...

In the past I would simply write my own 'LineSegementIntersector' to return
just a hit and simply use a node mask to just test against terrain nodes,
just subclass or make a copy of the current 'LineSegementIntersector' and
just later what it returns and data it collects etc 

 

 

Gordon Tomlinson

Product Manager 3d Technology  Project Wyvern

OverwatchR

An Operating Unit of Textron Systems

__
WARNING: Documents that can be viewed, printed or retrieved from this
E-Mail may contain technical data whose export is restricted by the Arms
Export Control Act (Title 22, U.S.C., Sec 2751, et seq,) or the Export
Administration Act of 1979, as amended, Title 50, U.S.C., App. 2401 et seq.
and which may not be exported, released or disclosed to non-U.S. persons
(i.e. persons who are not U.S. citizens or lawful permanent residents
[green card holders]) inside or outside the United States, without first
obtaining an export license.  Violations of these export laws are subject to
severe civil, criminal and administrative penalties.

 

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Tueller,Shayne R Civ USAF AFMC 519 SMXS/MXDEC
Sent: Tuesday, August 24, 2010 1:13 PM
To: OpenSceneGraph Users
Subject: [osg-users] LineSegmentIntersector...

 

All,

 

I have a question about LineSegmentIntersector. Does it always return all
intersections or does it have a feature that tells you whether or not you
got a hit or not? I have a need to use something for terrain masking from a
viewpoint to another location. In this case, all I want to know is if I hit
terrain or not. I don't care about where the hit is or how many hits there
are. It would certainly be more optimal to test for a single hit in this
case rather than computing ALL intersections along a line of sight.

 

Any feedback on this would be appreciated.

 

Thanks,

-Shayne



smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector and alpha-blended polygons

[Matthew Hielsberg]

Hi,

I finally found another post that gets pretty close to what I wanted, but did 
not work right out of the box (see 
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-January/021653.html).
  I wrote the following function starting from the above post's code and it 
seems to work well, at least for my few test models.
 

Code:

float GetAlphaAtTexCoords(const osgUtil::LineSegmentIntersector::Intersection 
*hit)
{
osg::Vec2 tc(0.0f,0.0f);
float alpha = -1.0f;

osg::Drawable* drawable = hit-drawable.get();
osg::Geometry* geometry = drawable ? drawable-asGeometry() : NULL;
osg::Vec3Array* vertices = geometry ? 
dynamic_castosg::Vec3Array*(geometry-getVertexArray()) : NULL;
if (vertices)
{
// get the vertex indices.
const osgUtil::LineSegmentIntersector::Intersection::IndexList indices 
= hit-indexList;
const osgUtil::LineSegmentIntersector::Intersection::RatioList ratios 
= hit-ratioList;

if (3 == ratios.size()  3 == indices.size())
{
osg::Array* texcoords = (geometry-getNumTexCoordArrays()0) ? 
geometry-getTexCoordArray(0) : NULL;
osg::Vec2Array* texcoords_Vec2Array = 
dynamic_castosg::Vec2Array*(texcoords);
if (texcoords_Vec2Array)
{
osg::Vec2 tc0 = (*texcoords_Vec2Array)[indices[0]];
osg::Vec2 tc1 = (*texcoords_Vec2Array)[indices[1]];
osg::Vec2 tc2 = (*texcoords_Vec2Array)[indices[2]];
tc = tc0 * ratios[0] + tc1 * ratios[1] + tc2 * ratios[2];
}
else
return alpha;
}
else
return alpha;
}
else
return alpha;

osg::TexMat* activeTexMat = NULL;
osg::Texture2D* activeTexture = NULL;
osg::Image* activeImage = NULL;

if (geometry-getStateSet())
{
osg::TexMat* texMat = 
dynamic_castosg::TexMat*(geometry-getStateSet()-getTextureAttribute(0,osg::StateAttribute::TEXMAT));
if (texMat) 
activeTexMat = texMat;

osg::Texture2D* texture = 
dynamic_castosg::Texture2D*(geometry-getStateSet()-getTextureAttribute(0,osg::StateAttribute::TEXTURE));
if (texture) 
activeTexture = texture;
else
return alpha;
activeImage = activeTexture-getImage();
}
else if (drawable-getNumParents()  0)
{
// XXX - assumes texture info is at most one level up
for (unsigned int i = 0; i  drawable-getNumParents(); ++i)
{
// reset all ptrs just in case
activeTexMat = NULL;
activeTexture = NULL;
activeImage = NULL;
// get the current parent ptr
osg::Node *p = drawable-getParent(i);
if (p-getStateSet())
{
osg::TexMat* texMat = 
dynamic_castosg::TexMat*(p-getStateSet()-getTextureAttribute(0,osg::StateAttribute::TEXMAT));
if (texMat) 
activeTexMat = texMat;

osg::Texture2D* texture = 
dynamic_castosg::Texture2D*(p-getStateSet()-getTextureAttribute(0,osg::StateAttribute::TEXTURE));
if (texture) 
activeTexture = texture;
else
continue;
activeImage = activeTexture-getImage();
if (activeImage)
break;// bail from the for loop
}
}
}

if (activeTexMat)
{
osg::Vec4 tc_transformed = osg::Vec4(tc.x(),tc.y(),0.0f,0.0f) * 
activeTexMat-getMatrix();
tc.x() = tc_transformed.x();
tc.y() = tc_transformed.y();
}

if (activeImage)
{
// handle s wrapping
switch (activeTexture-getWrap(osg::Texture::WRAP_S))
{
case osg::Texture::CLAMP:
case osg::Texture::CLAMP_TO_BORDER:
case osg::Texture::CLAMP_TO_EDGE:
if (tc.x()  0.0f)
tc.x() = 0.0f;
if (tc.x()  1.0f)
tc.x() = 1.0f;
break;
case osg::Texture::MIRROR:
tc.x() = tc.x() - floor(tc.x());
if ((int)(floor(tc.x())) % 2)
tc.x() = 1.0f - tc.x();
break;
case osg::Texture::REPEAT:
tc.x() = tc.x() - floor(tc.x());
break;
}
// handle t wrapping
switch (activeTexture-getWrap(osg::Texture::WRAP_T))
{
case osg::Texture::CLAMP:
case osg::Texture::CLAMP_TO_BORDER:
case osg::Texture::CLAMP_TO_EDGE:
if (tc.y()  0.0f)
tc.y() = 0.0f;
if (tc.y()  1.0f)
tc.y() = 1.0f;
break;
case osg::Texture::MIRROR:
tc.y() = tc.y() - floor(tc.y());
if ((int)(floor(tc.y())) % 2)
tc.y() = 1.0f - tc.y();
break;
case osg::Texture::REPEAT:
tc.y() = tc.y() - floor(tc.y());
break;
 

[osg-users] LineSegmentIntersector and alpha-blended polygons

[Matthew Hielsberg]

Hi,

Does anyone know how to access the rgba texture values at the point of 
intersection in a polygon found using osgUtil::IntersectionVisitor and  
osgUtil::LineSegmentIntersector?  Ideally I would pass a threshold to the 
IntersectionVisitor so that it automatically skips intersecting polygons whose 
alpha values at the intersection point fall below the threshold.  Since this 
functionality does not seem to exist, I am wondering if there is another means 
available to find this information.  I am hoping that I do not have to write a 
new IntersectionVisitor.

Thank you!

Cheers,
Matthew

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





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

Re: [osg-users] LineSegmentIntersector and alpha-blended polygons

[J.P. Delport]

Hi,

look at the intersection code in osgmovie. I think it gets the texture 
coords of intersection.


jp

Matthew Hielsberg wrote:

Hi,

Does anyone know how to access the rgba texture values at the point of 
intersection in a polygon found using osgUtil::IntersectionVisitor and  
osgUtil::LineSegmentIntersector?  Ideally I would pass a threshold to the 
IntersectionVisitor so that it automatically skips intersecting polygons whose 
alpha values at the intersection point fall below the threshold.  Since this 
functionality does not seem to exist, I am wondering if there is another means 
available to find this information.  I am hoping that I do not have to write a 
new IntersectionVisitor.

Thank you!

Cheers,
Matthew

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





___
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] LineSegmentIntersector and alpha-blended polygons

[Jean-Sébastien Guay]

Hello Matthew,


Does anyone know how to access the rgba texture values at the point of 
intersection in a polygon found using osgUtil::IntersectionVisitor and  
osgUtil::LineSegmentIntersector?  Ideally I would pass a threshold to the 
IntersectionVisitor so that it automatically skips intersecting polygons whose 
alpha values at the intersection point fall below the threshold.  Since this 
functionality does not seem to exist, I am wondering if there is another means 
available to find this information.  I am hoping that I do not have to write a 
new IntersectionVisitor.


I don't think you need to write a new intersector, just filter the 
intersections it returns with your criteria. I've never done what you 
want to do, but in theory, given what information 
osgUtil::LineSegmentIntersector::Intersection gives you, you should be 
able to compute the texture coordinates of the hit point (i.e. the hit 
point in texture space) and then sample the texture.


The general idea is:

You have the localIntersectionPoint, which is the intersection point in 
object space, you have the pointer to the drawable, and you have the 
primitiveIndex. Get the primitive's vertex positions and texture 
coordinates (there will be 3, 4 or more of each depending on if it's a 
triangle, a quad or a polygon - you can always choose to handle only 
triangles). Find where the intersection point lines within the primitive 
(which will be a linear combination of the 3, 4 or more vertices' 
coordinates), and then do a linear combination of the texture 
coordinates by the same ratios to find the texture coordinates at the 
intersection point.


Then find the texture that's applied to the drawable by starting in the 
drawable's stateset and if there's no texture, checking the parent(s) 
until you find one. Given that, you can sample the texture at those 
coordinates (perhaps filtering 2x2 or something) and you'll have what 
you need to make a decision to use that intersection or not. If not, 
then move on to the next one.


I wonder if there's any built-in functionality in OSG to do what I 
described above. I don't recall any, but I may have just never seen it. 
Or perhaps there's some code that does that somewhere in the examples. I 
hope in any case that someone can reply with more concrete information, 
as what I describe above is pretty general and you'll have to figure out 
the math yourself.


Hope this helps,

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] LineSegmentIntersector, IntersectionVisitor and children

[Robert Osfield]

Hi Julien-Charles,

The interesection code only using the node bounding spheres during
traversal, it doesn't use them for the final intersection calculation as
this is done against the actual primitives of the drawable leaves.   I can't
say way is wrong with your setup, but it won't be a parental bounding sphere
issue.

Robert.

On Tue, Sep 15, 2009 at 8:24 PM, Julien-Charles Levesque 
levesque...@gmail.com wrote:

 Hi,

 I am using LineSegmentIntersectors with IntersectionVisitor to do some ray
 casting in my architecture. Everything works fine to select and move
 objects. However I want to implement a drag-and-drop interaction, where I
 can move an object onto another and have something different happen. I want
 to obtain this object using the ray casting as well, so I cast a ray and
 check to get the first object in Intersections that is not my current object
 (which I saved in a member variable at the beginning of my drag-and-drop).

 It all works fine until I start interacting with parent/child objects. I
 have a sphere and a cube, the sphere is the parent of the cube. When I
 drag-and-drop my cube over black space, the IntersectionVisitor returns me
 the sphere (the parent) as the second object intersected even though there
 is nothing behind the cube at the place I dropped it.

 Now I believe this has something to do with the parent's bounding sphere
 including it's children and thus being counted as an intersection, but I'm
 not sure how I can deal with this kind of stuff. Then again, I could be
 mistaken.

 I tried reading about bounding spheres in the reference guide and did not
 see much, neither could I get much information (or enough information ;)
 about IntersectionVisitors.. any help would be strongly appreciated !


 Thanks in advance !

 Sincerely,
 Julien-Charles

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





 ___
 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] LineSegmentIntersector, IntersectionVisitor and children

[Julien-Charles Levesque]

Hi,

I am using LineSegmentIntersectors with IntersectionVisitor to do some ray 
casting in my architecture. Everything works fine to select and move objects. 
However I want to implement a drag-and-drop interaction, where I can move an 
object onto another and have something different happen. I want to obtain this 
object using the ray casting as well, so I cast a ray and check to get the 
first object in Intersections that is not my current object (which I saved in a 
member variable at the beginning of my drag-and-drop). 

It all works fine until I start interacting with parent/child objects. I have a 
sphere and a cube, the sphere is the parent of the cube. When I drag-and-drop 
my cube over black space, the IntersectionVisitor returns me the sphere (the 
parent) as the second object intersected even though there is nothing behind 
the cube at the place I dropped it. 

Now I believe this has something to do with the parent's bounding sphere 
including it's children and thus being counted as an intersection, but I'm not 
sure how I can deal with this kind of stuff. Then again, I could be mistaken.

I tried reading about bounding spheres in the reference guide and did not see 
much, neither could I get much information (or enough information ;) about 
IntersectionVisitors.. any help would be strongly appreciated !


Thanks in advance !

Sincerely,
Julien-Charles

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





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

[osg-users] LineSegmentIntersector with transformations

[Poirier, Guillaume]

Hello,
 
I am trying to use a LineSegmentIntersector and want to specify start and end 
points in world space coordinates. Aditionally, the Drawable I want to 
intersect has parent nodes with transformations (translate / rotate / scale). 
How can I achieve this ?
 
 
regards,
 
 
bill
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector with transformations

[Jean-Sébastien Guay]

Hello Guillaume,

I am trying to use a LineSegmentIntersector and want to specify start 
and end points in world space coordinates. Aditionally, the Drawable I 
want to intersect has parent nodes with transformations (translate / 
rotate / scale). How can I achieve this ?


When you use your LineSegmentIntersector with an IntersectionVisitor, 
the start and end will be assumed to be in the coordinate space of the 
node you use the visitor on. So if you want to specify start and end in 
world space, use the visitor on the root node of your scene graph. If 
you want them to be in screen space, use it on the camera.


When the IntersectionVisitor traverses the hierarchy down to the 
drawables, it will automatically accumulate the transforms.


Hope this helps,

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

[osg-users] LineSegmentIntersector and line width

[a.lagnier]

Hi,

I'm using osgUtil::LinesegmentIntersector to pick objects from my scene.
It works all fine except Geode containing line geometry (with LineWidth 
stateset). But, I want to pick somes thick lines, how can I do?

Thanks in advance!

Aude



 Créez votre adresse électronique [EMAIL PROTECTED] 
 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector and line width

[Peter Hrenka]

Hi Aude,

a.lagnier schrieb:

Hi,

I'm using osgUtil::LinesegmentIntersector to pick objects from my scene.
It works all fine except Geode containing line geometry (with LineWidth 
stateset). But, I want to pick somes thick lines, how can I do?


LinesegementIntersector cannot pick lines (or points).
You can use osgUtil::PolytopeIntersector instead.
Have a look at the osgkeyboardmouse example for
example code.


Thanks in advance!

Aude


Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Florian Geyer,
Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Prof. Dr. Hanns Ruder
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


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

Re: [osg-users] LineSegmentIntersector does not work with Billboards

[Robert Osfield]

Hi Judd,

I have done some work on osgUtil::IntersectionVisitor to add proper
support for Billboards.  Could you try out the attached
IntersectionVisitor header/source files and let me know how you get
on.  This builds against OSG-2.6/OSG-SVN, but might also compile
against 2.4.

In my own testing 'osgpick lz.osg' now works fine, whereas before this
fix it failed to pick the billboarded trees.

Robert.


IntersectionVisitor
Description: Binary data
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield 
 *
 * This library is open source and may be redistributed and/or modified under  
 * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or 
 * (at your option) any later version.  The full license is in LICENSE file
 * included with this distribution, and on the openscenegraph.org website.
 * 
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
 * OpenSceneGraph Public License for more details.
*/


#include osgUtil/IntersectionVisitor
#include osgUtil/LineSegmentIntersector

#include osg/PagedLOD
#include osg/Transform
#include osg/Projection
#include osg/Camera
#include osg/Geode
#include osg/Billboard
#include osg/Geometry
#include osg/Notify
#include osg/io_utils

using namespace osgUtil;


///
//
//  IntersectorGroup
//

IntersectorGroup::IntersectorGroup()
{
}

void IntersectorGroup::addIntersector(Intersector* intersector)
{
_intersectors.push_back(intersector);
}

void IntersectorGroup::clear()
{
_intersectors.clear();
}

Intersector* IntersectorGroup::clone(osgUtil::IntersectionVisitor iv)
{
IntersectorGroup* ig = new IntersectorGroup;

// now copy across all intersectors that arn't disabled.
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if (!(*itr)-disabled())
{
ig-addIntersector( (*itr)-clone(iv) );
}
}

return ig;
}

bool IntersectorGroup::enter(const osg::Node node)
{
if (disabled()) return false;

bool foundIntersections = false;

for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if ((*itr)-disabled()) (*itr)-incrementDisabledCount();
else if ((*itr)-enter(node)) foundIntersections = true;
else (*itr)-incrementDisabledCount();
}

if (!foundIntersections) 
{
// need to call leave to clean up the DisabledCount's.
leave();
return false;
}

// we have found at least one suitable intersector, so return true
return true;
}

void IntersectorGroup::leave()
{
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if ((*itr)-disabled()) (*itr)-decrementDisabledCount();
}
}

void IntersectorGroup::intersect(osgUtil::IntersectionVisitor iv, osg::Drawable* drawable)
{
if (disabled()) return;

unsigned int numTested = 0;
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if (!(*itr)-disabled())
{
(*itr)-intersect(iv, drawable);

++numTested;
}
}

// osg::notify(osg::NOTICE)Number testing numTestedstd::endl;

}

void IntersectorGroup::reset()
{
Intersector::reset();

for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
(*itr)-reset();
}
}

bool IntersectorGroup::containsIntersections()
{
for(Intersectors::iterator itr = _intersectors.begin();
itr != _intersectors.end();
++itr)
{
if ((*itr)-containsIntersections()) return true;
}
return false;
}


///
//
//  IntersectionVisitor
//

IntersectionVisitor::IntersectionVisitor(Intersector* intersector, ReadCallback* readCallback)
{
// override the default node visitor mode.
setTraversalMode(osg::NodeVisitor::TRAVERSE_ACTIVE_CHILDREN);

_useKdTreesWhenAvailable = true;
_dummyTraversal = false;

_lodSelectionMode = USE_HIGHEST_LEVEL_OF_DETAIL;
_eyePointDirty = true;

LineSegmentIntersector* ls = dynamic_castLineSegmentIntersector*(intersector);
if (ls) 
{
setReferenceEyePoint(ls-getStart());
setReferenceEyePointCoordinateFrame(ls-getCoordinateFrame());
}
else
{
setReferenceEyePoint(osg::Vec3(0.0f,0.0f,0.0f));
setReferenceEyePointCoordinateFrame(Intersector::VIEW);
}

setIntersector(intersector);

setReadCallback(readCallback);

Re: [osg-users] LineSegmentIntersector does not work with Billboards

[Judd Tracy]

It seems to work just fine in my application.  Thanks for the support.

Judd

Robert Osfield wrote:

Hi Judd,

I have done some work on osgUtil::IntersectionVisitor to add proper
support for Billboards.  Could you try out the attached
IntersectionVisitor header/source files and let me know how you get
on.  This builds against OSG-2.6/OSG-SVN, but might also compile
against 2.4.

In my own testing 'osgpick lz.osg' now works fine, whereas before this
fix it failed to pick the billboarded trees.

Robert.
  


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

Re: [osg-users] LineSegmentIntersector does not work with Billboards

[Judd Tracy]

Robert

I have added a method called set (did not know what to call it) that 
allows you to set the start and end points for the LinSegmentIntersector 
using the CooridnateFrame and the x, y values like one of the 
constructors does.  It just makes it easier to reset the start and end 
points without having to know which values to use depending on the 
CoordinateFrame.


Judd

Robert Osfield wrote:

Hi Judd,

I have done some work on osgUtil::IntersectionVisitor to add proper
support for Billboards.  Could you try out the attached
IntersectionVisitor header/source files and let me know how you get
on.  This builds against OSG-2.6/OSG-SVN, but might also compile
against 2.4.

In my own testing 'osgpick lz.osg' now works fine, whereas before this
fix it failed to pick the billboarded trees.

Robert.
  


/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield 
 *
 * This library is open source and may be redistributed and/or modified under  
 * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or 
 * (at your option) any later version.  The full license is in LICENSE file
 * included with this distribution, and on the openscenegraph.org website.
 * 
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
 * OpenSceneGraph Public License for more details.
*/


#include osgUtil/LineSegmentIntersector

#include osg/Geometry
#include osg/Notify
#include osg/io_utils
#include osg/TriangleFunctor

using namespace osgUtil;

namespace LineSegmentIntersectorUtils
{

struct TriangleIntersection
{
TriangleIntersection(unsigned int index, const osg::Vec3 normal, float 
r1, const osg::Vec3* v1, float r2, const osg::Vec3* v2, float r3, const 
osg::Vec3* v3):
_index(index),
_normal(normal),
_r1(r1),
_v1(v1),
_r2(r2),
_v2(v2),
_r3(r3),
_v3(v3) {}

unsigned int_index;
const osg::Vec3 _normal;
float   _r1;
const osg::Vec3*_v1;
float   _r2;
const osg::Vec3*_v2;
float   _r3;
const osg::Vec3*_v3;
};

typedef std::multimapfloat,TriangleIntersection TriangleIntersections;

struct TriangleIntersector
{
osg::Vec3   _s;
osg::Vec3   _d;
float   _length;

int _index;
float   _ratio;
bool_hit;

TriangleIntersections _intersections;

TriangleIntersector()
{
_length = 0.0f;
_index = 0;
_ratio = 0.0f;
_hit = false;
}

void set(const osg::Vec3d start, osg::Vec3d end, float ratio=FLT_MAX)
{
_hit=false;
_index = 0;
_ratio = ratio;

_s = start;
_d = end - start;
_length = _d.length();
_d /= _length;
}

inline void operator () (const osg::Vec3 v1,const osg::Vec3 v2,const 
osg::Vec3 v3, bool treatVertexDataAsTemporary)
{
++_index;

if (v1==v2 || v2==v3 || v1==v3) return;

osg::Vec3 v12 = v2-v1;
osg::Vec3 n12 = v12^_d;
float ds12 = (_s-v1)*n12;
float d312 = (v3-v1)*n12;
if (d312=0.0f)
{
if (ds120.0f) return;
if (ds12d312) return;
}
else // d312  0
{
if (ds120.0f) return;
if (ds12d312) return;
}

osg::Vec3 v23 = v3-v2;
osg::Vec3 n23 = v23^_d;
float ds23 = (_s-v2)*n23;
float d123 = (v1-v2)*n23;
if (d123=0.0f)
{
if (ds230.0f) return;
if (ds23d123) return;
}
else // d123  0
{
if (ds230.0f) return;
if (ds23d123) return;
}

osg::Vec3 v31 = v1-v3;
osg::Vec3 n31 = v31^_d;
float ds31 = (_s-v3)*n31;
float d231 = (v2-v3)*n31;
if (d231=0.0f)
{
if (ds310.0f) return;
if (ds31d231) return;
}
else // d231  0
{
if (ds310.0f) return;
if (ds31d231) return;
}


float r3;
if (ds12==0.0f) r3=0.0f;
else if (d312!=0.0f) r3 = ds12/d312;
else return; // the triangle and the line must be parallel 
intersection.

float r1;
if (ds23==0.0f) r1=0.0f;
else if (d123!=0.0f) r1 = ds23/d123;
else return; // the triangle and the line 

Re: [osg-users] LineSegmentIntersector does not work with Billboards

[Robert Osfield]

Hi Judd,

Could you post your ammendments to osg-submissions.

Cheers,
Robert.

On Thu, Aug 14, 2008 at 5:11 PM, Judd Tracy [EMAIL PROTECTED] wrote:
 Robert

 I have added a method called set (did not know what to call it) that allows
 you to set the start and end points for the LinSegmentIntersector using the
 CooridnateFrame and the x, y values like one of the constructors does.  It
 just makes it easier to reset the start and end points without having to
 know which values to use depending on the CoordinateFrame.

 Judd

 Robert Osfield wrote:

 Hi Judd,

 I have done some work on osgUtil::IntersectionVisitor to add proper
 support for Billboards.  Could you try out the attached
 IntersectionVisitor header/source files and let me know how you get
 on.  This builds against OSG-2.6/OSG-SVN, but might also compile
 against 2.4.

 In my own testing 'osgpick lz.osg' now works fine, whereas before this
 fix it failed to pick the billboarded trees.

 Robert.



 /* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
  *
  * This library is open source and may be redistributed and/or modified
 under
  * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
  * (at your option) any later version.  The full license is in LICENSE file
  * included with this distribution, and on the openscenegraph.org website.
  *
  * This library is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * OpenSceneGraph Public License for more details.
 */


 #include osgUtil/LineSegmentIntersector

 #include osg/Geometry
 #include osg/Notify
 #include osg/io_utils
 #include osg/TriangleFunctor

 using namespace osgUtil;

 namespace LineSegmentIntersectorUtils
 {

struct TriangleIntersection
{
TriangleIntersection(unsigned int index, const osg::Vec3 normal,
 float r1, const osg::Vec3* v1, float r2, const osg::Vec3* v2, float r3,
 const osg::Vec3* v3):
_index(index),
_normal(normal),
_r1(r1),
_v1(v1),
_r2(r2),
_v2(v2),
_r3(r3),
_v3(v3) {}

unsigned int_index;
const osg::Vec3 _normal;
float   _r1;
const osg::Vec3*_v1;
float   _r2;
const osg::Vec3*_v2;
float   _r3;
const osg::Vec3*_v3;
};

typedef std::multimapfloat,TriangleIntersection TriangleIntersections;

struct TriangleIntersector
{
osg::Vec3   _s;
osg::Vec3   _d;
float   _length;

int _index;
float   _ratio;
bool_hit;

TriangleIntersections _intersections;

TriangleIntersector()
{
_length = 0.0f;
_index = 0;
_ratio = 0.0f;
_hit = false;
}

void set(const osg::Vec3d start, osg::Vec3d end, float
 ratio=FLT_MAX)
{
_hit=false;
_index = 0;
_ratio = ratio;

_s = start;
_d = end - start;
_length = _d.length();
_d /= _length;
}

inline void operator () (const osg::Vec3 v1,const osg::Vec3
 v2,const osg::Vec3 v3, bool treatVertexDataAsTemporary)
{
++_index;

if (v1==v2 || v2==v3 || v1==v3) return;

osg::Vec3 v12 = v2-v1;
osg::Vec3 n12 = v12^_d;
float ds12 = (_s-v1)*n12;
float d312 = (v3-v1)*n12;
if (d312=0.0f)
{
if (ds120.0f) return;
if (ds12d312) return;
}
else // d312  0
{
if (ds120.0f) return;
if (ds12d312) return;
}

osg::Vec3 v23 = v3-v2;
osg::Vec3 n23 = v23^_d;
float ds23 = (_s-v2)*n23;
float d123 = (v1-v2)*n23;
if (d123=0.0f)
{
if (ds230.0f) return;
if (ds23d123) return;
}
else // d123  0
{
if (ds230.0f) return;
if (ds23d123) return;
}

osg::Vec3 v31 = v1-v3;
osg::Vec3 n31 = v31^_d;
float ds31 = (_s-v3)*n31;
float d231 = (v2-v3)*n31;
if (d231=0.0f)
{
if (ds310.0f) return;
if (ds31d231) return;
}
else // d231  0
{
if (ds310.0f) return;
if (ds31d231) return;
}


float r3;
if (ds12==0.0f) r3=0.0f;
else if (d312!=0.0f) r3 = ds12/d312;
else return; // the triangle and the line must be parallel
 intersection.

float r1;
  

Re: [osg-users] LineSegmentIntersector does not work with Billboards

[Robert Osfield]

Hi Judd,

I've just tried

  osgpick lz.osg

And zooming into the trees and attempting picking is showing no
intersections results where I'd expect.  Reviewing the relevent code
in IntersectionVisitor.cpp suggests that there is no special code for
handling the local model transforms that are required for billboards,
the so the answer is looks to be that even 2.6 hasn't had this problem
addressed. The relevant code is:

void IntersectionVisitor::apply(osg::Billboard billboard)
{
if (!enter(billboard)) return;

for(unsigned int i=0; ibillboard.getNumDrawables(); ++i)
{
intersect( billboard.getDrawable(i) );
}

leave();
}

Looking at the old IntersectVisitor.cpp code shows that it does have
some proper matrix code in there, which could probably copied across
into the IntersectionVisitor:



Robert.
void IntersectVisitor::apply(Billboard node)
{
if (!enterNode(node)) return;

// IntersectVisitor doesn't have getEyeLocal(), can we use
NodeVisitor::getEyePoint()?
const Vec3 eye_local = getEyePoint();

for(unsigned int i = 0; i  node.getNumDrawables(); i++ )
{
const Vec3 pos = node.getPosition(i);
osg::ref_ptrRefMatrix billboard_matrix = new RefMatrix;
node.computeMatrix(*billboard_matrix,eye_local,pos);

pushMatrix(billboard_matrix.get(), osg::Transform::RELATIVE_RF);

intersect(*node.getDrawable(i));

popMatrix();

}

leaveNode();
}

Try merging this code in. If it works out just post the changes to
osg-submissions.  Although it won't be in 2.6.0, this fix could
probably make it into later 2.6.x maintenance releases.

Robert.


On Mon, Aug 11, 2008 at 4:03 PM, Judd Tracy [EMAIL PROTECTED] wrote:
 The LineSegementIntersector in osg 2.4 does not work properly with
 Billboards.  Is there a fix in the SVN or that anyone else might have
 submitted that exists for this.  I have searched the SVN and as far as I can
 tell it has not been addressed.  Any help would be appreciated.

 Judd
 ___
 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] LineSegmentIntersector LEAK-Problem ?

[Kaiser, Hagen (CT)]

Yes you are right. Code compiles fine in release-mode.


Greetings
Hagen


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

[osg-users] LineSegmentIntersector LEAK-Problem?

[Kaiser, Hagen (CT)]

Hello everyone,

I using the following code:
Is it a bug? Its used inside C++/CLI Environment but inside a pure
native class.

This was halfways copypasted from one of the examples. It's a function
inside a GUIEventHandler called in cas of a GUIEvenetAdapter::REALESE:

void pick(const osgGA::GUIEventAdapter ea, osgViewer::Viewer* viewer)
{
osgUtil::LineSegmentIntersector::Intersection
intersection;
osg::Node* scene = viewer-getSceneData();
if (!scene) return;

/*osg::Node* node = 0;
osg::Group* parent = 0;*/
osg::ref_ptrosgUtil::LineSegmentIntersector picker;
picker = new osgUtil::LineSegmentIntersector(
osgUtil::Intersector::PROJECTION,
ea.getXnormalized(),ea.getYnormalized() );  

picker-setThreadSafeReferenceCounting(true);
---Thought this could solve the problem but didnt change anything
picker-setThreadSafeRefUnref(true);
Same here
osgUtil::IntersectionVisitor iv(picker.get());
viewer-getCamera()-accept(iv);
if (picker-containsIntersections())
{
intersection = picker-getFirstIntersection();
---THIS LINE THROWS AN ERROR
}
return;
}


I get the following error:

The output window may have more diagnostic information.
HEAP[interfaceD.exe]: Invalid Address specified to RtlFreeHeap(
0217, 11395350 )
Windows has triggered a breakpoint in interfaceD.exe.

This may be due to a corruption of the heap, which indicates a bug in
interfaceD.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while interfaceD.exe has
focus.

The output window may have more diagnostic information.
The program '[840] interfaceD.exe: Managed' has exited with code 0
(0x0).
The program '[840] interfaceD.exe: Native' has exited with code 0 (0x0).



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

Re: [osg-users] LineSegmentIntersector LEAK-Problem?

[Robert Osfield]

HI Hagen,

I think there is a good chance that this is false reading or perhaps a
bug in your setup/environment.

FYI, the intersection visitor isn't multi-threaded so there will be no
need to enforce thread safe ref/unref.

Robert.

On Tue, Jul 22, 2008 at 9:38 AM, Kaiser, Hagen (CT)
[EMAIL PROTECTED] wrote:

 Hello everyone,

 I using the following code:
 Is it a bug? Its used inside C++/CLI Environment but inside a pure native
 class.

 This was halfways copypasted from one of the examples. It's a function
 inside a GUIEventHandler called in cas of a GUIEvenetAdapter::REALESE:

 void pick(const osgGA::GUIEventAdapter ea, osgViewer::Viewer* viewer)
 {
 osgUtil::LineSegmentIntersector::Intersection intersection;
 osg::Node* scene = viewer-getSceneData();
 if (!scene) return;

 /*osg::Node* node = 0;
 osg::Group* parent = 0;*/
 osg::ref_ptrosgUtil::LineSegmentIntersector picker;
 picker = new osgUtil::LineSegmentIntersector(
 osgUtil::Intersector::PROJECTION, ea.getXnormalized(),ea.getYnormalized()
 );

 picker-setThreadSafeReferenceCounting(true);
 ---Thought this could solve the problem but didnt change anything

 picker-setThreadSafeRefUnref(true);
 Same here
 osgUtil::IntersectionVisitor iv(picker.get());
 viewer-getCamera()-accept(iv);
 if (picker-containsIntersections())
 {
 intersection = picker-getFirstIntersection();
 ---THIS LINE THROWS AN ERROR
 }
 return;
 }

 I get the following error:

 The output window may have more diagnostic information.
 HEAP[interfaceD.exe]: Invalid Address specified to RtlFreeHeap( 0217,
 11395350 )
 Windows has triggered a breakpoint in interfaceD.exe.

 This may be due to a corruption of the heap, which indicates a bug in
 interfaceD.exe or any of the DLLs it has loaded.

 This may also be due to the user pressing F12 while interfaceD.exe has
 focus.

 The output window may have more diagnostic information.
 The program '[840] interfaceD.exe: Managed' has exited with code 0 (0x0).
 The program '[840] interfaceD.exe: Native' has exited with code 0 (0x0).


 ___
 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] LineSegmentIntersector LEAK-Problem?

[Kaiser, Hagen (CT)]

I traced the error now:
The function LineSegementIntersector::getFirstIntersection() executes
very well to the last bit that is:
Dereference _intersections.begin();

It jumps therefor to xtree.h :
reference operator*() const
{   // return designated value
return ((reference)**(const_iterator *)this);
--TO HERE
}

Afterwards it jumps for a reason that i dont understand to vector
destructor and there to:

void _Tidy()
{   // free all storage
if (_Myfirst != 0)
{   // something to free, destroy and
deallocate it

 #if _HAS_ITERATOR_DEBUGGING
this-_Orphan_all();
 #endif /* _HAS_ITERATOR_DEBUGGING */

_Destroy(_Myfirst, _Mylast);
this-_Alval.deallocate(_Myfirst, _Myend -
_Myfirst); --THIS IS THE POINT WHERE THE PROGRAM DIES
}
_Myfirst = 0, _Mylast = 0, _Myend = 0;
}

So it tries somehow to free items in a vector that doesnt exist (?)

A solution for my pov is:
Instead of writing (picker is a LineSegementIntersector:
Picker-getFirstIntersection()-dowhatwever()
I write: 
Picker-getIntersections().begin()-dowhatever();

Still think there must be a bug somewhere at microsoft stl degubimpl or
openscenegraph.


Greetings,
Hagen

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

Re: [osg-users] LineSegmentIntersector LEAK-Problem?

[Robert Osfield]

Hi Hagen,

I believe the OSG code is OK, a quick code review just now doesn't
reveal anything that might be amiss.  I have been told of bug with
certain combinations of VS's iterator debugging.  I'm not a Windows
developers so the exact details went over my head, but my guess is
that this might be worth looking in to.

It'd also be worth just compiling your app in release and seeing if
there are any problems.

Robert.

On Tue, Jul 22, 2008 at 3:14 PM, Kaiser, Hagen (CT)
[EMAIL PROTECTED] wrote:

 I traced the error now:
 The function LineSegementIntersector::getFirstIntersection() executes very
 well to the last bit that is:
 Dereference _intersections.begin();

 It jumps therefor to xtree.h :
 reference operator*() const
 {   // return designated value
 return ((reference)**(const_iterator *)this); --TO
 HERE
 }

 Afterwards it jumps for a reason that i dont understand to vector destructor
 and there to:

 void _Tidy()
 {   // free all storage
 if (_Myfirst != 0)
 {   // something to free, destroy and deallocate
 it

  #if _HAS_ITERATOR_DEBUGGING
 this-_Orphan_all();
  #endif /* _HAS_ITERATOR_DEBUGGING */

 _Destroy(_Myfirst, _Mylast);
 this-_Alval.deallocate(_Myfirst, _Myend -
 _Myfirst); --THIS IS THE POINT WHERE THE PROGRAM DIES

 }
 _Myfirst = 0, _Mylast = 0, _Myend = 0;
 }

 So it tries somehow to free items in a vector that doesnt exist (?)

 A solution for my pov is:
 Instead of writing (picker is a LineSegementIntersector:
 Picker-getFirstIntersection()-dowhatwever()
 I write:
 Picker-getIntersections().begin()-dowhatever();

 Still think there must be a bug somewhere at microsoft stl degubimpl or
 openscenegraph.

 Greetings,
 Hagen

 ___
 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] LineSegmentIntersector - nodePath invalid?

[Robert Osfield]

Hi Glenn,

Your analysis is correct, when the DatabaseCacheReadCallback is
deployed  one can potentially end up with dangling pointers.
Switching to ref counted NodePath would be the safest way to fix this.
 There is a performance penalty though, which is why a straight
NodePath was used.  There is no easy way around this though, as
clever schemes can easily come undone.

Robert.

On Nov 13, 2007 8:59 PM, Glenn Waldron [EMAIL PROTECTED] wrote:
 Robert,

 Thanks for your response. I see what you mean, that under normal
 circumstances the children of a PagedLOD are guaranteed to stick around
 until at least the next update traversal.

 However I think there is still an issue here. The
 IntersectionVisitor::ReadCallback allows you to bypass the database pager's
 normal mechanism and load PagedLOD children manually so to speak. This is
 exactly what the osgSim::DatabaseCacheReadCallback does. It loads children
 and puts them in a cache rather than in the scene graph. Since they're not
 in the scene graph, their lifespan is not tied to the pager. When the cache
 reaches maximum size and starts pruning nodes, a node that might have been
 previously stored in an Intersection's nodePath could get dereferenced and
 destroyed.

 I tested this by changing the type of
 LineSegmentIntersector::Intersection::nodePath to a osg::NodeList. This
 resolved the crash I was seeing.

 If you agree with this analysis, I will be happy to submit a fix. If I'm
 missing something obvious I will go away :) I think PlaneIntersector and
 PolytopeIntersector exhibit the same issue BTW. -gw



 On Nov 13, 2007 3:04 PM, Robert Osfield [EMAIL PROTECTED] wrote:
 
 
 
  Hi Glenn,
 
  Its a potential problem but for most part won't be if you use the
  OSG sensibly - the addition and removal of subgraphs via PagedLOD is
  done single threaded as part of the update traversal so as long as you
  don't run code multi-threaded with this you should be fine.
 
  If your NodePath lives longer than a frame then you'll need to convert
  it into a Ref converted NodePath
 
  Robert.
 
 
 
 
 
  On Nov 13, 2007 4:49 PM, Glenn Waldron [EMAIL PROTECTED] wrote:
   Another intersection-related question for the group:
  
   LineSegmentIntersector::Intersection contains a nodePath member.
 However,
   the osg::NodePath is a simple osg::vectorNode* that doesn't use
 ref_ptr's.
   So I'm not convinced that by the time you are finished intersecting,
 that
   nodePath member contains valid references.
  
   I mention this because I'm trying to use that nodePath and getting
 crashes
   that look suspiciously like the kind you get when you reference deleted
   objects. The problem only arises when traversing PagedLOD nodes (since
 those
   nodes aren't guaranteed to stay resident).
  
   Thanks again. -gw
  
   --
   Glenn Waldron : Pelican Mapping : http://pelicanmapping.com :
 703-652-4791
   ___
   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
 



 --


 Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791
 ___
 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