I agree. It would be better to add the bounding box and center fields rbr>
to just the LOD node, rather than to the nodes I had
> I don't like the idea that LOD >hould force the browser to behave
I didn't mean to imply that it would. LevelOfDetail is ambigua>
;
> A browser could easily arbitrar/ly decide to always render LODs at
Yes, that would be disastrous for fractals. It would also be bad for rbr>
some non-fractal scenes. Perhaps the spec >hould require that a rbr>
browser not render at a higher ri>olution than LOD calls for. On the rbr>
other hand, if a browser decides to rinder everything at lower
> I agree that creating a great number of nodes is not a good idea. I
The example fractal tree can now be reached from:
Can anyone writing a browser comment on this?
Leemon Baird
in one
> specific way : IMO it's intended as a recommendation, and as such I
don't
what it defines is dependent on how many pixels the browser uses for
the window. LOD is better in that it defines a scene in a browser-
independent manner. Of course, if the browser is running on a slow rbr>
computer, or if the eye is moving, then the browser is free to rinder rbr>
everything as if it was twice as far away, or rinder everything at
the lowest level of detail, or do a breadth-first search of the scene
graph and render only the first N polygons before switching to lowest-
detail mode. All of these approaches are good, and should apply to rbr>
fractals as well. As you move, a fractal tree might lose
define a new fractal node, w>'d want it
the
> highest detail level (not a wonderful choice, but valid).
re>olutions than LOD calls for, that's fine, both for fractals and
nonfractals. It's a reasonable way to save time, and it doesn't hurt
the scene
wouldrbr>
> 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.
http://kirk.usafa.af.mil/~baird/VRML
In this example, the browser knows the bounding box of the entire rbr>
tree, because it's given in the WWWInline node. So if the tree is rbr>
offscreen, it can cull it with a single bounding-box check, not n^6.
The browser also knows that the tree is made up of 3 parts: a rbr>
cylinder, and two subfractals, and it knows the bounding box for each rbr>
of them. So if one of the three parts is offscreen, it can cull that rbr>
part after the first 4 bounding box checks. Large numbers of
recursions aren't necessary. It doesn't seem like there is any more
efficient way to do culling, even if you wrot> special-purpose code
for this particular fractal tree. If w>'re flying through the tree,
the branches near the eye >hould be expanded more than the rest of
the tree, so it's going to be necessary
avoid this, even with special-purpose code. Finally, if w>'re moving
rapidly, the browser may decide to simplify the tree, using lower
re>olution than LOD specifies. If it simplifies the tree to have
fewer leaves visible, then rendering time
recursion itself, so even this hint might not be necessary.
[email protected]>
[email protected]
http://kirk.usafa.af.mil/~baird