When I execute the following script I get strange results....the spacecraft NEP is supposed to travel in a circular orbit....it does for most of the orbit but during part of the orbit I get a high amplitude sin wave effect. This is part of a nuclear powered mission to the moons of Jupiter. You can substitute a sphere for NEP.
The time and space multipliers here shrink the time and space demensions down to Maya's liking. The for loop skips lines of data to get the number of points down.....any ideas on why this scipt executes so slow....my actual data files are hundreds of times as large.
Re: Check this out by Steve on Oct 15, 2002 at 9:50:36 pm
Rob, I copied your data and was able to duplicate your results (oscillating discrepancy, usually near the negative X axis).
After poking around for a little while, I think I have the answer, if not the solution, to your problem.
The culprit seems to be the 'SetKeyPath' command. As you know, what it does is add spacetime markers (xyzt) to an existing path, or create a new path if the selected object has none. The problem arises due to the fact that by default, it will create a NURBS curve of degree 3 and then try to fit that as closely as possible to any new points, yanking CVs around as necessary to make things fit.
Incidentally, have you ever watched Maya create the curve? --Setting my Front camera to an Orthographic Width of 1500 allowed me to watch the process unfold and that's what first tipped me off about what's happening.
Your data has minor offsets from a perfect circle, I suppose... either that or rounding errors introduced as Maya processes your data creep in, or something of the sort. The upshot is that, as Maya continues to try to add points to your motion path, a feedback loop gets set up whereby the curve starts to swing wildly back and forth as it tries to match up precisely with all the points.
Think about a driver who loses control and tries to straighten the vehicle out, only to overcorrect and swerve the other way... this repeats and if the variables are just right, the amplitude increases. Finally, the curve is swinging so wildly about the circle that Maya is unable to connect it to the actual markers (your data points), so it is forced to move those data points to the closest place on the curve. This is evidenced by the fact that the 'print $time $line $f1 $f2 $f3' output is correct (ie. it describes points on the circular orbit), but differs from the actual locations of the corresponding markers.
Here are a couple of directions that you might explore to find solutions.
First of all, I noticed that if I run your script, then run it again, the curve seems to 'fix' itself. Apparently the conditions for the feedback loop only exist when there's no curve ahead of the current point. So you could run the script twice and let it iron out its own wrinkles. Unfortunately, this is very slow to do. (Oh, and speaking of speed... I noticed that by default, the position markers on the path are left visible, and this really hammers interactivity. Getting the script to run faster might involve keeping those from showing up, or hiding them as soon as they do. For example, adding the line 'hideShow -posMarker -hide;' to hide all markers after evey SetKeyPath cut my processing time in half. But that seems a sloppy way of doing it; I'm sure there's something better. Also, the effectiveness of that might be vidcard dependent.)
Second of all, you could make the path linear instead of degree 3. This way there is no interpolation between points, so no feedback loop. Plus calculation is much faster. Of course, the nature of your project might mean that this level of detail is not sufficient. I don't know if there's a solution to this; perhaps you could rebuild the curve to degree 3 afterwards? I don't know what this would do to the position/precision of the markers. If you want to try this approach, what you have to do is manually create a linear curve and attach the NEP object to that as a motion path BEFORE you run your script. Then the script will append points to the linear curve and all will be well... if somewhat faceted.
Re: Check this out by Steve on Oct 16, 2002 at 7:27:07 pm
I don't have experience working with large arrays. I suspect it depends on the machine; give it a try. If your computer doesn't choke, then it will likely be faster to read all the data in at once than to keep going back to read lines which will be thrown away.
I think you're right about the SetKeyPath command not having any flags, but maybe tech support can shed more light on it. If you could flag it to create a linear curve, you'd be out of the woods! But failing that...
You don't want to 'set keyframes to linear;' you want to attach the moving object to a linear curve before running your script. That way, when the script then invoke the SetKeyPath tool, it simply adds points to the curve (which is already linear), rather than creating its own degree 3 curve--which is what was causing the problem.
What I recommend is to just use the CV curve tool; use the options box to specify that you want to create a linear curve. Then click a couple of points anywhere in the scene--location doesn't matter. Hit enter to make the curve, then select it and your NEP object and go Animate -> Paths -> Attach to Path and open the options box for that command. Select 'start and end' and specify negative times for the start and the end, say -2 and -1. This will prevent these marker points from interfering with your real data points, which you will subsequently add by running your script.
Make sense? --Drop me a line if I've failed to make something clear.
Re: Check this out by thomas briggs on Oct 15, 2002 at 9:56:36 pm
Why don't you read the file into an array all at once and then parcel out the data to make your paths. I do this routinely when creating paths from particles. I have made arrays of 1000000x5 and filled them with particle data. I have not gone bigger but believe I could go many times larger without gagging my machine.