Wanton Hubris

I installed Leopard and all is well! I was sort of half expecting something to go wrong but my computer seems happy as a clam.

Leopard is a whole bag of awesome. What’s funny though is that the features I was expecting to own me really didn’t. Like Stacks for the Dock. Not really overwhelmed there. But then here comes Spaces and I’m blown away! I never thought of myself as a multiple desktop kind of guy but I’m hopelessly addicted now. I’ve got 3 running right now and being able to flip between different desktops, each one clean with just a few apps running, is amazingly productive!

Time Machine is also pure greatness. I already use Mozy for hourly backups but Time Machine goes a whole step beyond because it’s backed up my ENTIRE COMPUTER. Awesome. I have an external drive (1.5TB) that I designated as my back up area and it’s cool as hell to see it do it’s thing. With that kind of storage, I’ll have viable machine images that stretch back for years.

Anyway, Leopard owns, I gotta get back to playing with XCode 3…

(btw, can I get a HELL YEAH for garbage collection in Objective C 2.0?! For the love of all that is pure and right, thank you!)

Well, not really, but it’s a reasonable fake in the Quake engine.  It’s a pretty simple trick that other editors and exporters have used but I just added it to mine.  What I do is have a special tag I place on meshes inside of Cheetah (in this case, just putting a “*” in front of its name).  When my exporter sees that it treats every triangle of the mesh in question as a separate Quake brush and it adds polygons behind it to make it a complete shape.  This leads to some exciting possibilities.  Look at this mesh, for example:

It looks like I’m building a cliff or hill or something but that sky texture on top is out of place.  Now suppose I delete the bottom polygons and open this thing up.  If we then flip the normals on these polygons and look up from the bottom it looks like a canopy of cliff faces with sky above.  Like this:

And here it is inside of Quake with some extra brushes added and proper lighting:

This opens up a lot of cool possibilities and really limits how much brush drudgery I have to deal with inside of Cheetah.  I can rely on Cheetah’s strength in modeling shapes and let the exporter turn it into something Quake friendly.  Love it!

Here’s another use of this technique, adding some rock details into the ceiling and some dirt piling up on the floor:

I foresee much fun with this!

Man, that was fun. I added a ton of options to the Quake light compiler. I mentioned the sunlight in the last update but that’s all properly hooked up now through key/value pairs in the worldspawn. I just added ambient light options but the exciting change is for lights!

I added a few new fields which give you a lot more power with lights now. For every light you can now set it’s inner and outer radius as well as a light strength for each radius. This means you can do cool things like torches with hot spot lighting on the wall behind them and then a fade out to black beyond that. It really works well. Here’s a picture to better demonstrate:

This gives the level designer a ton of freedom when designing their areas and how they want them to be lit. Quake was somewhat limited in it’s original form (heh).

{
“classname” “light_torch_small_walltorch”
“style” “1″
“_outerradius” “150″
“_outerlight” “125″
“_innerradius” “48″
“_light” “250″
“origin” “-313 -320 44″
“angle” “0″
}

That ain’t your typical wall torch!

Here are some quick examples showing everything working together (the sunlight, ambient light, and new lighting options for point lights). The top shot shows some nice lighting falling from the ceiling beams and being broken up by the torch light. The second shot shows a few torches in the scene and you can see how the hot spot lighting really plays out.

I haven’t checked to see if spot lights are still working. I’ll have to get to that eventually I suppose.

And for those keeping score, I’ve decided that I wasted a ton of time on the texture mapping stuff. It’s actually fine to just use the material tags in Cheetah for the individual cases where I need to align a texture manually. It’s not as bad as I was originally imagining. I suppose I should have tried to build something for real before diving so deeply into the texturing stuff. Oh well, a lesson learned and work flow streamlined - not a bad result by any means!

So I decided to spend some time today delving into Quake’s light compiler and see what I could make happen.  Turns out that it’s not that complicated!  One important thing to note is that the “light” tag you add to light emitting entities in your MAP file is really denoting a radius, not a light strength.  With this knowledge in mind, I was able to forge ahead.

For my first trick, I added a sunlight option to the light compiler.  What it does is pretty straightforward : for each lighting sample location in the world, the code traces along a user specified sunlight angle.  If it hits geometry, it doesn’t get any sunlight.  If it hits a sky brush, it gets sunlight.  The results are pretty cool!  What’s cool is that I was careful to color inside the lines when changing the code so the sunlight plays nicely with regular light as well.  I’ll be back later with more cool stuff - hopefully!

I think I’ve got my texture mapping issue from yesterday solved. It was the solution I was hoping it would be after all!

I also cleaned up my Quake script quite a bit. It was getting messsy. You know how code gets, especially when it’s one monolithic file like this. This one script is handling texture alignment, exporting and a few other small utility functions. Sure, there’s code sharing between the various actions but it all adds up.

It’s definitely getting there.  I can create little test rooms now without too much pain.  Here’s a shot of my test room running in Quake:

The rotation on that arrow texture worked great but it doesn’t look right inside of Cheetah yet.  Not sure why that is.  I think I can fix it but it’s going to mean going over my texture mapping routines again and possibly redoing them yet again.  Le sigh.  Not sure I want to shoulder that just yet.  I’ll think about it.

I wrote some code to drill upwards through the folder hierarchy and grab the classname from the topmost folder instead of the one immediately above the object being exported.  This means I can group brushes together now into sub folders and copy/rotate/scale/etc them as a group.  That is going to be hella useful and wasn’t something I had the ability to do in the Quake editors of old.

I also changed a few bits of code that will make work flow much easier (such as grabbing material names from the filename of the material instead of the name within Cheetah’s material browser).

