Wanton Hubris

Nothing all that exciting to report these days.  I’ve been working on the core of the editor and some of the less visually exciting features.  I took a few wrong turns with the code but thanks to the snapshot feature in XCode I was able to recover pretty easily.  Here are some shots of the new entity editing panel I’ve been working on.  It doesn’t do key/values yet but that’s next!

You know what’s neat though? Since the editor is drawing everything as WYSIWYG as it can manage, the spawn flags change the appearance of entities in real time.  Watch this!

Decided to move on from the loading/saving issue and push ahead on editing features.  Once I can create levels from scratch and write them out to MAP files for compilation, I’ll be able to create test cases and custom maps easily.  This will lead to easier debugging in the future so that’s how I’m selling it to myself.

I added the ability to rotate brushes and entities this morning.  I’m trying to orient the editor towards having certain key modifiers always be related to something specific.  For example, the CMD key always allows you to add to your current selection (like it does in Finder).  The SHIFT key does things related to brush faces.  The CONTROL key is related to manipulation of entities/brushes (dragging and rotating them for example).  The OPTION key modifies whatever is going on (for example, when dragging, this key will allow you to drag vertically in the 3D view rather than just side to side).

 I also added some menu items for loading new WADs into the editor.  You have the choice to just load a new WAD and replace your currently loaded texture set or you can append a WAD which will add the new textures into the currently existing set.  I want to eventually have a save menu item which will let you write out your current texture set as a new WAD.  I can read WADs so writing them should be doable.

Man, lots of stuff came together over the last little bit.

I have full dragging support in now for entities, brushes and brush faces. I need to figure out how to do edges and vertices next but the framework is in place. The drag code is nice too because it figures out which axis you want to drag on based on your mouse movement and the camera angle. So dragging to the right will pick the right most axis based on your camera view. It’s hard to explain but super intuitive when you’re using it!

Since selecting brush faces works now, I added clicking in the texture browser which naturally led to changing texture assignments on brushes and faces. That all works and is fully supported by the undo/redo system.

Everything, in fact, is fully supported by the undo/redo system. It’s fantastic! I love having it there and being able to add new features to it as they come online has been great. As soon as I get something new working, I immediately hook up the undo/redo support. You’ll thank me later!

Here’s something cool … you can cut, copy and paste pieces of your map between levels. So open up DM2, select some stuff that you want to borrow, hit CMD+C, flip back to your map in another window and hit CMD+V. Voila! Enjoy your borrowed goods. This is especially cool because it’s writing and reading to the clipboard in Quake MAP text format so once you copy something, you can paste it into a text editor and save it for later use if you want.

Once the clipboard stuff was working, it was pretty trivial to get duplication set up. Hitting the space bar will duplicate whatever you have selected and offset it slightly.

The editor also now writes out to MAP file format so you can save your work - kind of important, I know. The thing is I must be doing something wrong because currently I can’t load a map that I KNOW compiles, save it out, and compile it again successfully. I have a rounding bug somewhere but I’ll get to the bottom of it. That’s currently my top priority because, well, it’s pretty bad. Heh.

What was great in this process however was the cut/copy/paste functionality. The fact that it works is great but I love the fact that I was able to refactor the code base a few times over and now everything MAP related flows through a single pipeline. Loading a map, saving a map, copying and pasting, and duplication all use the same functions. As a programmer, that satisfies me greatly.

Got my bug list down to zero today so I started working on the next large feature which is : selecting things!  Kind of important in a level editor.  I never fully understood the OpenGL selection system but it actually clicked this morning.  I see it clearly in my mind which is wonderful.  I hate working in the dark and under assumptions and just praying that these weird function calls I’m making will do the right thing.

I’m getting that quite a bit with this project.  Other light bulbs that have come on for me have been realizing why and how to put the camera transforms into the MODELVIEW matrix and how poly/plane clipping could be made to work.

So even if this project turns into nothing, I will have learned a lot of really great stuff!  Obviously I’m hoping that it doesn’t turn into nothing but sometimes life takes over.  You know.

Anyway, selection is almost working!  I have it doing the selection correctly wherever I click in the viewport.  I just need to retrieve the results now and figure out specifically who got clicked.  I’m going to get the selection stuff set up to where it’s fast and easy to use before I move on to other features.  It’s pretty important to get it right.

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!

A simple door so we can add some exits to the area.

 And some misc junk to drop around the scene and stick to walls. I’ll like need to make a few more items in this category but not too much.  Maybe a garbage can and a sign or two.