Subject:
|
Re: My humble opinion about LDraw animation
|
Newsgroups:
|
lugnet.off-topic.geek
|
Date:
|
Mon, 29 Aug 2005 12:38:06 GMT
|
Viewed:
|
5414 times
|
| |
|
|
> First thing I should point out on this thread is that I *do* have
> experience developing tool for professional animation software,
> professional CAD software with animation and simulation systems, and I
> have also been a game coder to boot.
>
> 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.
ALthough I have no experience in this area, I have to completely agree with you
here. If I wanted to make an animated film, the last thing I would want to do is
script the whole thing. Maybe it was fine for games designers in days of CGA and
2D but now it would be too slow for all but the most dedicated.
> Putting scriptable programming languages in is only okay if you want
> to develop something only developers will use. If only programmers
> can represent anything decent, then this format will be dismissed and
> fall by the wayside as non-techies steer well clear. In Damiens last
> but one paragraph, the majority of Lego builders are immediately
> excluded.
I'm guessing that most animation programs convert the animators behaviour to a
script first and then process the script. Is this correct?
> We need a format that is accessible to everybody, and easy to use and
> build GUIs for (someone has to code them). We also need an
> intermediate format to save down the high level definition of an
> animation - so it is easy to edit and change. Saving down a complex
> script, or directly to a POV script may eliminate the ability to load
> it back into the GUI/manipulation tool and make high level changes to
> it. It should not be necessary for a non-techie potential Lego
> animator to understand how to refactor POV code, or OCaml code, or any
> other text based language for that matter.
Could you give some details of the layers of software needed to proccess an
animation? My guess would be the GUI outputs a script, the script processor
outputs the frames, and the renderer renders those frames.
> I agree with Tim on using an XML format - which was actually what I
> was alluding to with my post. I do not like extending LDraw with
> comments either, that is merely a hack not a solution. The XML format
> still also allows people to break out into embedded POV code if they
> are so inclined. That also means advanced GUIs may be able to embed
> POV code themselves for advanced tricks.
I too considered the meta-command option but decided against it. I'd be
interested in trying to hash out an XML schema for this process. If one was made
properly it could also deal with a connection system as some sort of connection
proccessing is neccesary for animation.
I look forward to hearing more from you.
Tim
PS. rethreaded to .off-topic.geek where it really belongs
|
|
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
|
|
|
|
