Software Edge Clipping With GL?

[Baker]

The software renderer doesn't have Z-fighting with brush models because it clips the edges of brush model to the world.

I've been thinking a little of trying to use this in a GLQuake engine.

I've been looking through the software renderer code, it seems like a somewhat largish challenge would be converting the clipped edges into polygons and getting the texcoords. It looks like the model loader provides all the information needed to do this.

[I'd also kind of like to get alpha-masked textures (fence-like textures) working in software, but there are some obstacles to that too ...]

[Baker]

[qbism]

Fence textures would be incredibly easy in a software engine that already generates its own alphamap tables. It's just a new table. Color index X let's the base color show through.
In terms of mapping use *fenceXXX texture naming and the engine can flag it. The compiler will treat it like water so have to clip brush around it. I can't remember if typical compiler treats all * as water.
I did a similar thing for *glass.

[mankrip]

The software renderer doesn't actually clip the edges. It doesn't generate new edges, and it doesn't generate new vertices, so there's no way to use it to reshape the brushes.

The clipping is done at the spans level. It's kinda like a run-lenght encoded Z-buffer check: each span is segmented by the nearer span segments of other planes.

To port this to the GL renderer, a large portion of the software renderer would have to be used, all the way to the spans generation. And then, a fragment shader could be used to make the GPU only draw the pixels that matches the corresponding spans from the software renderer.

[Baker]

[leileilol]

that's more for preventing from drawing past the refdef's edges iirc

[Baker]

[qbism]

Via texture naming the compiler will treat fence textures like water, so won't see void. But will also inherit whatever limitations water brushes have.
Brush models are the 'hard way'' to implement but are more flexible and easier to map. Alpha is implemented this way in Makaqu in a robust way in terms of proper sorting and layered transparency. The only SW engine AFAIK that renders backtoforward correctly.

[Knightmare]

[mh]

It's also the case that texturechains built from R_RecursiveWorldNode (using the stock code) are in back-to-front order, which is not optimally friendly for modern GPUs. You can reverse the chains before drawing (I suggest reversing into per-lightmap chains) or chain in front-to-back order instead (see JoeQuake for one way of doing it) which can help get the performance up a little more.

[Baker]

[mankrip]

[Baker]

[mankrip]

WarpSpasm runs in WinQuake? I've got to try it.

[mh]