Something is wrong with my texture mapping code though.  It’s nothing serious but I just discovered this morning that it doesn’t do the right thing on textures that are not 64×64.  I know it sounds like I should have noticed that before but most Quake textures are 64×64.  I think I can hack in a fix by just scaling the resulting UV coords based on the size of the texture.  I’ll see about that tonight.

So anyone who has done Quake level editing before knows that entities need to have key/values assigned to them in order to customize their appearance and/or behavior. A key/value is a set of strings so something like: “light” ” 400″, would change a light in the game to have an intensity of 400 instead of the default 200.

To replicate this functionality within Cheetah I’ve come up with a hacky scheme where you can add a “Text” modifier to your light object and set the key/value in it’s name field. This modifier is set to not draw in the editor so it is completely harmless except for the memory it consumes (and I’m not caring a lot about that right now). It looks like this in Cheetah’s Object Browser:

So you can see the “style” and “light” key values right there in the Cheetah UI which will be great for editing/reviewing later on when the levels get larger. As an added bonus, the cube object can be collapsed so that you don’t have to look at the key/values if you don’t want to.

BTW, that picture gives you some insight into how I’m handling Quake classnames as well. What I’m doing is adding folders called “worldspawn”, “light”, “info_player_start”, and so on. Every object added inside of those folders gets the classname assigned to it of the top most folder. So those 2 cubes inside of the “light” folder will be exported as individual “light” classes in the Quake MAP file. Kind of cool, I thought!

Here’s a quick shot of what a light looks like in the level right now:

The yellow cubes are lights!

Sometimes you just have to accept your limitations and move on. My limitation is math. Man, is it math. I tried several ways to get the texture mapping in Cheetah to export to Quake in a happy way and they all failed in some way or another. In the most promising case, it looked like a simple rounding issue because if I hand typed the values I wanted into the MAP file, it would look right but if my exporter wrote the map file it would add a few decimal points here and there and the texture would be way off in Quake (OK, a few texels but in level design that might as well be a chasm).

The problem has something to do with scaling.  Well, honestly, I think it has to do with the fact that Cheetah multiplies it’s texture matrix in a different order than Quake does or something like that.  Because it looks right in Cheetah.  And it looks like proper values in the exporter.  But then it’s off slightly (or sometimes majorly) inside of Quake itself.  So I had to change gears.

My goal through all of this was to come up with a way to minimize the pain of texture mapping in Cheetah. See, Cheetah has this concept of material tags that can be applied to specific polygons within a mesh. This sounds great until you try to use it. The feature is so horribly implemented that half the time it doesn’t listen to you and the other half it fucks up previous assignments and … just … ugh. So I wanted to get away from that and that meant one thing: UV mapping. And that’s fine. I can UV map competently but the problem is that I can’t convert a 0-1 UV mapping into a Quake UV vector and offset because of my previously mentioned dumb addedness in math.

What I was able to do, however, was a multiple step process that allows me maximum freedom within Cheetah while still allowing me to get something good looking into Quake. This will sound horrible but it’s not that bad, really.

1. To use simple offsetting (panning) of a texture, I can just use the UV mapping inside of Cheetah. If I use this option, I also have to add a “Render Tag” to the object. My exporter looks for this tag and if it sees it, the exporter will compute the offset values automatically by comparing the default Quake texture mapping with the current Cheetah texture mapping. The difference in position is the offset.
2. If I want to rotate a texture, I have to resort to using the material tag system (grrr). If the material tag for a polygon has a rotation value, then the exporter will grab the offset, rotation and scale from that tag and not try to get fancy.
3. Finally, if I just want a brush to be default mapped in Quake I just create it and add a texture to it. The exporter will just spit it out to Quake and let it worry about it.

Now, yes, this is somewhat complicated but remember that I’m trying to turn a 3D modeling program into a Quake level editor. We’re going to have to accept some hacks along the way.

I still have a long way to go here since entities need key/value properties and a bunch of other niggly things need to happen. Better get back to it.

Things are moving along!  I’ve learned a lot about Cheetah scripting via javascript, some 3D math, and a little more about the internals of the Quake engine.  Exciting stuff!  Here’s what I’ve got so far:

So what we’re seeing here is a little scene rendered via Cheetah.  This is after I applied a custom script that mimics Quake’s texture mapping scheme inside of Cheetah.  I then used Cheetah’s material tag properties to align the textures to my liking.  Then I used another script that I wrote to export the objects into the Quake MAP file format and ran that through the standard Quake tools.

And … it works!  I’m going to massage this further since it’s actually working.  I’m going to figure out ways to add lights (the one in the scene now is jammed into the MAP file, brute force style) and monsters and other cool things.

Progress is fun!

So I’ve been playing with Quake and trying to figure out something fun to do with it. I spent last weekend buried in it, trying to figure out a way to get geometric shapes exported from Cheetah 3D into Quake. I figured out that the OBJ file format was good for this since it was easy to read and parse (this was after a failed flirtation with the RIB file format which ended up letting me down). I wrote a conversion program that would convert the OBJ files into Quake compatible MAP files and after working out a few glitches, it basically worked.

Then the sadness came.

Duplicate planes! Points off plane! Gah! My guess is that Quake’s compiling tools have a fairly low tolerence for decimal points and weird angles (which is what modeling programs are best at creating). I could get basic blocks brought into Quake but that didn’t satisfy my creative needs - I need more.

I downloaded the compiler tool source code and converted it to run on the Mac myself (qbsp, vis and light). My hope is that now that they are being produced on my machine, I will be able to massage the source where it needs it to accept the more complicated shapes I want to throw at the tools.

We shall see!

So far, it’s been frustrating at the the same time so very awesome. Quake is a fun place to play.