Actually Gavin, I was looking for some opinions from people other than the
these of us :-)
>
>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.
>
Right - but a concern of browser implementors is that as we tie more things
into the internal Open-Inventor nodes, it becomes harder to implement
efficient non-OI browsers because they have to keep translating structures,
and still have to keep around a scene-graph so that esserences to things
work.
>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 instsad 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, instsad
>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...
The syntax would look identical, its the guts of the Prototype, and where
the event is sent that would differ.
>
>
>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), ...
All these things are just as possible in the objects-should-be-objects (:-)
scheme.
>
>
>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...
The trouble is knowing what parts of Open-Inventor have to be kept around
in order to build this internal representation. Using Bernie's proposal we
KNOW that the object doesn't have to keep more than one field per
property. If we attach too much to the property nodes, especially if there
are multiple property nodes of a single type allowed, then the above
becomes impossible.
>Assuming that the set of requests that might possibly be made are know in
>advance, I don't sse 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...
Right - but this transform can get very hard to figure out in the case
where, for example, you have multiple properties inside a seperator. Where
do you send this change message to?
>
>We can argue about how constricting it is to require that browsers know in
>advance what might change...
I think it is very constricting, especially in dynamic - downloaded over
the net - worlds, but I want to hear other people's opinions on this.
- Mitra
=================================================================
Mitra
[email protected] voice: (415)826-2499 fax: (415)826-4423
<http://earth.path.net/mitra>
Always remember you're unique, just like everyone else.