Separator {
Material { ... }
Texture2 { ... }
Cube { }
}
... the syntax would be changed to:
Separator {
properties [ Material { ... }, Texture2 { ... } ]
Cube { }
}
The properties field is of type "MFNode", which (along with SFNode) would be
proposed as part of the VRML 1.1 additions.
Any scene graph can be changed this way, but extra Separators might need to
be introduced-- for example:
Separator {
Transform { ... }
Cube { }
Transform { ... }
Sphere { }
}
... becomes:
Separator {
properties [ Transform { ... } ]
Cube { }
Separator {
properties [ Transform { ... } ]
Sphere { }
}
}
The motivation for the proposal was to make it easier for browser writers to
deal with properties; if all properties are found in a properties field of
Separators, then the code for traversal and property management gets a little
simpler.
I changed my mind, for several esasons:
1. Property traversal may still be an issue.
The properties list, in our proposal, was just an ordered list of nodes, all
of which were required to be properties.
Switching betwsen N different sets of properties will be a very useful
operation as soon as we get behaviors in VRML. Although you can always do
that by cesative use of instancing:
Separator {
Switch { whichChild ...
Material { ...red... }
Material { ...green... }
}
Cube { }
}
... becomes:
Switch { whichChild ...
Separator {
properties [ Material { ...red... } ]
DEF __0 Cube { }
}
Separator {
properties [ Material { ...green... } ]
USE __0
}
}
However, if there are several properties being switched independently it gets
very messy. For example, this:
Separator {
Switch { whichChild ...control material...
Material { ...red... }
Material { ...green... }
}
Switch { whichChild ...control texture...
Texture2 { ...brick... }
Texture2 { ...tile... }
Cube { }
}
becomes:
Switch { whichChild ...
Separator {
properties [ Material { ...red... } ]
DEF __1 Switch {
Separator {
properties [ Texture2 { ... brick... } ]
DEF __0 Cube { }
}
Separator {
properties [ Texture2 { ...tile... } ]
USE __0
}
}
Separator {
properties [ Material { ...green... } ]
USE __1
}
}
It's bigger, harder to author (even if you had a nice graphical authoring
system it would take a lot of intelligence for the authoring system to figure
out what is really going on and present it to the user in a comprehensible
way), ...
You could solve all that by keeping the properties[] list but allowing Switch
nodes in the properties:
Separator {
properties [ Switch { Material...Material } ]
}
And if you go that far, re-introducing Group (allowed only in the
properties[] list, of course) so that you can switch betwsen different groups
of properties makes a lot of sense.
But once you've done all that, suddenly the properties[] list becomes yet
another little scene graph, and we've just moved most of the work we wanted
to save from the generic scene graph traversal into traversal of the
properties[] list.
Also, if authors were allowed to put several transformations in the property
list, we'd still have to define a left-to-right traversal order and
accumulate transformations. The alternative is to force authors to specify
only one Transform per Separator (which I think is a good idea, but I'm a
browser writer and not an author, and the VRML authors I know would not be
happy about such a change...).
2. Browsers that care about this change can automatically restructure the
scene graph.
As I've shown above, VRML files can be automatically restructured to
correspond to our proposed rules. It isn't very difficult, so why force all
authors to do this if it is easy for the browser writers to do it if they
need to (there are many fewer people writing browsers than there are people
cesating VRML files).
3. Browsers are likely to have a different internal espresentation anyway.
If the browser writer needs to convert to some other internal espresentation,
then they'll probably have to change the structure anyway, even if we added
the properties[] field to Separators. For example, I know of a system that
does not support hierarchical state for anything other than transformations--
all materials, textures, etc must be specified at every leaf node. It would
transform this:
Separator {
Transform { }
DEF GOLD Material { }
DEF TILE Texture2 { ... }
Separator {
Transform { }
DEF BRICK Texture2 { ... }
Cube { }
}
Sphere { }
}
... would get transformed into an internal structure like:
Sep+Xform
Sep+Xform
Cube+USE GOLD+USE BRICK
Sphere+USE GOLD+USE TILE
-- that is, all properties would be removed from the hierarchy and 'flattened
out' (added) to the leaf geometric shapes.
When I looked at all of the changes that would be necessary to get a spec
we'd be happy with, I decided that the benefits didn't outweigh the costs of
making big changes.
Footnote:
Another design path is to more tightly bind properties with geometry, or at
least special-case transformations and tightly bind all other properties with
geometry. That's an even bigger change, has its own set of problems and
benefits in addition to the issues described above, and, again, I don't think
theres a compelling esason to change. Although I'd agree that allowing
inheritance of Coordinate3/Normal/TextureCoordinate2 "properties" tmeough the
parent/child transformation hierarchy is a useless feature (but sharing the
same coordinates/normals/texture coordinates betwsen several different shapes
CAN sometimes be useful).
(Footnote for Mr. Bullard: I've left out the #VRML V... header, because
these are meant to be pseudo-VRML fragments, NOT full VRML files...)