| |
In lugnet.cad, danny staple <orionrobots@gmail.com> wrote:
>
> It appears from this discussion that methods already exist, its just
> that they are not particularly easy to use or accessible.
>
> Whatever solution we choose, we need to think about usability. I am a
> developer, and even I dont like having pull things through 5 or 6
> different command line programs just to get something done.
>
> So whatever method, additional files formats, using POV or whatever, a
> single API library could be built, and then incorporated into existing
> UI's so non-developers can use it. If you still want a command line
> app, then that could also be built around the same API
Agreed.
> (there might be
> some developer types who want to use makefiles to build animations).
Ewe!!! I'll just throw in here that doing animations from text files is
possible. But it is a nightmare once you want anything slightly complicated. I
re-rendered the start and end keyframes in the PCS Dogfight animation so many
times, I practically have the pixels burned into my memory. A GUI app would be
very very very good to eliminate this step. (Setting up a scene with a text
file requires a lot of imagination, and often the numbers don't turn out how you
think they are so you have to render, tweak, render, tweak, render, tweak, very
bad.)
> I would like to reach the stage where we can use something like MLCad
> to build my design (and group it as MPD's - that is a good technique),
> then use *the same tool* to build keyframes, and preview the animation
> with OpenGL or DirectX based rendering. I can then hit an export
> animation button, which will ask me (much like MAX) what resolution I
> want, animation format, colour depth etc, and hit go - and it will
> generate what it needs, render the file(might be time to go to work or
> bed for a few hours), and when finished, offer me an option to play it
> back now, or go back to the editor.
First, is Mike willing to do the work? AFAIK, he isn't sharing his code with
anyone... If he is going to do the work, I don't know that he would listen to
anything we discuss here anyway.
Second, if he (or someone else) does pay heed to this thread, I want to
discourage extending the LDraw file format to include time info or creating a
brand new format from scratch.
I know the ldraw file format is so easy to understand, but it can't do things
like scripting. For example, my walk macro is a script. The script takes 3
simple parameters: a line/curve, number of frames, and the number of steps. It
figures out where to put the minifig feet, and how far they should be (it even
slows down on sharp turns). I can think of no way to do this in an extended
LDraw file format.
LDraw files contain models. Not scenes and time. It would be difficult to have
my walk macro in the LDraw file format. Are you going to not use scripts and
instead specify every step of a minifig? That is what a script is for. When I
was doing Lani, I was going to have a "walk" command. Problem with that is what
if I wanted to give the minifig a little swagger? Or what if I wanted it to
walk faster, take shorter steps. What if I put flippers or ski's on the minfig
feet? A "walk" command wont allow me any of that but a script gives me all the
power to do what I want.
And when specifying the rotation of a leg, you don't want a linear delta
(instant accel/decel at start and end of movement). There are many different
types of acceleration/deceleration options, such as S curve, sin curve
(pendulum), or any math function on time. Hard to put all of that in the ldraw
file format...
I'm not trying to discourage this topic. I just don't to get people pulling in
the same direction, which honestly, I don't know what it is. But I know
extending the LDraw format is a very bad idea.
Developing a new format from scratch is ok, IF you first learn how it is done in
Maya and Lighwave because then you will be able to *plan*. In fact, I suggest
nobody actually write up any formats unless you have actually created some
complex animations and know what you are up against.
POV-Ray doesn't really deal with time. It just has a clock variable. It is up
to you to develop the keyframe info, and this thread has at least got me started
to think about trying to make this easier on myself because right now it is a
nightmare.
|
|
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
|
|
|
|
