Bryed 3d (1998) postmortem

[phibermon]

I must say that software rasterization is the one aspect of 3D graphics coding that I have very little experience with - I've made a simple ray tracer to learn about some concepts but hardcore fast routines on lower spec hardware? I'm all but oblivious!

I've watched some talks by Romero and Carmack about the development of doom and they did touch on a few aspects but I guess I've been spoiled by 3D hardware :\

I've been toying with an interesting concept of late - similar to the 'imposter' technique - basically rendering distant objects to buffers every other frame with the frame in the middle being a translated drawing of the frame before - I already claw back some cycles with things such as rendering skydomes - only updating them at 15fps etc

i'm heading towards using such a technique for rendering distant terrain - I suspect I might be able to find a sweet spot between movement speed and rendering updates for distant geometry that looks acceptable.

So in the middle frame I render half of the geometry to a different cube map - and then render the previous buffer, with the new camera translation - next frame I render the other half of the cube map and then swap the new buffer with the old and render the new buffer.

That way I'm spreading the load across two frames - surely such techniques have been done before but I'm currently unaware of any commercial application - hopefully that doesn't mean I'm wasting my time

[SilverWarior]

I've been toying with an interesting concept of late - similar to the 'imposter' technique - basically rendering distant objects to buffers every other frame with the frame in the middle being a translated drawing of the frame before - I already claw back some cycles with things such as rendering skydomes - only updating them at 15fps etc

i'm heading towards using such a technique for rendering distant terrain - I suspect I might be able to find a sweet spot between movement speed and rendering updates for distant geometry that looks acceptable.

So in the middle frame I render half of the geometry to a different cube map - and then render the previous buffer, with the new camera translation - next frame I render the other half of the cube map and then swap the new buffer with the old and render the new buffer.

That way I'm spreading the load across two frames - surely such techniques have been done before but I'm currently unaware of any commercial application - hopefully that doesn't mean I'm wasting my time

I could see benefits of this when you have pretty much constant movement speed. But I don't think it will work well when your movement speed varies a lot. But then again I'm not an expert in graphical rendering. So I might be wrong.

[Chebmaster]

I don't think distant terrain would work well. There'd be tearing and cracking and all sorts of nasty artifacts.

Distant objects, on the other hand...

Every other frame is too often! Impostors really shine when you redraw at rates from from 6 to 1 FPS.

So: impostors are best used for static objects like rocks, trees or even buildings (preferrably with a depth component so they can be blended flicker-free into the scene, like they were 3d). Slowly moving creatures as well.

But! A modern impostor must be made using multi-target render, to consist of, at least, color, specular, normal, glow and depth textures so deferred lighting could be applied to it.

Also, you need a sophisticated manager that decides which objects are rendered normally and which use impostors, how much texture memory each one uses (hello, fbo space manager). And, if you think of it, lots of impostors require lots of texture space.

To summarize, the best application where impostors shine would be a dense forest.