Hmm, I should have picked my example more carefully. I can see how
this could confuse. No, it doesn't mean dynamically moving the blocks
in the scene. Only in the procedural construction
of the scene because in tsipp objects are abstractly instantiated at
the origin and then moved into position, either relative to the origin
or relative to some other object so that composites can be easily
built and moved.
> that would be the only thing not possible (as I
> understand it) with a purely declarative language. Well, not possible
> is perhaps not true. That is the scripting vs API thread really, as an
> attribute of the object can be declared which defines the behavior of
> the object. This does not necessarily require the VRML language to be
> anything more than descriptive.
>
> So, in setting a variable, you are actually just declaring the
> attributes of an object.
Perhaps, in the sense of a class or a prototype, in the statement:
set cornerBlock [SippBlock {.5 .5 5} $metal_dull WORLD]
but from this statement $cornerBlock is a handle variable to the
class that can be used later in additional instantiations.
Linas is convincing me that this can be done declaratively, but I don't
yet understand the declarative way of doing things that I would typically
do with iteration in a procedural language.
> If you wish dynamic action, then there is
> indeed a problem. (but from my understanding, VRML is intended to be
> static, like HTML)
I assume by "dynamic" you mean: with further interaction with the VRML
server?
No I wasn't looking for dynamic action (yet), just efficient representation
of a scene across the network.
BTW I hope "static" VRML doesn't exclude the possibility of moving the
camera viewpoint dynamically and independently in each browser?
If you have encoded a 3d scene then presumably you have enough
information locally for this kind of dynamics without further
interaction with a VRML server?
John Ellson
AT&T Bell Labs