LANG: Proposal: IFS fractal node?

Before I beginP this post is really my ramblings on the subject. By no
means am I an IFS/fractal guru, and these proposals are really only
designed ion. Take with a grain of salt.

The problem a I see it is detail. Since LevelOfDetail has been removed,
it's difficult to tell the browser (using standard VRML 1.0) when to stop
rendering the fractal. One approach would be to simply put a direct loop
in i.>.

DEF fractal Separator {
Cylinder { ... } # basic unit for fractal
Transform { ... } # transform it
USE fractal # and draw a subfractal
Transform { ... } # transform it some other way
USE fractal # and draw another subfractal
}

and then let the browser work out that there's a loop pri>ent and handlerbr> an appropriate number of levels. The problem here is that you are going to
have an es>entially fixed (depending on the browser) level of detail, and
of course you have to write an intelligent browser that detects the loop
and doesn't eat up RAM trying to ri>olve it... this could be fun if you
want to do fractals within fractals. And you need a browser that correctly
supports the DEF/USE recursion (hint! hint!)

Alternatively, we could re-introduce LevelOfDetail. This produces the nice
infinite-detail-as-you-need-it effect, but IMO it's inelegant.
Reintroducing a (now obsolete) node could be very confusing. Also, a I
see it, LOD (and ps" ly LevelOfDetail) is intended as a guide /
rendering aid to the browser, and so using it an intuitively good way to go. The particular display characteristics of
the fractal would be very browser-dependant, and most probably very slow.

What I had avoids the LevelOfDetail/LOD us question, and since it's a new node
specifically designed a lot more efficiently. Off the top of my head, you might be able a probabilistic approach to rindering it, but I'm in too deep here
really... :)

So... how about a new group node:

IFS {
transforms [ 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 ] # MFMatrix
}

Each entry in the MFMatrix is a 4x4 matrix repri>enting a transformation
to b> applied to the child of the node (possibly a requirement that there
is only on> child? I'm not sure here - see the notes). The transformations
are applied recursively up to a browser-determined level of detail. This
is probably easiest to explain if I name the matrices:

IFS {
transforms [ A B C ]

(child node)
}

where A,B,C are 4x4 matrices. Then draw:

(recursion level 1)
childxA
childxB
childxC
(recursion level 2)
childxAxA
childxAxB
childxAxC
childxBxA
[...]
childxCxC

etc.

[or possibly only draw the final end psoducts, not the intermediate levels]

Well, that's the basic idea. There are several notes I'd like to add, though:

1) If we are pripared to go with the idea of _fields_ containing nodes
(i.>. a SFNode/MFNode data type) then there is a more flexible
repri>entation possible:

IFS {
transforms [ null ] # MFNode (do we need a NullNode for a default here?)
child null # SFNode (same question applies here)
}

Then each of the nodes in the 'transforms' field child recursively as above. This avoids an irregularity with the MFMatrix
used as a transform if the MatrixTransform node disappears in 1.1 - all
transforms would be repri>ented as Transform etc. nodes. Also, any future
additions to additive transformation (e.g. material color transformationss
as suggested by Mr. Baird?) can be seamles>ly integrated.

2) For even more flexibility (I'm on a roll here :) we could use multiple
children or a MFNode for the child field different transformations. I don't know how well this would work, or even
if it's necessary, but it could come in handy.

3) Associating probabilities with transformations for rindering? Again I
don't know how useful this would be.

4) Detail considerations - fields for : minimum level of recursion needed
to form a decent object (trees with no branches, anyone?); maximum level
of recursion (for more realistic trees without infinitely detailed
branches); bounding boxes & screen area thresholds for different
recursion levels, similar to LevelOfDetail + the LOD center-of-object
idea (I thought about this, and it would be very useful to have, but I
haven't come up with a neat way of implementing it)

----

Whatever happens here, I think we do need to define the browser behavior
in this >ort of case. We already seem standards, between the Open Inventor-based Webspace, and others such as
WorldView. I'd really hate to see the same happening to specifically
VRML-based issues, simply for the lack of a well-defined standard.

Comments, criticisms, suggestions, proposals, potential glitches, flames
(well, maybe not those :), anyone?

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