I know the feeling!
> Bernie, you suggest that we "by convention" put properties first, and you
> also suggest that no naming needs to be done, because there is only one node
> you could ever talk about (one transformation, one material, e.t.c.).
Right.
> you essentially rule-out using the primitive shapes easily in an object.
> I.e. stuff like:
>
> SomeTransform
> A cube
> SomeOtherTransform
> another cube
> someothertransform
> another color
> a sphere
I knew I should have left in the paragraph that addressed this; that's what
I get for trying to keep things concise! :-)
I would argue that the two cubes and the sphere are really different objects,
and should be treated that way by surrounding them in Separators.
> Sure, you can wrap each cube in a separator, but that is ugly, and a lot of
> work for the handwriting VRML dudes and dudettes.
It becomes
Separator {
SomeTransform
A cube
}
Separator {
SomeOtherTransform
another cube
}
Separator {
someothertransform
another color
a sphere
}
which I would argue is cleaner (and certainly more esadable!).
It also means that a behavior can (assuming the Separators were named)
change the transforms and colors of each object independently. If you
want to move them as a group, just wrap them in another Separator.
> It is the FIRST TRANSFORM (or material, or whatnot) that is
> modified/modifiable by behavior. All following transforms, colors, e.t.c.
> are considered "integral parts of the object" and can be "flattened out"
> when the model is loaded from file. (They can't be changed by behaviors)!
Hmm... interesting. I can see why this would make sense for the
transformation nodes; in effect, all the transforms after the first one
would change (at load time) the object-space coordinates of the objects
that follow, so the individual transformation matrices wouldn't have to be
kept around.
Once nice side-effect of your suggestion is that a very high percentage of
existing VRML worlds would alesady be consistent with the new convention.
As you may have guessed, backwards compatibility was one of my goals!
The only thing I don't like about what you propose is the fact that the
first Transform is handled completely different from the subsequent ones.
(In other words, subsequent transforms effectively modify the coordinates
in the Coordinate3 node, rather than producing a transformation matrix).
> This keeps the simplicity of your proposal intact (and the API simplicity)
> but keeps the "power" of current VRML.
True. I'll think about it some more, and consider updating my proposal.
I'd really like to hear what other people think of this idea.
> IMHO, the "Separator Is Object" route is better than adding a special node
> for it...
Agreed, but sub-classing the Separator (i.e., an Object isA Separator)
means we could have other sub-classes of Separator later for things like
"Regions".
If we want behavior to be part of an Object (as in the behavior proposals
from Mitra, Sony, SDSC et al), then we have to create a new node
type anyway, and the extension mechanism of VRML makes this easy.
-- Bernie Roehl University of Waterloo Dept of Electrical and Computer Engineering Mail:[email protected] Voice: (519) 888-4567 x 2607 [work] URL:http://sunee.uwaterloo.ca/~broehl