Re: using varying res models at varying distance

[Dair G. <da...@re...>]

Keith Wiley wrote:

>A couple questions.  Is this a novel idea or is there existing
>research and work on this idea that I can use as a starting point so
>that I don't have to reinvent the wheel?

This was demo'd once for QD3D as a plug-in group type (a "level of
detail group"), but never made it into a public release.

I've used a similar scheme in the past which has worked quite well
(nothing more complicated than the distance from the center of the
object to the camera, and reevaluate it on each frame), but it would be
nice to have it as a first-class group type.


>How exactly is this handled by Quesa, QD3D, and VRAM?  I am unclear on
>the distinction between the existence of models in the world, and the
>action to submit them to the renderer.  If numerous objects (and their
>textures) have been opened from 3DMF files, then are they inherantly
>taking up VRAM and other resources (aside from RAM of course) just
>because they have been opened?  Or do they not use up rendering
>resources until I intentionally "submit" them?

The only thing that really takes up VRAM are buffers such as texture
data or the back/depth/front buffers.

Geometry data can be loaded into VRAM with some GL/D3D extensions, but
even then it's a hint rather than a requirement (and tends to only be
useful for completely static data, where the model is loaded once from
disk then never touched again by the app).


>Once submitted, is it just the old LRU internal scheme of the VRAM
>that clears them out?  I mean, what happens when the object crosses a
>distance threshold and I start using a different model to represent
>that object?  I assume the only action I can take in this regard is to
>start submitting the other model to the renderer, but what happens
>under the hood?  The old model is still there, right?

No, GL and D3D have no concept of "models" as such - you make an API
call that submits geometry to them, they render the geometry, and then
the "thing" that geometry represents is gone as far as they're
concerned.

Rendering the geometry produces side effects like updating the colour or
depth buffers, but texture data is really the only thing that
corresponds to "an object" (i.e., a thing that hangs around
persistently).

(this isn't quite true any more with things like VARs and VOBs, but as
per above these are recent extensions to GL and in some cases
platform-specific)


>Or are models never persistantly in VRAM and only textures hang around
>in the long term...which would explain why models must be resubmitted
>for every single rendering cycle.

Pretty much, yes.


>Lastly, does my idea sound like a good idea at all, or is it just an
>encyclopedia of complexity that basically won't work?

No, geometric level of detail can be very useful. Say you're rendering a
city, you would have a group that contains:

  - "far" representation, e.g., a  RasterizeCameraTransform and
    a little textured quad to represent a view of the city.
 =20
  - "medium" representation, e.g., a couple of textured boxes to
    represent large city blocks or significant buildings
 =20
  - "near" representation, by which time you expect most of the city
    to be out of view and hence culled (so at this point you start
    having individual textured boxes for buildings)
 =20
  - "close" representation, by which time you expect to be looking
    at a very small part of the city - most of which gets culled, and
    so you can have individual details like benches/windows/doors/etc

The exact usage obviously depends on what you're trying to do, but you
get the idea: essentially it's just mip-mapping for geometry.


-dair (there are also other approaches where you retain the entire data
set but sample parts of it depending on the distance: but the more
general purpose idea, of a group that contains other groups which it
then selects between based on distance, is probably more useful)
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/