Subject:
|
Re: Restart of LDA2001 Project (using LDraw models - L3P - POV)
|
Newsgroups:
|
lugnet.cad.ray, lugnet.animation
|
Date:
|
Wed, 12 Jan 2005 08:35:35 GMT
|
Viewed:
|
177 times
|
| |
|
|
> You still have to impress me. It way too complicated to be even close to
> user-friendly.
Ok, so I'll explain why I'm going with POV-Ray.
First, did you see this:
http://www.ldraw.org/article/348
Oh, install Quicktime to see the MPEG4 (MPEG4 is a standard, I don't know why
Windows Media Player wont display it). Anyway, I had to install Divx to see
that AVI. :)
I'm just barely starting to understand POV-Ray and I came up with that. Sure,
it is Anton Raves' lib, but the actual animation code (moving the ships) would
be identical (except a different scale) for LDraw models.
---
Second, I'm not saying you shouldn't make a tool. I'm just saying why I finally
decided to let mine die. I think it would be great if you did make one. It
would certainly make animation available to people who will never use POV-Ray.
But if you want some real power, you will have to use POV-Ray. Read on.
---
So, one of the big reasons I wanted a tool was because I wanted to animate
Mechs. So I came up with the link and pivot point stuff. POV-Ray has all of
this already. It is done with Unions and Macros. I just haven't gotten around
to making a Mech move yet (I plan on converting some of Mladen's to Anton's lib
soon). Here is what a minifig looks like with correct unions (this is one of
Anton's minifigs--I have taken some details out to make it simpler to read):
#macro man_010(headrotation, rightarmrotation, leftarmrotation, leftlegrotation,
rightlegrotation, lefthandrotation, righthandrotation, bodyrotation)
union {
object { left_leg(green_tex) rotate rightlegrotation*x }
object { right_leg(green_tex) rotate leftlegrotation*x }
union {
object { leg_joiner(green_tex) }
object { body(green_tex) translate <0, 5.05, 0> }
}
union {
object { left_arm(white_tex) }
object { hand(yellow_tex) rotate lefthandrotation*z rotate -45*x
translate <2.15, -8, -3.5> }
rotate leftarmrotation*x rotate 10*z translate <6.15, 14.05, 0>
}
union {
object { right_arm(white_tex) }
object { hand(yellow_tex) rotate righthandrotation*z rotate -45*x
translate <-2.15, -8, -3.5> }
rotate rightarmrotation*x rotate -10*z translate <-6.15, 14.05, 0>
}
union {
object { head( ...face code here... ,1)
}
object { cap(red_tex) rotate -90*y translate <0, 24.05, 0> }
rotate headrotation*y
}
rotate bodyrotation*x
}
}
#end
So when the right_arm rotates, the hand rotates with it and I don't have to tell
it to. Using the macro, I can rotate the arm by calling the macro:
man_010(headrotation, 10 + 40 * my_clock, leftarmrotation, leftlegrotation,
rightlegrotation, lefthandrotation, righthandrotation, bodyrotation)
(all the other variables would be need to be replaced with numbers or predefined
variables)
If my_clock moves from 0 to 1, then the starting rotation is 10, the end
rotation is 50.
If I want it to accelerate and decelerate, I can use my own math, but I forgot
everything from Calculus several years ago, so I can't even remember how to do
that. So I cheat and use:
Interpolate(clock-start_scene,start_scene,end_scene,250,-250,0)
Which, in that form, accelerates and decelerates.
There is also the AutoClock macro that does a similar thing.
So this satisfies one of my main needs, which is the ability to move the hand
when I move the arm.
If I wanted to move the hand and have that move the arm, that is also possible,
but not the way I have it defined here. It would take a bit more logic. I'm
trying to figure this part out, because walking is more like the feet move the
minifig. In the macro I have and the other animation linked in this thread, the
body moves, and the feet swing with the movement. This isn't as realistic. I
do like the way stopmotion people are doing it more and I intend to duplicate
that eventually.
---
Another need was pivot points and rotation axises. Notice the arm again:
union {
object { left_arm(white_tex) }
object { hand(yellow_tex) rotate lefthandrotation*z rotate -45*x
translate <2.15, -8, -3.5> }
rotate leftarmrotation*x rotate 10*z translate <6.15, 14.05, 0>
}
The rotate 10*z and translate <6.15, 14.05, 0> declares the pivot point and
rotation axis. This can be hard to figure out, but it has to be done no matter
what, if you have your own tool or if you use POV-Ray.
---
Another need was splines. Chris Colefax solved it all. I'm sending you to page
3 because it shows how splines are used in POV-Ray for animating objects. Take
a look at the movie of the ball towards the bottom of the page.
http://www.geocities.com/ccolefax/spline/tutorial3.html
---
Another need was camera control. Again, POV-Ray already does it. There are
many settings to simulate a real camera. I can even get lens flares.
http://www.nathan.kopp.com/nkflare.htm
If I want to repeat a scene from a different camera angle, that is easy. I use
a switch statement where I set the scene clock back and set the camera to a
different location. (note, in most of my animations I have my main_clock start
at 1 and increment by 1 for each frame--it is easier to read this way I think)
#switch (main_clock)
#range (1,10)
#declare scene_clock = main_clock; // Clock moves from 1 to 10
camera {
location Camera_Location_1
look_at Camera_Look_At_1
...
}
#break
#range (11, 20)
#declare scene_clock = main_clock - 10; // Clock moves from 1 to 10
camera {
location Camera_Location_2
look_at Camera_Look_At_2
...
}
#break
#end
---
Another need was ray tracing the results. I was planning on using POV-Ray
anyway. By using POV-Ray for the whole thing, I am forcing myself to learn how
to deal with lights and other issues like texture maps (backgrounds), height
fields for terrain, special effects like fog, clouds, underwater, stars,
galaxys, etc.
And by using POV-Ray the whole time, I don't have to worry about defining a
bridging mechanism for the tool so I can do something like animating fog. This
is easy within a povray file, but would be very hard to define in a tool. In
other words, the tool has to bridge the raytracer features or it forces the user
to add that to the tool's output file in order to animate those features (like
fog or water).
Oh, and particle systems are already solved in POV-Ray:
http://runevision.com/3d/include/particles/
---
Finally, the real reason I switched to POV-Ray was because I rendered a bunch of
Mladen's models by using l3p to convert the ldr to pov. I scripted l3p to use a
different camera position for each frame. See here:
http://www.macos.utah.edu/Documentation/xgrid/povray.html
I was very unhappy with the lighting. So I went looking for how to do it right,
and I came across Anton Raves' site. I saw his animations and decided right
then to do it how he was doing it. His parts weren't LDraw, so I was pretty
much forced to work within POV-Ray. After working with it for awhile (almost a
year now), I came to see all of the benifits I describe above.
---
Another thing, there are GUI POV-Ray editors for Windows. Not for Mac. :( So
I have been using text editors to code everything.
---
> Have you seen the works at BrickFilms.com ? The stop-motion gang leads by at
> least 50-1 against us! It's time to make a change here.
I love the stuff they are doing! I actually bought iStopMotion and was going to
start doing my own stop motions, but I decided to keep doing virtual.
> sorry, I don't mean to strike down on anyone's efforts, but the scarce pages I
> found so far is not much of help for me at all - until then I will try to work
> my path and you are free to work yours.
You are right, nobody is really using POV-Ray animations with Legos. I am
amazed nobody is...
> Sorry for the harsh words, I'm not angry or trying to hurt you or
> boasting at your expense (hey, my own project has been standing still for 3
> years!), and I really hope that I'm wrong. But, like I said before, so far I'm
> not at all impressed by the progress I have seen.
Yup! No offense or anything else taken. I'm just getting started! I hope to
knock some socks off soon, and am more than willing to help others.
In fact, I'm looking for help too. I need ldraw models of buildings and
landscape. If possible, limit your models to parts in Anton's library:
http://www.antonraves.com/reference_gallery.php?actie=1&start=0&grootte=1
It is possible to add more parts to his library, but that will slow everything
down.
And yes, we do use LDraw to create stuff and convert it to his library.
Scripts are good too. I plan on using Erik Olson's Spheriod script.
http://olson.pair.com/moc/spheroid/
I might have to write one to generate landscape and generic houses (used as
background).
Has anyone really thought about automating the process of creating models like
homes? For example, from a height field that represents walls? I need alot of
scenery, so meticulous detail to a background home isn't really needed...
These are all things I am playing with.
James
|
|
Message is in Reply To:
28 Messages in This Thread:
  
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
