Software Edge Clipping With GL?

Discuss programming topics for the various GPL'd game engine sources.
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Software Edge Clipping With GL?

Post by mankrip »

:) Good info MH.

Are there vanilla-compatible BSP & VIS compilers for this?
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Software Edge Clipping With GL?

Post by mh »

mankrip wrote::) Good info MH.

Are there vanilla-compatible BSP & VIS compilers for this?
The decision was to only support them on brush models, so any compiler is compatible.

Some of the reasoning behind that decision was that you can see through them anyway, and light shines through them anyway, so you'd be effectively recreating brush model support for world brushes and doing a whole lot extra work for something that just already exists and with no work required. Plus I'm very much NOT a tools person so there was an element of pragmatism in it.

I still really don't see any value in wanting to support them on the world model; it just seems a hell of a lot of messy work for no real gain.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Software Edge Clipping With GL?

Post by 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
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Software Edge Clipping With GL?

Post by Baker »

Spike wrote: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.
...
Nice notes :D I did notice that WinQuake uses efrags and visibility to determine what to compare, comparing the world model visibility set against the brush model.
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.
I found this out the painful and hard way when I got HOM trying to (NOT) draw alpha masked pixels. Still studying Mankrip's engine, haven't had time to completely walk through Makaqu's drawing code.
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
I have noticed an annoying circumstance of alias vs. brush model z-fighting in WinQuake, it is very rare. I'll have to keep this in mind and look at the alias drawing code in WinQuake.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Software Edge Clipping With GL?

Post by mankrip »

mankrip wrote:Also, it would be nice to make them solid to the player, while allowing projectiles such as rockets and grenades to pass through them. This happens in Doom, but I don't remember if such mechanics are present in the vanilla engine.
John Fitzgibbons wrote:the "clip" texture -- a texture named "clip" which mappers use to create invisible geometry which blocks players and monsters, but not gunfire.
Well, that's the answer. "Fence" textures would have to be compiled as clip textures, but visible.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Software Edge Clipping With GL?

Post by Spike »

or as part of func_Illusionary, with a separate clip brush compiled as part of some other entity (probably world).
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Software Edge Clipping With GL?

Post by 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. this texture should not cast shadows, but this other one should. And textures with small decorative holes such as these 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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Software Edge Clipping With GL?

Post by 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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Software Edge Clipping With GL?

Post by 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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Software Edge Clipping With GL?

Post by 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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Software Edge Clipping With GL?

Post by Baker »

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

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.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Software Edge Clipping With GL?

Post by 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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Software Edge Clipping With GL?

Post by 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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Software Edge Clipping With GL?

Post by 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?
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: Software Edge Clipping With GL?

Post by 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.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Post Reply