GL nodes; need to be made a requirement

DaniJ

<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Engine, Mac OS X, Unix/Linux, Windows.</i>

I believe we have now just about reached the stage where in order to progress the Doomsday renderer, GL node data is a requirement.

Now that the map data structures are engine-side, we have the opportunity to restructure things into a layout more suited to the way Doomsday renders the map. If the map data objects were linked together into a mesh-like structure there would be far greater opportunity to optimize the renderer.

Therefore, I would like to make GL nodes a requirement, so that we have complete convex polygons  (the subsectors) to work with at all times.

skyjake

The requirement of having the GL nodes present is a sensible one, especially since glBSP is now used as plugin and is guaranteed to be available.

What do mean by "mesh-like structure" for the map data objects?

DaniJ

Basically what I was thinking of was organizing the map data so that its internal representation matched the relational structure created for render.

A sidedef's segs would be ordered and linked to the linedef.
Vertex line owners would be refactored so that their owner node links are attached to segs. Plus other minor changes.

This would allow walking freely between segs of all adjacent subsectors just by following vertex owner nodes.

More importantly though, this modified structure would allow easy dereferencing from a sidedef to the relevant seg(s) and then the polygon used for render (which could be linked into the level data structure and used for walking). This would mean that the various data structures which make up the map would actually represent:

sector == simple polygon
subsector == convex polygon
seg == poly edge
vertex == poly vertex

Therefore, once linked together in the way that model geometry is we have a "normal mesh".

DaniJ

Recently you may have noticed how large and unwieldy finalizeMapData() (dam_main.c) has become due to the logic required to try to make sense of DOOM map geometry. In particular, I have recently been making this detection more robust so as to try and rationalize the structure we will ultimately have to render (once polygonized). This logic is not yet good enough (IMO) as it allows certain structures (based around self-referencing lines) to pass through undetected (though it is noticeably more successful than previous algorithms... but much slower).

Over the past day or so, I have been discussing the issue with Ajapted (of glBSP) and reached the conclusion that a new strategy is required to best support these structures in a GL renderer. Basically, it involves simply not generating segs for self-referencing lines and instead, the application should detect self-referencing linedefs seperately.

Using a quick implementation and testing with various maps (such as the crane structure near the map start in PAR.wad MAP01) I have found that by using this strategy, our emulation success rate is greatly increased (and a lot of the complex logic found in finalizeMapData() is made redundant). Another benefit of this approach is that numbers of segs and subsectors are reduced.

However, what this does mean is that if we want to embrace this strategy; it requires we ignore nodes supplied to us from other nodebuilders and instead opt to always build nodes (which of course can be cached as we do currently) using dpmaploader (which would be updated to the latest glBSP version; 2.24).

I am proposing we adopt this approach. Any objections/reservations/thoughts?

Yagisan

ok. Make it work *correctly* with NO regard to speed. please - just don't try to optimise this. I'm happy to rebuild all nodes, and I can test it here on a pentium 2, 233Mhz box to see how slow it may be, once *NIX builds ok (as in, I can play it)

dengDevs Import

<i>This comment was posted by dengDevs user <b>Ajapted</b>.</i>

There is another possible solution, which I think I should mention before you commit yourselves to using glBSP.

Basically: use the normal BSP tree, and when the renderer hits a seg, draw the floor/ceiling of the *whole* sector (well, everything touching the camera frustum).

This will suck for some cases, like those maps surrounded by a single water sector. So it depends how badly you need to prevent overdraw.

The other part of this solution is being able to polygonise each sector, both robustly and fast enough to do it at level load. While this is not trivial, I do think it can be achieved (hell even the GLU polygonising code might be up to it these days).

DaniJ

I did consider that approach, primarily because we plan to "relax" the clipping a bit anyway so that we can freeze the geometry for render across multiple frames.

However, I don't think it will be the best way to do it due to the excessive overdraw, drawing all segs + subsector planes will lead to under fairly common situations in which a sector has multiple disjoint subsector groups.

Polygonizing the subsectors is actually pretty trivial (given that glBSP ensures they are convex polygons) once segs belonging to self-referencing linedefs are taken out of the picture completely. We already have a fairly quick algorithm in place for this.