Re: [osg-users] Intersect Point Cloud wth precision

[Chris Hanson]

Take the results from the PolytopeIntersector, project them to screen
space, measure the distance from your mouse XY to the projected point, sort
the result set by this metric and take the closest.

On Fri, Dec 23, 2016 at 3:22 AM, Robert Osfield 
wrote:

> HI Bruno,
>
> For a point cloud you may be best to implement your own
> osgUtil::Intersector, the design is meant to facilitate this,
> LineSegmentIntersector and PolytopeIntersector are both examples of
> subclasses from Intersector so you could use these as inspriation.
>
> Robert
>
> On 22 December 2016 at 17:02, Bruno Oliveira
>  wrote:
> > Hello,
> >
> > I have a point cloud and need to get the intersection of my mouse with
> that
> > point cloud. For that I use a PolytopeIntersector. I use this intersector
> > because I found out that a LineSegmentIntersector will not do the trick.
> >
> > I set the polytope width and height to 5.0 and therefore I get lots of
> > intersections, which is not good for me since I need to get the neartest
> > intersection to my mouse, and if I pick the first intersection of the
> > polytope I am not guaranteed to have that. A way of doing this would be
> to
> > change the polytope size to, for instance, 1.0 or 0.5, but this sometimes
> > results in no intersections.
> >
> > How can I get the cloud point that is neartest to the polytope's center?
> >
> > ___
> > 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
>



-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Intersect Point Cloud wth precision

[Robert Osfield]

HI Bruno,

For a point cloud you may be best to implement your own
osgUtil::Intersector, the design is meant to facilitate this,
LineSegmentIntersector and PolytopeIntersector are both examples of
subclasses from Intersector so you could use these as inspriation.

Robert

On 22 December 2016 at 17:02, Bruno Oliveira
 wrote:
> Hello,
>
> I have a point cloud and need to get the intersection of my mouse with that
> point cloud. For that I use a PolytopeIntersector. I use this intersector
> because I found out that a LineSegmentIntersector will not do the trick.
>
> I set the polytope width and height to 5.0 and therefore I get lots of
> intersections, which is not good for me since I need to get the neartest
> intersection to my mouse, and if I pick the first intersection of the
> polytope I am not guaranteed to have that. A way of doing this would be to
> change the polytope size to, for instance, 1.0 or 0.5, but this sometimes
> results in no intersections.
>
> How can I get the cloud point that is neartest to the polytope's center?
>
> ___
> 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] Intersect.

[Paul Melis]

Danny Lesnik wrote:
I'm trying to use intersect for primitive collision detection. 

I load one 3DS file into my scene and test whether this object has any intersections. The problem is following: Although ,there is only one object in my scene, I can clearly see that this object intersects with something. 


This is the code I'm using:

tankNode = osgDB::readNodeFile(c:\\3.3DS);
osg::Vec3d intersection;
osg::BoundingSphere bs = tankNode-getBound();
osg::Vec3 start = bs.center() + osg::Vec3d(bs.radius(),0.0,0.0);
osg::Vec3 end = bs.center() ; 


osg::ref_ptrosgUtil::LineSegmentIntersector lsi = new 
osgUtil::LineSegmentIntersector(start,end);
osgUtil::IntersectionVisitor iv(lsi.get());

tankNode-accept(iv);

  if (lsi-containsIntersections())
   {
intersection = lsi-getIntersections().begin()-getWorldIntersectPoint();
   }


While I'm running this code in debugger,the values are following:

bs.center = (0,0,0);
bs.radius = 43.0

start = (43.0,0.0,0.0)

end= (0,0,0)

intersects = (12.5,0,0) and this is weird. Am I missing somthing?
  
It's not an unexpected result, actually. You shoot a line along the X 
axis, so any intersection you're going to find is going to be (value, 0, 
0) in this case.
Note that the bounding sphere is usually not very tight in OSG, so your 
model might easily be intersected at X=12.5.


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

Re: [osg-users] Intersect.

[Danny Lesnik]

Hi Paul,

I just can't realize I have only one object its bs radius os 43. what is the 
object that I can intersect with on x =12,5? 

There supposed to be nothing. 

Thank you!

Cheers,
Danny

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





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

Re: [osg-users] Intersect.

[Paul Melis]

