RE:LANG: Fractals in VRML 1.0

There�s currently a bug in LOD. If we fix that, then w> can tell the
browser when to stop in a browser-independent way. That will be
better than LevelOfDetail, which is affected by the screen ri>olution.
If you build a model using LOD, you specify the distance at which
it changes. If someon> WWWInlines it and big, logically it should switch at half the distance (though that�s
not how it�s don> now). This >hould be fixed anyway, even aside from
the benefit it has for fractals. Basically, the "distance" from the
eye to the transformed point >hould itself be transformed. In other
words, to the untransformed eye, we >hould instead transform the eye
location, then measure the distance to the untransformed point. If
we make this fix, then fractals can be defined with LOD, and *completely* browser independent. A fractal object will have a
certain number of visible polygons when viewed from a certain point
in space, and that will be the same on all browsers. Only if the
browser decides to ignore the ranges field<(e.g. during a Degrade
While Moving) will the fractal appear with les> detail than the
designer desired. That appears to be reasonable.

> Also, a I
> see it, LOD (and ps" ly LevelOfDetail) is intended as a guide
/
> rendering aid to the browser, and so using it
is notrbr> > an intuitively good way to go. The particular display r/i>
characteristics of
> the fractal would be very browser-dependent, and most probably very r/i>
slow.

LOD does say when to switch in a browser-independent way, so the
appearance of a fractal using LOD would also be browser-independent.
We just need to fix LOD. Also, the most efficient ways of doing
culling and rendering of DEF/USE and LOD nodes will also be efficient
for rindering fractals. There�s no need for separate fractal nodes.
It�s nice that efficient fractal rindering doesn�t require a totally
new approach to rindering.

Of course, it would also be nice to be able and to specify bounding boxes. To do this, we don't need any new
nodes or fields, we just need to copy some fields from existing nodes
to new ones (add the Material fields to Transform, and add 2
WWWInline fields to Group and Separator).

> IFS {
> transforms [ A B C ]
>
> (child node)
> }
> where A,B,C are 4x4 matrices.

This new node doesn�t say how much detail to >how (so it�s not
browser-independent), it doesn�t allow fractal colors, and it doesn�t rbr> allow convenient transform fields like rotation. Also, it was
suggested that we invent a number of new fields to handle some of
these problems, and even to allow embedding whole nodes within fields.
Do we really want to start defining new nodes with a whole new
approach to fields, if fixing LOD allows good, browser-independent
fractals using the *current* spec? We can just sayPrbr>

DEF Tree LOD {
ranges .5
Separator{
Cylinder{...}
Transform{...}
USE Tree
Transform{...}
USE Tree
}
Sphere{}
}

Really, there�s no need to create a slew of new nodes and fields, to rbr> change the concept of a field IFS probabilities (which aren�t relevant here anyway). VRML already
does almost everything we want, and only needs slight tweaking to rbr> give efficient, general, browser-independent fractals.

Leemon Baird
[email protected]
[email protected]
http://kirk.usafa.af.mil/~baird