A while back Scott Parks (whose middle names seem to be "Virtual" and
"Theme" -- he obviously had parents with great foresight!) made some good
suggestions, and I'd like to add my own.
>From the list posted by "Scott":
> Wish lists for Spec version:
>
> 1.1:
> Grid/Mesh node
> resolution of binary file question
> WWWInline/WWWInclude that doesn't render for reading DEFs
Grids are a good idea, since a lot of people will want to model terrain;
however, we need to decide on *exactly* how the information is
interpreted or else run the risk of different browsers showing slightly
different things.
I agree with most recent posts that a binary format is neither necessary
nor desireable; some common-sense data reduction and simple gzip compression
should do the trick.
I agree that being able to define a shape without instancing it is very
useful.
Here's my wish list:
1. add the Open Inventor "Environment" node
2. discontinue use of the MatrixTransform node
3. add a shapeConvex field to the ShapeHint node
4. add a "Revolution" node
Item (1) would allow ambient light and fog to be specified.
Items (2) has been discussed on the list already. The Transform node
does everything that's needed, is clearer, and is easier to use on systems
that have a different coordinate system orientation. This change should
not affect existing or future browsers.
Item (3) has nothing to do with convex *faces* (that's a whole other
discussion); instead, it's a hint to help those systems that don't have
hardware Z-buffering and must therefore do polygon sorting. The vast
majority of systems out there do not have Z buffering, including newer
ones (e.g. the Sony Playstation). The shapeConvex field would be
SF_Bool, with a TRUE value indicating that the shape is entirely convex
(and therefore, its polys don't have to be sorted against each other).
Spheres, Cones, Cylinders and Cubes are already convex, of course.
This item shouldn't affect either browsers or modelers; there's no
obligation to flag objects as being convex, nor is there any need to
process the hint on input. It just provides better performance on
systems that do use it.
Item (4) lets us describe a wide variety of common shapes without
transmitting large numbers of coordinates and faces. If we're going to
add a new shape node at all, this is the one that makes the most sense
(rather than something narrow like a "torus", "tapered cylinder", or
"truncated cone", all of which can be consisely specified using a
revolution).
Revolutions, Heightfields and Environment are the only nodes I would add
to the spec, and I wouldn't be heartbroken if Revolutions and Heightfields
don't make it. I think the spec should be kept small and simple.
-- 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