[gameprogrammer] Re: Level of detail rendering

>
>  A1: Yeah moving really fast would totaly own this technique.  I'm not
> sure how much support there is on the average computer for rendering to
> offscreen textures in video cards these days but if it's out there, and
> assuming rendering to an off screen texture was as fast or faster than the
> screen texture, even if you had to draw every other frame you'd be using
> half the rendering power needed for this object.  In a worst case scenario,
> youd be re-rendering the distant object every frame which would suck but
> umm...maybe like you said, you could keep track of how often an object was
> being rendered and if it was too often, make it revert to some other LOD
> technique (:
>
> In fact, i bet instead of making this all based on distance, to see if
> something should become a billboard instead of a model, you could just see
> how fast it updates ::shrug:: what do you think, good or bad?  One thing
> that would sure suck would be if a player stood still so that everything
> became a billboard then started moving again, would there be some cpu lag
> spike as it switched back to models? hmm :P
>
>
That sounds like a good idea, in the worst case scenario it would only
render a frame (when it realizes the object is updating really fast) and
then reverts to billboard (if the player slows down or it stops). But if the
player is static not everything is made into a billboard, close objects
still remain their 3-d detail). Moreover the programmer could have the
chance to choose when to turn the billboard on or off, in case he/she wants
to use another tecnique or knows there there is going to be alot of changes.

For the mountain LOD here are some ideas I've noticed seeing real mountain
from far and close (the city is called Monterrey (Mountain King), that
should give you an idea about how many mountains are over here). When seen
from a certain distance trees become blurry green (making to texture, that's
been done). But farther away they actually look blue(in case you haven't
noticed the air is blue, and it actually works like fog at really high
distances) and not only that, but slowly the sense of color disapears and
only tones of light blue appear (convert to grayscale?). Details on ridges
and so on from far could also easily be kept with a bump-map since the
mountain is so far away the illusion will be kept but the polygon count is
lowered. I don't know how much of these has been already done (but I know
somethings have).


 B: Ooo you are sooo correct. Well actualy because the drop is close to you,
> it *should* render in 3d and do LOD to a certain point and if the drop was
> really far, maybe use a billboard past that point.
>
> What i was picturing for this was like basicly getting the effects of a
> "skybox" but make the skybox be rendered on the fly (well hopefully not very
> often).  Maybe it would be a simple matter of something like temporarily
> moving the camera 1/2 a mile in front of where the player is, rendering what
> it sees to a texture, and then making that the skybox (or skysphere?).
>
> Do you think it would be acheivable w/ such a simple trick?  I was
> thinking maybe as you rotated your view around and you saw more of the
> "sphere" surrounding you, it could render those tiles on the skysphere and
> cache them, re-rendering only if something out there changed significantly,
> or after you moved enough to re-render it.
>



Yeah that would work really nicely, actually the guy at machall (
www.machall.com) did a trick very similiar to this, maybe later I'll find a
more direct link to the post he made. The trick he did though was for
blurring, and actually isn't much faster at all. He basically renders the
frame, and then passes a plane, perpendicular tu the camera, at a certain
distance and and puts the pre-rendered frame blurred as texture. The effect
is that anything behind the plane appears blurred, anything infront of the
plane covers the plane (as long as it streches to cover the screen from that
distance).
The problem with making the thing into a sky box is that if a mountain moves
to the impostor distance, the whole skybox would have to be redrawn, it
would be much easier to just draw the mountain and put a billboard for that
mountain.
Now that I think of it, couldn't another impostor be added for a ridge, be
it far enought? Even if I'm in a mountain, it's just about calculating the
angle that the object is normally seen on and making the plane perpendicular
to that angle (and positioned appropietly?)
So if I'm on a very deep ridge, the close border, and maybe the other side
is actually 3d, but if I watch the bottom I'm actually watching a billboard,
in the worst case scenario I would only see it one frame, in which case it
was as if though the billboard wasn't used. Again bump-mapping would help
create the illusion when I changed angle slightly. In the case I was in a
mountain the floor could be a billboard, since it's so far away it barely
appears to move, because the billboard terrain distance is so big there
shouldn't be glitces on mountains. Other mountains could also be billboards,
if they are far away enought. Because we actually billboard whole pieces of
land, not just areas which are far away (again the whole idea of dividing
the map into areas that represent big height changes), the whole mountain
would be bill boarded or it would all be not billboarded. It would actually
be nice the ability to force billboard certain things, the programmer may
know that when the character is on mountain B there's no way to reach
mountain A or change angle dramatically, so it's just billboarded (though
later, when he leaves mountain B he may go to mountain A). And the ridge
from the mountain, would also be a big billboard..
Another thing about areas: when I'm at the base of a mountain, the peak may
still be so far away (and the mountain be so big) that the peak may be
billboarded, so even when on the mountain, it would be convenient to
billboard certain parts of the mountain.


>  A downside tehre would be that the weak link in the chain (the most
> updated object) needed to be updated, everything would, so maybe
> pre-rendering everything to textures and then rendering onto the skysphere
> would be a better idea so that distant things would only need to be
> re-rendered as their threshhold was exceeded.
>

Again if every object is it's own billboard it maybe could change, if at
most it would be a thing of every so many frames actually rerender the
impostor, if we want to waste cpu in exchange for a very good change
checker. The more attractive solution I think would be to have the
programmer "reset" the billboard whenever he/she feels that something
drastic enought to affect the model at large. Hopefully the programmers
would find a solution that works for their specific issue, or they could
just repeat the technique I just said up there (only it's their choice).
I don't even know if you understand what I'm saying :P

Other related posts: