dabroz.scythe.pl

Recently everyone went insane about tesselation. Like every other shitstorm, there is a lot of BS about it.

So to be clear: tesselation itself can only smooth objects, not make them more detailed. The "magic" comes from displacement mapping -- and it's not that easy.

For example I was browsing today Gamedev.net's Image of the Day forum and found this example of tesselation:

Can you tell me that in above picture, tesselation is state-of-the-art technology, allowing extreme 3D experiences? Would you believe yourself?

I would split all bump mapping effects into 2 categories: flat surfaces & others. For flat surfaces we have wonderful raytrace-in-pixel-shader solutions right now, like relief mapping or my favorite Cone Step Mapping. Look:

from Bruno Evangelista Detailed Surface

Apart from lighting which doesn't match (due to some shader errors probably), can you tell the difference? I mean, can you tell which is tesselated and displacement mapped and which is raytraced in pixel shader?

But flat surfaces are (very) easy case. What about complex meshes? The truth is: both parallax and displacement mapping will help as very little. Have you ever tried to bake heightmaps to use them will those techniques? There just aren't any tools available that would create good heightmaps. For this reason most games stick to normal mapping for complex meshes (or eventually do parallax with very little height which doesn't improve quality much, but can provide nice artifacs -- and that artifacts are growing along with parallax strength). Sure, Unigine graphics team could spend a lot of time to polish their dragon's textures -- well, thorns are quite easy as you can grab flat polygon and draw a circle with gradient on it:

But what next? How long does it take to create ready-to-use mesh with real displacement map? I'm not saying that tesselation is bad. It's just greatly overrated.

BTW: Displacement mapping seems to have advantage about silhouette modifications. But look at this:

It's from Nvidia's SDK -- pure parallax mapping with fins extrusion. And look how does the shadow mapping work on parallax mapped surface. Now, this is something!

When I've started UT engine & editor about 1.5 years ago, I needed to decide about attaching editor to engine. I've decided to create editor in C# connected to game engine (which does all rendering in editor's subwindow) via sockets (see this [PL]). Now I know it's probably not the best choice.

Let's call it option 1. Benefits: WYSIWYP, no editing/GUI in main engine. But another problem arises. We need several "edit/debug" features anyway, like displaying objects selection, moving objects with mouse, click-to-select, visualise lights/markers/scripts. Game engine doesn't need to, for example, save models but still there is a lot of code unnecessary for normal gameplay and a lot of optimizations missed (for example you can't assume that static objects will remain static as level designer can move them).

There are of course other options. We could code editor as completly standalone application with its own renderer. It lets engine rendering code be super-well optimized but lacks very important feature: WYSIWYP. I believe it's no use as of 2010.

And, of course, you can code everything inside your engine (including level editor and other stuff). Well, I was somehow scared to do it as my C++ was way worse 2 years ago -- now I don't see this option as total madness :)

What would I do if I've started coding this toolset now? I would go 1+2. I would code editor with its own, quite simple renderer and connect with main engine via sockets only for "Preview" tab/window (or just let engine window run on other display). This option is also possible if you have engine running on PS3/X2Π and editor toolset on PC. Still some optimizations are gone (like non-static static objects) but many other are saved.

It's a little too late for me to start coding editor from scratch (maybe in version 2.0) but I have a little different solution: I have separate Object Editor (able to import models/skeletons/animations/physics and do some basic editing and setting up) which -- to be honest-but-not-so-modest -- is itself probably more advanced than many amateur engines. ;)

Usually we start fullscreen game using ChangeDisplaySettings to change desktop resolution and then create window with flags WS_EX_APPWINDOW and WS_POPUP. This is fine as long as you are running one display system. If you have 2 monitors connected, ChangeDisplaySettings will change resolution on BOTH of them. Not nice.

So the solution is:

• (probably in config/startup window) use EnumDisplayDevices to obtain list of valid displays (entries like \\.\DISPLAY1 (NVIDIA GeForce 9800 GT))
• when user selects monitor he wants to use, you can change resolution only on that monitor, using ChangeDisplaySettingsEx, passing device name (\\.\DISPLAY1) as the first argument
• but another problem arises -- how can you specify on which screen you want the window to be created? In Windows, both monitors are one big virtual display which resolution is approximately sum of monitors resolutions. You can obtain location and size of each screen using EnumDisplayMonitors. You need to provide your own callback function. Happily for us, IDs of entries are just the same as for EnumDisplayDevices. You'll get list of screens with LPRECTs of them, so you can create window at given (X, Y).
• and others displays are ready to provide useful info during testing, like VS' output (you can detach it outside main VS window)

There are 2 big problems with SSAO. First is locality. The lower radius, the higher quality. But set radius too low and instead of occlusion you get very slow edge detection filter. And main disadvantage of SSAO is how it looks on flat surfaces. This is typical implementation (similar to Crysis') and looks OK as long as you want to use it as only shading method. If you want to combine it with normal lighting & shadows, it's just too messy.

I was in Warsaw ZOO today and I found something that truly amazed me as graphics programmer.

Apart from realistic fluid simulation, do you see those wonderful god rays? And marvelous caustics everywhere? Let alone color balance, postprocessing is also first class. And seeing manta rays flying like they were in the air, not water... It makes me want to write suitable 3D demo :)