Danny Lesnik wrote:
I just can't realize I have only one object its bs radius os 43. what is the object that I can intersect with on x =12,5? 

There supposed to be nothing. 


Thank you!
  
The only suggestion I have is to check out what is really going on by 
writing a small OSG app that shows both your model and the bounding 
sphere (using e.g. osg::Sphere and an osg::ShapeDrawable). Here, let me 
do it for you :)  (see attachement)


Paul
/* Show the bouding sphere for a given scenegraph
 *
 * Paul E.C. Melis (p.e.c.me...@alumnus.utwente.nl),
 * August 2009
 *
 * g++ -g -o ob osgbound.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/ -losg -losgDB -losgViewer -losgUtil -losgGA -losgText
 */

#include osg/PolygonMode
#include osg/Shape
#include osg/ShapeDrawable
#include osgDB/ReadFile
#include osgViewer/Viewer

class UpdateBoundCallback : public osg::NodeCallback
{
public:
UpdateBoundCallback(osg::Sphere* s)
{
sphere = s;
}

virtual void operator()(osg::Node *node, osg::NodeVisitor *nv)
{
osg::BoundingSphere bound = node-getBound();
sphere-set(bound.center(), bound.radius());
}

osg::ref_ptrosg::Sphere   sphere;
};

int
main(int argc, char *argv[])
{
osg::ref_ptrosg::Node model;
osg::ref_ptrosg::Group root;

if (--argc != 1)
return 0;

model = osgDB::readNodeFile(argv[1]);
root = new osg::Group;
root-addChild(model.get());

osg::BoundingSphere bs = model-getBound();
osg::Sphere *sphere = new osg::Sphere(bs.center(), bs.radius());
osg::ShapeDrawable *shape = new osg::ShapeDrawable(sphere);
shape-setUseDisplayList(false);

model-setUpdateCallback(new UpdateBoundCallback(sphere));

osg::Geode *geode = new osg::Geode;
geode-addDrawable(shape);

osg::PolygonMode *polymode = new osg::PolygonMode;
polymode-setMode(osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::LINE);
geode-getOrCreateStateSet()-setAttributeAndModes(polymode, osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON);
root-addChild(geode);

osgViewer::Viewer viewer;
viewer.setSceneData(root.get());
viewer.realize();
return viewer.run();
}


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

Re: [osg-users] Intersect.

[Tomlinson, Gordon]

I would suggest what I would in this case which is Step into  the code
and look at the triangles as they are tested etc and then you can see
what's happening rather than play 50 guesses


Gordon
Product Manager 3d
__
Gordon Tomlinson
Email  : gtomlinson @ overwatch.textron.com
__


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Danny
Lesnik
Sent: Tuesday, August 25, 2009 6:55 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Intersect.

Hi Paul,

I just can't realize I have only one object its bs radius os 43. what is
the object that I can intersect with on x =12,5? 

There supposed to be nothing. 

Thank you!

Cheers,
Danny

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





___
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] Intersect.

[Paul Melis]

Danny Lesnik wrote:

Hi,

I'm trying to use intersect for primitive collision detection. 

I load one 3DS file into my scene and test whether this object has any intersections. The problem is following: Although ,there is only one object in my scene, I can clearly see that this object intersects with something. 
  
Now that I reread your post I'm wondering if you misunderstand the 
LineSegmentIntersector, which has nothing to do with collision 
detection, per se. The LineSegmentIntersector does not test objects 
against each other, it tests if the line segment you specify intersects 
any of the polygons in the model you test against. And as you are 
shooting the line straight through the center of your model's bounding 
sphere you are very likely to get intersections.


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

Re: [osg-users] Intersect.

[Danny Lesnik]

Hi Paul,

Thank you for your help. 

I think I understand now what LineSegmentIntersector is doing. 

What might be the correct approach to test wether bounding sphere intrsect with 
any other project?

My idea is to move object with UpdateCallBack and stop movement if I have any 
other object on its way.  

Thank you!

Cheers,
Danny

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





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

Re: [osg-users] Intersect.

[Paul Melis]

Danny Lesnik wrote:
Thank you for your help. 

I think I understand now what LineSegmentIntersector is doing. 


What might be the correct approach to test wether bounding sphere intrsect with 
any other project?
  
That depends on how coarse/precise you want the intersections to be. 
Testing bounding spheres against each other is easy, but you might still 
need an acceleration structure to avoid testing every bounding sphere 
against every other (depending on the number of objects to test you will 
have).


