Warp <war### [at] tagpovrayorg> wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:

> > My point of view is that within a single frame, all transforms should be
> > defined at creation time, and post creation transforms should be forbidden
>
>   Why impose such an artificial limitation? It doesn't make any sense.
>
> --
>                                                           - Warp

I agree there is no technical limitation. But I can see drawbacks. In the
current syntax, we write

#declare my_sphere = sphere
{
   0, 1
   pigment {White}
   translate <1,2,3>
}
..../...
trace (my_sphere, ...)

Once the sphere has been created (= after the ending '}' of the syntactical
block), the sphere stays how it is and we have no mean to apply a new
transform to it afterwards. The only way I see to fake this is to create a
new object and transform it:

#declare my_sphere_2 = object {my_sphere translate <4,5,6>}

But the first sphere remains present (even if it had no_image, no_shadow
....).


The new syntax might allow such code:

my_sphere = sphere
{
   0, 1
   pigment {White}
   translate <1,2,3>
}
..../...

my_sphere.translate y;

trace (my_sphere, ...)

And you get what you want, for animations for example, provided you are
programmatically skilled enough to keep track of your objects and what
happens to them.

My opinion (I'd rather say my 'intuition', but may change, I am not that
proud of myself) is that if you perform transformations in different
locations in the code, perhaps out of the scope of the current source file,
you can never be sure for the current object's situation, and therefore for
the end result.

I agree that, with current syntax, you can store transforms in an array,
access this array through the clock or frame_number variable. But I find
this not very handy. I would prefer a build-in mechanism for animations
with relevant syntax. For example, if we attach timelines to objects, we
could write (I put it as it comes to my mind, I am trying ...):

DURATION = 25;

ejection = timeline (direction:vector)  // could be 'animate' keyword
{
    function
    {
        <parabolic trajectory equation>
        return <computed transform>
    }
}

stone
{
    0, 1
    roundness 0.3
    random 123.456
    pigment
    {
        timeline
        {
            [0 agate turbulence 0.3 color_map{CM_LAVA_HOT}] // t<=0
            [2 granite turbulence 0.3 color_map{CM_LAVA_SEMI_HOT}] // t=2
            [5 agate turbulence 0.3 color_map{CM_VOLCANIC}] // t=5
            cycle 3 // restart at t=3 for t>5*n
            interpolate 2
        }
    }

    transform
    {
        translate {CRATER_POS}
        timeline {ejection (DURATION)}
    }
}

And POV4 does the job. And 3rd party tools could easyly generate code for
anims.

Bruno.

Post a reply to this message