View Full Version : Shortest Edge Path a hoax?
speC 02 February 2009, 07:10 PM Hi!
Just started to melscript on my macbook (no not pro...).I know that
sounds funny, but anyway ;)
Am I wrong thinking that the algorithm for rendering the shortest path between
two given vertices is not working properly?
Wanna try it? Make a sphere with let's say a radius of 25 units.
14/14 subdiv....
name it mySphere
then write
polySelect sep 2 42 mySphere;
funny?
anyone who knows this problem?


claydough
02 February 2009, 09:23 PM
A picture would be helpful here or an explanation as to what is "funny".
otherwise is this the result u got?:
http://farm4.static.flickr.com/3658/3304795460_81d3d312aa_o.jpg
if so... Is it edge 0 instead of edge 183 that u assume is correct?
I guess that would depend on the logic:
maya in yer example is just getting the edge that is closer to the target and building from that:
using yer radius and divisions...
mag distance of edge 183 to vrt 42 = 14.9
mag distance of edge 0 to vrt 42 = 16.79
if ( 14.9 < 16.79 ) then edge 183 iz the closest to the target.
To do what u want would take at least two passes: Begin Loop >
( calculate for the two shortest paths as above)
and then calculate the next distance for both paths in a second pass.
( for both edge path candidates find the next closest edges to each.
if they both land on the same vrt. add up each path's total mag so far, and
the shortest mag total so far is the winner. Otherwise the final edge closest to the target is
the winner of the second pass )
begin next "two pass" loop etc... till target
Does that cover it?
speC
02 February 2009, 04:49 PM
Sorry...u are right. I should have added a picture to illsutrate my issue.
And thanks a lot for your answer!
this is the result i get.
I assumed that a command that says "SHORTEST path" means
shortest in the sense that it refers to a DISTANCE between two points.
do i get you right that you think maya does not calculate the shortest
distance?
that is actually my impression and conclusion!
the calculated rute from vtx[2] is
vtx[2]  vtx[1]  vtx[15]  vtx[14]
and not
vtx[2]  vtx[1]  vtx[0]  vtx[14]
from a geometrical point of view the second answer should
be the right one(...at least I guess so...)
thnx!
spec
claydough
02 February 2009, 06:17 PM
Like before. no and yes
first, No: ( distance centric )
vrt 42 is the target endpoint so we use it to measure each candidate's magnitude from. Like before, lets assume that vrt 1 is obvious. So the competition is now betweenvrt 15 and vrt 0:path a: vrt 15 to target 42 distance: 12.87559902 ( winner )
path b: vrt 0 to target 42 distance: 16.51395174
secondly, YES!: ( shortest path length centric )Now let's assume that from both paths above for both of these paths vrt 14 is the obvious conclusion. In which case we can add up the length of each paths segments so far ( from obvious vrt 1 to each divergent vrts back to the ending obvious vrt 14 )
and compare:
path a: (vrt 1 to 15 = distance 5.598223563 )
+
(vrt 15 to 14 = distance 4.827410129 )
=
( paths total magnitude so far: 10.425634 )
path b: (vrt 1 to 0= distance 2.475778257 )
+
(vrt 0 to 14 = distance 5.598222876 )
=
( paths total magnitude so far: 8.074001 ) Winner!
http://farm4.static.flickr.com/3574/3306358899_ccfc4b2afd_o.jpg
Knowing this ( "consecutively" measuring each candiddate for closest distance,
doesn't always yield the shortest path ),
How do we get a true( or at least truer ) shortest path?
Look over again the two pass method I outlined above..
That sounds like a fun project to learn mel script on the macbook! I wish I was u!:)
Hope that helps.
.
speC
02 February 2009, 09:01 PM
I think i get it!
Thanks for your effort!
keep it up
spec
CGTalk Moderation
02 February 2009, 09:01 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.