Software Edge Clipping With GL?

[mankrip]

Good info MH.

Are there vanilla-compatible BSP & VIS compilers for this?

[mh]

[Spike]

regarding z-fighting, you're probably best going with some sort of csg solution. try this:
shrink the submodel's bounding box by an epsilon.
find all non-solid world leafs within shrunken bbox.
if all were solid, then early out: the bbox is in a wall and nothing should be drawn (might be coplaner like the lift on e1m1).
create a bounding box of the open leafs you found, expand it by your original epsilon.
if this new bounding box is bigger than the original bbox, early out: its a closed door or something that's fully visible.
anything remaining is half-embedded within some geometry, but its side may be coplaner (e1m2 exit doors)
chop off any part of the geometry that extends outside this new bounding box. use clip planes or an equivelent (if you've got only one clip plane, you can just pick the most significant axis).
assuming everything is axial, the worst case is that any z-fighting is restricted to an epsilon along the coplaner side of the door. if you have confidence in your numerical precision, you can keep the epsilon small (using .3 fixed point for bsp geometry should give precise clipping without any zfighting at all, assuming you implement your clip plane in software). if you want non-axial then things become much more complex, and it will hopefully not be needed.

regarding fences, yes. compat was with halflife. tools not understanding { was somewhat of a surprise, but then tools not supporting spaces either is also an issue. a gl engine 'should' generally be able to support fences on world surfaces (again, more recent halflife maps use it) if only because its somewhat trivial to do so, but this requires qbsp support and isn't recommended for that reason alone (presumably similarity with water+watervis could be used here too). I don't think software rendering was a consideration at all. iirc, doesn't the software renderer merge submodels with world surfaces resulting in fences being a problem regardless of which bsp tree its in? all I really remember now is that software writes bsp colour and depth in separate passes which is a significant issue with alpha testing, so pulling it out into a separate pass from the opaque span rendering stuff is mandatory.
* warps with optional alpha blend
{ does not warp, and requires an alpha test to ensure that depth buffering happens properly. blending should only be needed if the entity its on has .alpha set. tools should be careful to enclose such texture names in quotes when saving maps with these textures, if possible (like they should if it has a //, /*, whitespace, or non-ascii char in the name, or arguably an open bracket).

[Baker]

[mankrip]

[Spike]

or as part of func_Illusionary, with a separate clip brush compiled as part of some other entity (probably world).

[mankrip]

Yes, but iirc it wouldn't cast shadows then, which isn't always desirable.

Surfaces using alpha-masked textures with only a few holes through it would look bad if they don't cast shadows. E.g. should not cast shadows, but should. And textures with small decorative holes such as should cast shadows too.

However, they probably shouldn't let projectiles pass through them when they don't cast shadows.

These are the kind of complications that made me not implement support for such textures yet. I'm only implementing them when I get around to taking care of all of these possibilities at once.

[mh]

If memory serves we never even bothered about the question of shadows. It just didn't come up in discussions.

Only having them on brush models means that it's immaterial anyway, since the light tools don't create shadows for brush models either.

[mankrip]

Well, I just woke up and felt like implementing support for alphamasked textures, so it's done.

The implementation supports it on both BSP entities and world surfaces, and not only it accepts the '{' naming convention, but it also searches for transparent texels (color index 255) on the textures, so either way is valid.

The non-alphamasked surfaces of all BSP entities will still be rendered through the solid surfaces renderer, so they're still fully optimized. Only the alphamasked surfaces are drawn over.

There's also preliminary code for optimizing this on a per-mipmap basis. Each mipmap is individually scanned and flagged for transparent texels. I've done this because if the holes on the texture are small, they can disappear at lower mipmap sizes, so the surface could be treated as non-alphamasked when that happens.

I'll post a screenshot on Saturday, because I'm on the phone and don't have internet access at home anymore.

[mankrip]

Some more notes, before I forget:

It doesn't work on opaque turbulent surfaces ( '*' ), skies, and opaque mirrors ("window02_1") — even though mirrors aren't implemented. Supporting alpha masking on those wouldn't be hard now, but it seems quite pointless.

I'm not sure if it works properly on animated textures and on alternate textures, specially if the first/default frame isn't alphamasked.

Other related features such as clip brush physics, and water-style visibility to prevent void/HOM artifacts aren't engine-dependent, so they should be fully implemented in the mapping compilers instead.

[Baker]

Adding alpha masked textures was probably a 15 minute ordeal for your engine

Mirrors: I bet you could do it if you implemented a stencil buffer into software. The main obstacle would be the WinQuake skybox support, which is why you'd need a stencil buffer. Then again, having control of the software renderer, you might not actually need a stencil buffer and can write your own rules.

[mankrip]

Makaqu 1.6 already has a good chunk of specific code for it, but it was still surprising to see how much time that saved me.

Anyway, it was more like 1 hour to get the meat of the code done, and another 3 hours testing, fixing and finishing it.

I don't think there's any vanilla-compatible map with alphamasked animated textures, so I'm probably going to make one for testing.

Mirrors are fun, but there are more important stuff to improve first.

[mankrip]

I was partially wrong.

The software renderer does Z-sort the spans, but it also clips the edges. This edge clipping is only performed against the world's edges, which means the software renderer does have Z-fighting — but only between BSP entities.

When I noticed that in the code, I made a test map with two exploboxes partially inside each other, and it happened. However, due to the renderer using Z-sorting on a per-span basis instead of per-pixel Z-buffer checks, its BSP Z-fighting looks like a screen-space horizontal cut from one BSP face to another.

I've noticed that when taking a quick look at how to disable the Z-sorting of "fence" textures' spans. In fact, now it feels like it wouldn't be too hard to optimize all the different kinds of BSP translucency in a much better way, and to add sky-brush depth occlusion to skyboxes.

By the way, the edge clipping is skipped on BSP models that falls entirely on one node/leaf/something like that. And it isn't clear to me how the new edges are stored in the RAM, and how they're linked in the edges list.

[Baker]

Hopefully this means I wasn't insane when I interpreted the code as clipping bsp entities against the world. Right?

And this means with enough thought I could apply the existing functions to OpenGL (if I take some/most of the software renderer overhead) and then use the output set of edges to render entities (although it will require conversion, like calculating the texcoords, etc.)

Am I correct?

[mankrip]

The function you posted is for clipping against the view, as leileilol said.

The render path for clipping against the world comes much earlier, and is more complex. Search for the string "falls entirely" and you'll find the comment of the code where it begins.

In theory, with some effort it should be possible to port it to hardware-accelerated engines, but I don't fully understand that part of the code yet.