Fade to black + Yaw-Pitch-Roll

Some more progress today:

• The colours now fade to black with distance. After much discussion with my friends who work professionally with 3D graphics, I implemented a function neither of them suggested, but that seems all right to me, namely, Gaussian luminescence. This has the property, that the lighting stays roughly constant near the camera, then gradually decays to zero further off. There are many ways of doing the same thing, but Gauss is very convenient to me as a physicist, since it has a well defined scale to it which can easily be tweaked (the physicist in me chooses not to think to much about the fact that the light should really fade like 1/R²…). I also tweaked the light source to have a very faint red hue, but it’s very subtle.
• I’ve implemented rotations for the objects (and refactored that piece of the code since it was becomming stupidly redundant). This means that the engine is now visible! I’ve implemented the rotations by using explicit rotation matrices, which is what I know and understand, but its probably not very efficient compared to quarternions. If, at a future stage, this appears to be a performance issue, then maybe I’ll have to learn about those…

Next on the list are (in no particular order):

• Depth culling
• Better object sorting
• Controls (mouse + keyboard)
• More objects
• Shadows
• Particles
• Variegated ground

But that’s all for another day!

Lander-craft doing aerial acrobatics. The small house has turned and repositioned to have a better view in the dimming light. Click for full-size! (CC: BY-NC-SA-2.5-SE)

Read Full Post »

Depth sorting and flying objects

Guess what? It turns out, that rather than being trivial, sorting is one of the main problems in 3D graphics. The landscape renders ok, as long as the camera is not too low, it should be fine due to its ordered nature (small angles between neighbouring patches), but when it comes to more complex objects it becomes a hassle. There are no simple solutions, and no elegant ones, so I nearly gave up on it, until a friend (who is soon a Ph.D. in 3D graphics, and yet was kind enough not to laugh out loud at my dabbling in his field) pointed out that one can choose only to render surfaces whose normals point toward the screen. That is simple, it is almost elegant, and it solves much of the problem if care is taken when constructing the objects. Three cheers for science!

Below, you can see a picture of the “Lander-craft” (our hero-to-be) hovering over a landscape with a small house. The landscape is generated from data generated using pseudo-random sine waves, by way of an extremely circuitous route involving FFTs, binary morphology, and a lot of heuristics. Unfortunately, the engine of the craft is not visible in this view. Not that it’s visually very impressive, but I had to work quite a bit to get it to “stick” through triangle sorting… The next job is to make the demo interactive and implement some sort of dimming of the light with distance, neither of which should be too hard either…

Lander-craft (our hero-to-be) hovering over a landscape with a small house. Click for full-size! (CC: BY-NC-SA-2.5-SE)

Read Full Post »

Two different versions of the sea

This post is a follow-up to the previous post on 3D rendering. I thought I’d made enough progress to warrant a new post. The landscape is still the same, but I’ve now implemented a “patch” renderer, where the ordered set of points in space combine to create square (in the xy-plane) patches. If these are above the sealevel, they are flattened and given a blue colour, whereas if they are above it, they are given a green colour. The base colours are then shaded by a simple light scattering algorithm, based on their (approximate) normals’ orientation with respect to a light source, which in my example follows the camera.

The sea is treated in two different ways, depending on whether the “flattening” is performed before or after the normals are calculated: in the first case, the result is a sea with a fairly uniform blue, whereas in the second case the structure “beneath the surface” shows in the colour of the “waves”. Both versions have their merits, but final judgement will have to be made when I’ve seen how it looks when the camera is closer (the intended view for the eventual game is 12 * 9 patches on screen, while this scene is 64 * 62 patches). For this zoomed out version, I’m inclined towards the flat sea.

Read Full Post »

First steps in 3D animation

My friend Pica pica makes animated GIFs as a hobby, and is very good at it. Some examples are her philosophia naturalis studies at Reanimate Objects and the frankly fantastic (and more artistic) works available in the various Calendars at Unknown Incubator (seriously, check them out!). Another friend — Local Minimum — makes games, of late mostly in 3D. I’m not very keen on 3D graphics myself, but I like to fiddle with things, learning and understanding them, and I do like retro-games, so I decided to write a simple 3D-renderer in Python. It was quite fun mathematics, and I’m rather pleased with the first result, which I present as an animated GIF. Since they both inspired me to it (and since I had the data) I decided to visualise the terrain around their mansion as my first example.

The code is available at Gitorious. It is licensed under GPLv3. It uses NumPy heavily for the backend and currently uses MatPlotLib for visualisation. The latter is rather horrible for the task though, and in the future, I’m planning on making a simple shader algorithm and implementing surfaces in PyGame, though I guess in the opposite order to that stated… But, the future is not now, and now I am tired. Therefore, please enjoy the fruits of my endeavours thus far:

Terrain data from western Sweden, visualised using a primitive 3D renderer I made. The area is approximately 128 * 128 m². (CC: BY-NC-SA-2.5-SE)

EDIT: The future is semi-now! I’ve now rendered the same scene using PyGame:

Read Full Post »