#LW Help
24 messages in this thread
I need to be able to convert LW 3.1 keyframe motion files that consist of keys
spaced (say 10 frames apart) into the exact same motion but with each frame
being keyed. It's not as easy as it sounds!
I have tried going back and creating new keyframes between the original ones
but this destroys the splines. It has the effect of making the motion linear.
Has any one come up against this and solved it? Is there a reliable Modeler
Macro for this? This is fairly important to a project, any help would be
greatly appreciated.
Jim Roof
Just curious, why would you want every frame key-framed?
GT
I just got Sparks and in order to use certain functions of this particle system
you must provide motion files with every frame keyed. I think its going to be
pretty cool once I get the hang of it.
Jim
You mean YOU have to generate a motion file by hand keyframed every
frame!? Shoudn't the program do that for you? Assuming you do, why don't
you generate one, save it as a motion file, and then just load it up when
you need one.
GT
Greg, The problem isn't in the concept nor in the tedium of creating the motion
file. The problem is in the actual working out of converting a nice spline
curve into a frame by frame motion path. My question is simply this: Is there
a reliable method for creating a motion file that has all frames keyed from one
that does not. The attempts that seem at first glance to be simple prove
false. As I mentioned in an earlier message, when you attempt to fill in the
gaps between the already-placed key frames you "squeeze" out the roundness of
the splines. This is what I am trying to overcome. Sparks needs this
information for the way that it processes its files.
I can't think of a way to do that. You mimght want to ask John Gross;
that's what I do anyway…..
GT
(course it's easy because he's in the next room…)
I think LW automatically makes adjacent frames linear, you may try
doubling the length of the animation(scaling), hand-making keys at every
other frame, then just rendering every other frame. Sparks should be able
to do this, if it needs it. The splines are a variant of Kochanek-Bartels
splines which one could probably find in some siggraph paper.
Why….????? What is the purpose of key-framming every frame??
There is normally a way of getting around having to do that.
Just curious (VERY!!),
TO get out the data for accurate position plots/data to feed a trajectory
analysis or some such? I always wanted a way to be able to get a motion
versus time data set for any object, light, camera in a LW anim and to be
able to set same using a formula (procedural path) instead of having to
key it. I think DMM is based on this principle.
wmc – via Autopilot!
I believe this is how DMM makes its paths. Essentially figures every
frame pos/rot and keys every frame.
The only way I can thnk of to do it is to select the object, go into
layout, advance the anim 1 frame at a time and hit create key, selected
object and take the default (current) frame mumber. In fact, if LW
supports an ARexx command to advance the frame, and one to set the key
frame for a selected object you could gin a macro to do it. Then save the
objects motion to a motion file.
wmc – via Autopilot!
Wayne,
That was my first guess. The problem with it is that the splines flatten out as
you create a new key closer to the next "original" keyframe. Its kind of like
squeezing toothpaste out of a tube, only your squeezing the spline curve into a
more linear shape. My last try was to do it this way: Create keys at 0,15,30;
go to frames 7,22 and create keys; then to 4,11,19,26 to create keys; then
fill in the rest of the holes. This ends up fairly cloes to the original
curve. The original key at 15 is a little "out of shape" compared to the
original spline but it is ok.
BTW, I'm doing this because Sparks needs motion files that have every frame as
a keyframe.
Jim Roof
Seems like if SParks needs every frame as a key, they should provide a
way to work the LW spline path math backward to create them in an "import
motion" operation, don't you think?
wmc – via Autopilot!
That would be deluxe. Unfortuneately that's not the way it works now.
Jim
Wayne,
I realize you probably don't want to hear this now that you've bought
Sparks, but if you need particle animation without keyframing EVERY frame
perhaps you should look at movepf.lha. With this program you set up your
particles with 2 keyframes and a few requesters. It's shareware and
available on Compuserve. If Sparks doesn't do everything that this
shareware program does and more I'd be pretty surprised and would start
pestering the makers of Sparks for an upgrade. For $100 is should be at
least as good as a shareware program right?
Jeff H…
It's actually pretty powerful. What I am trying to do is something like making
a rotating lawn sprinkler with all of the inherited motions coming from the
rotations of the arms. Sparks does a lot of things but the motion files used
for inherited motion must be supplied key-by-key. I have looked at the file
that you suggested and it does very little compared to Sparks.
Jim
Have you tried saving the the 'path to motion' macro in the modeler?
In your case, it sounds like you'd want to create a circle in Modeler with
the number of points=the number of frames for one rotation of the
sprinkler head. Then use the 'path to motion' macro to save the circular
object out as a motion path.
I just tried it, and it seemed to work.
BTW, I just started playing with SPARKS last night. Man, it takes along
time to calculate each frame!
Keep On Toastin'
Erik Flom
Erik: The path-to-motion works unless I go over 20 points or so. it then makes
real neat string art! If your version does not do this would you UL it? Mine
may be an early defective version.
I get pretty fast SPARKS frametimes. But I'm not using over 100 objects. I did
one with 1500 and it was taking about 5 minutes per frame. then I realized
that the scene would probably crash with that many objects.
let me know how it cames along.
Jim Roof
That's an interesting limitation you mention about SPARKS. (One of _many_
it would appear. :^) Have you considered trying just do a 1/4 rotation of
the rotation, and then clone that 4 times for each 'spoke' of the
sprinkler? (or however many 'spokes' you want.)
I've actually been trying to get some 'flocking' particles to do what I
want….To no avail. Using the default value for a gravity well sent the
flock flying in every direction (maybe because it passed through the
center of the well? :^) I've tried other values, but now _none_ of the
'flocking' objects are moving as the group passes by the gravity well.
Oh well…..
Have you noticed how _BAD_ the manual is?!?!! They credit 2 people for
writing this flimsy thing that's chock full of grammatical errors, poor
spelling, and bass-ackwards logic.
The program itself is pretty bad too. It's the little things like: when
you bring up the 'gui' editor for the 'flock' controls and try to exit by
clicking on the close box (there's no 'OK' button, that'd be too complex),
it doesn't close the window until you deactivate the 'gui' button in the
'flock' dialog box! – Hitting return will 'tab' through all active fields
in the main window, except of course for 2 fields (maybe they're 'special'
:^) – It doesn't work with the ASL File Requester replacement I use,
etc…….
It's typical of Amiga software: really cool concept, some nice features,
and a piss-poor user interface……
Oh well, I figured out why each frame was taking so long…..it was
updating the display window in LW each time. When I had a file rewuester
up in LW, SPARKS ran much faster.
Thanks for your feedback. Good luck with your endeavors.
Keep On Toastin'
Erik Flom
I have gotten flocking to work but it takes scaling back the effects numbers as
well as gravity. Also, if you are using the path to motion script you might
check out your final path for accuracy. Gotta go.
Jim
Thanks. I had finally noticed some problems in the path I had created.
FYI, I gave up on the flocking, and tried to create a sprinkler
stream. I got the stream to shoot out while traveling in a 30 frame
circular orbit, but I couldn't get the 'nozzle' to align to the path!
So, even though it's traveling in a circular path, the 'nozzle' is
always spewing parts out directly to the right (the default 0 degree
position for the nozzle)!
I actually called them about it today. The guy took my name and said
they'd get back to me when they figured out a solution. (There seems
to be no solution currently – though an 'align to path' option would
solve all of our problems.)
Erik,
There is a "scene tag" function that is used to place addendums to each object
after Sparks writes the scene file. This Tag can be used to parent every
object to a null, load bones and bone motion files, etc. I would check and see
if the "align to path" function is turned on in the object section. My guess is
that if you could align each object to the path then this might solve the
problem. Also, make sure that "inherit motion" is on, this way you get a
feeling of imparted velocity from the motion of the particle spout.
I am actually fairly pleased with what I can do with this. You're right, the
doc is pretty bad but experimentation will work (if you have a fast machine).
I would give the documentation a "7" on the Real3D V.2 scale of hopelessness.
Jim
There was a bug in modeler which caused it to spit out points in random
order to arexx. This caused problems for path-to-motion which were fixed
(allegedly) in v3.1 modeler. I think there are also macros from making
motions from formulas .. like x=r*cos(t), y=-r*sin(t)…
Allegedly fixed, but I still have a problem with 'Path To Motion'
randomly ordering the points. I got around it by creating a 'curve'
instead of a polygon – it worked then, but the length was about twice
what it should have been (seemed related to the number I entered in
the 'frame count' window)
Jim,
I can see where doing a rotating lawn sprinkler would be difficult.
Perhaps I misunderstood what the problem is. As I picture it your
sprinkler will consist of 2 particle sources. They will rotate around a
pivot point half way between them and will both face away from the pivot
point toward the outside of the circle. You need to make a keyframe
describing the position and heading of each particle source for each frame
of the anim. Sparks will then generate the particle streams based on these
keyframes. Is this pretty much what you're trying to do?
If so, why don't you e-mail me a scene file you've done by hand. (About 30
frames will do.) A long time ago I wrote a program to generate paths for
VistaPro that had some simple motions built in. It may be possible for me
to modify it to write LightWave scenes. If it looks like a lot of work
perhaps I'll upload the source code. It's written in Cando but it will
easily translate to basic (that's what I designed it in) and should be
simple enough to convert to ARexx.
Jeff H…