[Fluxus] parenting and frames of reference

[Kassen]

Dear list,


The next step in my quest would hopefully be parenting and tasks, or from a
more amusing perspective, "let's build a working windmill". A bit to my
surprise tasks and parenting are fairly easy to get the hang of but they do
lead to questions in the details. Below is some code for a rudimentary
windmill (I'm Dutch after all). The blades rotate around a cube which they
are parented to and a task makes the cube rotate. As the blades get defined
with the cube as a frame of reference, the standard cube has it's centre as
it's origin and a cylinder has it's base as it's origin this seemed like a
safe perspective, but that doesn't turn out to be true. when we translate
the whole windmill by tweaking the bottom lines a bit it turns out that the
centre of the rotation isn't the centre of the blades and I'm at a complete
loss about why this is. I'd say I'm defining the blades by rotating around
the origin of the cube, then rotating the cube (around it's origin) so this
should be fine.

In fact; the further we translate the whole windmill the further the origin
of the blades gets away from the centre of rotation in the dimension(s)
concerned, leading me to believe we are dealing with some phenomenon related
to both origin and scale. My question is "what phenomenon?".

Another issue I found is that tasks are named but those names aren't
affected by name-space/scope. In other words; we can make the movement of
the mill a part of the mill's code (this is nice) but when we then build 5
windmills only the last one will actually move as the names are the same. I
see two solutions here; looking into frisbee which promises to make
behaviour a part of the object (in ways I don't yet understand) or create a
list of "windmill axles" in the global scope, have each defined windmill add
it's axle at the end and write a single task to update all axles each frame.
What would be smarter?

Finally, I'm finding that some errors in coding are a sure-fire way to crash
Fluxus outright, especially "let" and "for*" expressions with the outer
brackets of the defining list forgotten by novice schemers. I feel crashing
a system like this outright because of a typo is a bug. Should these be
reported to the list or is there another method that would be prefered?

Yours,
Kas.


Windmill code follow, sorry about my fight with the frame of reference,
rotation-wise.

(clear-colour (vector 0 0 1))
(clear)

(with-primitive (build-plane)
    (scale 10)
    (colour (vector 0 1 0)))

(define (build-windmill)
    (define a
        (with-state
            (translate (vector 0 -1 2))
            (colour (vector .2 .2 0))
            (scale .1)
            (build-cube)))

    (with-primitive a

    (with-state
        (rotate (vector 0 90 90))
        (for* ((x (in-range 0 4)))
            (rotate (vector (* 90 x) 0 0 ))
            (with-state
                (colour (vector .2 .2 0))

                (scale (vector  .8 14 .8 ))
                (parent a)
                (build-cylinder 4 4))
            (with-state
                (colour (vector .2 .2 0))
                (rotate (vector 0 90 0))
                (scale (vector 10 3 1))
                (translate (vector .9 .5 0))

                (parent a)
                (build-plane)))))

    (with-state
        (colour (vector .9 .9 .9))
        (with-primitive (build-cylinder 10 10)
            (rotate (vector 90 0 0))
            (scale (vector 1 2 1)))
        (with-primitive (build-sphere 10 10)
            (translate (vector 0 0 2))
            (rotate (vector 90 0 0))
            ))



    (spawn-task ( lambda () (with-primitive a (rotate (vector 0 (* 45
(delta)) 0)))) 'mill-turn)

)

(with-state
(translate (vector 0 0 0))
(build-windmill))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20090815/b627c100/attachment-0002.htm>