| |
The textual and the graphical
*****************************
The history of computers, user interfaces, and LDraw are basically the same:
1. a command-line tool offers the initial functionality
2. a point & click GUI layer hides the initial tool
3. eventually everybody forgets the command-line tool
4. textual interfaces reappear in new forms, mainly as scripting languages
5. users request GUI-based IDE for these scripting languages
6. a point & click GUI layer hides the scripting language
What is demanded and what is delivered
**************************************
Users demand GUI interfaces and tend to be attracted by candy eye.
Considering the above paragraph i consider this as an impeding trend.
It's clear that the textual sets the standard functionality.
The GUI only sets the standard user-interface.
The cutting-edge is textual and the mainstream is graphical.
This is why i think LDraw users should stop whining about the lack of an
animation-enabled LDraw graphical tool, as long as no such tool even exists in a
textual form.
The textual step simply can't be avoided.
No programmer will go directly to sophisticated GUIs when no proven underlying
animation concepts have been defined.
First someone has to define the animation concepts by providing an animation
scripting language.
Only after a GUI will eventually support the concepts and offer end-user
friendliness to the masses.
Screaming for a more advanced GUI when there are no concepts to support is
demanding the step n°6 (a point & click GUI layer hides the scripting language)
when we are actually at the step n°3 (everybody has forgetten the command-line
tool).
Whatever loud users will scream for, what will eventually be delivered is step
n°4 (an interpreted animation scripting language).
Considerations,
- damien
|
|
| |
In lugnet.cad, Damien Guichard wrote:
>
>
> This is why i think LDraw users should stop whining about the lack of an
> animation-enabled LDraw graphical tool, as long as no such tool even exists in a
> textual form.
> The textual step simply can't be avoided.
I'm no boffin, but doesn't POVray already do this?
Allister
|
|
| |
> First someone has to define the animation concepts by providing an animation
> scripting language.
Take a look at Maya and Lightwave. The concepts have been all thought out
already.
www.alias.com/maya
http://www.newtek.com/lightwave
If you want an LDraw animation package, you are first going to have a willing
programmer TEAM. That is right, animation applications take teams of people to
write them. Several individuals (myself included) attempted to do various
things with LDraw and have not produced very much. Look what has been done with
Lightwave, and they didn't need the LDraw library either.
http://www.daveschool.com/projects/BATMAN/assets/pages/index.html
|
|
| |
In lugnet.cad, Allister McLaren wrote:
> In lugnet.cad, Damien Guichard wrote:
> >
> >
> > This is why i think LDraw users should stop whining about the lack of an
> > animation-enabled LDraw graphical tool, as long as no such tool even exists in a
> > textual form.
> > The textual step simply can't be avoided.
>
>
> I'm no boffin, but doesn't POVray already do this?
>
> Allister
MLCad + L3P + POVray does static pictures, greatly limited when it comes to
animation scripting capability.
Considerations,
- damien
|
|
| |
> Take a look at Maya and Lightwave. The concepts have been all thought out
> already.
>
> www.alias.com/maya
>
> http://www.newtek.com/lightwave
Can't have a look, would be too expensive for me.
May be the concepts in these sofware are fine for 3D artists, but nobody has
ever experienced and validated them for complete lego animation. Take "Revenge
of the Brick" as an example: it's more about adding some bricks in traditionnal
animation than adding some animation effects in a complete lego world.
The simple concepts are deceptive: the software components that implement them
are really difficult to develop, require software-engineering experts, and
finally have poor chances too seamlessly connect at the end of a long and
painful development cycle.
> If you want an LDraw animation package, you are first going to have a willing
> programmer TEAM. That is right, animation applications take teams of people to
> write them. Several individuals (myself included) attempted to do various
> things with LDraw and have not produced very much. Look what has been done with
> Lightwave, and they didn't need the LDraw library either.
>
> http://www.daveschool.com/projects/BATMAN/assets/pages/index.html
It takes several tries before someone succeeds.
Will is a bad substitute for talent concentration.
You still think about a GUI tool, but a textual scripting language does not take
a team to develop.
As far as i know no LDraw team has succeeded either, so your argument ressembles
an open-source myth.
The success/failure criterium is not the individual vs. the collective, it's
about the concentrated vs. the diluted. I think only the concentrated side
stands a chance, the diluted side will ever be too divided (both in minds and in
geography).
Considerations,
- damien
|
|
| |
In lugnet.cad, Damien Guichard wrote:
> > Take a look at Maya and Lightwave. The concepts have been all thought out
> > already.
> >
> > www.alias.com/maya
> >
> > http://www.newtek.com/lightwave
>
> Can't have a look, would be too expensive for me.
> May be the concepts in these sofware are fine for 3D artists, but nobody has
> ever experienced and validated them for complete lego animation. Take "Revenge
> of the Brick" as an example: it's more about adding some bricks in traditional
> animation than adding some animation effects in a complete lego world.
>
> The simple concepts are deceptive: the software components that implement them
> are really difficult to develop, require software-engineering experts, and
> finally have poor chances too seamlessly connect at the end of a long and
> painful development cycle.
>
> > If you want an LDraw animation package, you are first going to have a willing
> > programmer TEAM. That is right, animation applications take teams of people to
> > write them. Several individuals (myself included) attempted to do various
> > things with LDraw and have not produced very much. Look what has been done with
> > Lightwave, and they didn't need the LDraw library either.
> >
> > http://www.daveschool.com/projects/BATMAN/assets/pages/index.html
>
> It takes several tries before someone succeeds.
> Will is a bad substitute for talent concentration.
> You still think about a GUI tool, but a textual scripting language does not take
> a team to develop.
> As far as i know no LDraw team has succeeded either, so your argument ressembles
> an open-source myth.
>
> The success/failure criterium is not the individual vs. the collective, it's
> about the concentrated vs. the diluted. I think only the concentrated side
> stands a chance, the diluted side will ever be too divided (both in minds and in
> geography).
>
> Considerations,
>
> - damien
Dear Damien,
I'm not 100% sure what you are saying for a lot of this post but I do have to
say that writing an animation scripting language, even utilising what else is
around, is a very difficult task.
As a simple example of how hard this problem is, lets say the only animation
allowed would be from sub-models with a defined connection to other sub-models
(perhaps through a meta-command). With one connection, the problem is
straightfoward, with two, a little more difficult, if we want five connections
though, we already have a difficult computational problem, even without a
physics engine. Once we throw in a physics engine it becomes even more
complicated.
I'm not saying it can't be done. Just that it is difficult. It obviously could
be written given enough time and energy. For me though, I do not have the free
time, nor the inclination to embark on such a large project. If you believe you
can do it on your own then go ahead and if it works effectively I'm sure people
will use it. I would be happy to volunteer mathematical 'expertise' to such a
project were it required.
Tim
|
|
| |
In lugnet.cad, Damien Guichard wrote:
> In lugnet.cad, Allister McLaren wrote:
> > In lugnet.cad, Damien Guichard wrote:
> > >
> > >
> > > This is why i think LDraw users should stop whining about the lack of an
> > > animation-enabled LDraw graphical tool, as long as no such tool even exists in a
> > > textual form.
> > > The textual step simply can't be avoided.
> >
> >
> > I'm no boffin, but doesn't POVray already do this?
> >
> > Allister
>
> MLCad + L3P + POVray does static pictures, greatly limited when it comes to
> animation scripting capability.
I have been working on what you want for 5 years. At first I came up with Lani
as a language.
http://james.magnusviri.com/lego/lani/details.html
It sucks. I now use POV-Ray. Have you learned POV-Ray? Have you seen this:
http://www.ldraw.org/article/348
I fully agree, POV-Ray isn't as powerful as, say, Maya. But it is as powerful
as you are going to get in free software.
|
|
| |
I've had a basic animation system working in LeoCAD for a while, I
tried to do things as close to how 3DS works as I could since I didn't
have much experience with animations and I figured the guys at Discreet
know what they are doing (I'm not going get into a debate between Maya
and Max, I didn't have access to Maya at that time).
You can set keyframes and animate the camera and move objects and
then the program will interpolate the position/rotation between them. I
was going to start working on a good GUI but then I decided it was more
important to focus my time on features that more users would like to
see, it would take a lot of work to get a good system in and people that
want to make animations seriously would just rather export the file and
use it in 3DS or Maya.
Leonardo
James Reynolds wrote:
> > First someone has to define the animation concepts by providing an animation
> > scripting language.
>
>
> Take a look at Maya and Lightwave. The concepts have been all thought out
> already.
>
> www.alias.com/maya
>
> http://www.newtek.com/lightwave
>
> If you want an LDraw animation package, you are first going to have a willing
> programmer TEAM. That is right, animation applications take teams of people to
> write them. Several individuals (myself included) attempted to do various
> things with LDraw and have not produced very much. Look what has been done with
> Lightwave, and they didn't need the LDraw library either.
>
> http://www.daveschool.com/projects/BATMAN/assets/pages/index.html
>
>
|
|
| |
In lugnet.cad, Damien Guichard wrote:
> > Take a look at Maya and Lightwave. The concepts have been all thought out
> > already.
> >
> > www.alias.com/maya
> >
> > http://www.newtek.com/lightwave
>
> Can't have a look, would be too expensive for me.
At the very least you should read the manuals to see what techniques the artists
use. They aren't stupid. And they do apply to Lego animation because I have
read some manuals so I know.
Lightwave is only $895, which isn't that expensive (how much does Windows cost?
How much does Photoshop cost? How much does Flash cost? How much does
Dreamweaver cost?).
Learning Lightwave is a different issue. Paying $895 for the software is much
easier than learning it. People could even get a cracked version for free, but
guess what? Most likely they would never learn how to use it well enough to
make anything. If you aren't willing to pay the $, will you be willing to spend
the time needed to learn how to make animations at all? It is a huge investment
of time.
I'm surprised you aren't aware of what POV-Ray can do:
http://james.magnusviri.com/lego/pov_ray_tutorial/
http://james.magnusviri.com/lego/animatable_models/
http://james.magnusviri.com/lego/minifig/
This is only a partial picture of what POV-Ray can do since I'm not displaying
works in progress that would probably blow your mind.
James
|
|
| |
In lugnet.cad, Damien Guichard wrote:
| |
| |
Take a look at Maya and Lightwave. The concepts have been all thought out
already.
www.alias.com/maya
http://www.newtek.com/lightwave
|
Can’t have a look, would be too expensive for me.
|
Maya Personal Learning Edition is free for non-commercial use.
|
|
| |
In lugnet.cad, James Reynolds wrote:
> Lightwave is only $895, which isn't that expensive (how much does Windows cost?
> How much does Photoshop cost? How much does Flash cost? How much does
> Dreamweaver cost?).
How much does Linux cost? How much does OpenOffice cost? How much
does Gimp cost? How much do thousands of titles of quite useful
free software cost? I think you are missing the point. Professional
software titles are often out of range for ordinary home users
who are doing stuff for fun or for educational reasons, and not
for profit. People get Windows "for free" when they buy a computer,
and they either use a pirated copy of Office or stick to the bundled
MS Works they get "for free" just like the Windows license, i.e.
rammed down their throat at a hidden and heavily discounted OEM price.
> If you aren't willing to pay the $, will you be willing to spend
> the time needed to learn how to make animations at all?
> It is a huge investment of time.
And still people all over the world learn how to create wonderful
stuff with entirely illegal copies of 3dsmax, Maya and Lightwave.
Once again, I think you are missing the point. For many people,
private individuals and young people in particular, time is
cheap and in plentiful supply if needed, but money is very scarce.
Free 3D modeling and animation software exists. Blender is not
a dream to learn (I have tried), but some very good stuff has
been produced with it, and you are kind of shooting yourself
in the foot by mentioning POV-Ray, which is also free and has
spawned some supporting free modeling and animation software.
Software does not *have* to cost money. If you have a couple
of thousand dollars to spare, you have more options, and I
much prefer some professional software titles over many
free equivalents, but I see the advantages of free software
and I happily use both free and non-free software every day.
> I'm not displaying
> works in progress that would probably blow your mind.
Ahem. This is an attitude that would put many people off.
Talking about the wonderful quality of unreleased work that
sits on your hard disk is about the least constructive thing
you can do in a public forum.
I am not saying that you should not mention it, or that it
would not in fact knock our socks off if we saw it, but please
refrain from boasting about it until you can release it.
And even then it is wiser to watch silently and let others
praise it. In my experience, Saying "What do you think of
this?" and getting a "Wow!" is a lot better as an ego boost
than saying "This is great, don't you agree?" and getting a
"Well, if you say so, yeah, I guess".
Please do not take offense by this. I mean no harm,
but I do know what I am talking about, too.
|
|
| |
In lugnet.cad, Stefan Gustavson wrote:
> In lugnet.cad, James Reynolds wrote:
>
> > Lightwave is only $895, which isn't that expensive (how much does Windows cost?
> > How much does Photoshop cost? How much does Flash cost? How much does
> > Dreamweaver cost?).
>
> How much does Linux cost? How much does OpenOffice cost? How much
> does Gimp cost?
And I'll add to that the animated GIMP (forgotten its name) is used by
Dreamworks and other big animation studios.
Tim
|
|
| |
In lugnet.cad, Damien Guichard wrote:
>
> Whatever loud users will scream for, what will eventually be
> delivered is step n°4 (an interpreted animation scripting language).
I think it would be wise to include a step 3.5:
We first need some means for saving animation data,
i.e. we need to design and agree upon a file format
for time-varying LDraw data.
Without that, we might end up with the situation that
is still crippling some aspects of the otherwise very
successful RenderMan graphics standard: the file format
for RenderMan input is static, and each frame is actually
a still image generated from other, non-standard and
often proprietary scene description formats.
I am not saying this is easy. I am saying, like you,
that this is hard. But it can be done, and I would
like to see it. The connection database that was
attempted (is that project still alive?) is a clear and
commendable step towards LDraw animation capabilities.
Stefan
|
|
| |
In lugnet.cad, Jordan Bradford wrote:
| |
In lugnet.cad, Damien Guichard wrote:
| |
| |
www.alias.com/maya
http://www.newtek.com/lightwave
|
Can’t have a look, would be too expensive for me.
|
Maya Personal Learning Edition is free for non-commercial use.
|
My computer is a Celeron-Mendocino 500Mhz, 128Mb RAM, Win98se.
Thus, even free is too costly because i can’t afford the required hardware.
damien
|
|
| |
In lugnet.cad, Timothy Gould wrote:
> Dear Damien,
>
> I'm not 100% sure what you are saying for a lot of this post but I do have to
> say that writing an animation scripting language, even utilising what else is
> around, is a very difficult task.
>
> I'm not saying it can't be done. Just that it is difficult. It obviously could
> be written given enough time and energy. For me though, I do not have the free
> time, nor the inclination to embark on such a large project. If you believe you
> can do it on your own then go ahead and if it works effectively I'm sure people
> will use it. I would be happy to volunteer mathematical 'expertise' to such a
> project were it required.
>
> Tim
Yeah it's already difficult enough and i don't say i will try.
And if i try i will not embark anyone as a collective project can have a
negative impact when it fails: people who have invested time and effort want
someone to be blamed and that's very bad for small communities.
Damien
|
|
| |
In lugnet.cad, Timothy Gould wrote:
> And I'll add to that the animated GIMP (forgotten its name) is used by
> Dreamworks and other big animation studios.
Right. When free software exists and is good enough to
outperform commercial solutions in some applications,
it will of course be used. The extremely successful
combination Apache/PHP springs to mind - lots of web
sites who could easily afford IIS/ASP still run Apache,
because it solves their particular problems better.
My point was that even if a free software title pales in
comparison to a commercial equivalent, it will still be
used if it is useful at all.
Get *any* kind of animation capabilities into the LDraw
tools, and if it is needed at all people will probably
start using it, and some will step forward to improve it.
Right now, nobody knows where to begin.
The LDraw file format, which is at the heart of it all,
is a static scene description language. I think we should
start attacking the problem there, and I would suggest
moving on to a more modern (but of course compatible)
file format, perhaps based on XML which has proven itself
in a large number of applications, quite a few of them
related to computer graphics.
Stefan
|
|
| |
In lugnet.cad, James Reynolds wrote:
> I have been working on what you want for 5 years. At first I came up with Lani
> as a language.
>
> http://james.magnusviri.com/lego/lani/details.html
>
> It sucks. I now use POV-Ray. Have you learned POV-Ray? Have you seen this:
> http://www.ldraw.org/article/348
>
> I fully agree, POV-Ray isn't as powerful as, say, Maya. But it is as powerful
> as you are going to get in free software.
I downloaded Lani long time ago, not deeply tested it but i wouldn't say it
sucks.
I know about POV-Ray, ray-tracing primitives and Constructive Solid Geometry.
My lego POV-Ray gallery: http://perso.wanadoo.fr/alphablock/
Damien
|
|
| |
In lugnet.cad, Stefan Gustavson wrote:
> In lugnet.cad, Damien Guichard wrote:
> >
> > Whatever loud users will scream for, what will eventually be
> > delivered is step n°4 (an interpreted animation scripting language).
>
> I think it would be wise to include a step 3.5:
> We first need some means for saving animation data,
> i.e. we need to design and agree upon a file format
> for time-varying LDraw data.
>
> Without that, we might end up with the situation that
> is still crippling some aspects of the otherwise very
> successful RenderMan graphics standard: the file format
> for RenderMan input is static, and each frame is actually
> a still image generated from other, non-standard and
> often proprietary scene description formats.
You mean a movement should be a continuous function rather than successives
position interpolations. If that's you mean then i agree. If not, can you be
more explicit?
Damien
web page: http://perso.wanadoo.fr/alphablock/
|
|
| |
In lugnet.cad, Stefan Gustavson wrote:
> The LDraw file format, which is at the heart of it all,
> is a static scene description language. I think we should
> start attacking the problem there, and I would suggest
> moving on to a more modern (but of course compatible)
> file format, perhaps based on XML which has proven itself
> in a large number of applications, quite a few of them
> related to computer graphics.
XML has poor human-readibility.
The text format should be accepted before it has a GUI front-end, and that can
be only if it's readeable enough.
Anyway, who writes the interpreter decides the format.
Considerations,
Damien
|
|
| |
In lugnet.cad, Damien Guichard wrote:
> In lugnet.cad, Stefan Gustavson wrote:
> > The LDraw file format, which is at the heart of it all,
> > is a static scene description language. I think we should
> > start attacking the problem there, and I would suggest
> > moving on to a more modern (but of course compatible)
> > file format, perhaps based on XML which has proven itself
> > in a large number of applications, quite a few of them
> > related to computer graphics.
>
> XML has poor human-readibility.
> The text format should be accepted before it has a GUI front-end, and that can
> be only if it's readeable enough.
> Anyway, who writes the interpreter decides the format.
>
> Considerations,
>
> Damien
Poor XML has poor human-readibility. XML in general is fine.
<part>
<no>
13
</no>
<pos>
10,12, 15
</pos>
</part>
is quite readable.
|
|
| |
In lugnet.cad, Jordan Bradford wrote:
| |
In lugnet.cad, Damien Guichard wrote:
| |
| |
Take a look at Maya and Lightwave. The concepts have been all thought out
already.
www.alias.com/maya
http://www.newtek.com/lightwave
|
Can’t have a look, would be too expensive for me.
|
Maya Personal Learning Edition is free for non-commercial use.
|
The Maya PLE watermarks all of the renders and is very limited. Don’t use it
unless you plan on buying a full version or something.
James
|
|
| |
In lugnet.cad, Stefan Gustavson wrote:
> In lugnet.cad, Timothy Gould wrote:
> > And I'll add to that the animated GIMP (forgotten its name) is used by
> > Dreamworks and other big animation studios.
>
> Right. When free software exists and is good enough to
> outperform commercial solutions in some applications,
> it will of course be used. The extremely successful
> combination Apache/PHP springs to mind - lots of web
> sites who could easily afford IIS/ASP still run Apache,
> because it solves their particular problems better.
>
> My point was that even if a free software title pales in
> comparison to a commercial equivalent, it will still be
> used if it is useful at all.
> Get *any* kind of animation capabilities into the LDraw
> tools, and if it is needed at all people will probably
> start using it, and some will step forward to improve it.
> Right now, nobody knows where to begin.
>
> The LDraw file format, which is at the heart of it all,
> is a static scene description language. I think we should
> start attacking the problem there, and I would suggest
> moving on to a more modern (but of course compatible)
> file format, perhaps based on XML which has proven itself
> in a large number of applications, quite a few of them
> related to computer graphics.
There are 2 ways you can approach this.
Animation involves time. The LDraw format does not include anything in it to
deal with time. The first approach would be to add something to deal with time
to the LDraw format. This is a very bad idea IMO. Leave LDraw to what it was
designed to do: create models.
The second approach is to convert LDraw files to other formats that already
support time functions. There are several converters for POV-Ray, Blender,
Maya, Lightwave, etc etc. If you stick with these, than you can use their
renderers as well.
There are things you can do to make your LDraw files animation ready. Please
read this:
http://james.magnusviri.com/lego/animatable_models/
I wrote it specifically to address the parent/child or node linking that the
commercial packages support. To sum it up, when performing an action on a
parent node, it affects the children nodes. If you don't have these
relationships in your models, or if the pivot points are off, animation is a
nightmare.
It is possible to have parent/child relationships in LDraw by using MPD and
subfiles. My article talks about this. It is also possible to have
parent/child nodes in POV-Ray by using the union command.
So animation is already possible. But I'm sure what everyone wants is a 3d
animation packaged aimed at Legos ONLY. And to get that, as Damien says, you
first have to have a file format. Well, I'm suggesting POV-Ray because it is
free and many LDraw users are already familiar with it (via rendering). But
whatever format is picked is pretty much up to the programmers.
I don't see much programming going on lately though. Who would even do any of
this work? An animation GUI is a huge project. I would rather fork out $895
than wait for someone to write the app. And I'm not a pro. To me the hobby is
worth $895. I'm just lucky I've learned POV-Ray and don't have to fork out
$895.
I should also note that animations themselves are huge projects. I have found
that I don't have time to animate and make models at the same time. So I have
turned to the many LDraw files out there for scene and props. Unfortunately,
most are not set up so I can animate them without a lot of work. This is why I
have written the animatable models tutorial. And *hint hint* I could use help
with props as I'm sure would anyone else who actually started to make
animations.
|
|
| |
In lugnet.cad, Stefan Gustavson wrote:
> In lugnet.cad, James Reynolds wrote:
>
> > Lightwave is only $895, which isn't that expensive (how much does Windows cost?
> > How much does Photoshop cost? How much does Flash cost? How much does
> > Dreamweaver cost?).
>
> How much does Linux cost? How much does OpenOffice cost? How much
> does Gimp cost? How much do thousands of titles of quite useful
> free software cost? I think you are missing the point.
Yes, I must have. I thought the point was that Damien wants a scripting
language to do animation. And I keep trying to say POV-Ray is it. Or something
comercial. Don't try to reinvent the wheel like I did with Lani. Learn the
current offerings.
For a scripting language.
> Free 3D modeling and animation software exists. Blender is not
> a dream to learn (I have tried), but some very good stuff has
> been produced with it, and you are kind of shooting yourself
> in the foot by mentioning POV-Ray, which is also free and has
> spawned some supporting free modeling and animation software.
Again, for a scripting language only, not something to give to teenagers.
> > I'm not displaying
> > works in progress that would probably blow your mind.
>
> Ahem. This is an attitude that would put many people off.
> Talking about the wonderful quality of unreleased work that
> sits on your hard disk is about the least constructive thing
> you can do in a public forum.
Sorry about that. I wasn't trying to brag. What I meant to convey is that
POV-Ray can already do everything you could want. If I were better at math, I
would already have released the WIP's I'm refering to. It is a bit hard, but
reinventing the wheel will be harder and put the whole effort years behind.
What it sounds like to me is that nobody wants to learn POV-Ray. I can
understand, it took me years to be willing to give it a try, wasted a lot of
time on Lani and other projects. But once I decided to learn POV-Ray, it was so
easy I feel stupid I didn't spend the time to learn it before.
And while it may be hard, there are people who do know how to use it and are
more than willing to help others. Some have even gone as far as to make
tutorials.
http://www.ldraw.org/modules.php?op=modload&name=News&file=article&sid=58#animation
http://james.magnusviri.com/lego/pov_ray_tutorial/
I have gotten only one feedback from my tutorial, so I'm just assuming either I
wrote it poorly or people don't really want to learn it.
James
|
|
| |
In lugnet.cad, James Reynolds wrote:
> I thought the point was that Damien wants a scripting
> language to do animation. And I keep trying to say POV-Ray is it. Or something
> comercial. Don't try to reinvent the wheel like I did with Lani. Learn the
> current offerings.
>
> For a scripting language.
Many thanks to you James, your experience is priceless to me.
Before i attempt anything i will now carefully consider:
* what POV-Ray can do
* how it does
* whether i can do easier/better
* if people don't want to learn POV-Ray, then they probably don't want to learn
a scripting language at all, so i must take into account the fact that
easier/better may not be a sufficient motivation. a scripting language is still
a scripting language, and a more powerful one can be more difficult to learn,
raising the entry barrier even higher
* i have supposed that any early adopter is a programmer, regarding your reply i
reconsider the question. may be programmers do programming and only animators do
animation, and they don't want to invest time in a programming language and even
less in a new programming language
Finally, i don't do lego animation myself, i am a programmer for fun. In a few
weeks i will deliver a more mature version of Peeroml, a programming tool for
computation with lego inventories. Peeroml is supposed to be a replacement for
LDiff. Then i will see if a similar replacement for Lani is demanded. If it's
not then i will consider whether fun drives me alone.
Considerations,
Damien
lego web page: http://perso.wanadoo.fr/alphablock/
|
|
| |
On 23/08/05, Damien Guichard <damien.guichard@wanadoo.fr> wrote:
>
> Many thanks to you James, your experience is priceless to me.
>
> Before i attempt anything i will now carefully consider:
> * what POV-Ray can do
> * how it does
> * whether i can do easier/better
> * if people don't want to learn POV-Ray, then they probably don't want to
> learn
> a scripting language at all, so i must take into account the fact that
> easier/better may not be a sufficient motivation. a scripting language is
> still
> a scripting language, and a more powerful one can be more difficult to learn,
> raising the entry barrier even higher
> * i have supposed that any early adopter is a programmer, regarding your reply
> i
> reconsider the question. may be programmers do programming and only animators
> do
> animation, and they don't want to invest time in a programming language and
> even
> less in a new programming language
>
> Finally, i don't do lego animation myself, i am a programmer for fun. In a few
> weeks i will deliver a more mature version of Peeroml, a programming tool for
> computation with lego inventories. Peeroml is supposed to be a replacement for
> LDiff. Then i will see if a similar replacement for Lani is demanded. If it's
> not then i will consider whether fun drives me alone.
>
> Considerations,
>
> Damien
>
> lego web page: http://perso.wanadoo.fr/alphablock/
Considering what we have here, I think we need:
* A Lego animation file/script format which positions LDraw parts in
relation to others, which is then distilled (using a front end) into
POV scripts - so POV still handles the rendering.
* A GUI tool/front end for this.
An animation script which is simply an extension of LDraw, where a
meta-command tells it where the animation starts, and then (using line
numbers or some reasonable ID), only details the *changes* to the last
frame is relatively easily acheivable, crude, but acheivable. This
would be the key frames, with part of the meta-data detailing how many
steps to interpolate over.
Adding extensions to existing LDraw GUIs to create an animated drawing
script again - if these are just positioned in free space (with some
interpolation), would still be quite easy - you use existing
positioning, but taking into account the identification of parts to
get the difference could be interesting.
Someone would then create a simple library, which interpolates the
frames, and generates an "unrolled" version of the animation. A front
end command line app could be created, and the GUI's extended to use
this so they could generate "rough" animation playbacks from the
key-frames. If the library calls take streams or large string data,
then you dont necessarily need to save a file to play it back.
The library could then have functionality added to convert the Lego
script, with the help of the LDraw parts library to a POV rendering.
It would have a number of switches you could set, with sane defaults -
so a client of it could simply tell it to render out a POV file with
defaults, or set a number of state attributes first, then render. A
command line client could be created to use that library
functionality, and in the GUI's, a button in the file menu to export
the POV animation from the file added.
This shared "LDraw Animation" library (in the .dll or .o sense) would
enable many front ends to surface.
So there are a few steps here, and I am not sure I would have the time
to volunteer to create these systems myself - but its a starting
point, albeit a crude one. I would certainly appretiate it. It takes
into account some of the existing systems - and hopefully makes
minimal changes to them.
It does not cover connection databases, which allow for animation at
the real axes - but that is still a little way off. This is a solution
which could be started on fairly soon, and satisfies both the command
line people who like to open up a text editor and dive in, while
leaving room for GUI mods to accomodate it as well.
Cheers
Orion
--
http://orionrobots.co.uk - Build Robots
|
|
| |
> Considering what we have here, I think we need:
> * A Lego animation file/script format which positions LDraw parts in
> relation to others, which is then distilled (using a front end) into
> POV scripts - so POV still handles the rendering.
You do not need a new format. MPD's do the job just fine. I now realize I need
to write a follow up to this article:
http://james.magnusviri.com/lego/animatable_models/
In it I will show how modeling using these guidelines leads to animation bliss.
> An animation script which is simply an extension of LDraw, where a
> meta-command tells it where the animation starts, and then (using line
> numbers or some reasonable ID), only details the *changes* to the last
> frame is relatively easily acheivable, crude, but acheivable. This
> would be the key frames, with part of the meta-data detailing how many
> steps to interpolate over.
LDraw files are perfect for models, but trying to add time information to the
format is a bad idea. Mainly because there are other formats that already have
time information as a part of them.
The reason why you don't want to add time info to the LDraw format is because it
will add complications that at first don't seem that bad, but as you try to get
more and more out of it, you keep having to add more and more until eventually
it is as hard to learn or *harder* than the current formats.
For example, POV-Ray supports equations and variables. My walk macro would not
work without variables and equations. Are you going to add equations and
variables to the LDraw format?
Another example, POV-Ray supports splines. Splines are smoothly curving lines
that are made of points. My walk macro can actually walk on a spline. That is,
I give it a whole bunch of points, and the spline makes a smooth curve that
intersects all the points. So my minifig can walk on that curve without
anything more I need to do. I haven't really made an animation showing this
because I'm too busy doing other development work.
Another example, POV-Ray has math functions like sin, tan, cos, power, square
root, etc. Will the format support those? A simple circle requires sin and
cos: object_location = <sin(clock), 0, cos(clock)> (or something)
For a list of povray functions, see:
http://www.povray.org/documentation/view/3.6.1/226/
And look at everything that can be done with floats:
http://www.povray.org/documentation/view/3.6.1/228/
James
|
|
| |
> * i have supposed that any early adopter is a programmer, regarding your reply i
> reconsider the question. may be programmers do programming and only animators do
> animation, and they don't want to invest time in a programming language and even
> less in a new programming language
Animators use Maya and Lightwave.
> Then i will see if a similar replacement for Lani is demanded. If it's
> not then i will consider whether fun drives me alone.
Your whole thread has got me thinking. I am convinced you do not want to try to
extend LDraw to do animation and that POV-Ray already does what you want.
But that doesn't mean things can't be done to make POV-Ray easier to use. I'll
be thinking about it, perhaps I could even make it easier on myself...
James
|
|
| |
> > Then i will see if a similar replacement for Lani is demanded. If it's
> > not then i will consider whether fun drives me alone.
>
> Your whole thread has got me thinking. I am convinced you do not want to try to
> extend LDraw to do animation and that POV-Ray already does what you want.
>
> But that doesn't mean things can't be done to make POV-Ray easier to use. I'll
> be thinking about it, perhaps I could even make it easier on myself...
>
> James
That is a great idea. Why recreate the wheel when you can add a joystick
instead?
Tim
|
|
| |
In lugnet.cad, Damien Guichard wrote:
> Before i attempt anything i will now carefully consider:
> * what POV-Ray can do
> * how it does
> * whether i can do easier/better
I mostly agree with James (use POV-Ray for animations), but I'll throw my 2
cents in anyway ...
It seems like an LDraw-based animation format is reasonably possible, with the
following requirements/additions:
- Use MPD format. This isn't totally required, but as James has documented, it
is a Very Good Idea.
- Support the LDLite language extension. This includes meta-statements such as
ROTATE, TRANSLATE, SCALE, POINT, and MATRIX, and enhanced syntax to use defined
POINTs and MATRIXs in normal LDraw statements.
- Some concept of variables and expressions.
- A Timer system variable
- An ANIMATE meta-statement, giving the paremeters to control the animation.
- An IF/END IF block meta-statement. This would be important for any animation
other than very simple single-action animations.
OK, that list is longer than I thought it would be. But most of the items on
the list are relatively straightforward to implement. At least, they are well
known and well-solved programming problems. The code to support LDLite language
can be gotten/adapted from the ldglite source code. That gives a base for block
statements and variables. Parsing/interpreting expressions is a common
scripting challenge, the logic/code should be available somewhere.
A program to process such a script could take an animation (.LDA?) source file
as input, and generate a standard LDR file (or series of files) for output.
We've already got programs that can render images, no need to reimplement that.
The key-frame processor suggested by Orion-2 is interesting, but sounds harder
to implement...
Steve
|
|
| |
In lugnet.cad, Steve Bliss wrote:
> In lugnet.cad, Damien Guichard wrote:
> > Before i attempt anything i will now carefully consider:
> > * what POV-Ray can do
> > * how it does
> > * whether i can do easier/better
>
> I mostly agree with James (use POV-Ray for animations), but I'll throw my 2
> cents in anyway ...
>
> It seems like an LDraw-based animation format is reasonably possible, with the
> following requirements/additions:
>
> - Use MPD format. This isn't totally required, but as James has documented, it
> is a Very Good Idea.
> - Support the LDLite language extension. This includes meta-statements such as
> ROTATE, TRANSLATE, SCALE, POINT, and MATRIX, and enhanced syntax to use defined
> POINTs and MATRIXs in normal LDraw statements.
> - Some concept of variables and expressions.
> - A Timer system variable
> - An ANIMATE meta-statement, giving the paremeters to control the animation.
> - An IF/END IF block meta-statement. This would be important for any animation
> other than very simple single-action animations.
>
> OK, that list is longer than I thought it would be. But most of the items on
> the list are relatively straightforward to implement. At least, they are well
> known and well-solved programming problems. The code to support LDLite language
> can be gotten/adapted from the ldglite source code. That gives a base for block
> statements and variables. Parsing/interpreting expressions is a common
> scripting challenge, the logic/code should be available somewhere.
>
> A program to process such a script could take an animation (.LDA?) source file
> as input, and generate a standard LDR file (or series of files) for output.
> We've already got programs that can render images, no need to reimplement that.
>
> The key-frame processor suggested by Orion-2 is interesting, but sounds harder
> to implement...
>
> Steve
Unfortunately, I am very busy right now. Once again, I have to move and it sure
takes its toll from my resources.
But I'd like to repeat what I've said earlier on creating LDraw based
animations. We have LD4D, we have POV-ray's support for animations, we have the
abandoned LANI project, and we have my LDA2001. As its name suggests, it's been
on ice since 2001. I tried to restart the project earlier this year, but failed
due to lack of time and energy.
There are advantages and drawbacks with all of the choises. LD4D had a very
professional feel, but all the newer versions have crashed at start on my PC:s.
Also, it seems to have a very high learning threshold at the first step. I may
be wrong at this - hopefully.
So far, we haven't seen anything useful (IMHO) in using POV's own animation
engine, but its support for math's functions is undoubtly a very strong
advantage. Some kind of MPD with animation METAs, run through a special L3P-like
program might do the trick!
But if I ever get the time to, I lean towards keep deveoping my own LDA2001,
even though it needs a total rework. It is the only easy-to-use animation system
that really works today IMHO. Anyone with a windows PC, the LDraw package, L3P,
and POV can make an animation with one or more minifigs walking using LDA2001.
But, like I said, LDA needs a total rework with support for .LDR, new minifig
parts, and many, many other things. Yet, it does work, which means that my
system is a workable way, while the other ways have yet to prove that.
/Tore
(I do really hope to get more time for LDraw based animations after September
15th, when my moving must be done...)
|
|
| |
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 (there might be
some developer types who want to use makefiles to build animations).
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.
I might be asking too much - and it is early days yet, but by starting
with a wrapper API around the existing tools, and being aware of what
external tools and dependancies there are, it is an acheivable goal.
POV has libraries that can be built against instead of calling its
executable, but I am not so familiar with the other items in the tool
chain.
Cheers,
OrionRobots (I am going to use this for now on to avoid confusion with
the other Orion)
--
http://orionrobots.co.uk
|
|
| |
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.
|
|
| |
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.
If we followed that logic, LDraw would never have existed in the first place.
When LDraw started out, there were already plenty of 3D modeling systems. Heck,
there were already lego-brick subsets of 3D modeling systems.
Yet LDraw does exist, and it seems to be a useful thing to have.
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.
Steve
|
|
| |
On 26/08/05, Steve Bliss <steve.bliss@sbcglobal.net> 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.
>
> If we followed that logic, LDraw would never have existed in the first place.
> When LDraw started out, there were already plenty of 3D modeling systems.
> Heck,
> there were already lego-brick subsets of 3D modeling systems.
>
> Yet LDraw does exist, and it seems to be a useful thing to have.
>
> 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.
>
> Steve
In this context - a very simple or basic extension language could be
used to add an animation block with keyframe/timecode information.
Then, when you need to break out the big guns, you can embed POV code
into it for complex techniques. The code is interpreted by the output
exporters so that each part in the MPD (and certain subparts) become
POV named structures (I cannot remember the syntax, but I remember
doing that in POV) with the same names or references as used in the
timebase. This would give a combination of simplicity, extensibility
(programs that dont want to deal with it just ignore the tags, and
write them back out, possibly flagging that they may need
regeneration), and huge flexibilty or complexity if you need that.
Embedding languages in others is a well known technique, and things
like that do exist in some of the pro animation packages. Only here -
because we are intending to render out to POV, it is even easier to
embed it, as long as you get your identifiers correct. The GUI could
then offer a basic notepad widget to edit those in.
To handle this in LDraw as it is now - you would have to probably use
a metacommand, and then prefix every line of the embedded block with a
metacommand - which would work, but be a little ugly. Again though - a
GUI could wrap this away, and give you a text editor which
automatically deals with meta-command generation.
<contraversial>
One problem with LDraw is that extending it can sometimes be awkward
(multi-line extensions), and it is one reason that I have though that
a modern XML style file format based upon LDraw would give more
extensibility.
</contraversial>
I have to agree here with Steve, LDraw and the tools around it didnt
get where it is by having its head in the sand - it changed, and there
may be cases in the future for it to change in other ways.
OrionRobots
--
http://orionrobots.co.uk - Build Robots
|
|
| |
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
|
|
| |
> 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
That is a good point. Take a look at the .png format. They have made a fully
extensible format which covers the simple, and covers the complex. I would
suggest that any animation format should be based on an equally extensible
format, probably based on XML. It would be quite simple to convert an LDRAW file
to an equivalent XML file (you wouldn't have to convert the parts) which could
then be used as a base for animation. For example you could include variables as
follows
<part number="2001" colour="3">
<position>
<absolute>1 2 3</absolute>
</position>
</part>
could be replace by
<part number="2001" colour="3">
<position>
<onspline id="legspline/>
</position>
</part>
<spline id="legspline">
<startframe relative="0"/>
<endframe relative="10"/>
<startposition absolute="1 2 3"/>
<endposition absolute="4 5 6"/>
<continuesfrom flat="true">
<continuesto id="legspline2">
</spline>
where of course you can extend the <spline> class to deal with anything you
like. Note I left off the rotation matrix for convenience. It would be able to
take the same form as the other position.
Such a format would be quite easy to convert to PovRay (back is unlikely to ever
work without a huge effort) which would be used for the final rendering. You
could also 'snapshot' it at any frame and convert any frane back to LDraw.
Just my thoughts,
Tim
|
|
| |
In lugnet.cad, Timothy Gould wrote:
> Plan for the most powerful system.
That's also my approach.
I have never used any animation system.
I don't know what are the best animation concepts.
As a programmer i only know what i can eventually do (my skills), what is my
preferred approach (my talent) and what i consider as good practice (my
methodology).
Here is the architecture i envision for LDraw animation.
Constraints i would respect:
* no LDraw extension: i hate extensions and especially comments as statements
* use MPD files as input, may be with ROTATION points as MLCad do
* would insert an animation-scripting layer between LDR files and POV files
* no new file format, no XML, just programming
* use POV-Ray as a renderer
Thus the whole problem would be confined within the animation layer and would
not alter any existing standard.
Once the problem confined i could propose a solution.
Some directions i would explore:
* use expressions rather than statements, expressions are just more...
expressive
* use OCaml as the interpreter, so i wouldn't have to write an interpreter, i
wouldn't have to invent yet another scripting language, any LDraw scripting
would be OCaml programming
* a composite data model would be loaded from a standard MPD file
* movements would be fonctions, thus you could compose moves by function
composition
* the main module would be high-order functions for highly skilled programmers,
to achieve highly complex tasks
* user-friendliness would be derived from the high-order functions by
partially-applicating them with common-used parameters
* user documentation would progress from basic usage to high-order functions
* output would be a unique MPD file, each animation step being separated by a
CLEAR statement
The Pros:
* no change to existing standard material
* unlimited expressive power
The Cons:
* previous POV work would be not supported
* advanced OCaml programming quickly ressembles academic math work
But there would be no elistism: end-users and programmers would use the same
language, just not at the same skill level. And let's be honest:
1. if you are fluent with vectors and matrices then you have math skills
2. anything really advanced quickly ressembles engineering or academic work
3. nothing prevents someone to build a GUI that outputs text as MLCad do
I speak, i speak, but first i still have to deliver Peeroml...
damien
lego web page: http://perso.wanadoo.fr/alphablock/
|
|
| |
In lugnet.cad, Damien Guichard wrote:
> * output would be a unique MPD file, each animation step being separated by a
> CLEAR statement
What's the Pro with MPD files in this case? My experince is that it makes
programming much, much more difficult, and the gain is...(?) In LDA, I inlined
all submodels into one model DAT* file for each Frame, and then one Master DAT
file that calls all Frames separated by a STEP and a CLEAR statement.
*(Today I would of course have given them the LDR extension...)
>
> The Pros:
> * no change to existing standard material
> * unlimited expressive power
>
> The Cons:
> * previous POV work would be not supported
> * advanced OCaml programming quickly ressembles academic math work
* and yet another programming syntax to learn...
|
|
| |
In lugnet.cad, Tore Eriksson wrote:
> In lugnet.cad, Damien Guichard wrote:
>
> > * output would be a unique MPD file, each animation step being separated by a
> > CLEAR statement
>
>
> What's the Pro with MPD files in this case? My experince is that it makes
> programming much, much more difficult, and the gain is...(?) In LDA, I inlined
> all submodels into one model DAT* file for each Frame, and then one Master DAT
> file that calls all Frames separated by a STEP and a CLEAR statement.
>
> *(Today I would of course have given them the LDR extension...)
Not really a big deal, i could change my mind if that's too difficult for me to
program.
> > The Pros:
> > * no change to existing standard material
> > * unlimited expressive power
> >
> > The Cons:
> > * previous POV work would be not supported
> > * advanced OCaml programming quickly ressembles academic math work
>
> * and yet another programming syntax to learn...
It's much worse than a new syntax.
A whole new, entirely different programming paradigm to learn.
A whole new program semantic.
Almost any programming skill you have would vanish in planned obsolescence.
You would have to restart from scratch, using only modern math background.
When i say academic i really mean academic:
1. Most important notion is recurrence theorem
2. Another important notion is anonymous functions
3. As far as possible, loops and variable assignments are banned!
But i also said no elitism: the basic usage would have basic syntax.
I could even add a preprocessor for those who don't like the syntax.
A friend advised me it may be necessary to provide a preprocessor for smooth
transition to more powerful concepts that people don't intuitively master.
damien
my lego web page: http://perso.wanadoo.fr/alphablock/
|
|
| |
> > * and yet another programming syntax to learn...
>
> It's much worse than a new syntax.
> A whole new, entirely different programming paradigm to learn.
> A whole new program semantic.
> Almost any programming skill you have would vanish in planned obsolescence.
> You would have to restart from scratch, using only modern math background.
>
> When i say academic i really mean academic:
> 1. Most important notion is recurrence theorem
> 2. Another important notion is anonymous functions
> 3. As far as possible, loops and variable assignments are banned!
>
> But i also said no elitism: the basic usage would have basic syntax.
> I could even add a preprocessor for those who don't like the syntax.
> A friend advised me it may be necessary to provide a preprocessor for smooth
> transition to more powerful concepts that people don't intuitively master.
>
> damien
>
> my lego web page: http://perso.wanadoo.fr/alphablock/
Damien,
I don't see the advantage in using OCaml over any other language. Particularly
ones people are more familiar with. Could you outline any advantages is might
have over, say, Perl (which also has inbuilt strings and memory management).
Tim
|
|
| |
> I don't see the advantage in using OCaml over any other language. Particularly
> ones people are more familiar with. Could you outline any advantages is might
> have over, say, Perl (which also has inbuilt strings and memory management).
>
> Tim
Follow up set to .off-topic.geek
|
|
| |
One more thing: I will use CAMERA.dat and LOOK_AT.dat in each Frame file in my
planned LDA (hopefully LDA2005...). I find them very handy, anyone can use them
and move them around in MLCad or whatever LDraw editor. This is how I made them,
but anyone can make his own version of them:
0 ~Camera Position
0 Name: Camera.dat
0 Author: Tore Eriksson
0 Un-official part
2 24 -20 0 0 20 0 0
2 24 0 -20 0 0 20 0
2 24 0 0 -20 0 0 20
0 L3P IFNOTPOV
1 0 0 25 37 1 0 0 0 1 0 0 0 1 30148.dat
0 L3P ENDPOV
0
---------------------------------------------
0 ~Look_at Position
0 Name: look_at.dat
0 Author: Tore Eriksson
0 Un-official part
2 24 -20 0 0 20 0 0
2 24 0 -200 0 0 20 0
2 24 0 0 -20 0 0 20
0 L3P IFNOTPOV
1 42 0 16 0 1 0 0 0 1 0 0 0 1 30153.dat
0 L3P ENDPOV
0
A sample frame may look like this:
0 Testing Camera and More...
0 Name: testing.ldr
0 Author: Tore Eriksson
0 [L3P Parameters]
0 LDA CAMERA_ANGLE 60
1 0 100 -150 0 -1 0 0 0 1 0 0 0 -1 camera.dat
1 0 20 -50 40 1 0 0 0 1 0 0 0 1 look_at.dat
0 [Parent Object]
0 Scene Object cannot have a Parent Object
0 [This Object]
1 16 0 0 0 1 0 0 0 1 0 0 0 1 Scene.dat
0 [Child Objects]
1 1 0 -40 52 1 0 0 0 1 0 0 0 1 970.dat
1 4 0 -72 52 1 0 0 0 1 0 0 0 1 973.dat
1 14 0 -96 52 1 0 0 0 1 0 0 0 1 3626bp01.dat
1 0 0 -96 52 1 0 0 0 1 0 0 0 1 3624.dat
1 2 16 -64 52 0.9855 0.17 0 -0.17 0.9136 -0.4067 0 0.4067 0.9136 981.dat
1 15 23.9875 -44.3382 50.1846 0.9855 0.1241 -0.1088 -0.17 0.4066 -0.8816 0
0.8816 0.4066 983.dat
1 1 -16 -64 52 0.9855 -0.17 0 0.17 0.9136 0.4067 0 -0.4067 0.9136 982.dat
1 10 -23.9875 -51.4722 35.5434 0.9855 -0.1241 0.1088 0.17 0.9272 -0.2878 0
0.2878 0.9272 983.dat
1 1 0 -28 52 1 0 0 0 0.9136 0.4067 0 -0.4067 0.9136 972.dat
1 1 0 -28 52 1 0 0 0 0.9136 -0.4067 0 0.4067 0.9136 971.dat
0
and the animation program will generate this line in the L3P batch file:
"l3p -o testing.ldr -ca60 -cc100,-150,0 -cla20,-50,40"
Sad thing that Lars doesn't want to add support for these things directly in
L3P...! But on the other hand, I plan to make LDA meta-commands that sets light
attributes and maybe more, so I'll likely need this preprocessing anyway.
/Tore
|
|
| |
On 27/08/05, Damien GUICHARD <damien.guichard@wanadoo.fr> wrote:
<snip>
> The Cons:
> * previous POV work would be not supported
> * advanced OCaml programming quickly ressembles academic math work
>
> But there would be no elistism: end-users and programmers would use the same
> language, just not at the same skill level. And let's be honest:
> 1. if you are fluent with vectors and matrices then you have math skills
> 2. anything really advanced quickly ressembles engineering or academic work
> 3. nothing prevents someone to build a GUI that outputs text as MLCad do
<snip>
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.
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.
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.
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.
OrionRobots
--
http://orionrobots.co.uk - Build Robots
Online Castle Building RPG -
http://www.darkthrone.com/recruit.dt?uid=V30311I30328J30379X30379E30260X30277
|
|
| |
> 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
|
|
| |
I may very well abandon my LDraw based LDA2001 project when I...
* see something that really works, and when I...
* understand enough of it to make my own animations from it.
|
|
| |
In lugnet.cad, danny staple <orionrobots@gmail.com> wrote:
<snip>
> 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.
<snip>
Wow, that really hurts.
Especially the last sentence.
Thanksfully i know you play role reversal: what you mean is users would
immediatly exclude my tool from their choice panel and will stick to POV or any
other alternative.
The Lego Mindstorms popularity means there are Lego builders that can program.
Whether they would learn OCaml for the sole purpose of animation is the
question.
Thanks for sharing your experience, whether professionnal or not.
The reason why i propect is precisely to benefit from others experiences.
There is a little possibility i will develop something but no chance that i do a
point & click interface.
If i develop something i will be prepared for having 0 users.
No user would be developping for fun.
One user would be one additionnal reward.
damien
|
|
| |
In lugnet.cad, Timothy Gould wrote:
>
> Damien,
>
> I don't see the advantage in using OCaml over any other language. Particularly
> ones people are more familiar with. Could you outline any advantages is might
> have over, say, Perl (which also has inbuilt strings and memory management).
>
> Tim
(* off-topic discussion *)
Design and implementation are not as independant as i wish.
As part of the design requirements, i pointed moves should be functions and be
as composable as functions are. Practically that means the language must
support:
1. anonymous functions
2. closures
3. partial application
4. type inference (Milner's type system)
Java doesn't meet any of these requirements.
Perl, Python and Ruby may barely meet 2 or 3 of the requirements.
Scheme confortably meets 3 of the requirements.
The 4 requirements together leave only 3 language candidates:
1. OCaml
2. Haskell (the successor of Miranda)
3. SML (Standard ML)
OCaml is by far the most popular of them.
Why is a Milner's type system so much needed ?
Because of the heavy use of partial application.
Partial application means you can't check the number of applied arguments. Thus
code is very fragile: forgetting a function argument goes undetected, this leads
to code that is clean to read but nightmarish to debug. The solution found by
Robert Milner is a stronger typing system known as "Milner's type system".
damien
|
|
| |
> (* off-topic discussion *)
>
> Design and implementation are not as independant as i wish.
>
> As part of the design requirements, i pointed moves should be functions and be
> as composable as functions are. Practically that means the language must
> support:
> 1. anonymous functions
> 2. closures
> 3. partial application
> 4. type inference (Milner's type system)
>
> Java doesn't meet any of these requirements.
> Perl, Python and Ruby may barely meet 2 or 3 of the requirements.
> Scheme confortably meets 3 of the requirements.
>
> The 4 requirements together leave only 3 language candidates:
> 1. OCaml
> 2. Haskell (the successor of Miranda)
> 3. SML (Standard ML)
>
> OCaml is by far the most popular of them.
>
> Why is a Milner's type system so much needed ?
>
> Because of the heavy use of partial application.
> Partial application means you can't check the number of applied arguments. Thus
> code is very fragile: forgetting a function argument goes undetected, this leads
> to code that is clean to read but nightmarish to debug. The solution found by
> Robert Milner is a stronger typing system known as "Milner's type system".
>
> damien
Hi Damien,
The correct place for your response would be .off-topic.geek which is where I
set the follow up to in the response post.
I thought you were proposing to write a scripting language, but now I suspect
you mean that people should use OCaml for their programming. Is this correct?
If you are proposing that people learn OCaml just to run animations then I would
suspect that your target audience would most probably be yourself only. I have
experience in quite a few programming languages and I would not wish to learn
OCaml unless it was for a very good reason.
Please correct these assumptions if you think they are wrong!
Yours,
Tim
|
|
| |
Why not develop something abstract. If you come up with a way to
notate an animation in any langauge, perhaps it will catch on.
James
On Aug 29, 2005, at 9:59 PM, Damien Guichard wrote:
> Java doesn't meet any of these requirements.
> Perl, Python and Ruby may barely meet 2 or 3 of the requirements.
> Scheme confortably meets 3 of the requirements.
>
> The 4 requirements together leave only 3 language candidates:
> 1. OCaml
> 2. Haskell (the successor of Miranda)
> 3. SML (Standard ML)
>
> OCaml is by far the most popular of them.
|
|
| |
> 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
|
|
| |
I wonder if anyone remembers the 80s game "Story Machine" from Spinnaker
Software (publishers of "Face Maker" and other silly products.)
This program acted out the sentences you typed in. It was a kind of
self-illustrating text adventure. For example typing "The boy walked to the
tree" meant that the two characters would materialize out of nothing and the boy
would walk over next to the house. Or you could make the tree run to the boy (it
had animated legs.) There were a limited number of nouns and verbs, about 30 in
all. As you typed (or erased), your story was recorded for replay later. My
stories ended with the terrible tree eating everything on the screen. Yum.
This concept is mostly for calling up canned routines. However, 6 year olds and
non-programmers will happily write programs in such languages. If you implement
natural language, certainly many more people will use your program.
-Erik
|
|
| |
On 29/08/05, Damien Guichard <damien.guichard@wanadoo.fr> wrote:
> In lugnet.cad, Timothy Gould wrote:
> >
> > Damien,
> >
> > I don't see the advantage in using OCaml over any other language.
> > Particularly
> > ones people are more familiar with. Could you outline any advantages is
> > might
> > have over, say, Perl (which also has inbuilt strings and memory management).
> >
> > Tim
>
> (* off-topic discussion *)
>
> Design and implementation are not as independant as i wish.
>
> As part of the design requirements, i pointed moves should be functions and be
> as composable as functions are. Practically that means the language must
> support:
> 1. anonymous functions
> 2. closures
> 3. partial application
> 4. type inference (Milner's type system)
>
> Java doesn't meet any of these requirements.
> Perl, Python and Ruby may barely meet 2 or 3 of the requirements.
> Scheme confortably meets 3 of the requirements.
>
> The 4 requirements together leave only 3 language candidates:
> 1. OCaml
> 2. Haskell (the successor of Miranda)
> 3. SML (Standard ML)
>
> OCaml is by far the most popular of them.
>
> Why is a Milner's type system so much needed ?
>
> Because of the heavy use of partial application.
> Partial application means you can't check the number of applied arguments.
> Thus
> code is very fragile: forgetting a function argument goes undetected, this
> leads
> to code that is clean to read but nightmarish to debug. The solution found by
> Robert Milner is a stronger typing system known as "Milner's type system".
>
> damien
I think you may need to explain you choices further. Python supports
variable numbers of function arguments, as does Perl. In Python it is
relatively easy to check the types of the arguments, and implement
overloading and type checking inside a function. In Python you can
pass around an object containing a function and call it.
Considering that (as you pointed out) animation is mathemetics and
matrix multiplication - I quote this posting from comp.lang.python:
[QUOTE]
To create a matrix the OCAML code is
7 let mkmatrix rows cols =
8 let count = ref 1 and last_col = cols - 1
9 and m = Array.make_matrix rows cols 0 in
10 for i = 0 to rows - 1 do
11 let mi = m.(i) in
12 for j = 0 to last_col do mi.(j) <- !count; incr count done;
13 done;
In Python with Numeric it's just
x = zeros([nrow,ncol],Float)
[/QUOTE]
OCaml is not a widely used, or recognised language - and asking people
to learn something that is even more esoteric than Perl would be a
complete turn off. Popular is not a word I would associate with it at
all. My point about usability is even stronger - when you use an
obscure language, most developers wouldnt even touch it, let alone the
end users. Please dont make something so over the top - Lego is
simple, and easy to use - and so should any tools built to work with
it be simple and readable.
Dont get me wrong - I like the idea of embedding a nice, scriptable,
object oriented, readable and high-level language so that complex
animations using mathematical functions could be created. But I
strongly feel the OCaml is not the way to do it, its not as readable
as other languages - and going into Milner is just not necessary.
OrionRobots
--
http://orionrobots.co.uk - Build Robots
|
|
| |
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
|
|
| |
In lugnet.cad.dev, danny staple <orionrobots@gmail.com> wrote:
>
> On 29/08/05, Damien Guichard <damien.guichard@wanadoo.fr> wrote:
> > In lugnet.cad, Timothy Gould wrote:
> > >
> > > Damien,
> > >
> > > I don't see the advantage in using OCaml over any other language.
> > > Particularly
> > > ones people are more familiar with. Could you outline any advantages is
> > > might
> > > have over, say, Perl (which also has inbuilt strings and memory management).
> > >
> > > Tim
> >
> > (* off-topic discussion *)
> >
> > Design and implementation are not as independant as i wish.
> >
> > As part of the design requirements, i pointed moves should be functions and be
> > as composable as functions are. Practically that means the language must
> > support:
> > 1. anonymous functions
> > 2. closures
> > 3. partial application
> > 4. type inference (Milner's type system)
> >
> > Java doesn't meet any of these requirements.
> > Perl, Python and Ruby may barely meet 2 or 3 of the requirements.
> > Scheme confortably meets 3 of the requirements.
> >
> > The 4 requirements together leave only 3 language candidates:
> > 1. OCaml
> > 2. Haskell (the successor of Miranda)
> > 3. SML (Standard ML)
> >
> > OCaml is by far the most popular of them.
> >
> > Why is a Milner's type system so much needed ?
> >
> > Because of the heavy use of partial application.
> > Partial application means you can't check the number of applied arguments.
> > Thus
> > code is very fragile: forgetting a function argument goes undetected, this
> > leads
> > to code that is clean to read but nightmarish to debug. The solution found by
> > Robert Milner is a stronger typing system known as "Milner's type system".
> >
> > damien
>
>
> I think you may need to explain you choices further. Python supports
> variable numbers of function arguments, as does Perl. In Python it is
> relatively easy to check the types of the arguments, and implement
> overloading and type checking inside a function. In Python you can
> pass around an object containing a function and call it.
>
> Considering that (as you pointed out) animation is mathemetics and
> matrix multiplication - I quote this posting from comp.lang.python:
>
> [QUOTE]
> To create a matrix the OCAML code is
>
> 7 let mkmatrix rows cols =
> 8 let count = ref 1 and last_col = cols - 1
> 9 and m = Array.make_matrix rows cols 0 in
> 10 for i = 0 to rows - 1 do
> 11 let mi = m.(i) in
> 12 for j = 0 to last_col do mi.(j) <- !count; incr count done;
> 13 done;
>
> In Python with Numeric it's just
>
> x = zeros([nrow,ncol],Float)
> [/QUOTE]
>
> OCaml is not a widely used, or recognised language - and asking people
> to learn something that is even more esoteric than Perl would be a
> complete turn off. Popular is not a word I would associate with it at
> all. My point about usability is even stronger - when you use an
> obscure language, most developers wouldnt even touch it, let alone the
> end users. Please dont make something so over the top - Lego is
> simple, and easy to use - and so should any tools built to work with
> it be simple and readable.
>
> Dont get me wrong - I like the idea of embedding a nice, scriptable,
> object oriented, readable and high-level language so that complex
> animations using mathematical functions could be created. But I
> strongly feel the OCaml is not the way to do it, its not as readable
> as other languages - and going into Milner is just not necessary.
>
> OrionRobots
(* off-topic discussion *)
To create a matrix the OCaml code is:
let x = Array.make_matrix nrow ncol 0.0
I acknowledge:
* OCaml is not widely used
* even more esoteric than Perl would be a complete turn off
* popular is not a word I would associate with OCaml (other than relativily to
Haskell)
* OCaml is obscure (assuming the average user is not familiar with
lambda-calculus)
I even add my own comment to the mix:
* OCaml sucks as an OOP language
These are facts and i won't deny.
Now why would i stick to OCaml?
I have read the thread "Lego CAD systems infuriating?" and it convinced me
usability is a user-concern. Users are zappers, they try and zap, try something
else and zap again in the vain hope that "Just imagine...", "Plug & Play", "Just
do it" are more than slogans.
There IS a barrier for CAD and animation. Whatever low the barrier it will be
too high anyway.
OCaml is a full-fledged functional language, and that's what i need.
Paste the 6 following lines in your OCaml top-level (this is the
implementation), there are a bunch of nonsense definitions:
let to_the () = ();;
let walk_minifig () () = ();;
let drive_car () () = ();;
let mario = ();;
let mario_car = ();;
let grocery_store = ();;
Now paste the 2 following lines (this is the end-user command) in the top-level:
(walk_minifig mario (to_the mario_car));
(drive_car mario_car (to_the grocery_store));;
The text is valid OCaml and executes nicely.
Suddenly what was an obscure OCaml implementation seems much like a natural
language interface.
What programming tricks i would use to derivate the animation from the user
command is my business, not the user concern.
My plan is to go bottom-up, to progress seamlessly from math concepts to natural
concepts. The first prototype would be inaccessible for the average lego
builder. But, incrementally, as more and more layers would be added, the command
line would be more and more pleasant to use. At the upper level the commands
would be usable both as a user command line tool and as a load/save text format
for a point-and-click interface.
We have the same usability goal, just you concentrate first on the interface, i
concentrate first on the implementation.
I don't see how "walk_minifig" and "drive_car" could be implemented.
Because they certainly need concepts i have not yet developped.
Probably they are just gimmicks and other commands will reveal more appropriate.
What is important is that the final user syntax will be readeable and
user-friendly. That is a long-term goal, the more abstract layers are added, the
less skills required for scripting:
* the lowest implementation level would be a quite stable animation engine
* above it would be generic animation commands
* above them would be domain-specific animation commands
The strength of OCaml is all user/developper levels would use the same language
that will seamlessly connect thus allowing incremental improvements.
The feedback would be straightforward:
* changes in the implementation would surface as improvements in the upper level
commands
* user requests would drive adjustments in the lower level commands
* as they progress advanced users would seamlessly become implementers
Having XML for datas and Python for commands would be having two languages, that
is playing Dr. XML & Mr. Python and separating the users from the implementers.
So when users would explain me why my tool is not useable i could answer "Just
do it".
Moreover i am not an OCaml believer, i have used Scheme, Smalltalk and Eiffel
previously and i know how "cutting-edge" technology can be misleading. So let me
assume the implementation failure before i can assume the interface failure.
Having a working implementation would already be a huge success for me.
damien
my lego web page: http://perso.wanadoo.fr/alphablock/
|
|
| |
> Right - now to James' question:
>
> To animate, you should probably use paths. Consider the format as
> objects, which are stored as XML.
Ok, you lost me. Are you talking about paths as lines and curves or paths as in
parent.child.grandchild? Because you mention XML and objects, I'm confused
(could mean XPath or OO...).
> 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.
Yes! I talk about overriding default origin here:
http://james.magnusviri.com/lego/animatable_models/
> 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.
I'm pretty sure you means paths as lines and curves, but I'm having a hard time
visualizing what you are describing.
> 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
Ah. So that is what it is called. Yes, I've gone crazy because of it.
> 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.
...
I'm lost. I've been reading about MEL, and I was VERY surprised to see that MEL
uses a clock just like POV-Ray. It makes me wonder if the 2 systems aren't that
different.
Anyway, so I think I know what you mean by nodes and objects. I know Maya has
history nodes. Does it also use keyframe nodes? Is that what you are referring
to?
What would your description actually look like formated as XML? Here is my
guess:
<model objectid=1>
<part color=bla origin=bla orientation=bla pathid=1 />
</model>
<path objectid=1>
<segment type=arc otherinfo=bla>
<node objectid=1keyframeid=1 />
</segment>
</path>
<keyframe objectid=1 timecode=bla />
James
|
|
| |
On 05/09/05, James Reynolds <james@magnusviri.com> wrote:
> > Right - now to James' question:
> >
> > To animate, you should probably use paths. Consider the format as
> > objects, which are stored as XML.
>
> Ok, you lost me. Are you talking about paths as lines and curves or paths as
> in
> parent.child.grandchild? Because you mention XML and objects, I'm confused
> (could mean XPath or OO...).
I did mean paths as in lines and curves, as I hope became apparent later on.
>
> > 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.
>
> Yes! I talk about overriding default origin here:
> http://james.magnusviri.com/lego/animatable_models/
Yes - I read that guide, and agree. The only awkward thing, which
would apply to this technique, is that it may make building steps a
little unnatural. Though you might be able to get it to look good in
LPub...
>
> > 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.
>
> I'm pretty sure you means paths as lines and curves, but I'm having a hard
> time
> visualizing what you are describing.
Yes - a single path (which may be closed or open), would basically be
a sequence of straight or curved lines. I was just describing the man
fancy ways which curves can be generated - which can allow you a lot
of freedom.
>
> > 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
>
> Ah. So that is what it is called. Yes, I've gone crazy because of it.
Gimbal lock gets animators and game coders tearing their hair out. It
is one thing that quarternions are good for dealing with, although
quarternions are fairly complex mathematical constucts - while more
powerful than a simple Euler matrices, but they have a steeper
learning curve. They are however what the professionals use. The UI
and API of course, are free to hide this away. In the UI - a nice
little rotation widget please...
>
> > 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.
> ...
>
> I'm lost. I've been reading about MEL, and I was VERY surprised to see that
> MEL
> uses a clock just like POV-Ray. It makes me wonder if the 2 systems aren't
> that
> different.
How do you mean? All of the formats I know about use a clock...
>
> Anyway, so I think I know what you mean by nodes and objects. I know Maya has
> history nodes. Does it also use keyframe nodes? Is that what you are
> referring
> to?
A keyframe node here is an object which ties a certain point along a
path to a timecode, and an object on that path at that time (multiple
objects might follow a path!).
>
> What would your description actually look like formated as XML? Here is my
> guess:
>
> <model objectid=1>
> <part color=bla origin=bla orientation=bla pathid=1 />
> </model>
> <path objectid=1>
> <segment type=arc otherinfo=bla>
> <node objectid=1keyframeid=1 />
> </segment>
> </path>
> <keyframe objectid=1 timecode=bla />
close - but not quite:
<model modelobjectid=1>
<part color=bla origin=bla orientation=bla pathid=1 />
</model>
<path pathobjectid=1>
<segment type=arc otherinfo=bla/>
<segment type=spline otherinfo=bla>
<controlpoint cpobjectid="1" x="1.0" y="blah" z="blah" otherinfo=blah/>
...(spline control points)...
</controlpoint>
</segment>
</path>
<keyframe keyframeobjectid=1 timecode="000000">
<!-- If you consider the length along a path segments as a floating
value between 0 and 1,
then, depending on your floating point precision - you can
represent any point along that
path with said value which we will call pathpoint. It is often
mathematically known as t-->
<node pathid = 1 pathpoint = 0.0 model = 1/>
<node pathid = 3 pathpoint = 1.0 model = 2/>
</keyframe>
<keyframe keyframeobjectid=2 timecode="002400">
<node pathid = 1 pathpoint = 0.5 model = 1/>
<node pathid = 3 pathpoint = 0.2 model = 2/>
</keyframe>
<keyframe keyframeobjectid=3 timecode="003500">
<node pathid = 3 pathpoint = 0.8 model = 2/>
</keyframe>
<keyframe keyframeobjectid=4 timecode="010000">
<node pathid = 1 pathpoint = 0.7 model = 1/>
</keyframe>
Okay - explaining this xml mouthful:
The first section describing the object is as you put it, that is
ideal. I have added one here, skipping others for conciseness.
In the second section, I describe a path - note I have given the
objects longer ID tags, this is only so people do not get confused and
think they are using a model ID in the pathid.
Note also, after the line seg, I have put a spline segment, just to
show that a path may consist of different types of line segments. I
have also skipped them, but imagine there are a few more paths....
Now the keyframes are where it gets interesting.
The first keyframe sets the initial scene, and which models are where
on which path in the first frame of the animation. The first keyframe
would be a requirement (something for the DTD?).
I put a comment in to describe pathpoint, a position along the path in
terms of t - a very useful method to describe travelling along a path
indeed, as it makes interpolation a lot simpler, you only need
interpolate t, then pass that into the path calculation functions
which will position your items. This says that in the first frame,
model1 starts at the beginning of path1, and model 2 starts at the end
of path 3.
Now on the next keyframe, say 24 seconds in, model 1 is now halfway
along path 1 - so the interpolation would mean at each second between
frame 1 and this keyframe, t is 0.5/24t along. Model2 is now however
one fifth along path 3, which means it has moved backwards four
fifths, so at each second, thats a variation (in terms of t) of
0.8/24t - depending on the relative lengths of path1 and path3, the
object on path3 will have moved furthar.
In keyframe 3, we only describe the bahaviour of model 2, at 35
seconds. This means that object 1 is not affected /at all/ on this
keyframe, and will be interpolated using the next keyframe that it is
referenced in. model 2 has now changed direction along its path, and
will have moved (0.8 - 0.2)/(35 -24) = 0.6/11 t/s along path3.
In keyframe 4, which for this example, we will only describe model 1
at 50 seconds. Since this is the last frame, and there is no furthar
infor,mation to interpolate for model2 on path3, then it is assumed
that it will remain stationary on 0.8t. However, model 1 has now moved
to 0.7t along path 1, and is interpolated from keyframe 2 - at 0.5t.
So the movement per second is now (0.7 - 0.5)/(50-24) = 0.2/26 t/s.
Now the beauty of this is that while I have now described the movement
along the paths, I have completely left out the actual frame numbers -
this means a render could be done with different frame rates, and when
played back, still be the same length, just smoother/coarser. This
means you could preview at 10fps and then render at 50fps.
An additon to this would be the 2d graphs for manipulating properties
- like rotation, which are simply a special case of a 2D only path, an
object/property reference as opposed to just the model ref, and still
have a current t.
Now, where Damien was probably going was the addition of formulae and
functions - for example describe t in terms of : t<path1> =
sine(somekeyframevalue).
This would be an additional XML block describing the actual function,
and then a different nodetype inside a keyframe plugging values into
the functions. The functions should be created so that they can take
an input in terms of t - which it can internally reference an
graph/path or some other function with. What the function actually
does, and what setup an instance of a function needs is the functions
own business. In that sense - it is a little like a callable class.
This class idea would mean that even the basic object along path node
is actually just a predefined function - and would give some sort of
uniformity to the description.
Now you get Damiens flexibility in real programming in the funtions,
and the simplicity of the XML referencing them. It is not a bold step
to reference function libraries. A UI would gloss this, so you could
import a library with particularly useful functions and a UI widget,
then build graphs or keyframes to provide inputs to the functions, and
even gloss over building the simplest functions. However - more
serious programmers could open up the code (still just XML and plain
text), and do something really fancy.
OrionRobots
--
http://orionrobots.co.uk - Build Robots
|
|
| |
Ok, this post took me a long time to get through...
> > > 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.
> >
> > Yes! I talk about overriding default origin here:
> > http://james.magnusviri.com/lego/animatable_models/
>
> Yes - I read that guide, and agree. The only awkward thing, which
> would apply to this technique, is that it may make building steps a
> little unnatural. Though you might be able to get it to look good in
> LPub...
Ah. I've never cared for instructions... I didn't take that into account when I
wrote the article...
> > > 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.
> > ...
> >
> > I'm lost. I've been reading about MEL, and I was VERY surprised to see that
> > MEL
> > uses a clock just like POV-Ray. It makes me wonder if the 2 systems aren't
> > that
> > different.
>
> How do you mean? All of the formats I know about use a clock...
I was only familiar with POV-Ray (well, I'm starting to be familiar with others
now that I'm reading) and I thought others were different, mainly because I've
read apologies for POV-Ray's clock, like it was a bad way of doing animation.
> <keyframe keyframeobjectid=1 timecode="000000">
> <!-- If you consider the length along a path segments as a floating
> value between 0 and 1,
> then, depending on your floating point precision - you can
> represent any point along that
> path with said value which we will call pathpoint. It is often
> mathematically known as t-->
> <node pathid = 1 pathpoint = 0.0 model = 1/>
> <node pathid = 3 pathpoint = 1.0 model = 2/>
> </keyframe>
> <keyframe keyframeobjectid=2 timecode="002400">
> <node pathid = 1 pathpoint = 0.5 model = 1/>
> <node pathid = 3 pathpoint = 0.2 model = 2/>
> </keyframe>
> <keyframe keyframeobjectid=3 timecode="003500">
> <node pathid = 3 pathpoint = 0.8 model = 2/>
> </keyframe>
> <keyframe keyframeobjectid=4 timecode="010000">
> <node pathid = 1 pathpoint = 0.7 model = 1/>
> </keyframe>
Ok. This all makes sense.
> An additon to this would be the 2d graphs for manipulating properties
> - like rotation, which are simply a special case of a 2D only path, an
> object/property reference as opposed to just the model ref, and still
> have a current t.
Not sure what you mean by this.
> Now, where Damien was probably going was the addition of formulae and
> functions - for example describe t in terms of : t<path1> =
> sine(somekeyframevalue).
Yes, this is what I want too: a way to specify acceleration, a way to specify t
so that more is available besides a linear change.
> This would be an additional XML block describing the actual function,
> and then a different nodetype inside a keyframe plugging values into
> the functions. The functions should be created so that they can take
> an input in terms of t - which it can internally reference an
> graph/path or some other function with. What the function actually
> does, and what setup an instance of a function needs is the functions
> own business. In that sense - it is a little like a callable class.
>
> This class idea would mean that even the basic object along path node
> is actually just a predefined function - and would give some sort of
> uniformity to the description.
>
> Now you get Damiens flexibility in real programming in the funtions,
> and the simplicity of the XML referencing them. It is not a bold step
> to reference function libraries. A UI would gloss this, so you could
> import a library with particularly useful functions and a UI widget,
> then build graphs or keyframes to provide inputs to the functions, and
> even gloss over building the simplest functions. However - more
> serious programmers could open up the code (still just XML and plain
> text), and do something really fancy.
A little confused here. For example, I'm not sure how I would specify a simple
acceleration between 2 keyframes. Here is an attempt:
<keyframe keyframeobjectid=3 timecode="003500">
<node pathid = 1 pathpoint = 0.0 model = 1>
<acceleration value=t*t>
</node>
</keyframe>
<keyframe keyframeobjectid=4 timecode="010000">
<node pathid = 1 pathpoint = 1.0 model = 1/>
</keyframe>
That isn't a very good guess, I know. This is what I haven't been able to
figure out at all. But this is the closest I've seen anything come up with
something useful!
Another example of modifying t. How do I say between keyframe a and b the model
is only located at t = 0.0 until keyframe 2 is reached? This type of modifying
t is what I really need to flush out.
Moving on.
Another thing to add to this is how to modify the model depending on what t is
as well. For example, a car's wheels should rotate as it moves. So the model
needs to be able to take t as a variable and have some way of changing itself
based on t.
Another example is my minifig macro. It takes the path and divides it into
points where the feet are going to land. Then as the minifig moves along the
path, the rotation of the legs are calculated so that the feet land on the
points and the whole body movement is smooth. So the actual location of the
minifig is not the value of t. Also, the feet landing points are calculated by
the sharpness of the turn. A straight path has large steps and the points are
far apart. A sharp turn has smaller steps and the points are closer together.
So the location of the minifig is nowhere near t.
See it in action:
http://www.antonraves.com/animations.php?actie=2&no=12&start=0&teller=13
Now this has nothing to do with acceleration I spoke about above. Of course
acceleration would affect this all, but they are independent. The movie example
has a 0 acceleration. The t is linear. But because of the other variables
(step length around turns) the actual minifig does slow down and speed up. If t
had acceleration, then the walk would start out slow, proceed like it does, then
slow down and stop. So you see they are independent: t and the actual location
of the model.
I'm not sure how to plug this in also. This could be left up to the rendering
engine to implement. In other words, send the rendering engine instructions.
Like I would put in POV-Ray commands and pass t as the controlling variable.
Then all the walk smarts is performed by my good old minifig macro. Or I could
even put in MEL commands if I were going to use Maya. Etc.
James
|
|
| |
Hi James, whew - this is getting to be a big mail, but I will try and
answer in situ...
On 14/09/05, James Reynolds <james@magnusviri.com> wrote:
> Ok, this post took me a long time to get through...
>
> > > > 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.
> > >
> > > Yes! I talk about overriding default origin here:
> > > http://james.magnusviri.com/lego/animatable_models/
> >
> > Yes - I read that guide, and agree. The only awkward thing, which
> > would apply to this technique, is that it may make building steps a
> > little unnatural. Though you might be able to get it to look good in
> > LPub...
>
> Ah. I've never cared for instructions... I didn't take that into account when
> I
> wrote the article...
I suppose I consider it part of the concept, so then I, or others can
build what I built, although given the original LDraw file, some may
be able to work it out themselves.
>
> > > > 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.
> > > ...
> > >
> > > I'm lost. I've been reading about MEL, and I was VERY surprised to see that
> > > MEL
> > > uses a clock just like POV-Ray. It makes me wonder if the 2 systems aren't
> > > that
> > > different.
> >
> > How do you mean? All of the formats I know about use a clock...
>
> I was only familiar with POV-Ray (well, I'm starting to be familiar with
> others
> now that I'm reading) and I thought others were different, mainly because I've
> read apologies for POV-Ray's clock, like it was a bad way of doing animation.
Hmmm - I am not sure about this. Maybe the concept is that instead of
having a clock, to use t-values for the timecode instead of
seconds/minutes, and that would mean you could time-stretch the
animation easily as well...
>
> > <keyframe keyframeobjectid=1 timecode="000000">
> > <!-- If you consider the length along a path segments as a floating
> > value between 0 and 1,
> > then, depending on your floating point precision - you can
> > represent any point along that
> > path with said value which we will call pathpoint. It is often
> > mathematically known as t-->
> > <node pathid = 1 pathpoint = 0.0 model = 1/>
> > <node pathid = 3 pathpoint = 1.0 model = 2/>
> > </keyframe>
> > <keyframe keyframeobjectid=2 timecode="002400">
> > <node pathid = 1 pathpoint = 0.5 model = 1/>
> > <node pathid = 3 pathpoint = 0.2 model = 2/>
> > </keyframe>
> > <keyframe keyframeobjectid=3 timecode="003500">
> > <node pathid = 3 pathpoint = 0.8 model = 2/>
> > </keyframe>
> > <keyframe keyframeobjectid=4 timecode="010000">
> > <node pathid = 1 pathpoint = 0.7 model = 1/>
> > </keyframe>
>
> Ok. This all makes sense.
>
> > An additon to this would be the 2d graphs for manipulating properties
> > - like rotation, which are simply a special case of a 2D only path, an
> > object/property reference as opposed to just the model ref, and still
> > have a current t.
>
> Not sure what you mean by this.
Okay, the basic path describes the translation of an object, but, as
you would in POV or other animation systems, there are other things
you would vary, such as rotation, colours, texture choices and so on.
Each of these could be described with a graph that is continuously
varying and interpolated like the paths. There may also be cases for
descretes, but even then, a fader/slider use of the graph may make
sense. These graphs may also be used to feed values for functions.
>
> > Now, where Damien was probably going was the addition of formulae and
> > functions - for example describe t in terms of : t<path1> =
> > sine(somekeyframevalue).
>
> Yes, this is what I want too: a way to specify acceleration, a way to specify
> t
> so that more is available besides a linear change.
Absolutely, and it may not merely be acceleration, but a function
could produce any number of interesting results. Again, by specifying
the start value for t (which regardless of which graph or function is
the required magic variable here), and end value for t, then the
software is left to interpolate those. So we may want to (for more
complex usage) modify the keyframe like so (I am going to get strict
with those XMl quotes now, we are going to need them):
<keyframe keyframeobjectid="4" timecode="010000">
<node pathid = "1" pathpoint = "sin(t) + 3 * t" t = "1.0" model = "1"/>
</keyframe>
Now the problem here is how to manage changes of functions between
keyframes, Ie for the first 20 seconds it follows that sine path, and
then it follows another. We may have an outgoing function (the one we
have been following), and a new function starting - or something to
declare that in the keyframe, as well as the final t value for the
outgoing function, and the initial t-value for the next function.
Though here, you would hope that there is a way to ensure that the
transition between functions is smooth, and does not jump - that may
be down to the user.
> > This would be an additional XML block describing the actual function,
> > and then a different nodetype inside a keyframe plugging values into
> > the functions. The functions should be created so that they can take
> > an input in terms of t - which it can internally reference an
> > graph/path or some other function with. What the function actually
> > does, and what setup an instance of a function needs is the functions
> > own business. In that sense - it is a little like a callable class.
> >
> > This class idea would mean that even the basic object along path node
> > is actually just a predefined function - and would give some sort of
> > uniformity to the description.
> >
> > Now you get Damiens flexibility in real programming in the funtions,
> > and the simplicity of the XML referencing them. It is not a bold step
> > to reference function libraries. A UI would gloss this, so you could
> > import a library with particularly useful functions and a UI widget,
> > then build graphs or keyframes to provide inputs to the functions, and
> > even gloss over building the simplest functions. However - more
> > serious programmers could open up the code (still just XML and plain
> > text), and do something really fancy.
>
> A little confused here. For example, I'm not sure how I would specify a
> simple
> acceleration between 2 keyframes. Here is an attempt:
>
> <keyframe keyframeobjectid=3 timecode="003500">
> <node pathid = 1 pathpoint = 0.0 model = 1>
> <acceleration value=t*t>
> </node>
> </keyframe>
> <keyframe keyframeobjectid=4 timecode="010000">
> <node pathid = 1 pathpoint = 1.0 model = 1/>
> </keyframe>
>
> That isn't a very good guess, I know. This is what I haven't been able to
> figure out at all. But this is the closest I've seen anything come up with
> something useful!
Again - taking a look above, this example could be served int he
following way. The starting point of the acceleration, and the end
point would be interpolated in terms of t. As we didnt specify a new
pathpoint function (ahah - now it is function interpolated in terms of
t, and not merely a constant), then on the outgoing final frame, it
uses the same one.
<keyframe keyframeobjectid="3" timecode="003500">
<node pathid = "1" pathpoint = "t * t" t="0.0" model = "1">
</node>
</keyframe>
<keyframe keyframeobjectid="4" timecode="010000">
<node pathid = "1" t="1.0" model = "1"/>
</keyframe>
If keyframe 4 is a transition, maybe something like the following
would work (this might be ugly - sorry):
<keyframe keyframeobjectid="4" timecode="010000">
<node pathid = "1" int="1.0" outpathpoint="1.0" model = "1"/>
</keyframe>
Again - this might be refactored, but i will explain. since we have
specified the incoming function in the previous frame, we should not
have to respecify it, on the value of t it will have at this end. That
is specified by the "int" attribute. As we are starting a new
function, we can then specify an output pathpoint "outpathpoint" and a
value t as "outt". Now we could say that if only a single constant is
put in the pathpoint, we do a simple linear interpolation and do not
need a seperate t attribute - however for consistency, although it is
a little more verbose, we might be better to make all pathpoints
specified in terms of t, even if there value is only "t". The latter
would certainly make it easier for both generator and editor software
as well as programmers although more verbose- its a defensive
technique, as it would be a bit too much to identify and interpolate
all the constants in the function, where simply assigning t in it is
much simpler, and having two methods could mean someone easily
slipping up and expecting a different result.
>
> Another example of modifying t. How do I say between keyframe a and b the
> model
> is only located at t = 0.0 until keyframe 2 is reached? This type of
> modifying
> t is what I really need to flush out.
If you mean the value t is stationary at 0.0, and then jumps to a new
value at exactly frame 2, then maybe this concept I have introduced of
incoming and outgoing values would be the solution. Again - it might
be something that could be tidied up, and I am not entirely happy with
it.
>
> Moving on.
>
> Another thing to add to this is how to modify the model depending on what t is
> as well. For example, a car's wheels should rotate as it moves. So the model
> needs to be able to take t as a variable and have some way of changing itself
> based on t.
This was the concept (that confused you a little) of the 2D graphs -
simply a path that is used to determine the value of the wheels
rotation, or a path that feeds a function of t that specifies the
rotation.
>
> Another example is my minifig macro. It takes the path and divides it into
> points where the feet are going to land. Then as the minifig moves along the
> path, the rotation of the legs are calculated so that the feet land on the
> points and the whole body movement is smooth. So the actual location of the
> minifig is not the value of t. Also, the feet landing points are calculated
> by
> the sharpness of the turn. A straight path has large steps and the points are
> far apart. A sharp turn has smaller steps and the points are closer together.
> So the location of the minifig is nowhere near t.
Now - the first thing is to remember that not every model is acted on
with every keyframe, other models/objects continue to be interpolate
to the next keyframe that specifies them. Next is that you could use
functions here to take the value of t along the path, and calculate or
use another path to work out where the feet should be placed. For
stuff involving legs and feet, I would maybe want to specify a
function library to handle bones and IK, so I can specify as
parameters to setup functions the origin, length, minumu and maximum
angles etc of the bones. This is complex stuff, but by having a
function library, which supplies functions the renderer can use
(python again? you are talking about an IK object, and I think we now
need variables to store those objects in!) as well as accompanying
code to help add plugin widgets to the UI to manipulate the functions.
Of course, a porgammer could also import and specify by hand the
parameters to those.
Have you played with Inverse Kinematics and similar stuff in MAX or maya?
>
> See it in action:
>
> http://www.antonraves.com/animations.php?actie=2&no=12&start=0&teller=13
>
> Now this has nothing to do with acceleration I spoke about above. Of course
> acceleration would affect this all, but they are independent. The movie
> example
> has a 0 acceleration. The t is linear. But because of the other variables
> (step length around turns) the actual minifig does slow down and speed up. If
> t
> had acceleration, then the walk would start out slow, proceed like it does,
> then
> slow down and stop. So you see they are independent: t and the actual
> location
> of the model.
Now we could use some sort of subreffing on our model to specify stuff
in relation to the current position of the origin of the model (which
if you remember the initial XML contained any number of PARTS), so
while the minifig takes a linear path, functions supplied to the
parameters (position, rotation, or IK values if we ue that route)
would be independant of that. To allow for the subreffing, we should
probably add an ID to the part, and we should also allow a model (as
an assembly of parts) to be embedded inside another model. The
subreffing syntax should be nice and concise, although numeric IDs
begin to become a little hard to see now - so maybe we need to name
them, in an OO style fashion.
Something like
...model = "minifig1.leg.lowerleg.foot"...
in the node tags, where the relationships are dependant upon where
things are joined, so the leg is joined to the minifig and oves with
that, and lowerleg is part of the leg and moves with that, and the
foot is joined to/part of the lowerleg and moves with that, as well as
each level possible getting its own path or function follow.
>
> I'm not sure how to plug this in also. This could be left up to the rendering
> engine to implement. In other words, send the rendering engine instructions.
> Like I would put in POV-Ray commands and pass t as the controlling variable.
> Then all the walk smarts is performed by my good old minifig macro. Or I
> could
> even put in MEL commands if I were going to use Maya. Etc.
My goal with this format is that it can deal with the smarts itself,
and by allowing function libraries and objects with variables from
python, it would be a very, very versatile system. However, it would
also be able to hide most of the really deep stuff from the user, kind
of like a very well written UI. I get the feeling python and xml
together could be a really neat combination, especially (AFAIK) there
are not many syntactic clashes between them, so embedding python in
the XML for specifying functions should be simple.
Maybe we could treat the parameters (the translation, rotation,
scaling or the path it is on and its current t value etc) of one model
as simply variables, to be reffed with the dot syntax.
The other amazing thing about these functions, and the joints here, is
that we start to be able to use this not merely for animation, but
also for simulation. Imagine that you have a module that knows how to
deal with the torque and RPM of a motor, or how to deal with a number
of technic gears, where it can begin to at least calculate which way
and at what speed they will turn, and possibly if they are impeded.
Imagine an extreme module library which allowed you to specify an NQC
file and then using the timecode through a python RCX simulator did
stuff there - I know this might seem way of the scale, but it would
not be impossible.
My interest in this is not simply animation you see, I am a Lego
builder and software engineer, but first and foremost I am a robot
builder, and being able to simulate Lego interactions as well as
animate would be a huge benefit to me.
Thanks for anybody who got this far - this is deep stuff, and we still
have to start somewhere a little more humble than RCX simulations, but
by thinking ahead, and planning for extensibility, there is a huge
mileage in this.
Danny
--
http://orionrobots.co.uk - Build Robots
|
|
| |
Ok. So this is exactly the reason I didn't want anyone to invent a
new animation scripting language for Legos! It is something new and
is in danger of: being a sucky 1.0 release (or worse, never reaching
1.0), and not getting widespread use and so it falls by the the
wayside and turns out to be a big waste of time. Isn't there stuff
out there that already does all of what we are talking about? If
yes, why shouldn't we just use it? If no, well, let's keep going!
This is great stuff! :)
> > > An additon to this would be the 2d graphs for manipulating
> > > properties
> > > - like rotation, which are simply a special case of a 2D only
> > > path, an
> > > object/property reference as opposed to just the model ref, and
> > > still
> > > have a current t.
>
>
> Okay, the basic path describes the translation of an object, but, as
> you would in POV or other animation systems, there are other things
> you would vary, such as rotation, colours, texture choices and so on.
> Each of these could be described with a graph that is continuously
> varying and interpolated like the paths. There may also be cases for
> descretes, but even then, a fader/slider use of the graph may make
> sense. These graphs may also be used to feed values for functions.
Bingo! This is exactly what I want! And I think it can be used to
solve the acceleration problem too.
Linear graph:
<graph graphid="1" function="t" />
Acceleration:
<graph graphid="2" function="t*t" />
Climbing wave:
<graph graphid="3" function="sin(t) + 3 * t"" />
etc etc.
> <keyframe keyframeobjectid="4" timecode="010000">
> <node pathid = "1" pathpoint = "sin(t) + 3 * t" t = "1.0" model
> = "1"/>
> </keyframe>
Doesn't that get confusing to have the pathpoint be variable?
Shouldn't it be a constant since it is used to determine what the
start pathpoint is for the start of the keyframe?
> Now the problem here is how to manage changes of functions between
> keyframes, Ie for the first 20 seconds it follows that sine path, and
> then it follows another. We may have an outgoing function (the one we
> have been following), and a new function starting - or something to
> declare that in the keyframe, as well as the final t value for the
> outgoing function, and the initial t-value for the next function.
> Though here, you would hope that there is a way to ensure that the
> transition between functions is smooth, and does not jump - that may
> be down to the user.
How about this. I believe we intend to use 2 keyframes to declare
the start and stop of an action:
<keyframe keyframeobjectid="4" timecode="010000">
<node model = "1"/>
</keyframe>
<keyframe keyframeobjectid="5" timecode="020000">
<node model = "1"/>
</keyframe>
That will apply to model 1 from 010000 to 020000. I'm wondering if
it would be good to allow a start and stop timecode in one keyframe
declaration:
<keyframe keyframeobjectid="5" starttimecode="010000"
endtimecode="020000">
<node model = "1"/>
</keyframe>
And allow a startpathpoint and endpathpoint for nodes. These next 2
code examples are identical (and both allowed):
Short version:
<keyframe keyframeobjectid="4" starttimecode="010000"
stoptimecode="020000">>
<node pathid="1" startpathpoint="0.5" endpathpoint="0.75"
graphid="3" model="1"/>
</keyframe>
Long version:
<keyframe keyframeobjectid="4" starttimecode ="010000">
<node pathid="1" startpathpoint="0.5" graphid="3" model="1"/>
</keyframe>
<keyframe keyframeobjectid="5" starttimecode ="020000">
<node startpathpoint="0.75" model="1"/>
</keyframe>
[The reason I left pathid and graphid off of keyframe 5 is because
those 2 attributes apply to the *next* set of frames, not the
previous set. So in keyframe 5, if I specified a pathid and graphid
they would apply until the next keyframe for model 1 or the end of
the animation.]
So both examples are enough to figure out everything that happens to
model 1 from 010000 to 019999.
So at 010000, the location of model 1 is calculated like this:
x,y,z = pathid[1](graphid[3](0.5))
And at 019999, the location of model 1 is calculated like this:
x,y,z = pathid[1](graphid[3](0.75))
Actually the value passed to to graphid[3] would be a tiny bit less
than .75 because at 020000 it is .75. But at 020000 it will be using
a different path and graphid... So the stoptimecode really specifies
the next timecode. Maybe it should be named nexttimecode...
The output of graphid[x](0) should always be 0. The result of graphid
[x](1) should always be 1. The graph is intended to only modify
acceleration. But because t is always suppose to be between 0 and 1,
the output of graphid is also between 0 and 1.
> > Another example is my minifig macro. It takes the path and
> > divides it into
> > points where the feet are going to land.....
>
>
> Now - the first thing is to remember that not every model is acted on
> with every keyframe, other models/objects continue to be interpolate
> to the next keyframe that specifies them. Next is that you could use
> functions here to take the value of t along the path, and calculate or
> use another path to work out where the feet should be placed. For
> stuff involving legs and feet, I would maybe want to specify a
> function library to handle bones and IK, so I can specify as
> parameters to setup functions the origin, length, minumu and maximum
> angles etc of the bones. This is complex stuff, but by having a
> function library, which supplies functions the renderer can use
> (python again? you are talking about an IK object, and I think we now
> need variables to store those objects in!) as well as accompanying
> code to help add plugin widgets to the UI to manipulate the functions.
> Of course, a porgammer could also import and specify by hand the
> parameters to those.
I'm thinking for starters just passing the parameters to the povray
code and not trying to implement it in the script yet.
> Have you played with Inverse Kinematics and similar stuff in MAX or
> maya?
Aha. Another one of those "oh, that is what it is called" moments.
I haven't played with IK in MAX or Maya, but I have tried to write my
own in POV-Ray. I had to get help, but I have done some IK for a
complex leg (not a minifig) on one plane. Adding the other planes
proved to be too much and remains unfinished.
> My goal with this format is that it can deal with the smarts itself,
> and by allowing function libraries and objects with variables from
> python, it would be a very, very versatile system. However, it would
> also be able to hide most of the really deep stuff from the user, kind
> of like a very well written UI. I get the feeling python and xml
> together could be a really neat combination, especially (AFAIK) there
> are not many syntactic clashes between them, so embedding python in
> the XML for specifying functions should be simple.
My goal is to make my povray animations easier. I probably have a
bit of a different slant also. As with my minifig macro, I intend on
having my models already built in povray. So my <model></model>
stuff will pretty much be empty but refer to the povray model name.
Also, I don't know Python. I just need an excuse to learn it
though. But I do know Perl well.
> Maybe we could treat the parameters (the translation, rotation,
> scaling or the path it is on and its current t value etc) of one model
> as simply variables, to be reffed with the dot syntax.
Yup.
> The other amazing thing about these functions, and the joints here, is
> that we start to be able to use this not merely for animation, but
> also for simulation. Imagine that you have a module that knows how to
> deal with the torque and RPM of a motor, or how to deal with a number
> of technic gears, where it can begin to at least calculate which way
> and at what speed they will turn, and possibly if they are impeded.
> Imagine an extreme module library which allowed you to specify an NQC
> file and then using the timecode through a python RCX simulator did
> stuff there - I know this might seem way of the scale, but it would
> not be impossible.
>
> My interest in this is not simply animation you see, I am a Lego
> builder and software engineer, but first and foremost I am a robot
> builder, and being able to simulate Lego interactions as well as
> animate would be a huge benefit to me.
Yes, I wanted this too! But that is way over my head. I do think it
would be cool to plan that in.
James
|
|
| |
In lugnet.cad, James Reynolds wrote:
> Ok. So this is exactly the reason I didn't want anyone to invent a
> new animation scripting language for Legos!
IMHO there is no reason why someone can't invent something new.
Especially as anything new would be still compatible with LDraw standards
(otherwise the author would have to reinvent the wheel, the LDraw library and
the existing Lego-Cad tools which would require several human lives).
> It is something new and
> is in danger of: being a sucky 1.0 release (or worse, never reaching
> 1.0), and not getting widespread use and so it falls by the the
> wayside and turns out to be a big waste of time.
Is something is new then:
* if it never reaches 1.0 it's died (no consequence for you)
* if it's sucky 1.0 it dies (no consequence for you)
* if it's a waste of time and effort (for its author) then no consequence for
you
* if it's not getting widespread use that means it's mitigated success, meaning
the tool is useful for some people and lays the bases for future and better
tools that will appeal to more people. you can't underestimate laying the bases,
when thing are uttermost complex (and animation-scripting really is), then
laying some bases is already a great achievement. succeeding the first time is
not always possible, failure or semi-failure is a premise for success.
> Isn't there stuff
> out there that already does all of what we are talking about? If
> yes, why shouldn't we just use it? If no, well, let's keep going!
> This is great stuff! :)
If something is new and doesn't do better than what exists then it dies (again,
no consequence).
> It is something new and
> is in danger of:
Where is the danger? Do we look so dangerous? My opinion is that you are
overreacting because you anticipate much too far. You anticipate the community
is splitting. That's not what i see, what i see here everyday is friendly people
exchanging many exciting ideas. May be 1% of these will see the light of day, so
you don't need to overreact just because the other 99% are crappy. You simply
can't have the 1% good ideas implemented if anyone can't express their 99%
foolish dreams.
There is this forum to discuss anything.
There are commitees to define and protect the standards.
None of the 2 is a danger, there are just complementary, they balance innovation
and the protection of the user time-investment.
Both are necessary.
Regards,
- damien
web page: http://perso.wanadoo.fr/alphablock/
|
|
|
