Software Edge Clipping With GL?

[Baker]

[mankrip]

Ok, I'm with my two laptops here now.

In R_DrawBEntity, near the end, BSP models that aren't in a single leaf are sent to R_DrawSolidClippedSubmodelPolygons, to be clipped against the world.

In R_DrawSolidClippedSubmodelPolygons, the medge_t data from the model is copied to a bedge_t struct, and then the bedge_t data is passed to R_RecursiveClipBPoly along with the model's surfaces and nodes.

R_RecursiveClipBPoly clips the edges from the medge_t data, and apparently it stores the resulting edges into the local psideedges array. Since this function is recursive, it means that every time it's called, a new copy of psideedges is allocated, so the code can allocate exactly the required amount of RAM for the clipped edges, without ever knowing how many edges will be generated. This is why I couldn't find any data set for clipped edges before. After each finalized polygon is generated, it's sent to R_RenderBmodelFace.

R_RenderBmodelFace calls R_ClipEdge to clip the edges of the polygon against the screen, and stores the resulting data in the surf_t *surfaces list through the surface_p pointer. The surfaces list is allocated in R_NewMap through the line surfaces = Hunk_AllocName (r_cnumsurfs * sizeof (surf_t), "surfaces");

Why such a generic name was used for a global variable so important? I've had to search for surfaces[, *surfaces and surfaces = to be able to track the parts of the code that uses it.

Anyway, R_RenderBmodelFace doesn't do anything afterwards. The surfaces data is rendered through D_DrawSurfaces, which is called by R_ScanEdges, which is called by R_EdgeDrawing after all R_DrawSolidClippedSubmodelPolygons calls have been issued by R_DrawBEntitiesOnList, which R_EdgeDrawing had also called before.

Holy crap.

[Baker]

Thanks for the explanation as it can be very difficult at times to make heads or tails of the code at times (due to the cryptic names, the local variables vs. the large number of globals).

Sometimes even finding something is a maze in WinQuake.

[mankrip]

Took another look to figure out the Z-sorting of spans, and nothing yet. They seem to be sorted by R_EmitEdge, but a quick test didn't work.

[Baker]

I noticed the qsort on the entities in your source. Of course not the same as the spans.

/Darn software renderer cryptically cloaking what it is doing

[mankrip]

Yeah, that's for translucent entities. But "fence" textures requires a per-surface solution, and disabling the Z-sorting would be the ideal one for this.

Eventually, I also want to modularize the whole renderer, to make it more flexible and less confusing.

[qbism]

[mankrip]

It looks like the whole r_ poly.c file from Quake 2 is needed. I'll try to port it.

And I've found a perfect example of how bad the Z-fighting of BSP entities can be. Open the start map of the Contract Revoked mod, and look at the floor of the Normal difficulty room. Both the lava and the bricks on the floor are BSP entities, and there's lots of Z-fighting between them - even though their planes are perpendicular to each other, which surprised me. This happens in all software-rendered Quake engines.

[mankrip]

Here's a screenshot:

[qbism]

I've seen a sawtooth effect similar to that but not as bad as that screenshot.

[ericw]

[Baker]

[ericw]

Yeah - I mean the .ent's aren't the worst, but if this "emulate SGIX_reference_plane with GLSL" idea actually works, it seems like it would be better, and wouldn't have the issues of adding cracks around secret doors that gl_ztrick does.

If it works, what I was thinking was:
- new "gl_zfightingfix" cvar deafults to "auto" which means "enabled on whitelisted original game levels only". You could manually set it to "1" when playing late 90s maps with z-fighting, to get software-renderer-like behaviour, but otherwise it would default to being off.

Last time I played the original levels I noticed several spots where the QS .ent's missed correcting z-fighting, and it is kind of distracting / takes you out of the game.

[mh]

There's a method using the stencil buffer described here: ftp://ftp.sgi.com/opengl/contrib/blythe ... ode20.html

Not certain how robust it is for this particular use case though.