Damn

Assembly has come and gone, and due to some work related stuff we didn't manage to finish anything again. This doesn't mean we're giving up on the project though, the keyframer is still up next. Apologies to Fairlight for not making it to the compo this year either and also congratulations for a kickass release again :)

[mzx] Here we go.

A good sign towards a good intro soundtrack (or executable music) so far seems to be the necessity to fix bugs which were there for years and slipped through, because they never really used this tight.

So yeah, started on the music. Jotted down some good ideas for the basic hooks a week ago, now have a basic theme, even a bit of a heel-turn which might be excellent if we can pull it off properly. Production sounds good so far, not as tight as I'd like it but we're still only about 24 hours in, and I didn't EQ much right now and the frequencies to fill in sound pretty obvious. Listening to it now I can say it's very catchy, and also very much unlike anything we've done so far, though in a sense it does sound like a logical continuation of Actuator. Size-wise we're at ~5k, plenty of headroom still. Might even squeeze some movie samples in later.

The biggest worry I have right now is (as always) the song structure, because like it or not, it's always consensual when it comes to collaborative effort like intro-making: Even basic concepts like "the introductory part is too long", "I'd like a breakdown here" or "That edit seems unnecessary" can be (and have been) subjects for a heated debate simply because most of us have ideas for how the final product should look/feel like, and they don't always match. That said, I'm a firm believe that a good song is a good song and visuals more adaptive, so I chose a different approach this time: I make the song, finish it as much as I can (or let's say up to 80-90%), they get an end product, and they take it or leave it. I've made soundtracks for 4 of our 64ks so far, and in hindsight the ones that became successful / memorable were the ones where I assumed free rains over most of the music and only asked for opinion (and NOT pointers) late in the process. It's a gamble worth taking.

The next step will be, I guess, to map out the song structure.

Bloated

Well the 12k engine size dream is not going to happen as I've already hit that mark with the latest additions: geospheres, bevel, scatter and a few overlooked generators have made it into the engine which currently is at 12340 bytes. Even 16k might be problematic at this rate if I want to add a good particle engine, but that might still be possible. All in all I'm making great progress on the modeler, only a few things left before it's completely finished.

Lots of progress

The development machine kicked into full swing over the weekend and I'm happy to write that the modeler is functionally finished - it still needs some work to make things comfortable but everything is in there. Huge thanks go out to the Maniacs of Noise for their track Firing up as it put me in the mood for the 36 hour coding session over the last two days.
Also, engine size is still only 9960 bytes with everything in there.

SVN Testrun

We got to the point where setting up an svn server for the projects made sense and we finally got around to test how the system behaves when multiple people are working on the same project file. The test went very well as changes made on both ends merged perfectly. This should help out a lot when the deadlines approach :)

Complicated

This is starting to look like an aircraft cockpit - the more technical part of the tool with material parameters finally finished and working.

The Star

Mapxform

And then there was...

Vertex tint

This one might not seem too interesting at first, but it'll be the basis of a lot of cool things. Texture based vertex tinting made it into the engine. I also added support for multiple texture channels, and as the texture read-back code is quite big the engine size bloated to 9895 bytes.

Loft upgrade

Rotations! \o/
New engine size: 9141 bytes (yeah, I managed to optimize a bit :))

Texture coordinates

I spent some time writing the texture coordinate calculator that will be used for everything. It supports several schemes ranging from planar texturing to spherical texturing, the latter of course causing the most issues. Finally I got to a version that gives very nice results for the default primitives and will work reasonably well for any object later as well. The engine size is up to 9429 bytes due to this, but this was the last large self contained addition to the engine (along with updating mesh smooth calculations to propagate texture coordinates correctly). From the viewpoint of the engine the modeler and even the keyframer are basically complete, but the tool still needs a lot of work on both fronts.
Anyway here are a few pictures on spherical texturing highlighting the pole and the level of artifacts I deemed acceptable.

This is how the x texture coordinate looks like. Notice the lines around the pole.

This is the result when textured with a polar mapped noise texture

A proper texture designed for this hides the problem perfectly

Proof of concept

I finally got around to testing the material parameter system completely. The image in this post is the proof of concept: one single material on both cubes, but separate settings for selected parameters on both (for now it's only the color).

Filtered

The mesh filtering system is in place, now all that are needed are some of the filters. Catmull-Clark mesh smoothing is already in place, smooth group edge hardness will be pretty easy to do, the hardest one is MapXForm where I'll need to link the texture generators result into the mesh system. After that's done the material system needs to be finished, import/export added and the modeler is finished. This can be done before the end of the month.

Lofty

The mesh type we abused the most before is now in the editor: lofts. With a proper generator engine working behind the scenes this time the editing of lofts in realtime at any moment is a breeze. Engine size is up to 8648 bytes in the meanwhile.

Platonic

After some heavy refactoring today things are finally starting to shape up nicely. Platonic solid demo, yay :)

Model generator flexibility

