Re: [osg-users] intersect() methods in LineSegment (probably others)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
:-) 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)
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)
:-) 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)
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
[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.org