| |
On 30/08/05, James Reynolds <james@magnusviri.com> wrote:
> > Usability was a key issue - coders are coders, and designers/animator
> > rarely want to dive in to the low-level guts of a system. Those
> > wanting to animate here - should not have to either. If they want to
> > do advanced animations - then yes they do want to understand paths and
> > a little about splines, but they also be able to place a part at point
> > A in a gui, then go to the next keyframe and place it at point B - and
> > the software be able to handle something simple enough to interpolate
> > between those two keyframes. That should not require any scripting on
> > a users part, or a description language - it should be just point and
> > click.
>
> How are keyframes internally structured and saved to disk? Are they
> arrays, hashes, and how is the interpolation between keyframes
> usually handled? I haven't had time to research it myself, and I'm
> not sure I would even be able to find the answer anyway. I'm very
> interested in learning because POV-Ray doesn't support keyframes and
> if I could just write a simple script to parse an array/hash that
> would probably make what I do easier on me.
>
> James
First I should apologise if I sounded harsh - I have spent the last
few months of my day-job dealing with a nightmare UI built by other
coders with absolutely no end-user consultation. So I recognised
similar patterns and had already gotten the hump.
I am not trying to belittle peoples ideas, but prevent mistakes I have
seen made being made again, especially with something like this. I
want to make it clear that I would be extremely keen to see a Lego
animation format, and to contribute to and use it.
Right - now to James' question:
To animate, you should probably use paths. Consider the format as
objects, which are stored as XML. For the intial scene, the LDraw
parts (LDR files, or an MPD file and specific part) would be
referenced and given object IDs in the top level of the file. The
parts object would also include enough information to optionally
override the default origin or orientation - which may make animating
some components easier. The paths would be a collection of line
segment objects which may be lines, arcs, splines/b-splines, and for
the sake of interpolation, should be represented internally in
parametric terms. Each part can then be assigned to follow a path.
The UI would create a simpler path when an object was dragged between
keyframes, but the user would be able to specify complicated ones by
building the paths then assigning objects to follow them.
A simpler graph would be used to represent each axis of rotation -
which could be viewed as a graph, or the object simply rotated in the
UI at certain keyframes. Rotations can get complicated - most 3D
people are aware of gimbal lock, and internally they maybe better
represented using quarternions as opposed to simpler euler matrices.
These graphs could quite happily use objects similar to paths, but
constrained to two dimensions. The graphs might also be used to
represent other varying data in the system - an example I can think of
might be lighting conditions if you want light intensities to change.
Keyframes would then be created as objects to which nodes along the
paths or graphs may be assigned. The nodes themselves are a collection
of objects inside the path container objects. The actual keyframe
objects would store the timecodes, and once read into an API, probably
have backrefs to the nodes that are assigned to it.
All of this complication should be hidden from the user, with an
interface with which they simply draw the segments, and constrain
them. The graphs would be accessible as graphs, as well as specific UI
widgets for their use (like a volume slider drawn beside a light, or a
cone for a cameras FOV. The camera would just be considered a part
along the others - so it can be manipulated in the same way. This
would mean that an editor app could visualise the camera tracking a
path from a fixed view during editing.
I am sure I could think of more given time - but this would be a start.
OrionRobots
--
http://orionrobots.co.uk - Build Robots
|
|
Message has 1 Reply:
Message is in Reply To:
61 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