Today was mostly spent diving headlong into the model generator, until I realized the concept we used before wasn't really thought over. After some discussion we managed to figure out a way for the model generator to work that will both be easy to implement and to work with. In the old system the user basically threw in commands after each other, things like "generate a cube", "apply mesh smoothing", but in a quite twisted way. We realized that the old approach could be cleaned up by implementing it as a linear "generate model" -> "filter model" -> "done" scheme. The problem of this approach is that there's no way to branch a half done model into two separate things. Other than that this scheme is perfect for our needs. Luckily we can create a "copy" primitive that takes a finished filtered model and essentially branches it off to a new one. With this, the new model editor concept is pretty much finished, so back to coding again.

Wrapping Normals

The object manipulator tool is finally in a state where I can quickly expand it in any way we need. Started working on basic mesh generation and realized that the way we generated the normals was off, so spent quite a while on it. Perfected normal calculation itself to work nicely with smoothing groups, but still hit a wall with some visual glitches. After hours of investigating and a very good tip from our other coder I found the problem: using texture wrapping while sending normal vectors in the TEXCOORD0 channel isn't a very bright idea. D'oh.
Anyway, with the new mesh generator additions and a skeleton project loader the engine size is up to 8028 bytes.

Ubertool

This weekend is spent working on the object manipulation gizmos. These are crucial to the smooth operation of the tool so I'm taking my time implementing them. Object picking is a bitch as always (the only thing I actually miss from OpenGL is the named rendering for object picking), so I decided to let D3DX do the bulk of the work for me instead of using clever semi raytracing techniques. D3DXIntersectTri ftw!

Camera views

I made very good time on the camera views for the modeler and finished everything in a single night. Display and camera movement are both finished and working perfectly. Time to start working on the actual model editing features. Also after numerous tiny fixes and several additions to the engine it's now at 6185 bytes.

Unified

My second oldest partner in crime has joined in the audience and possibly the authorship of the blog. The three of us are now seriously thinking about our next major release. The goal is to hit Assembly #20!

It's alive!

Well. The engine framework written blindly works like a charm. Lots and lots of work is still needed, but the blind part's over. Yay.

Smoothing

First mesh operator I implemented was the most intricate one, catmull clark mesh smoothing. Also added some management code to build meshes and added a cube "generator". These upgrades added ~1.2kbytes to the engine which is now at 5488 bytes - however the old butterfly mesh smoothing scheme we used would have added twice as much without even mentioning all the mesh topology issues we always had with it. The 12kbyte engine size might still be possible if all goes well.

Mesh basics

Yesterday night was quite productive, laid the foundations of the mesh class. Dynamic arrays for vertex, poly, and edge data, all the required connectivity info, edge list building and normal calculation with smooth groups - in about 750 bytes. This works. :) Mesh generators and filters are up next after I get some sleep.
Current engine size: 4298 bytes.

Mesh Generation

Had a long talk with my creative partner about the new modeler today. The mesh generators will be upgraded, but nothing drastic. The decision has been made to scrap everything from the last version of our toolchain and revert back to the ideas used before that one. Looks like this will work out best for us, the possibilities are really exciting.

Uninitialized

Lost a few creative hours to a weird bug yesterday, even went and installed the service pack for visual studio to see if it would fix it. Turned out to be an uninitialized variable. Should have known, I always fall for that.
Anyway the material editor is coming along nicely, I decided to take the hard route and create the UI for it as well while I'm on a creative streak. The engine framework I'm building upon didn't need a single change/fix up to this point so all is going well.

Still flying blind

The skeleton of the engine is basically complete, now I need to start working towards a very first rendered mesh. This is going to take a few more days, but I have the whole weekend in front of me dedicated to this purpose. Also did some size checking with the current version, according to kkrunchy I'm at 3364 bytes including every bit of code up to this point. Packing the whole thing into 12 KBytes seems like a strict but achievable goal which would make it our smallest engine yet. By half. Add 12 KBytes to that for the synth and music and you have 40 KBytes left for gfx art which would open up some very interesting possibilities :)

Engine graph

This is where I am in the brainstorming process of the engine. Could be worse.

Blind run

Working on the base of the 3D engine now. This part is a pain as I won't be able to see anything before everything is in place at least in parts. Got a decent new spline class up and running, and the material system I'm working on may finally fix all of the issues of the last system. Our customary scene in scene system will make scene graph traversal a bitch to implement, but it speeds up the workflow for the artists a lot.
So for now I'm flying blind and just putting framework and base engine code together, but it's shaping up to be something very cool.

Yep, it works

Texgen is up and running, opstacking didn't become a mess as I feared, and I have some very solid ideas on how to proceed. Things look promising.

Streamlining

Today was the day from hell in terms of work and school, but I still managed to get some streamlining done. The affected areas are mostly on the ui side, added syntax highlighting for #defines in the text editor, added a generator load graph and made single line text input a lot more user friendly. Also fixed a possible endless loop in the generator system. Hopefully tomorrow I can get the SAVE and LOAD operators up and running after which comes export and import for the texgen, and after that I can move on to 3D.

Inconsistency

So it turns out that >= comparison operations for very close float values under a win7,dx9,nvidia setup can give inconsistent results, even if the values tested and everything in the setup is exactly the same (think recorded pix run playback giving different results on different reruns). This one cost me two weeks to figure out, but finally I can move on with the tool.

Rise from the ashes

Let's try this thing again.

I'm scratching the tool and restarting based only on the UI engine and the base texgen code. Opstacking it is this time as that graph based approach just didn't turn out good.