RuTh's  RuThLEss  HomEpAgE


3D Game DesignEnglish
Programming Links
* INDEX * 3D game to-do list * 3D Engine to-do list ( chapter 1, 2, 3, 4, 5, 6, 7 ) *
* projection formula * transformation matrices * Bresenham algorithm * Scanline Polygonfill algorithm *
* Spieldesign / game design * Troubleshooting 3D * Irrlicht 3D engine * Blender for Beginners *

Chapter 4 -- Drawing


"I wanted a rotating cuboid, but all I get it crazy lines!"

Here I'm trying to give you a picture of how to troubleshoot a bug in your 3D-engine. If something goes haywire in 3D, often the results seem unpredictable and it's hard to diagnose where the bug starts. This is not a complete list, of course, but just meant as an example of how to approach different kinds of faulty output. This is what we want the filled sample cube to look like.

If the cuboid looks like this, you are successfully only drawing its edges, the so-called wireframe. Wireframe drawing is a good test whether your implementation of projection works: If the wireframe looks correct, but the filled version is wrong, then you know you have to look for the mistake in the polygon-fill routines and not in the projection routines.

This is an example of a buffer overflow: The part of the object that sticks out at the side reappears at the opposite side, one row below (if you look closely). This kind of overflow is clearly caused by a lack of clipping. It often goes along with unexpected crashes: If your drawing routine writes into the wrong line (especially at the top or bottom), it will sooner or later also write outside the buffer, rendering other data in memory useless.

This cube's width is too narrow: To track the cause down, try to estimate by how much the width is too narrow — it's two-thirds... So where in the algorithm do we use the value three...? Aha! In 24-bit color, each pixel consists of three samples, one for red, green and blue (RPG). So in this case, the algorithm did manage to put some colors in, but took merely 1-byte (8bit) instead of 3-byte (24bit) steps, failing to draw two-thirds of the object's width.

On the other hand, if the object depicted is drawn too wide, check whether something is wrong with your xUnit. Here too, you can track down the error by the factor by which it is woo wide.
Similarly, if you notice a horizontal line instead of a filled area, look at the parts of the algorithm that decide when to switch to the next scanline: One of them calculates a wrong value for yUnit (it draws several scanlines at the same y-height).

This stripey cuboid has several bugs, and it serves as a good example of another 24bit-color problem: Here apparently, only every third pixel gets set to a value, resulting in this peculiar RGB-striped look. Related errors color the cuboid indigo-yellow-magenta (not a pretty sight), or black/white (all samples 255 or all of them 0). Check your setPixel() method, the instance variables it uses, and the arguments it's given.

If objects in the back obstruct objects in the front, than you are either lacking hidden-surface removal or your implementation of it does not work.