Wednesday, May 6, 2009

MHColour 2009 Update 12

I've resolved the problem with slipgate lights mentioned previously. Everything now looks beautiful and subtle, but not so subtle that you'll need to look carefully to see the colour. Rather it's a case that you can plainly see that it's coloured, but the effect isn't overpowering. Sweet.

The last thing I want to do is address certain textures that don't contain fullbrights but which should cast coloured lights. The ones I mean by this are those which have light patterns in them, or certain window textures (like the circular red windows in some maps such as e1m2 or e1m5). A previous version used the texture name as a guideline here, but this is not viable, as texture names need not indicate their content.

One thing you should definitely note is that a major part of how well (or otherwise) it works in certain cases is down to entity placement; most specifically brush models. A brush model will be lit in the position it is placed in when the map is generated; if it is subsequently moved to another position when it's entity is spawned the lighting of it will look wrong. The elevator to the nightmare entry in the Rogue start map is a good example here. I'm not sure whether this is a problem for me to fix or for the mapper/engine author to fix.

Another interesting effect is the red glows around map exits (and certain other areas). These come from deathmatch only brush models which are removed in SP games. However, the WinMHColour program doesn't know (or care) about this, so once again we get some false colouring happening.

The last interesting case (for now) is hipnotic rotating brushes. I don't know how these work, only that they're ghastly, but the effect here is that the brush is just not coloured at all.

I don't really consider any of these to be bugs of my program (although I could resolve the first one by calling the entity spawn function and moving the model surfaces to the correct location before lighting), but rather quirks of the primitive technology available at the time Quake was designed. A more modern solution would be to use some form of realtime lighting to resolve all of these in a very clean and easy manner.

0 comments: