I beleive there are at least three issues to disentangle here:
1) performance of the VRML viewer
2) size of vrml file, and speed at which vrml data can be digested
3) new data types.
1) This comment just indicates that OpenInventor has poor or no native
mesh support. This comments does not necessarily imply that the
proposed Inventor-VRML file format is bad.
Lets distinguish "know more about the data (because it took the
time to figure stuff out)" from "were told more about the data (with
info in the file format)".
I have code that can visualize a 1Kx1K mesh (2 million triangles!)
at 2-5 frames per second. How? Magic! See below.
2) Even with fancy, high-speed rendering code, there is a problem of
file size. A 1-million quad data file, in ASCII, can be huge.
Reading and disgesting this file could take a long time. Far more
efficient file formats are possible.
3) Many quad-mesh file formats give only z-values, and leave x and y
values implicit, understood to be integers on a square grid. Thus,
right off the bat, your file is 2x smaller, cause you didn't waste
space specifying x&y's that lie on a regular grid.
-------------------------------------------------------------------
Visualizing quad meshes:
(a) quads outside of the viewing frustrum are culled -- they are
not even sent down to the 3D graphics subsystem. Of course,
culling single quads would be a performance disaster -- so
infact, large blocks of quads are culled.
(b) the code builds a "mipmap" or "quad-tree" of factor of 2^2
smaller messhes. A "quality factor" can be used to select
which of these smaller, lower resolution meshes are actually
drawn.
(c) a "stiching" mechanism stiches together the different resolution
meshes, so that low-resolution meshes are used for the far-away
quads, while high-resolution meshes are used for the close-up parts.
The size of the quad, measured in pixels of screen area, is about
constant, as a result.
(d) a servo-mechanism is used to time how long it took to draw the
last frame, and adjust the quality factor so that the next frame
takes approx 1/5th a second to draw.
I have code that combines all four techniques. I am pursuing with my
management to see if I can put this out into public domain (since we
have no plans to commercialize the stuff). Its in C++, uses templates,
uses helper classes (class within a class), and is in OpenGL. Some parts
are nice & squeky clean, some (e.g. the servo unit) are a giant ugly hack.
Help to clean up the code would be appreciated. But please, volunteer to
help only if you really have 10 or 20 or 40 hours to spare.
--linas