If you want to test a bounding sphere against a polygonal mesh then I'm 
not sure there is currently anything in OSG that will do that.


Depending on how much stuff you want to write yourself to do this with 
the classes OSG provides you might want to look at existing collision 
detection libraries.
For example, GIMPACT 
(http://gimpact.sourceforge.net/reference_html/index.html) might be of 
use for your case.


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

Re: [osg-users] Intersect.

[Maxim Gammer]

 For example, GIMPACT
GIMPACT - very slow
use BULLET physic + convex decomposition (BULLET example)

2009/8/25 Paul Melis p...@science.uva.nl

 Danny Lesnik wrote:

 Thank you for your help.
 I think I understand now what LineSegmentIntersector is doing.
 What might be the correct approach to test wether bounding sphere intrsect
 with any other project?


 That depends on how coarse/precise you want the intersections to be.
 Testing bounding spheres against each other is easy, but you might still
 need an acceleration structure to avoid testing every bounding sphere
 against every other (depending on the number of objects to test you will
 have).

 If you want to test a bounding sphere against a polygonal mesh then I'm not
 sure there is currently anything in OSG that will do that.

 Depending on how much stuff you want to write yourself to do this with the
 classes OSG provides you might want to look at existing collision detection
 libraries.
 For example, GIMPACT (
 http://gimpact.sourceforge.net/reference_html/index.html) might be of use
 for your case.

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




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

Re: [osg-users] Intersect objects

[Robert Osfield]

On Fri, Aug 15, 2008 at 9:25 AM, Victor Hurdugaci
[EMAIL PROTECTED] wrote:
 Hello everyone,
 I have two geodes and I want to intersect them in order to obtain another
 object. Something like in 3dsmax – Boolean operations.

 So I need to keep from two objects only the part that is common.

 Any way to do that?

No.  The OSG is a basically just a scene graph, its not a geometry
construction tool. I believe there are other open source projects that
are focused on what you want.

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

Re: [osg-users] Intersect objects

[Tomlinson, Gordon]

As Robert points out Boolean operation on geometry are not really the
role of a SceneGraph , although I admit it would be a nice utility
function at time


One avenue to maybe look at is GEOS (Geometry Engine Open Source)
http://trac.osgeo.org/geos/ , we use this for Boolean operations through
GDAL and OGR

It would be nice at some point to maybe have a direct OSG plug-in into
GEOS rather than GDAL/OGR route but sadly not something I have enough
cycles to work on


Gordon

__
Gordon Tomlinson
Email  : gtomlinson @ overwatch.textron.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Friday, August 15, 2008 4:56 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Intersect objects

On Fri, Aug 15, 2008 at 9:25 AM, Victor Hurdugaci
[EMAIL PROTECTED] wrote:
 Hello everyone,
 I have two geodes and I want to intersect them in order to obtain 
 another object. Something like in 3dsmax - Boolean operations.

 So I need to keep from two objects only the part that is common.

 Any way to do that?

No.  The OSG is a basically just a scene graph, its not a geometry
construction tool. I believe there are other open source projects that
are focused on what you want.

Robert.
___
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] intersect() methods in LineSegment (probably others)

[Andy Skinner]

Thanks!

Hopefully Robert can give it a look when he gets back.

thanks,
andy

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien 
Guay
Sent: Tuesday, February 12, 2008 9:21 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] intersect() methods in LineSegment (probably others)

Hi Andy,

 J-S, did you get to do any timing with my proposed use of doubles in the
 intersection code?

I did some tests last night. Full results below. The executive summary 
is this:

For 2,244,800 samples (individual ray tests),
Floats:  113.121566 seconds (original)
Doubles: 113.954178 seconds (your patch)

Difference: ~0.730655 %

Floats:  19844.138 samples / second
Doubles: 19699.146 samples / second


So with doubles, it is less than one percent slower, which I don't think 
is significant over that many samples... I did not have the time to do 
multiple tests though (because that 0.7% might even be due to some other 
activity on my machine) but I think we can safely say it's not a 
significant difference. You can quote me on that :-)

BTW, for reference, using the kdtree took 13.366302 seconds to do the 
same thing :-) See below.

Hope this helps,

J-S


