| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.animation, James Reynolds wrote:
> > 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 think a big part of the reason LDraw has survived and thrived is because of
> the simplicity of the file format. Implementing an LDraw renderer is a
> 'relatively' simple process (if you've got a graphics package handy), so more
> people are encouraged to write programs to work with the LDraw format. But
> LDraw doesn't allow all the powerful operations of POV-Ray.
>
> Likewise, an LDraw-based animation wouldn't have all the power of POV-Ray. But
> it would be simple, and could do basic things. So maybe an LDraw-based 'minifig
> walk' would have a minifig twiddling its legs. But for a lot of people, that
> would be sufficient. And people who want more, would go on to animating in
> POV-Ray.
Get ready for a book...
You've started to describe exactly what I want to avoid.
1. Doing something so simplistic would never be able to hold my interest, and I
suspect it would not interest anyone else who intended to do anything complex.
(I'm making the assumption that the programmers/scripters are the ones who would
be interested in the complex stuff and not the simple stuff--and my assumption
is built on the idea that writing an animation app is so difficult that it wont
hold the programmers interest if it doesn't produce wowzer results.)
2. So the simple animation stuff will likely be built by someone with little to
no animation/programming experience. I was in this category just a year ago.
I'm still not a "real" animator. I know many "real" animators who use Maya and
Lightwave and what I do is child's play to them. What I'm afraid of is someone
who doesn't even have the type of experience even I have extending the file
format and trying to make an animation program.
My concern is that a simple animation program would be totally incompatible with
anything more powerful or complex. Thus you have 2 groups of people working on
animation and there is a gap between them and they basically have nothing to do
with each other.
If that is what people want, that is fine with me.
But I'm hoping to not have this. I'm trying to encourage the community to have
1 group of experts that do the work that benefits the simpler folks who don't
want to do all the complex stuff. But the experts need the help of the simpler
folk too, because we get into our ruts and don't really try to break out. I
myself am barely aware of what goes on in the LDraw world because I just don't
have time to read all the posts (and most of them are about things that don't
apply to me) and it was a fluke that I even saw this thread and decided to pitch
in my 2 cents. But I've come up with many ideas in this thread, so already it
has been useful to me.
To go down this path of group work, you have to make sure the simple stuff can
accommodate the complex stuff. Embedding pov code in the model file for macros
sounds like a good idea. It depends though, because you can't have variables in
LDraw files so far and a pov macro is going to use variables.
When I convert an LDraw file to POV-Ray, I add variables to the pov file after
it has been converted and then the file is no longer LDraw and can no longer be
used with LDraw even if I had something to convert backwards. LDraw can't
handle variables. Variables are very required with keyframe info. Frame one the
model is at x1,y1,z1. Frame 50 it is at x2,y2,z2.
So we could add variables to the format, but will it really happen? It is up to
2 groups, the standards committee, and the actual programmers. The standards
committee can say whatever they want. Until a programmer writes code for it,
nothing will happen. And a programmer doesn't have to follow the standard
anyway.
So if it does happen, will it be done in the right way? Who here has experience
in writing a scripting language and is going to do the work? I don't think
there is anyone. If there is, GREAT! But until then, I propose we use what
already exists.
Does my request to not extend the LDraw file format make sense now?
I mean, we are just discussing theory. Is it possible to get down to details?
I keep bringing up examples, but I don't know if anyone has any idea what I'm
talking about. I haven't even looked at how the 3d pro apps do timeframe info.
Several times I have been tempted to just start writing actual code to do
timeline examples, but the shear complexity of the amount of info required for
just 2 keyframes is very bewildering to me.
(I guess I'm giving in to the temptation)
What is required for each keyframe:
- Hash with object names affected by this keyframe
- In each hash is another hash of info like location and rotation.
What I haven't been able to figure out is how to specify the linking info
between keyframes.
Here is an example:
<key>keyframe 1</key>
<hash>
<key>framenumber</key>
<int>1</int>
<key>objects</key>
<hash>
<key>object 1</key>
<hash>
<key>location</key>
<string>1,2,3</string>
<key>rotation</key>
<string>0,1,0,1,0,1,0,1,0</string>
</hash>
<key>object 2</key>
<hash>
<key>location</key>
<string>4,3,2</string>
<key>rotation</key>
<string>0,1,0,1,0,1,0,1,0</string>
</hash>
<key>camera 1</key>
<hash>
<key>location</key>
<string>-1,0,0</string>
<key>rotation</key>
<string>0,1,0,1,0,1,0,1,0</string>
</hash>
</hash>
</hash>
<key>keyframe 2</key>
<hash>
<key>framenumber</key>
<int>10</int>
<key>objects</key>
<hash>
<key>object 1</key>
<hash>
<key>location</key>
<string>5,6,7</string>
<key>rotation</key>
<string>0,1,0,1,0,1,0,1,0</string>
</hash>
<key>object 3</key>
<hash>
<key>location</key>
<string>2,3,4</string>
<key>rotation</key>
<string>0,1,0,1,0,1,0,1,0</string>
</hash>
</hash>
</hash>
Object 1 is the only object that appears in both keyframes. There is no rule
that says each keyframe has to apply to every object.
Now, how do I handle the transitions between the 2 keyframes? I honestly have
no idea. What is the relationship between object 1's location in keyframe1 and
keyframe2? Does it just leap from the first location to the second location?
Does it move with a flat acceleration (jerk start, jerk stop)? Does the
acceleration follow an S curve (most everything falls in this category)? Are
the two location points part of a circle/ellipse? Does it rotate on the way to
location 2 (think of a wheel)? Are the 2 points part of a larger spline? Or is
the location dependent on the location of some other object (think of the camera
hovered in front of a car)? This is where variables come in and this is where
much of the complexity comes in. I honestly have no idea how to solve this.
As I write this, I have a hard time imagining how to implement even what I wrote
as a language that can be used to generate a pov-ray file. Including the time
info in an LDraw file? I just don't even see how that makes one bit of sense.
LDraw files include model info. As you can see, the keyframe info above could
care less about the model info. All it cares about is the name of the object,
and any subparts that can rotate/translate. THIS is why the LDraw format is
already sufficient for animatable models. I have learned enough about model
structures in the pro apps to know that everything only has one parent, and can
have multiple children, just like the MPD files. So I just read the MPD files
and find out the names and the rotation/translation points and I put that info
in my povray file. I don't embed the time info in the LDraw file.
In my povray work, I separate my models from my scenes. It makes fixing models
easier. It makes multiple scenes easier. It makes more sense. It reduces the
clutter in my scene files. It is just a good idea.
Again, before I would develop something like what I showed, I would read how
Maya and Lightwave deals with keyframe info. But unfortunately, I don't have
time for that now... :(
What I am taking the time for is to try to convince you guys to not commit
yourselves to something that can never be powerful. Plan for the most powerful
system. It may never be as powerful as you planned, but that doesn't mean you
are stuck with a weak system. If you plan power into the system, then in time
perhaps it will be that powerful. (but dumbed down for beginners)
If I haven't convinced you by now, I give up.
James
|
|
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
|
|
|
|
