Temporal LOD

[Shifty Geezer]

Is there such a thing as time based LOD, that reduces detail based on time to render a frame, to maintain a constant frame-rate? Any ideas what that would look like with 60 fps but changes in models instead of dropped frames? Would that be preferable or just too wierd?

 

[ERP]

Is there such a thing as time based LOD, that reduces detail based on time to render a frame, to maintain a constant frame-rate? Any ideas what that would look like with 60 fps but changes in models instead of dropped frames? Would that be preferable or just too wierd?

I've seen a lot of attempts tp do similar things, the problem is the only way you really know how long something will take to render is to render it.

So you get reduced to feedback systems, which obviously have latency, I didn't manage to run at 60Hz this frame so I'll drop LOD next frame. Feedback systems have a number of problems and the only way to make them work is to target a fraction of the full frametime.

 

[Shifty Geezer]

Can't you render piecemeal? Render ground and main chars. How long did that take? Right, add some building. How much time> Still 5 ms to go til I need to finish the frame. Add some further detail. Presumably that'd need specialist hardware; existing pipelines being configured with a very static approach.

Trying to imagine it I'm not sure if it's a good idea or not though! Would there be flickering buildings on the horizon where they're drawn or not depending on what's happening nearer the screen? Would landscape quality show geometric wobbles? Maybe it's just a bad idea.

 

[Frank]

I think the simplest way to keep the frame rates high enough is just to limit the amount of geometry to below an upper bound. Give all your objects a number that describes their weight in rendering capacity, and add the visible ones. If the number is too big, go through your list of objects, see how big it would be on the screen, and if it is further away than a few meters and would be below a certain size, discard it, until you fall below your upper limit.

 

[ERP]

I think the simplest way to keep the frame rates high enough is just to limit the amount of geometry to below an upper bound. Give all your objects a number that describes their weight in rendering capacity, and add the visible ones. If the number is too big, go through your list of objects, see how big it would be on the screen, and if it is further away than a few meters and would be below a certain size, discard it, until you fall below your upper limit.

Unfortunately geometry is rarely the issue on it's own.
The problem is it's difficult to come up with a good metric to measure cost. Some models might be fill limited because of the shaders, some vertex limited and some even CPU limited. And worse it could be all 3 depending on the facing and size!

 

[ERP]

Can't you render piecemeal? Render ground and main chars. How long did that take? Right, add some building. How much time> Still 5 ms to go til I need to finish the frame. Add some further detail. Presumably that'd need specialist hardware; existing pipelines being configured with a very static approach.

Trying to imagine it I'm not sure if it's a good idea or not though! Would there be flickering buildings on the horizon where they're drawn or not depending on what's happening nearer the screen? Would landscape quality show geometric wobbles? Maybe it's just a bad idea.

Nope can't do that because rendering occurs in parallel with processing, when I call Draw Prim it just shoves some data in a buffer, it could be 10's of ms before that data is actually rendered.

 

[phat]

The early Tekkens on PS1 had something crudely like this, where the engine would simply stop drawing when it ran out of frame. The unfortunate thing was, because the PS1 didn't have a Z-buffer, polygons were drawn back to front, and the energy bars were drawn last, so as the engine got overloaded, the first thing to flicker out were the energy bars, then the fronts of characters. Tekken 2 or 3 started drawing the energy bars before the characters to avoid them flickering out, but then the energy bars were behind the characters instead of in front of them if there's any overlap.

 

[DemoCoder]

I believe Shiny's Messiah tried to do something like this.

 

[Farid]

I believe Shiny's Messiah tried to do something like this.

It wasn't in real-time. The engine, would "evaluate" your PC and then reduce high polygon models (for charaters only) to a level your PC can support.

 

[Qroach]

It was real time in the next game after messiah from shiney.

 

[Farid]

It was real time in the next game after messiah from shiney.

Sacrifice?

 

[Guden Oden]

I find for the the most part that what usually slows down a game isn't geometry (stand at the bottom of the pit level of Painkiller and look straight up to see what I mean; maybe even increase FOV a little), nor is it typically opaque complexity either unless the engine is crazy programmed (like ultima ascension or morrowind).

Instead, the most common thing (graphics related) that slows stuff down is multiple layers of transparencies, explosions, smoke and such. Such things is hard to LOD for too without causing lots of issues left and right.

 

[Iron Tiger]

I believe Shiny's Messiah tried to do something like this.

It wasn't in real-time. The engine, would "evaluate" your PC and then reduce high polygon models (for charaters only) to a level your PC can support.

It was called RTDAT (Realtime Tesselation Deformation And Transformation), and it was "revolutionary" because of the fact that the detail of models would change in realtime. It ended up looking more like an artifact or a glitch, though, when characters' bodies would distort as they "morphed" between detail levels.

 

[AlNom]

What does Halo use?

 

[Rockster]

LOD increments that are too large and too close to the camera!

 

[richardpfeil]

Halo 2 really has a hard time figuring out the LOD to use when there is a scene change. I'm really suprised they released the game in that condition (I guess it's not that bad over all, a one second barf a couple dozen times throughout the game, but each time it happens it's like watching a PS1 game convert itself into an XBox game). It's a difficult problem, but it seems like it should be doable. I'd rather have the first couple frames come in jerky than to start from simplest forms. How about, fade to black, render frames, measure render times, adjust, until the timings settle out, then start showing those rendered frame.

 

[Johnny_Physics]

I believe Shiny's Messiah tried to do something like this.

It wasn't in real-time. The engine, would "evaluate" your PC and then reduce high polygon models (for charaters only) to a level your PC can support.

It was called RTDAT (Realtime Tesselation Deformation And Transformation), and it was "revolutionary" because of the fact that the detail of models would change in realtime. It ended up looking more like an artifact or a glitch, though, when characters' bodies would distort as they "morphed" between detail levels.

Crud, I was going to mention that.

The system was really weird, it made the characters look somewhat like the characters from most Quake/Quake 2 based games that were released before it. Frame based vertex animations with linear interpolation between them, something like that if I remember correctly?
Anyway, the interpolation between the animation frames made the characters look like they pulsated in a fleshy and hellish way. It didn't look too wrong for Quake and Quake 2, but having a closeup of your characters pulsating head during the opening cutscene in Kingpin always felt weird.

 

[Shifty Geezer]

YEs, I imagined that might be the case! Frame drops would be more acceptable then squiggly, bulging bodies!

 

[AlgebraicRing]

I believe Shiny's Messiah tried to do something like this.

It wasn't in real-time. The engine, would "evaluate" your PC and then reduce high polygon models (for charaters only) to a level your PC can support.

It was called RTDAT (Realtime Tesselation Deformation And Transformation), and it was "revolutionary" because of the fact that the detail of models would change in realtime. It ended up looking more like an artifact or a glitch, though, when characters' bodies would distort as they "morphed" between detail levels.

How much detail do you need in your models before the effect of RTDAT is no longer noticeable? There's got to be a point where the changes are less than the eye notices and then RTDAT would be perfect for zooming in and zooming out, dynamically filling in the detail. But that point might be where 1 triangle translates to 1-3 pixel on the screen (or multiple triangles per pixel). Anything less detailed, like 1 triangle to 50 pixels would cause a noticeable change when the 1 triangle becomes 2. Then you have 25 pixels deforming.

 

[Colourless]

Quake and Quake 2 engine games used really sucky lossy compression in the verts. That caused all sorts of nasty 'wobbling' and deformations in the animation.