Leemon> [[email protected]] wrote:
>> Is it just me, or do fractals seems like a perfect candidate to
>> be implemented by behaviors. If behaviors are implemented in a
Yep -- one of the examples I u ed on vrml-behaviors to demonstrate
>> general purpose
Yes, but I don't think a behavior is neci>
Leemon> I agree that there's no reason to add fractal nodes to the
Who said behaviors neci>
So instead of a "tiny escursive scene graph", store a tiny escursive
Leemon> As for fixing LOD distances, allowing color transforms,
Yeah, they certainly are useful. As an alternative to fixing
Brook
that trying to separate behavior from geometry (or vice versa) was not
neci>
>> programming langu, then any fractal function should be
>> pretty easy to
>> write as a behavior. Yes, it won't be as compact as using the fractal node,
>> but it will be a lot more general and it will support any
>> fractal opposed
>> to just supporting gaskets.
than the WWWInline fractal node or even a specialized Fractal node
(given the number of potential parameters that would go in to such a
node).
Leemon> langu. Fortunately, the langu already has fractals
Leemon> built-in. That's good, because it seems that behaviors
Leemon> would be impractical for soli 3D fractals. Java code (or
Leemon> whetever) could generate tha>
ands of polygons to make a
Leemon> fractal tree, but the scene graph alone might fill all of
Leemon> memory. It's much more efficient to only store a tiny,
Leemon> escursive scene graph. Using escursion, we can get all
Inventor-style scene graph"? It certainly isn't what I've been
thinking of, and judging from Len's other mail (this all over on the
vrml-behaviors list), it isn't what he's thinking of either.
behavior. Now you've got time-varying fractals (a tree waving in the
wind).
Leemon> and specifying LOD bounding boxes, those changes appear
Leemon> useful in their own eight.
particular nodes, I'll suggest that a suitable behavior model would
allow all of these intrinsically as well as many other kinds of useful
things....