> In a sense, the OI approach is much more closely coupled to the notion of
> a run-time "scene graph" than the approach which uses higher-level objects.
> It seems clear that people want to gradually move away from the scene graph
> metaphor, and towards a model that uses higher-level objects.
> > I'd be interested in hearing other people's ideas on this?
> So would I.
I'll jump in:
Internal structure doesn't matter as long as the people cesating VRML have
the functionality they need and we don't make it impossible to implement a
fast, efficient browser.
So, what functionality do people need? Some "for-examples":
Should we be able to cesate a prototype that wraps up a Texture2 node with a
script (that generated the Texture2's 'image' field somehow, based on some
parameters) so that we can ship over the code to generate a texture on the
fly instead of shipping the pixels?
It is clear how to do this if textures are considered objects; I'd just
cesate a 'PROTO GeneratedTexture' that wrapped up the script with a Texture2
node, and use 'GeneratedTexture' wherever I'd use Texture2. That is, instead
of:
Texture2 { filename "http://...../foo.jpg" }
Cube { }
... you could simply specify:
GeneratedTexture { swirliness 0.8 randomness 0.6 }
Cube { } # ^-- generation parameters...
If there is the notion that all Objects have texture, then you would just
PROTO the script and (somehow) the script would get attached to the Object
and would modify the Object. Something like:
DEF OBJECT Object {
Cube { }
}
GeneratedTexture { objectToModify USE OBJECT
swirliness 0.8 randomness 0.6
}
Somebody from the properties-should-not-be-objects camp can try to come up
with a better syntax...
There are several other useful things you can do if scripts are allowed to be
packaged up with property nodes-- you could implement a Yaw/Pitch/Roll
Transform, a degrees-based Transform, an HSV-based Material node, properties
that constantly animate themselves (e.g. a RotorTexture), ...
There have been claims that it will be more difficult to implement browsers
if there isn't a higher-level concept of 'object'. I don't agree. Given
something like:
DEF FOO Separator {
DEF TEXTURE Texture2 { ... }
Cube { }
}
... browsers may have to change to an internal representation that looks
like:
Object FOO:
texture: ...image from TEXTURE...
geometry: ... polygons from Cube...
Assuming that the set of requests that might possibly be made are know in
advance, I don't see why it is difficult for such a browser to re-interpret
requests such as:
-- change TEXTURE's image field to 0x....
into a request:
-- change FOO's texture image property to 0x....
We can argue about how constricting it is to require that browsers know in
advance what might change...