dabroz.scythe.pl

Recently we've got a nice extension: ARB_debug_output.

It allows OpenGL implementations to provide more detailed errors and warnings. To be honest, person that invented glGetError (and consided it a reasonable debugging method) must have been mad or completely drunk. Am I over exaggerating? If you think so, try to fix your car using only one six-color LED diode. And I'll repeat once more: software engineering, and specifically graphics programming is not a goddamn MasterMind game.

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 :)

Using high-level stuff is fun. As long as it works.

Consider this C# code:

var s = new WebClient().DownloadString("http://foobar.biz").Replace("<br/>", "bar");
Console.WriteLine(s);

Cool, isn't it? Now imagine that you have to do the same thing in C, UNIX-like way (sockets etc). Yeah, seems like a real pain. And this is why high-level coding is fun.

But now assume something gone wrong. If you're "lucky" you'll get a nice exception. If you're not, you'll get some mess not related to expected result. What can you do next? Google "DownloadString mess" and read first three Stackoverflow topics? If this works, high-level programming is not as great as before, but still quite fun. But let's say that Google knows nothing. You can read API documentation. Oh yes, a lot of docs before you find something useful. And what if you find nothing?

The worst category of such bugs are "everything theoretically works, but I see nothing/crap". For example imagine you have high-level 3D engine and use such line of code:

engine.Render("car");

If it doesn't work as you expected, number of possibilities is +infinite. What can it be? Buffers? Shaders? Rendertarget settings? Where have you done it wrong? In loading stage? But there is no loading stage, engine loads everything from XML files itself, blah blah blah. And that is of course if you actually have knowledge about buffers and shaders and stuff. If you do high-level only, chances are you won't.

What I am going to say is that the only way to learn every tiniest details of some stuff is to code it COMPLETELY using most low-level you can afford. You can of course know no deep details of some stuff and still be happy human, worker and husband. But you won't know that tiny bit that makes it work. And if it fails, you'll be left alone on the ice floe.

Examples. You can know a lot about containers and algorithms, their Big O and characteristics. But will you ever be 100% sure what they exactly do to your objects? Another. You can happily use some UI library for years but when it comes to coding your own controls, their input handling, don't you feel a little nervous? If your control is on the scrollbox, in what exact order will they get mouse inputs? And why?

It is actually very easy to know if someone coded something or just used/read about it. One minute of talking and you know that he doesn't know all drawbacks, problems and dark sides.

But the sad fact is that things are getting now more and more complex. In 80' you actually could code just everything. And now? To be honest, to know every single details, you should start with x86 (and GPU, and HDD and...) emulator (VM), then do some OS programming, then code your C compiler (if you expect to reach 90+ age you can try C++), then most low-level libraries, and so on.

Yes, you could spend your whole life doing this. But... you would be surprised by NOTHING. :)