Feeds:
Posts
Comments

Posts Tagged ‘pygame’

So, I finished the 3d tech-demo nicknamed “Brandmateriel” nearly a year ago now, but for various reasons (mostly work related) neglected to post it. A screencast of the demo is shown below.

Red aircraft flying over landscape with huts and firing indiscriminately before escaping up into a star-field.

Screencapture of my tech-demo. Yay! (CC: BY-NC-SA-2.5-SE)

As always with these tech projects you learn a lot, and as is often the case you land somewhere with enough new ideas that you would rather start over than take it forward. All in all though I’m very happy with it: the controls are smooth, I like the looks and the particle effects, and from a technical perspective I really like how the shadow turned out in the end (‘cos in my primitive renderer that was a major head-ache!). The stuff I would improve are mostly to do with the lighting model. My model is too general for what I use it for, and I could possibly save a few million trigonometric calculations per second if I used that. The demo runs smoothly in up to 800×600 (actually, resolution isn’t much of an issue in this kind of renderer: it is mostly limited by polygon count, but I’ve limited the screencast to the lowest resolution to conserve bandwidth), but if I were to add more (and more complex) models in order to make an actual game out of it, I expect that this would be an issue before long.

To try the demo four yourself, it’s easiest to go to clone the repository. Since Gitorious is closing down (though it’s staying up as a museum of sorts) I’ve migrated it to GitLab. If I decide to work on it, I will probably do it there, or maybe I’ll move development to GitHub. Whichever way, since I consider the project finished enough both of these repositories should be equally up to date for the foreseeable future.

https://gitorious.org/brandmateriel/

https://gitlab.com/brandmateriel/

For more on my inspiration for this endeavour (and for a really inspiringh and awesome talk about the technical challenges of early realtime 3d and how it was overcome), see this great Classic Game Post-Mortem from GDC 2011 by none other than Elite’s and Zarch’s own David Braben!

Read Full Post »

A very small update. I decided to take a few days off from coding, instead spending them digging, swimming and drinking beer (all both in game and IRL). I hope to get back on track again, but we’ll see. There’s a bit too much pollen in the air for any sort of major commitments. Speaking of commits, my friend Bam decided to make me socially awkward by cloning my repository, implementing a benchmarking suite and then requesting a merging of the two repositories. All in all, it wasn’t too bad, and since he’s a very competent programmer, his contribution (and praise) was appreciated.

Since the last update, I’ve implemented the simple linear fader, which perhaps gives even more predictable results than Gaussian. I also toyed with the light settings, but I’ve sort of concluded that I like it best when then light follows the camera precisely, though I may tweak that a bit in the future. Most importantly, however, I’ve made a new ship, which while being (I hope) a clear homage to it, isn’t just an imperfect clone of the Zarch/Virus Lander:

New ship trying to do an Immelmann and over-compensating...

New ship, and slightly updated house model. Click for full-size! (CC: BY-NC-SA-2.5-SE)

The new ship is red, to reflect its designation as a “Fire Fighter”. I tried giving it stripes, but I didn’t like the look, so I reverted to the more simple design. The house has also been updated slightly, by dividing the faces into more triangles (4 per rectangle rather than 2) which gives it better sorting and shading properties.

Read Full Post »

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.

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 »

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.

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 »

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.

(more…)

Read Full Post »

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:

Rotating 3D view of landscape based on height data.

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:

(more…)

Read Full Post »