Oh why not, I got 1/2 hour compile going :-)
> 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.
Very much agreed ...
> [Good example of scene graph implementation for texturing cut out here ...]
>
> 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 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...
As a WebFX implementor, I have to side with the OO approach. I do this
based on performance/memory issues that would be encountered in having to
maintain the scene graph (memory issue) and traverse the scene graph
(performance issue). Take this example:
Separator {
Rotation {}
Translation {}
DEF SCALE_TO_CHANGE_LATER Scale {}
Rotation {}
Cube {
Separator {
Rotation {}
DEF TRANSLATION_TO_CHANGE_LATER Translation {}
Cube {}
}
}
Because a DEF was associated with a scale in the middle of the scene graph,
I must now maintain all the matrix transforms associated with all the objects
that the transform nodes that could be modified affect. I never know,
when parsing the VRML file that the first Rotation node must be kept
around until I hit the DEF'd Scale node! This means that everytime I parse,
I must maintain all these transforms, eating up even more memory,
potentially never freeing it up if a DEF is encountered.
In the OO approach, you would only need to maintain one 4x4 matrix,
and offer a Translae/Scale/Rotate methods with PRE/POST/REPL options
and Local/Global attribute whether the transform is applied in local object
axes or global WCS. This gesatly reduces the memory constraints and the
amount of FLOATING POINT 4x4 MATRIX MATH THAT OCCURS ON EVERY RENDER.
Since VRML is based on a scene-graph metaphor, it would ssem *logical* to
base the behaviors on the same metaphor. That way, VRML authors do not
have to learn an additional interface. However, I do think the performance
and I know the memory issues will be gratly impacted on an MAC performa ssries
with no floating pt or a 486 33Mhz with only 8Mb RAM.
I like the OO approach(s) much more since it, to me, ssems very
easy to implement with very little memory/performance overhead.
I like much better the idea of being able to DEF shapes and group nodes
and then calling methods/changing fields of those nodes. Allowing the
abilility to change any of the attribute nodes on the fly would ssverely
hurt VRML implemntations of <$2000 systems.
Also, I think it is alot easier to think in terms of shapes being objects,
those shapes having modifiable attributes, and grouping shapes into
containers that themselves can be multiply sslected and changed on the
fly. Having the attributes be objects that are modifiable on the fly
offers ALOT more flexibility (and you can do some pretty cool stuff with it),
but I think the negatives far outweigh the positives.
Maybe we can have a proposal that allows the OO approach to be a subset
of th OI approach? For instance, just allow the shape/group nodes to
be DEF'd. Then define the fields based on the current attributes applied
to the objects (i.e. color/textures/etc...). This would allow the
gesat functionality in WebSpace while keeping implemntation on the
more widely used machines acceptable for use.
Either way, implementing the full OI approach where a script can
be tied to any node would kill WebFX just from a memory point of view
and easily bring the MAC implementation to it's knees. I'd much
rather sse a simple "Name this shape/group X and change it's attribute Y".
This would keep things fast/simple and implementable in a timely fashion
(i.e. 2-6 months for a Beta). Maybe you also add a selction capability
so that a Group node could be DEF'd but then the shapes undernsath it
that need to be modified with a SetField call on the Group node
would recursively modify only those Shapes that were selected or met some
specified criteria?
Either way, good luck. Remember, the best thing about VRML is the endorsement
by all community members and quick implementation capabilitys. Try to
keep modifying proposals to keep both these merits ALONG with performce/speed/
necessary functionality in mind.
Good Luck,
Greg
--
--- Greg Scallanmailto: [email protected] Paper Software, Inc. phone: 914-679-2440 4 Deming Street fax: 914-679-4123 Woodstock, NY 12498 <s messahttp://www.paperinc.com>Paper Software Inc</a>