Re: [Gnu3dkit-dev] Optimization suggestion

[Brent Gulanowski]

On Sunday, October 6, 2002, at 08:38  PM, Matt Brandt wrote:

> I'm going off the source to the 0.3.1r2 version or the G3DKit so maybe 
> this is already in the new stuff. What I'm thinking is some way to 
> have multiple representations of  a scene that automatically switch 
> depending on the distance to the camera. This would be most useful for 
> games and programs that need full speed rendering. It could be done as 
> a subclass of G3DScene (maybe G3DMultiScene or something similar) or 
> it could just be built into G3DScene itself.
>
> In a typical application there might be one representation that is 
> just a pre-rendered texture on a surface or a sphere and another that 
> has 3D details. The details could be nested G3DScenes that switch from 
> pre-rendered representations to full 3D when the camera gets within 
> their detail sphere.
>
> There shouldn't be any limit on the complexity of each representation, 
> but I'm not sure I see a need for more than two levels of detail per 
> scene.
>
> What do you guys think?

In v0.3 this was managed by a G3DLODGroup. From the code, it appears to 
be straightforward. Calculate the distance from the camera to the local 
origin of the group (represented by the translation vector in the _fwtm 
matrix), and then chose the best child based on the number of children 
and the maximum distance ivar. You could use a 2D billboard just as 
well as a 3D model -- any graph node was acceptable. If we stick with 
this approach, I suggest calculating near and far threshholds for each 
child in advance, since it never changes. Not a big savings maybe, but 
it looks as though v0.3 only did one threshhold, which tends to lead to 
vertex popping when the viewer is hanging around near the that distance.

What about incorporating near and far culling threshholds into every 
node? If it's not provided on import, it can be calculated, based on 
the bounding box perhaps. Instead of just distance, I would rather use 
a rating which incorporated distance and size, to give a degree-of-arc 
rating, to be responsive to changes in the viewer's FOV. The main 
purpose is to keep big objects visible longer and make small objects 
disappear sooner, versus an indiscriminate distance culling (while that 
will still be needed, it would be good if it could be pushed farther 
away). We could have a hint in the renderer which could be more 
aggressive in heavily populated views, and less so in constrained and 
indoor scenes, or to err to either scene complexity or rendering speed.

In the past I have thought about the use of billboards to replace 
models near the far clipping plane, but usually that plane is 
frequently not far away enough to make billboards acceptable. Wrapping 
a sphere results in a spherical object -- billboards at least preserve 
the outline of the object. They work well in scenes where are very 
crowded, because they produce the right background patterns without 
being visible in detail. They have the potential to be a better effect 
than (non-volumetric) fog. In starkly populated scenes they look bad, 
however.

What we really should think about is a global sorting algorithm which 
does a good job, given any frustum, of determing which objects to draw 
and at what level of detail in order to draw the current frame within 
the maximum allowable amount of time. This means maximizing the 
perception of detail, both image and motion, while stabilizing the 
quantity of detail (read: triangles). There are numerous techniques. 
The trick seems to be to guess which one(s) to use and how to 
prioritized them for a given scene and situation. I've read of one 
which even incorporates the speed of the camera. It dynamically alters 
the LOD settings so that more objects can be drawn faster at lower 
detail when the user is moving the camera quickly, the theory being 
that the user can't see as much detail and wants to be able to react 
quickly.

--
Brent Gulanowski                                address@hidden

I bought some batteries... but they weren't included... so I had to buy 
them again.	- Stephen Wright