Software Renderer Mysteries

[Baker]

For WinQuake ...

Does anyone know how to make brush model entities render with alpha? If I make the code stipple brush models with .alpha, behind them = void (like the software rendering code has decided what is behind it cannot be seen).

Has anyone done this successfully or know how it can be done?

.alpha is part of the Fitz 666 protocol and although I added Fitz 666 to a WinQuake ages ago, without .alpha maps like back2forwards (great test case!) won't look right.



Thoughts?

[Spike]

the software renderer's spans are drawn with no overdraw. it clips the polys against each other before filling in the screen.
then it draws depth after, just so mdls+particles+sprites work properly.
if you want transparent or translucent stuff, you'll need to move those surfaces into a separate rendering mechanism, to ensure the stuff behind is already drawn.

[leileilol]

Quake2 even had this problem so they derived their translucent brush drawing code from the water spans code, making some very jumbled up glass textures as it worked strictly with 64x64 tiles. This is why that window in base1 right at the start looks corrupt, as well as other places such as bloody glass in the jail maps


Another place to research is Hexen II which absolutely ABUSED lookup table effects (among other crazy things like particle collision). Makaqu also got this to work with recursive translucency IIRC.

[Baker]

Darn, that's what I thought. Thanks for the infos.

[Update: although on the plus side, digging through the Makaqu code ... I'll have to see how this works out ... crosses fingers.]

[Update2: Makaqu hates the back2forwards QuakeC, crashes. Even if I do -game back2forwards +map e1m1 ....]

[Baker]

Documenting as I look around in the source:

r_main.c: Found r_foundtranslucency qboolean
r_draw.c: Several instances of same. Code in R_RenderFace.

[Baker]

Grabbed quakec source, open defs.h + add .float alpha. Made .ent file deleting one door and adding "alpha" "0.5" to other:

Loads Makaqu ...



Cool!



Incredible!

[mankrip]

[Update: although on the plus side, digging through the Makaqu code ... I'll have to see how this works out ... crosses fingers.]

The support for BSP entity translucency is the most complex and difficult feature I've ever written.

By the way, it doesn't work exactly as in hardware-accelerated engines. In Makaqu, translucent BSP entities doesn't blend with themselves. This can be noticed in the screenshots you posted:

Hardware acceleration


Makaqu

The cockpit blends with itself in hardware-accelerated engines, but not in Makaqu.

I've done it this way for performance reasons, and also because it's less problematic. Imagine something like this, but as a translucent BSP model:

In hardware-accelerated engines, it would look as if the wood had holes where the pieces touch each other. Makaqu doesn't have this problem.

[mankrip]

By the way, even though translucent BSP entities doesn't blend with themselves, they do blend with each other.

Makaqu screenshot:

[Spike]

to get depth working sensibly with the object itself:
draw the object's depth values.
draw the object's colour values using some depth test that draws with equality.

the further stuff will then safely be masked by the near stuff without drawing it.
perfectly viable in gl.
probably workable in software too, if needed (cache the spans!), but everything involving software rendering takes more time.

[mankrip]

perfectly viable in gl.

Yes, but I don't know of any hardware-accelerated Quake engine that does it.

[Spike]

fte does, at least for transparent view models (two render-entities to not break custom shaders on the viewmodel), and q2 shells (quad/god glows around players, using a 2-pass shader for the shell render-entity). both look much better for it (fte's rendering code is nothing like glquake, so good luck copying it, its nothing like software rendering either, of course, which was the focus of this topic).

[qbism]

Makaqu

The cockpit blends with itself in hardware-accelerated engines, but not in Makaqu.

I've done it this way for performance reasons, and also because it's less problematic.

Currently I'm trying to implement this by setting surface flags based on ent->alpha, but have hit a snag: alpha brushmodels aren't blending with other alpha brush models. Sometimes it looks bad. My best guess is that alpha surfaces should not clip against other alpha surfaces, but I don't know where to look for that.

[mankrip]

I can't look at the code yet, my house is a mess.

Anyway, the problem lies in the spans sorting&clipping algorithm, which still is a mystery to me.
A way around that is to reinitialize the BSP renderer before drawing each translucent entity. I've done that in r_main.c.

[qbism]

Thanks, that method got alpha entities working. Fence textures seem to work on bmodels but not the worldmodel. Might need a separate pass for fences. I'm working on support for the Rubicon Rumble Pack.

[mankrip]

Alpha masked texture support on the world BSP requires a number of complicated changes. I still have some major bugs to fix in it, and in the BSP entities too.