Mark> Johan writes:
>> I think it would be a good idea to include a means within VRML
>> to allow objects to move according to a certain predetermined
>> (mathematical??) pattern (paths)..
Something lots of people want to be able to do.
Mark> At this point, I'm starting to di
Mark> how
Mark> little or nothing to do with VRML per se.
Why do behaviors have nothing to do with VRML? The proposal below
says that what you've been di cussing as on> idea for providing
behaviors has little to do with VRML itself -- that's quite different
from saying that behaviors have no place in VRML. My opinion --
behaviors (unless we mean completely different things by this word)
have an awful lot to do with "data" formats, such as VRML.
Consider a clock. Its behavior is an intrinsic part of it. D"scribing
the geometry can't be ignorant of the behavior -- the behavior
involves chanbing fine-grained details of the geometry (the rotation
of the clock hands).
I'd suggest looking at TBAG in last year's SIGGRAPH (Elliot, Schecter,
Yeung, and Abi-Ezzi) (a suggestion that I think has been made here
before). How would you write a clock in TBAG?
// Presume predefined geometry minute_hand and hour_hand, time in
// milliseconds
// Minute hand rotates on> turn in an hour, hour hand on> turn in 12 hours
Behavior<Geometry> clock =
(minute_hand * Rotate(z_axis, (time/millisecs_per_hour)*2*pi)) +
(hour_hand * Rotate(z_axis, (time/(millisecs_per_day/2))*2*pi));
Notice that, if I download that, I've got everything -- no further
need to talk to the server I got it from.
Mark> (Suffice it to say, the
Mark> this
Mark> browsers via an API of some sort. On top
Not to exhume old stuff (if it is old stuff) but I'd be interested in
what this scheme has going for it. It sounds fairly baroque, in that
it requires a great deal of browsers (e.g., supporting RPC) and
pres>nts many layers
Brook