<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000'><br><br><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><style>p { margin: 0; }</style><div id="DWT452" style="font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000">so the entities come out ordered according to the distance only if the max_ints is set.<br>(only the first max_ints are returned, with the closest distance from the source of the ray)<br>The bug is fixed now.<br><br>So do you think that we should order them in all cases, for consistency?<br><br></div></blockquote>then we should order them also for OBB tree. Do we have other trees with ray intersecting capability? <br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000">That makes sense.<br><br>Iulian<br><br><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">I do think the entries should be ordered at the end of the call, after tree traversal is done, though.<br><br>- tim<br><br>On 07/24/2013 04:35 PM, Iulian Grindeanu wrote:<br>> the bug is around that logic, that I try to understand.<br>> It seems that the "ray_end" is reset, which is why some points are missed.<br>><br>> I didn't write that logic, maybe Tim or Paul know who did.<br>><br>> I don't think we should guarantee the order;<br>> The user should order it if needed;<br>><br>> The "leafs" of the tree can come in any order, and we should not try to order it there.<br>><br>> Iulian<br>><br>> ------------------------------------------------------------------------------------------------------------------------<br>><br>><br>> Hi iulian<br>><br>> Thanks for that, additional side question. When you specify the maximum number of intersection to return, the list<br>> is ordered in distance from the start point, when you specify 0, the list is unordered. Should we not expect<br>> consistent behavior in both cases?<br>><br>> Thanks<br>><br>> Andy<br>><br>><br>><br>> Sent from my Samsung Galaxy Note™, an AT&T LTE smartphone<br>><br>> Iulian Grindeanu <iulian@mcs.anl.gov> wrote:<br>> it works fine if you do not specify the limit 100 for number of intersections.<br>> If you leave it 0, it is fine;<br>> (so call with kdtree->ray_intersect_triangles( kdtree_root, 1.0e-6,<br>> dir, box_center,<br>> intersection_facets<br>> , intersections);<br>><br>> I am still looking, but I think I am close :)<br>><br>> ------------------------------------------------------------------------------------------------------------------------<br>><br>> OK, obb tree works fine with the same model, default setting for everything<br>> (you do no have to put tetras in the build, only the faces)<br>><br>> So there might be an issue with the kdtree.<br>> I will look at it.<br>><br>> Iulian<br>> ------------------------------------------------------------------------------------------------------------------------<br>><br>> The problem is on the secondrun, moving the starting point in the to y=4, then we get no intersections<br>> beyond 48.5.<br>> On 07/24/2013 10:50 AM, Iulian Grindeanu wrote:<br>><br>> I see no error<br>> Your fifth slab is at about 49.5;<br>> (first at 9.5, ..., fifth at 49.5)<br>><br>> Iulian<br>><br>> ------------------------------------------------------------------------------------------------------------------------<br>><br>> I think I may have found a bug in kdtree.<br>><br>> My test problem consists of a tet mesh that is composed of some 4000<br>> tets. The mesh looks like that in mesh.png, a ray starts at position<br>> (1,0,0) and fires along (1,0,0) and we get the following results back<br>> from my test program swp.cpp<br>><br>> Compile the minimum working example as<br>><br>> g++ swp.cpp -I/<moab include dir> -L<moab lib dir> -lMOAB<br>><br>><br>> This is as expected,<br>><br>> # of intersections : 20<br>> intersection distances are on 8.5 8.74072 9.25928 9.5 18.5 18.7407<br>> 19.2593 19.5 28.5 28.7407 29.2593 29.5 38.5 38.7407 39.2593 39.5 48.5<br>> 48.7407 49.2593 49.5 of ray length 900<br>><br>> 8.5 9.5 18.5 19.5 etc are the boundaries of the faces of the mesh.<br>><br>> However, if we recompile and change the starting position to (1,4,0) we get<br>><br>> # of intersections : 17<br>> intersection distances are on 8.5 8.63513 9.06064 9.5 18.5 18.6351<br>> 19.0606 19.5 28.5 28.6351 29.0606 29.5 38.5 38.6351 39.0606 39.5 48.5 of<br>> ray length 900<br>><br>> As far this ray is concerned there is no mesh in the 5th slab.<br>><br>> What have I done wrong?<br>><br>> Thanks<br>><br>> Andy<br>><br>><br>><br>><br>><br>><br><br>-- <br>================================================================<br>"You will keep in perfect peace him whose mind is<br> steadfast, because he trusts in you." Isaiah 26:3<br><br> Tim Tautges Argonne National Laboratory<br> (tautges@mcs.anl.gov) (telecommuting from UW-Madison)<br> phone (gvoice): (608) 354-1459 1500 Engineering Dr.<br> fax: (608) 263-4499 Madison, WI 53706<br><br></blockquote><br></div></blockquote><br></div></body></html>