Geometry.GetClosestLocations() and related operate in the local coordinate space of the searched object. If that object has scaling at values other than (1,1,1), then the radius will be affected by the scale values. It's often recommended to provide a transformation to the GetClosestLocations() method to indicate the coordinate space you wish to operate within. Generally, it's the identity coordinate space (meaning, no conversions).
To make life simple, convert your starting position to the local coordinate space of the object you plan to search. Set up an acceleration cache, then conduct your search. The returned PointLocator objects will be described in the local coordinate space of the searched object. When the search has completed, you can call the necessary Geometry methods to evaluate the PointLocator objects. After those results are obtained, convert to whatever coordinate space you need. If you get strange results, try freezing the scaling of your geometry before searching. Matt Date: Mon, 16 Oct 2017 09:17:42 +0300 From: Andrew Prostrelov <[email protected]> Subject: XSI Size difference issues. Pointlocators etc. To: "Official Softimage Users Mailing List. https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum_-23-21forum_xsi-5Flist&d=DwIFAw&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=S-BPUlaF8mjY1U2Z9Le1yO3A764oWQrbWlc31D0W0-k&s=AgNAyJyh5DGBYWCicbgHz95yVmohl-6O3xul3IZmCjg&e="; Today's question is about size difference. When we get pointlocators via GetClosestLocationsWithinRadius() or other similar methods we alwayse got size problems. When our object have dence geometry and vertexes lies close to each other GetClosestLocationsWithinRadius() method pick vertexes to soon. Even if we provide it with radius 0.01 on a dence mesh it may pick verts from center of polygon. In this case user would try zoom in to get more precise result, but zoom values does not affect GetClosestLocationsWithinRadius() method. Only if he scale up object he would get the result he want. The good example of how it should work is AddEdgeTool. Even if you have dense mesh this tool works according your current zoom value. If you zoom closer to geo it became more precise. So to mimic this accuracy change i try different approaches: 01. GetClosestLocationsWithinRadius() , filter by radius value. 02. GetRaycastIntersections() , get first and second closest verts , reconstruct CLine representation of closest edge, get vert by parameter value filtering. 03. GetRaycastIntersections() , get first and second closest verts , convert to screen space , reconstruct CLine representation of closest edge, get vert by parameter value filtering. 04. GetRaycastIntersections() , get first closest vert, get vector length from current intersection with geo and closest vert, filter by vector length value. 05. GetRaycastIntersections() , get first closest vert, convert to screen space , get vector length from current intersection with geo and closest vert, filter by vector length value. All this approaches have the same size problem. I assume that for all this approaches the filter value should be calculated via screen space coordinates. This way we got current component size as it was drawn to screen, in other words we preserve zoom value. But in this case all filtering values also changes and in result we still doesn't calculate zoomed components right. Here is the code: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dropbox.com_s_udfor0ts81yg9l6_PickVertes.cpp-3Fdl-3D0&d=DwIBaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=Ud_aoL80QOH6qlpe0_7aqJ03UeoOmjVPd-tGAX2za4k&s=6PmiSNJjP-LIAtse1Wn0ECnHpJDBsZuYmMjEDeLwaGA&e= ------ Softimage Mailing List. To unsubscribe, send a mail to [email protected] with "unsubscribe" in the subject, and reply to confirm.
