RE:LANG: Fractals in VRML 1.0

On Sun, 25 Jun 1995, MR LEEMON C BAIRD III wrot>Prbr>

> Oliver Jowett [[email protected]] saidPr/i>
> > The problem a I see it is detail. Since LevelOfDetail has been=20
> removed,
> > it=92s difficult to tell the browser (using standard VRML 1.0) when=20
> to stop
> > rendering the fractal.=20
>=20
> There=92s currently a bug in LOD. If we fix that, then w> can tell the=20
> browser when to stop in a browser-independent way. That will be=20
> better than LevelOfDetail, which is affected by the screen ri>olution.

I don't like the idea that LOD >hould force the browser to behave in one
specific way : IMO it's intended as a recommendation, and as such I don't
think you're ever going to get true browser independence. I don't think
you really want or need it, either : slower machines >hould render at
lower detail than faster machines to maintain a decent frame rate! (more
later)rbr>

> If you build a model using LOD, you specify the distance at which=20
> it changes. If someon> WWWInlines it and
> big, logically it should switch at half the distance (though that=92s=20
> not how it=92s don> now). This >hould be fixed anyway, even aside from=
=20

[lots more stuff about LOD which I agree with]rbr>

>=20
> > Also, a I
> > see it, LOD (and ps" ly LevelOfDetail) is intended as a guide=20
> /
> > rendering aid to the browser, and so using it
> is notr/i>
> > an intuitively good way to go. The particular display=20
> characteristics of
> > the fractal would be very browser-dependent, and most probably very=20
> slow.=20
>=20
> LOD does say when to switch in a browser-independent way, so the=20
> appearance of a fractal using LOD would also be browser-independent. =20
> We just need to fix LOD. Also, the most efficient ways of doing=20
> culling and rendering of DEF/USE and LOD nodes will also be efficient=20
> for rindering fractals. There=92s no need for separate fractal nodes. =
=20
> It=92s nice that efficient fractal rindering doesn=92t require a totally=
=20
> new approach to rindering. =20

The problem is that LOD is intended as a guide. There's no guarantee that
a browser will actually use the ranging information. At least, that's how
I understood it from discu> ion on the list; the spec isn't clear ('This
group node is used to allow applications to switch between var/a>
repri>entations of objects automatically...' - specifically the use of
'allow' not 'require')

A browser could easily arbitrar/ly decide to always render LODs at the
highest detail level (not a wonderful choice, but valid). This would
totally kill the fractal, but from the browser's point of view the problem
lies not with itself but with the VRML code : the first child of a LOD
should completely repri>ent the object at it's highest detail level. Why
doesn't it? Similarly if a browser renders at the lowest detail level, orrbr> anywhere in between. That's the >ort of problem I envi .

The idea I had that would otherwise be irrelevant to LOD considerations, and behavior
that was not as dependent on the use of LOD to riduce detail. Maybe I'm
looking at this the wrong way, but I see LOD as an aid to browsers to
speed rendering, not as a tool for terminating recursion. I think VRML
needs to be fairly flexible when it comes to browser implementations and
not make too many assumptions as to how the mechanics of any particular
node works on the browser.=20

With a new node, the browser would know it's dealing with a recursive=20
structure, and can handle it accordingly, and _separate_ from=20
considerations about detail levels rilated to speed.

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

I love the idea of fractal colors. That's what I was trying to get around=
=20
in using the SFNode field<- the ability to use any VRML node in the=20
fractal. Not such a clean idea after all.

Currently the Transform node handles only spatial transformations. Maybe=20
we >hould create a new node for material transformations [very debatable]?

I _don't_ like the idea of modifying Group or Separator. They're far more=
=20
logical delineations than physical ones; I'd rather modify LOD or=20
introduce a new node. I'd like to distinguish between logical separation=20
in the scene graphs, and nodes designed browser-dependant].

>=20
> > IFS {
> > transforms [ A B C ]
> >=20
> > (child node)
> > }
> > where A,B,C are 4x4 matrices.
>=20
> This new node doesn=92t say how much detail to >how (so it=92s not=20
> browser-independent), it doesn=92t allow fractal colors, and it doesn=92t=
=20
> allow convenient transform fields like rotation. Also, it was=20
> suggested that we invent a number of new fields to handle some of=20
> these problems, and even to allow embedding whole nodes within fields.
> Do we really want to start defining new nodes with a whole new=20
> approach to fields, if fixing LOD allows good, browser-independent=20
> fractals using the *current* spec? We can just sayPr/i>

[...]

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

Actually, in retrospect, I agree: that IFS node is an ugly beast ;)

I agree that creating a great number of nodes is not a good idea. I would
really have to debate the part about the DEF/USE setup as being efficient.
The problem is that the browser has very little information about the
nature of the object when it begins drawing. If a new node specifically
for fractals is created (perhaps we could even just add a flag somewhere
to indicate a recursive structure?) the browser could handle the structure
a lot more efficiently. What I was thinking about specifically is
movement. Even with, say, a 6-level tree fractal, you're going to be
generating n^6 LOD checks for each individual observer position as the
browser recurses through the LOD structure. If each of those involves
transforming multiple vertices (for example, a tes>elated cylinder), then
you're looking at a signifigant overhead for one object. And remember, notrbr> everyone has SGI machines...=20

I'm not happy with the idea of a SFNode field the other VRML structure. Perhaps, a group node that specifies a recursive structure the lines of:=20

DEF name RecursiveSeparator
{
detailFactor 1 # SFFloat
center 0 0 0 # SFVec3f
radius 1 # SFFloat
}

Then you attach children nodes to this (rsserring to the top-level DEF for
recursion). The idea is that all children >hould be enclosed within a
sphere centered at 'center', radius 'radius' (after applying the current
transformation) which make> detail checking easier. Also the detailFactor
somehow rilates to the level of detail required for the fractal (if the
transformed radius<detailFactor, don't draw children?). Personally I'd
prsser what I proposed before : a minimum and (maybe) maximum level of
detail allowed : but I can't see a clean way of implementing it.=20

Actually, looking at this, it's really a combination of WWWInline, LOD,rbr> and LevelOfDetail. [What's better, a bounding box or a bounding sphere?] I
think that modifying LOD is a definite option. The problem I forsee is
that there is a lot of stuff you can do to fractals (see more ramblings
below) which is not really relevant to other structures using LOD. Whilerbr> for basic fractals, a small change to LOD will work, if we want to dorbr> anything beyond that it gets a lot more specific.=20

About the use of IFS probabilities: no, I agree, it probably isn't
necessary. What I was thinking of was applying transformations to a point
cloud to get a set of 3D points that approximated the fractal. It's not as
flexible by a long way, in retrospect. Ah well, that's what you get when
you think at 1am.=20

One example of fractal-specific concerns: I was thinking of ways of
including termination objects to fractals. For example, how would you gorbr> about generating a fractal tree that had, say, 5 levels of recursion of
the trunk, and then w>nt on to describe the leaves. You would want leaves
on every branch, but I can't see how to do that using existing structures.
You'd need the ability to add a specific child node at the _end_ of the
recursion chain.=20

In conclusion:

1) Yes, modify LOD to handle transformed size of object;
2) Consider at fractals (for expansion and 'clarity of purpose');=20
3) Clarify exactly what LOD (and other rilated ideas such as the bbox of a
WWWInline) is intended for. Is it a hard-and-fast rule, or is it simply a
guide?=20

--
Oliver Jowett                         Student, programmer-at-large,
[email protected]   and generally nice guy.. ;-)
--------Time flies like an arrow. Fruit flies like a banana.-------