"John Keing" <joh### [at] yahoocom> wrote in message
news:3db5b520@news.povray.org...
>
> I've got the following questions, hope you can explain them to me. Thanks.

Okay, hope I can answer in a way you understand.

> 1) In your code for defining a box, what does "-1,1" mean? I know we need
to
> take 2 opposite 3D corners for defining a box.

In many of the primitive shapes floats immediately after the first brace are
converted to vectors so 1 is really <1,1,1>. An example of something that
doesn't do that is torus {}, but sphere {} does. box {} takes two, sphere {}
only one.

> 2) There are 10 frames, so the clock takes approximately 0.11 for each
> frame. Am I right?

Yes, you can check it by using keyword clock_delta to write to the message
stream. It is a subclock value per frame. So:

#debug concat("Per frame clock value is ",str(clock_delta,1,-1),"\n")

will do that.

>     So, for frame 1, clock=0, Count=0 ==> no box is created
>           for frame 2, clock=0.11, Count=0, Count<5*clock is true==> first
> box is created and Count=1
>           for frame 3, clock=0.22, Count=1, Count<5*clock is true==>second
> box is created and Count=2
>           problem comes for frame 4, clock=0.33, Count=2, Count<5*clock is
> false==>no box is created! However, another new box is
>           created! Why? The program should go out the while loop.
>
>     Also, how can you determine "Count<5*clock" can stack 5 boxes only?

It's just math (ha-ha)... Actually, frame_number instead of clock for such
things can be far more intuitive. It does get a bit deceptive unless you are
certain of what clock is doing. Even if int(clock*10) is used you end up
with 0,1,2,3,4,5,6,7,8,10 and no 9. Not exactly expected, but for the
example it doesn't matter. I'm not sure of the reason for this myself, I
don't remember past conversations about it which I'm fairly certain have
occured.
Idea was to go from 0 to 4 which equals 5 steps. It could also be 1 to 5,
(Count<6).

> 3) I would like to know the relationship between the frame, clock and the
> objects appear in each frame.
>
>     How do they work out to show an animation?

Easy. All objects (including camera, lights, unions, etc.) with a clock
variable used within their statements will shift, by the amount specified in
the clock equation, for every frame. Since clock is often set to run from 0
to 1 that means

box {-1,1 translate <3,0,0>*clock

is going to move that box 3 POV units to the  positive x direction over the
course of however many frames you state. And thats the relationship between
clock and frames, doesn't matter what number of them you use, whether 10 or
100 it will still only move 3 units. The factor here then is speed, a 10
frame animation of that will look like the box jumps right over to the side
and a 100 frame animation will look like it is slowly sliding across.

> 4) The example you gave is simple to let me know how to generate
animation.
> However, if I want to display an alphabet by boxes
>     say , "C", how can I do that?
>
>     It's not the same as stacking the boxes in one direction. Could you
> please show me the ways of doing this? I mean how you design the
>     scene. Also, how to determine the number of frames are appropriate?

What you'd be doing is creating a text object placed onto a box, either by
intersection or difference, or even union of the two primitives.

Let's say you want each lettered box to appear for 10 frames. You'd need a
270 frame animation so each letter is shown in succession 26 times. 0 to 10,
10 to 20, etc. up to 260 to 270 so that the last letter is inclusive.

#switch (clock) // frame_number here instead would be better...
#range (0*clock_delta,1*clock_delta) // ... so ranges would then be
(0,10)...
object {AlphabetBox_A}
#break
#range (1*clock_delta,2*clock_delta) // ... (10,20), etc. instead of using
clock_delta
object {AlphabetBox_B}
#break
#range (2*clock_delta,3*clock_delta)
object {AlphabetBox_C}
#break
...
#range (25*clock_delta,26*clock_delta) // last range
object {AlphabetBox_Z}
#break
#end

To actually rework the CSG into each letter, instead of creating one of
each, you can use chr() in the text {} object. You'll need to look up that
in Scene Help section 6.1.7 about string functions and check your font
numbering in something like Windows' Character Map (usually found in Start,
Programs, Accessories, System Tools).

> 5) My final question is I have added the following code to your example:
>
> plane {
>    y, 0
>
> Why the first created box looks smaller than the others? However, every
box
> looks the same size if the above code is not added.

My boxes weren't adapted for a y plane, they need to start 1 unit upward.
The -1 to 1 size of each box makes them go from -y to +y.

> Sorry for so many questions. If I don't have a good and clear concept, I
> know I can't move on to do anything.
> Hope you can help me!

Well, questions are all a part of it, but  a capability to learn the POV-Ray
documentation is still a priority. Hope I have helped.

Post a reply to this message