One of the really cool things about working with a bunch of crazy-assed talented content creators is the feedback and interaction that goes on between all parties as part of the ongoing quest to establish what features RMQ is going to have. There has been a lot of talk elsewhere about standards for moving Quake forward, and this is our chance to propose - and show off working examples of - some of the items we think should be included in these standards.
My own remit starts and ends with the engine, but even as part of that I do get to have input into some decisions regarding content. One recent one that we've just cracked is "fence textures", or - because pictures speak louder than words - things like this (not an RMQ map, by the way...):
I'm going to stick my neck out a little here and say that this is a feature that Quake should have had from the outset. Doom had it, Q3A had it, it's only poor little Quake (and Q2, of course, but that's to all intents and purposes the same engine) stuck in the middle that didn't have it.
Final decisions haven't yet been made, but what we're doing for now is using any texture who's name begins with "{" as such a "fence texture". The reason for selecting "{" is that it's what Half Life uses, and if there is prior art that has already established a standard naming convention, it makes sense to follow that example.
Next up - a dastardly disasterous DirectQ bug destroyed. Stay tuned.
Monday, August 9, 2010
Pushing for new standards
Posted by
mhquake
at
9:55 PM
Subscribe to:
Post Comments (Atom)
7 comments:
Excellent reasoning.
The only reason I think why Id Software didn't include this feature in Quake is because there was no depth mapping for 3D textures at the time, so color-keyed textures would always look flat. The lack of color-keying ensured that mappers would have to model their objects in 3D.
Or maybe they just lacked the time to implement this feature instead of polishing the rest, dunno.
Quake's software renderer uses sorted spans to render polygons without overdraw, and if there were transparent holes in the middle of some polygons then the whole system pretty much breaks down.
http://www.gamedev.net/reference/articles/article983.asp
http://www.gamedev.net/reference/articles/article984.asp
oh and about this standard, since i have considered this in the past, but was stopped short by lack of specifics....
1. should backfacing "fence texture" polygons be drawn or culled?
2. should the renderer use hard edge (gl_alpha_test) or soft edge (alpha blending?) If hard edge, what alpha threshold? Or is it up to the implementor?
3. What about replacement TGAs -- if they have an alpha channel do you use it always, or only if the original texture name starts with a '{'?
4. do you allow it on world polys or only on submodels?
This is one of the reasons that a major mapping/content project like RMQ is useful for creating de facto standards -- once they settle it for themselves, the obvious choice for engine devs is to be compatible with their way of doing things.
Some good questions. Right now we're not targetting any software renderers, but that's not to say that a viable engine might not emerge from somewhere. The most likely candidates already support r_wateralpha in software which is only a short step away from being able to do this, so it's most likely not going to be that big a problem.
1. So far there has been no visible need to draw backfacing polys; everything works fine with normal culling.
2. Up to the implementer. Some may prefer alpha blend, some may prefer alpha test, and each is actually better suited than the other for certain situations. It's actually best if engines with both options emerge so that players get a choice of which they prefer.
3. Easier to always require '{' irrespective of whether or not a TGA/PNG/whatever already has an alpha channel, otherwise things get messy.
4. We encountered some problems with world polys that would need a QBSP change, so it's submodels (and instanced bmodels) only.
1. cull normally (single-sided). Brushes using this will generally be thin. Drawing both sides for both the front and back would give an echo of sorts.
2. I say alpha test. This avoids all depth rendering glitches (drawn after world and before blended stuff). Either way, transparent pixels must be filled in with a different colour (at least if they came from an 8bit source).
3. Automagically enabling blending if the tga contains an alpha channel = wallhack. It should only be transparent if its explicitly marked as such.
Besides, there are probably many tgas out there used for walls that erroneously contain an alpha channel for one reason or another, and an engine suddenly deciding they're meant to be transparent would not be nice.
4. QBSP will consider them fully solid and cause pvs artifacts if they are part of the world, as well as cut away other surfaces. It should be possible to implement them as a kind of solid water perhaps, but I don't see that its too important to support it on world models. Renderers should support it on world probably, but it shouldn't be mandatory/noticable. If alpha-testing, then it makes no difference to an opengl renderer whether it was world or non-world.
One other factor with 4 is lighting. If part of the world they would also block light, which - 95% of the time - wouldn't be what you want. So light changes as well as qbsp changes then.
For 2, the RMQ engine is already sorting all non-solid objects back to front so it doesn't matter there. Other engines that don't sort or that draw in passes would need to use alpha test, and it's probably the easiest way overall.
From a mapper's perspective,
1. culling is fine as far as I can see; drawing both faces might be interesting for everything that can be seen from all sides, like a floating transparent touchscreen / HUD, or simply grass.
You could use sprites for those though (in RMQ usually loaded via misc_model), and just place two oriented sprites facing the opposite way, so the result is something that's partially transparent and has 0 thickness.
Proper lighting of sprites, at least sprites loaded via something like misc_model, would still be desirable because of this.
2. can't comment
3. Replacement textures should have to take the mapper's intention into consideration, thus only alpha where the original texture uses {.
4. can't comment, also I can't see why func_wall wouldn't suffice.
Having these things cast shadows would actually be nice, in some cases, like a fence with a torch behind it. But changes to map compiling tools can be problematic, since everyone prefers different ones and their code can be pretty different from each other. There is also no dedicated tool coder in the community atm.
On the other hand, no reason why RMQ couldn't include its own map compilers. That's not so far from having your own engine.
Post a Comment