Detailed results:
===
LineSegmentIntersector, float (original)
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] Checking for precomputed radiance transfer data file
data/PRT_test_scene_9b/lighting_25_400.prt:
  Not found. Computing. 0.534819 seconds. (747.917 samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt:
   Not found. Computing. (1017 vertices) 15.1999 seconds. (26763.4 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt:
   Not found. Computing. (930 vertices) 13.9724 seconds. (26624 
samples/sec)


[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt:
   Not found. Computing. (1596 vertices) 21.7206 seconds. (29391.5 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt:
   Not found. Computing. (1040 vertices) 40.901 seconds. (10170.9 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt:
   Not found. Computing. (1029 vertices) 21.3278 seconds. (19298.8 
samples/sec)

  Total time for loading transfer functions: 113.121566 seconds.
  Total loading/computing time: 113.657229 seconds.

Precalculation done, exiting.

===
LineSegmentIntersector, double (Andy Skinner's modification)
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] Checking for precomputed radiance transfer data file
data/PRT_test_scene_9b/lighting_25_400.prt:
  Not found. Computing. 0.524556 seconds. (762.55 samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt:
   Not found. Computing. (1017 vertices) 15.6853 seconds. (25935.1 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt:
   Not found. Computing. (930 vertices) 14.2079 seconds. (26182.6 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt:
   Not found. Computing. (1596 vertices) 21.8676 seconds. (29193.9 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt:
   Not found. Computing. (1040 vertices) 40.8934 seconds. (10172.8 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt:
   Not found. Computing. (1029 vertices) 21.3 seconds. (19324 
samples/sec)

  Total time for loading transfer functions: 113.954178 seconds.
  Total loading/computing time: 114.479672 seconds.

Precalculation done, exiting.

===
Adrian Egli's kdtree

Re: [osg-users] intersect() methods in LineSegment (probably others)

[Jean-Sébastien Guay]

Hi Andy,

 J-S, did you get to do any timing with my proposed use of doubles in the
 intersection code?

I did some tests last night. Full results below. The executive summary 
is this:

For 2,244,800 samples (individual ray tests),
Floats:  113.121566 seconds (original)
Doubles: 113.954178 seconds (your patch)

Difference: ~0.730655 %

Floats:  19844.138 samples / second
Doubles: 19699.146 samples / second


So with doubles, it is less than one percent slower, which I don't think 
is significant over that many samples... I did not have the time to do 
multiple tests though (because that 0.7% might even be due to some other 
activity on my machine) but I think we can safely say it's not a 
significant difference. You can quote me on that :-)

BTW, for reference, using the kdtree took 13.366302 seconds to do the 
same thing :-) See below.

Hope this helps,

J-S


Detailed results:
===
LineSegmentIntersector, float (original)
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] Checking for precomputed radiance transfer data file
data/PRT_test_scene_9b/lighting_25_400.prt:
  Not found. Computing. 0.534819 seconds. (747.917 samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt:
   Not found. Computing. (1017 vertices) 15.1999 seconds. (26763.4 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt:
   Not found. Computing. (930 vertices) 13.9724 seconds. (26624 
samples/sec)


[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt:
   Not found. Computing. (1596 vertices) 21.7206 seconds. (29391.5 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt:
   Not found. Computing. (1040 vertices) 40.901 seconds. (10170.9 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt:
   Not found. Computing. (1029 vertices) 21.3278 seconds. (19298.8 
samples/sec)

  Total time for loading transfer functions: 113.121566 seconds.
  Total loading/computing time: 113.657229 seconds.

Precalculation done, exiting.

===
LineSegmentIntersector, double (Andy Skinner's modification)
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] Checking for precomputed radiance transfer data file
data/PRT_test_scene_9b/lighting_25_400.prt:
  Not found. Computing. 0.524556 seconds. (762.55 samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall2_geode_0_25_400_DS.prt:
   Not found. Computing. (1017 vertices) 15.6853 seconds. (25935.1 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Wall1_geode_0_25_400_DS.prt:
   Not found. Computing. (930 vertices) 14.2079 seconds. (26182.6 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Floor_geode_0_25_400_DS.prt:
   Not found. Computing. (1596 vertices) 21.8676 seconds. (29193.9 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Sphere_geode_0_25_400_DS.prt:
   Not found. Computing. (1040 vertices) 40.8934 seconds. (10172.8 
samples/sec)

[DS] Checking for precomputed radiance transfer data file
 data/PRT_test_scene_9b/Cube_geode_0_25_400_DS.prt:
   Not found. Computing. (1029 vertices) 21.3 seconds. (19324 
samples/sec)

  Total time for loading transfer functions: 113.954178 seconds.
  Total loading/computing time: 114.479672 seconds.

Precalculation done, exiting.

===
Adrian Egli's kdtree
===
- Parsing command-line arguments.
  Using 5 bands (25 coefficients) and 400 samples per vertex.
  Deleting previously calculated data files to recalculate them.
- Loading model file data/PRT_test_scene_9b.ive.
- Optimizing model data/PRT_test_scene_9b.ive.

- Loading/Computing SH coefficients for lighting
[L] 

Re: [osg-users] intersect() methods in LineSegment (probably others)

[Jean-Sébastien Guay]

Hello Andy,

 J-S, did you get to do any timing with my proposed use of doubles in the
 intersection code?

Sorry, I was out of town finally this weekend. I will try it out tonight.

J-S
-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
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] intersect() methods in LineSegment (probably others)

[Andy Skinner]

J-S, did you get to do any timing with my proposed use of doubles in the
intersection code?

Thanks,
andy

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

Re: [osg-users] intersect() methods in LineSegment (probably others)

[Jean-Sébastien Guay]

Hello Andy,

 I've submitted a change to the submission list.  Please take a look and tell 
 me if and how much it affects timing.
   

Great, I'll try and check it out tonight and get back to you.

J-S

-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   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] intersect() methods in LineSegment (probably others)

[Andy Skinner]

I got the LineSegment::intersect() method to work when I converted the
vectors you get from finding the difference between the start and the
sphere center, and the difference between the start and the end, to
Vec3d.  You want the dot product to be in doubles.

In my version, I get the difference in terms of Vec3, and then convert
them to Vec3d.  The rest of the method is in doubles until setting r1
and r2.  Another approach would be to change the internal representation
of _e and _s to Vec3d, or maybe just keep _e - _s as a Vec3d so you
don't have to subtract that one each time.

So is anyone counting on this being floats for performance?  Would
anyone else welcome this calculation in doubles?  I don't mind adding
some code in our own source if other people don't want this in doubles,
but I'd have to make my own IntersectVisitor as well as my own
LineSegment, when all I really want to replace is the LineSegment.
Having an almost-but-not-quite copy of a class and having to watch the
original for updates doesn't sound like any fun.  If I could get
IntersectVisitor to use a class derived from LineSegment, with just the
changes I want, that might not be bad.

I think I'll submit a version of LineSegment, and you (Robert and the
mailing list) can tell me what you think.

andy

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy
Skinner
Sent: Tuesday, February 05, 2008 8:57 AM
To: OpenSceneGraph Users
Subject: [osg-users] intersect() methods in LineSegment (probably
others)

I'm not sure what changed (in OSG or our code), but one of our unittests
is failing on Windows as I try to upgrade our software to OSG 2.3.3.
The picking I'm doing isn't hitting anything.  It appears that the use
of floats in the LineSegment::intersect(BoundingSphere) method may be
hurting us.

I've seen mentions on this in the list archives.  Is the calculation
done in this method done in float on purpose?  If some of the
intermediate value in this calculation were done in double, would it
slow things down too much?

We're squaring some large numbers and subtracting them from each other,
and it isn't holding up for us.  I'm going to experiment with doing some
of this in double, but since it seems known that there are precision
problems in this code, I wonder if it has remained in float for a
reason.

I could try to make an example for this, but because there seems to be
an awareness of the issue, I'll raise it now.

Thoughts?

thanks
andy

___
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] intersect() methods in LineSegment (probably others)

[Jean-Sébastien Guay]

Hello Andy,

 So is anyone counting on this being floats for performance?  Would
 anyone else welcome this calculation in doubles?  

If you submit a patch, I can test it out in my Masters project which 
uses LineSegmentIntersector pretty heavily (not-quite-realtime 
raytracing :-) ) so that will tell us if there is really a performance 
difference. Off hand I can't really say, so I'd prefer to do some 
benchmarking.

 I don't mind adding
 some code in our own source if other people don't want this in doubles,
 but I'd have to make my own IntersectVisitor as well as my own
 LineSegment, when all I really want to replace is the LineSegment.
 Having an almost-but-not-quite copy of a class and having to watch the
 original for updates doesn't sound like any fun.  
   

I totally understand... It'll be a matter of the performance vs 
correctness tradeoff I guess, so as I said I can provide some answer to 
the performance side of that question and see what Robert thinks when he 
comes back.

So please, submit your changes and we'll see.

Thanks,

J-S

-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   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] intersect() methods in LineSegment (probably others)

[Adrian Egli OpenSceneGraph (3D)]

Hi Andy,

I feel open to change to double if we are working with double precision as
internal representation. Or if we have double precsion in bounding sphere.
For all care about performance, i don't be sure this change will become much
slower as it is for the moment. But of course double is not as fast as
floating point operations are. Few weeks ago i sent to the submission one
change i did in the intersection test, it make the tri-checks a little
faster, but it's not yet in the current SVN. May we could take it first, and
check the correctness, then we can do the double fix.

But if you like to change the intersection test, you should take care about
the number of triangles check: at the moment the check is done in O(n).
there is a need of kd-tree support in line intersection (real time ray
tracing data structure for ray intersection test).
i know that i still mentioned to propose some line of code, but
unfortunatelly i never get the needed time slot for doing that. if you were
interest in it, please let me know. but this change will be one of the most
important with respect to performance w.r.t. line intersection tests.

(screenshots on openscenegraph webpages)

/adegli

2008/2/6, Andy Skinner [EMAIL PROTECTED]:

 I got the LineSegment::intersect() method to work when I converted the
 vectors you get from finding the difference between the start and the
 sphere center, and the difference between the start and the end, to
 Vec3d.  You want the dot product to be in doubles.

 In my version, I get the difference in terms of Vec3, and then convert
 them to Vec3d.  The rest of the method is in doubles until setting r1
 and r2.  Another approach would be to change the internal representation
 of _e and _s to Vec3d, or maybe just keep _e - _s as a Vec3d so you
 don't have to subtract that one each time.

 So is anyone counting on this being floats for performance?  Would
 anyone else welcome this calculation in doubles?  I don't mind adding
 some code in our own source if other people don't want this in doubles,
 but I'd have to make my own IntersectVisitor as well as my own
 LineSegment, when all I really want to replace is the LineSegment.
 Having an almost-but-not-quite copy of a class and having to watch the
 original for updates doesn't sound like any fun.  If I could get
 IntersectVisitor to use a class derived from LineSegment, with just the
 changes I want, that might not be bad.

 I think I'll submit a version of LineSegment, and you (Robert and the
 mailing list) can tell me what you think.

 andy

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Andy
 Skinner
 Sent: Tuesday, February 05, 2008 8:57 AM
 To: OpenSceneGraph Users
 Subject: [osg-users] intersect() methods in LineSegment (probably
 others)

 I'm not sure what changed (in OSG or our code), but one of our unittests
 is failing on Windows as I try to upgrade our software to OSG 2.3.3.
 The picking I'm doing isn't hitting anything.  It appears that the use
 of floats in the LineSegment::intersect(BoundingSphere) method may be
 hurting us.

 I've seen mentions on this in the list archives.  Is the calculation
 done in this method done in float on purpose?  If some of the
 intermediate value in this calculation were done in double, would it
 slow things down too much?

 We're squaring some large numbers and subtracting them from each other,
 and it isn't holding up for us.  I'm going to experiment with doing some
 of this in double, but since it seems known that there are precision
 problems in this code, I wonder if it has remained in float for a
 reason.

 I could try to make an example for this, but because there seems to be
 an awareness of the issue, I'll raise it now.

 Thoughts?

 thanks
 andy

 ___
 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




-- 

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

Re: [osg-users] intersect() methods in LineSegment (probably others)

[Andy Skinner]

In your work, could you give me an idea of how often you intersect with a 
particular line segment object?  I'm trying to decide if it is worth it to keep 
a Vec3d in the class (marking whether it is valid), or keeping double versions 
of _s and _e.

thanks,

andy

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien 
Guay
Sent: Wednesday, February 06, 2008 9:52 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] intersect() methods in LineSegment (probably others)

Hello Andy,

 So is anyone counting on this being floats for performance?  Would
 anyone else welcome this calculation in doubles?  

If you submit a patch, I can test it out in my Masters project which 
uses LineSegmentIntersector pretty heavily (not-quite-realtime 
raytracing :-) ) so that will tell us if there is really a performance 
difference. Off hand I can't really say, so I'd prefer to do some 
benchmarking.

 I don't mind adding
 some code in our own source if other people don't want this in doubles,
 but I'd have to make my own IntersectVisitor as well as my own
 LineSegment, when all I really want to replace is the LineSegment.
 Having an almost-but-not-quite copy of a class and having to watch the
 original for updates doesn't sound like any fun.  
   

I totally understand... It'll be a matter of the performance vs 
correctness tradeoff I guess, so as I said I can provide some answer to 
the performance side of that question and see what Robert thinks when he 
comes back.

So please, submit your changes and we'll see.

Thanks,

J-S

-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/

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

Re: [osg-users] intersect() methods in LineSegment (probably others)

[Adrian Egli OpenSceneGraph (3D)]

Hi Andy,

If we are using drive manipulator, then we are testing many time with many
objects against a line.

/adegli

2008/2/6, Andy Skinner [EMAIL PROTECTED]:

 In your work, could you give me an idea of how often you intersect with a
 particular line segment object?  I'm trying to decide if it is worth it to
 keep a Vec3d in the class (marking whether it is valid), or keeping double
 versions of _s and _e.

 thanks,

 andy

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED] On Behalf Of Jean-Sébastien
 Guay
 Sent: Wednesday, February 06, 2008 9:52 AM
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] intersect() methods in LineSegment (probably
 others)

 Hello Andy,

  So is anyone counting on this being floats for performance?  Would
  anyone else welcome this calculation in doubles?

 If you submit a patch, I can test it out in my Masters project which
 uses LineSegmentIntersector pretty heavily (not-quite-realtime
 raytracing :-) ) so that will tell us if there is really a performance
 difference. Off hand I can't really say, so I'd prefer to do some
 benchmarking.

  I don't mind adding
  some code in our own source if other people don't want this in doubles,
  but I'd have to make my own IntersectVisitor as well as my own
  LineSegment, when all I really want to replace is the LineSegment.
  Having an almost-but-not-quite copy of a class and having to watch the
  original for updates doesn't sound like any fun.
 

 I totally understand... It'll be a matter of the performance vs
 correctness tradeoff I guess, so as I said I can provide some answer to
 the performance side of that question and see what Robert thinks when he
 comes back.

 So please, submit your changes and we'll see.

 Thanks,

 J-S

 --
 __
 Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
 http://whitestar02.webhop.org/

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




-- 

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

Re: [osg-users] intersect() methods in LineSegment (probably others)

[Jean-Sébastien Guay]

Hi Andy,

 In your work, could you give me an idea of how often you intersect with a 
 particular line segment object?  I'm trying to decide if it is worth it to 
 keep a Vec3d in the class (marking whether it is valid), or keeping double 
 versions of _s and _e.
   

In general terms, my program will do n^2 intersections from each vertex 
in directions around a sphere, where n=20 to 100 (so 400 to 10,000 
intersections per vertex). And right now, I'm working with scenes which 
have roughly 5,000 to 100,000 vertices. So say for the simplest scene at 
n=20, that would be 2 million intersection tests. And in terms of time, 
I'll take what I can get, but with Adrian Egli's kdtree I'm currently 
getting about 20 seconds (IIRC) for that, so that's about 100,000 
intersections per second. With the LineSegmentIntersector, I was getting 
about 10,000 to 20,000 intersections per second.

But I don't keep the line segment objects since none of my tests are 
have the same start _and_ end values... I guess I could precompute them 
and store them and then just use them each time, but since my goal is to 
do this for dynamic scenes, it would be one more thing to recalculate if 
something changes...

J-S

-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   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] intersect() methods in LineSegment (probably others)

[Adrian Egli OpenSceneGraph (3D)]

:-) only the first version of my kd.tree. latest i still extermly slow with
about 700K-800K intersection test per second. there are latest kd-Tree ray
check with more than ++ 6M rays per second. www.ompf.org :-)

so if we will have such a datastructure, we can do lot special effects, like
global illumination, high quality shadows, reflection , ... :-)



2008/2/6, Jean-Sébastien Guay [EMAIL PROTECTED]:

 Hi Andy,

  In your work, could you give me an idea of how often you intersect with
 a particular line segment object?  I'm trying to decide if it is worth it to
 keep a Vec3d in the class (marking whether it is valid), or keeping double
 versions of _s and _e.
 

 In general terms, my program will do n^2 intersections from each vertex
 in directions around a sphere, where n=20 to 100 (so 400 to 10,000
 intersections per vertex). And right now, I'm working with scenes which
 have roughly 5,000 to 100,000 vertices. So say for the simplest scene at
 n=20, that would be 2 million intersection tests. And in terms of time,
 I'll take what I can get, but with Adrian Egli's kdtree I'm currently
 getting about 20 seconds (IIRC) for that, so that's about 100,000
 intersections per second. With the LineSegmentIntersector, I was getting
 about 10,000 to 20,000 intersections per second.

 But I don't keep the line segment objects since none of my tests are
 have the same start _and_ end values... I guess I could precompute them
 and store them and then just use them each time, but since my goal is to
 do this for dynamic scenes, it would be one more thing to recalculate if
 something changes...

 J-S

 --
 __
 Jean-Sebastien Guay[EMAIL PROTECTED]
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




-- 

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

Re: [osg-users] intersect() methods in LineSegment (probably others)

