After some books finally arrived by mail, I’ve been spending the past two weeks reading up on 3D maths. Being unhappy with how my playground engine Wick3d was evolving (bad code flow resulting in poor maintainability being the worst of it), I decided to put some of this newly acquired knowledge to practice and redo the engine from scratch. Perhaps the biggest structural improvement would be that the operations such as transformations, culling, drawing, etc… are now being executed from a centralized render pipeline. Furthermore, some other things are done more correctly. For instance, the render target is now a viewport and the camera works with field of view instead of some random zoom factor. The latest addition is a rudimentary clipper, which clips triangles intersecting the projection plane so they don’t just disappear when they’re too close. Regretfully, it doesn’t look too great yet (I have linear texture mapping to thank for that). The shading that was in the previous version hasn’t been reinserted, and it will probably be a while. There’s still plenty of other things that I want to realise before I get back to that.

The code still isn’t available yet, mainly since the code’s not entirely the way I’d like it. In any case, this project is just a study case for me. But who knows what the future might bring

Check the demo if you feel bored, move around the mouse a bit and use the mouse wheel to change the field of view (and notice how fast it starts to look ugly).

I’m not sure why this is worth writing about, but I got bored and in a visit down memory lane, I decided to revisit some of my old DOS-experiments in Actionscript, and enlighten a thing or two on the subject

Chaos theory used to be a subject that interested me a lot in high school for some reason, and when looking at the subject, you can’t skim past Strange Attractors and, in particular, the famous Lorenz Attractor. An important aspect of what this system is showing, is that small changes in the initial state of a complex dynamical system can result in large and unexpected differences on a larger scale (commonly known as the butterfly effect). In this example for instance, changing the initial position just a little, will at first seem to converge with the trajectory of the original position. In later stages, however, it will diverge more and more. Plenty of that can be read in literature, and it’s beyond my scope here. The demo doesn’t really allow you to play around with that either, it only shows the trajectories for the constants in the equations. It’s mainly there for aesthetical reasons, and to give a source code example (right-click on the demo, you know the drill).

Anyway, I thought I’d just enlighten you on how to bring these babies to the screen. Why on earth would anyone even want to put them on a screen? Well, for some reason, I find them beautiful But perhaps more important, if you’re looking for complex, unpredictable, non-repeating, but pattern-like movements, you might just end up using differential equations (I’m thinking smoke, turbulence, adding milk to coffee…). Play around with it, and see what you can come up with.

In the case of the Lorenz attractor, the equation goes like this:
dx/dt = σ(y-x)
dy/dt = x(ρ-z)-y
dz/dt = xy-βz

In practice, this means that over an infinitisimal amount of time (dt), the variables x, y and z will change by the respective left-hand side of the equation. Of course, in programming, we’ll have to approximate the infinitisimal character. We’ll work in steps of time, instead. Obviously, smaller steps will be more correct. Let’s rework the equation just a tiny bit, replacing dt with our time step:

dx = σ(y-x)*timestep
dy = (x(ρ-z)-y)*timestep
dz = (xy-βz)*timestep

So afterwards, we just add dx, dy, and dz to x, y, and z respectively, and we have the next position in the trajectory! σ, ρ, and β are constants that will influence the attractor. By changing these values, there will be three possible situations: the trajectory will converge towards one point, diverge towards infinity, or will endlessly seem to be attracted around a set of points without ever repeating itself, in which case we have a chaotic system going.

And that’s it! Complexity doesn’t need to be complex at all Checkout the demo or the source to see the implementation.

The past week, I’ve mainly spent trying to figure out how to do (fake) Phong shading and environment mapping. In the case of phong, the result can be seen here. A few alternatives that I tried didn’t work out, but after some quick hints from Ralph and lots of calculations, I found a solution that more or less works (at least for me ). Weirdly enough, most of my time went into figuring out how not to show the lighting on the opposite side of the lit object (it’s a normal effect since this shading technique borrows from environment mapping). As you might notice, it’s still not quite right…

In the demo, you can see more or less the same cube and sphere from the Gouraud post. The uv-mapping is still off on the seem where the two horizontal ends of the texture (should) connect, but at least now I know why The texture “wraps back” because the U-coordinates are on opposite sides of the texture. I’ll have to figure out how to fix it… If it looks like a familiar problem, any suggestions are welcome

Next task: heavy duty optimization and refactoring! Good times

Since some time, I’ve been working (off and on, and more off than on) on a rudimentary 3D engine in ActionScript 3, code name Wick3d (hah, I know, rediculous!). Not to become the next Papervision, since there are plenty of engines doing a much better job (just check Papervision, Away3D, Sandy or Alternativa3D and keep a tissue close in case of droolage). Anyway, I’m just interested in 3D algebra and whenever I see something cool, I want to know how it works, and if it results in stuff like this, I’m having tons of fun as well

It’s surprisingly easy to get messy code while adding functionalities, so I had to start from scratch a couple of times. I also had to throw out some work such as coloured light sources, which were killing cpu when used with textures, and to be honest, no one really wants to use untextured objects so I might as well streamline it to be the same for all types of surfaces. This weekend, I reworked the lighting calculations according to Lambert’s cosine law for diffuse lighting and added support for specular highlights. Finally, I also added a Gouraud shader (I have to admit I had a grin on my face when it finally worked). Basically, it’s using a linear gradient image map and defining uv-coordinates on it based on the lighting per vertex normal. After that, it’s drawn the same as any affine texture map.

The code is not public (yet), coz it really needs a lot of cleaning up, and well… It can’t do much right now (apart from creating cubes and spheres). Of course, if there’s people who want to look at it out of interest, I can always clean up the mess I made in there and put it online.

Check the demo if you want, as you can see the frame rate isn’t all that high And apart from that, something is wrong with my UV-mapping. I’m not sure if it’s an error in the texture mapping or the calculations for the spherical coordinates (I suspect the latter…).