Scenes with lots of simple objects

Gavin Bell (
Tue, 7 Mar 1995 10:42:38 -0800

On Feb 28, 9:04am, Scott Nelson wrote:
> I'd appreciate any feedback on the following:
> I have a 50x50x50 block of cubes. This takes several minutes to
> image (using OpenInventor) the first time. Is this a:
> 1. parsing problem?

If you're doing Separator { Transform { } Cube { } } 50*50*50 times, it
probably is a parsing problem.

If you're using a MultipleCopy or Array node (not in the VRML spec, by the
way), then it won't be a parsing problem.

> 2. ordering problem?

I'm not sure what you mean by "ordering".

> 3. hidden object problem?

If you specify 50*50*50 cubes, Inventor will draw 1,500,000 triangles.
Inventor is not smart enough to do any preprocessing to figure out which
cubes are visible (and even if it was, doing that preprocessing would make
startup take even longer!)

The delay at startup is probably due to Inventor building an OpenGL display
list with 1.5 million triangles in it.

> I've always felt (and Jan Hardenbergh disagrees with me, I think) that
> are two distinct categories of 3D:
> 1. a few number of complex shapes
> 2. a large number of simple shapes.
> If others agree with my above statement, does this imply that
> VRML needs 'hints' as part of the language (kind of like "register"
> and "inline" for C++) to help describe parts of the scene to the viewer?
> This is just an optimization sort of thing, but then again that's the
> whole point.

Even if given hints, what would a viewer do with those hints? I don't know
how to write a general viewer that can render 50*50*50 cubes quickly.

I think it makes more sense to define new kinds of shapes that know how to
render large numbers of simple primitives, and that know how to optimize the
rendering. For example, a CubeSet could store the cubes in a spacial data
structure, figure out where the eyepoint is relative to the cubes, draw them
back to front, and (if it was really smart) avoid drawing invisible cubes.

The current thinking in InventorLand is to do something like:

PrimitiveProperty {
MFVec3f translation
MFRotation rotation
MFLong scaleFactor
MFColor color
SFEnum materialBinding
CubeSet { } # Or SphereSet{} / ConeSet{} / CylinderSet{}

... but nothing has been implemented and it will take an implementation to
find out if this will work (for example, we think Indexed versions will be
necessary to concisely represent molecular models).