[Jean-Sébastien Guay]

Hello Adrian,

 :-) only the first version of my kd.tree. latest i still extermly slow 
 with about 700K-800K intersection test per second. there are latest 
 kd-Tree ray check with more than ++ 6M rays per second. www.ompf.org 
 http://www.ompf.org :-)

Don't take it personally, I didn't mean it's slow at 100k intersections 
per second! Remember each application will be different, so you cannot 
compare 100k in my program to 700-800k in yours. My program probably 
does more processing between intersection tests than yours, since it 
traces in a sphere at each vertex and then stores that as vertex 
attributes in the Spherical Harmonics basis... Your program is just 
raytracing from the viewpoint and displaying that, which is simpler...

And I recently integrated the last version of your kdtree in my 
application, and it works well... If you have a newer one, you can send 
it to me if you want... :-)

J-S

-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   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] intersect() methods in LineSegment (probably others)

[Adrian Egli OpenSceneGraph (3D)]

:-)

2008/2/6, Jean-Sébastien Guay [EMAIL PROTECTED]:

 Hello Adrian,

  :-) only the first version of my kd.tree. latest i still extermly slow
  with about 700K-800K intersection test per second. there are latest
  kd-Tree ray check with more than ++ 6M rays per second. www.ompf.org
  http://www.ompf.org :-)

 Don't take it personally, I didn't mean it's slow at 100k intersections
 per second! Remember each application will be different, so you cannot
 compare 100k in my program to 700-800k in yours. My program probably
 does more processing between intersection tests than yours, since it
 traces in a sphere at each vertex and then stores that as vertex
 attributes in the Spherical Harmonics basis... Your program is just
 raytracing from the viewpoint and displaying that, which is simpler...

 And I recently integrated the last version of your kdtree in my
 application, and it works well... If you have a newer one, you can send
 it to me if you want... :-)

 J-S

 --
 __
 Jean-Sebastien Guay[EMAIL PROTECTED]
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




-- 

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

Re: [osg-users] intersect() methods in LineSegment (probably others)

[Andy Skinner]

I've submitted a change to the submission list.  Please take a look and tell me 
if and how much it affects timing.

thanks
andy

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien 
Guay
Sent: Wednesday, February 06, 2008 11:11 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] intersect() methods in LineSegment (probably others)

Hello Adrian,

 :-) only the first version of my kd.tree. latest i still extermly slow 
 with about 700K-800K intersection test per second. there are latest 
 kd-Tree ray check with more than ++ 6M rays per second. www.ompf.org 
 http://www.ompf.org :-)

Don't take it personally, I didn't mean it's slow at 100k intersections 
per second! Remember each application will be different, so you cannot 
compare 100k in my program to 700-800k in yours. My program probably 
does more processing between intersection tests than yours, since it 
traces in a sphere at each vertex and then stores that as vertex 
attributes in the Spherical Harmonics basis... Your program is just 
raytracing from the viewpoint and displaying that, which is simpler...

And I recently integrated the last version of your kdtree in my 
application, and it works well... If you have a newer one, you can send 
it to me if you want... :-)

J-S

-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/

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