Change of plan

After integrating a terrain engine (see screenshots), we ran a profiling test. The results disappointed us - ruby is really, really slow. Once we stopped garbage collecting every frame, the function that took the most time was this:

def Actor#update
   passed = Time.now.to_f - @last_update
   @rotv_x += @rota_x * passed
   @rotv_y += @rota_y * passed
   @rotv_z += @rota_z * passed
end

Looking at that, it was pretty obvious that we weren't even going to be using ruby for a scripting language, much less the basis of a 3d engine. Too bad - it was really nice to work with.

We tried writing a terrain engine in lisp to see how we liked it, and it was about as hard as it was in C. One really annoying thing was lisp's inability to allocate a large block of structures all at once. In Common Lisp, making an array creates a block of references, which then have to be filled in manually with references to new structures. This is pretty bad for a terrain engine's vertex map. Looking on the internet, the common suggestion is to use parallel arrays. How FORTRAN-esque.

So we've changed the strategy to use a lisp-type language as the scripting language for an engine written in C.

Network/Multi-user Support

We've separated vivis into a client and server, so multiple people can now get on and share the same space. The modeler file support was put on the back burner until we got more features in our rendering engine. The rendering engine hasn't been touched, so there are no new screenshots.

We'll probably be working on getting those necessary features into the rendering engine for a) eye candy and b) the modeler format support. After that, the particle support (and accompanying visual trinkets).

Multiple Mesh Support

Vivis now supports multiple meshes per actor. This means we can put our ships together dynamically, changing its appearance depending on its loadout. Our next step is uncertain. Particle support would be pretty cool, but so would directly supporting the format used by our modeler. We'll probably hash it out before the weekend.

Transparency! Yeah!

After a long hard weekend, we've finally got some transparency support. This is actually quite a milestone.

You see, in order to draw transparencies correctly, you need to draw all the opaque objects first, then draw all the transparent bits ordered from back to front. To order the drawing from back to front, you have to get the distance each one has from the camera, and to do that, you have to do your own 3d transformations.

Doing your own 3d transformations really sucks. I had previously been relying on the graphics hardware to do that.

Next milestone is handling ship models with multiple meshes, so ships can have moving parts. That should be fun.