Exporting subsector data to zscript

[Rachael]

This is something I would do on my own but I don't know enough about the engine to confidently know what data needs to be moved out.

This is for the native ZScript port of TDBots:
https://github.com/coelckers/gzdoom/compare/tdbots

TDRR said that he needed the subsector data in order to effectively build the bot nodes in a level. The nodes would help the bots more intelligently navigate the levels than what means are currently available for this.

[phantombeta]

TDRR said that he needed the subsector data in order to effectively build the bot nodes in a level. The nodes would help the bots more intelligently navigate the levels than what means are currently available for this.

I personally feel like having access to the split, triangulated mesh of the sector planes would work better for that, as well as being useful for more things than just the bots.

I'm also not sure if it's a good idea to export the subsector data in general, either. It's very implementation detail-y, and exporting it would lock their implementation into what it is now.

[Edit] Regarding the latter point, I just remembered these two threads: thread 1, thread 2. Graf confirms what I said about them being an implementation detail in both of them.

[Graf Zahl]

And nothing has changed here, all those points still apply.

[TDRR]

I personally feel like having access to the split, triangulated mesh of the sector planes would work better for that, as well as being useful for more things than just the bots.

As long as this is actually done in the end, I'm fine with this. Subsectors are easier to work with for me, but if it'd cause issues then I'm fine with anything that doesn't just involve using the sectors straight as they are.

[Graf Zahl]

What are you trying to do?

[TDRR]

The idea was to place nodes at the center of each subsector. Link them, and prune out all nodes with no links, or any that are in a place no player would be able to fit in. I assume something similar is perfectly possible with the triangulated mesh, I just don't know exactly how yet.

[Major Cooke]

TDRR said that he needed the subsector data in order to effectively build the bot nodes in a level. The nodes would help the bots more intelligently navigate the levels than what means are currently available for this.

I would also find this useful for making monsters that have an AI navigation route. Generally I have to place nodes by hand and painstakingly link them by TIDs or have them take off NOBLOCKMAP and do a trace to any that can be seen in order to record them.

[dpJudas]

In my opinion it would be better to triangulate the sectors in ZScript (using earclip or constrained delaunay triangulation) specifically for the purpose.

The quality of BSP subsectors is affected by many things since they have to subdivide the entire map (with the painters algorithm for the software render), which can create local areas with an unexpected high count of subsectors. Those areas could make the navigation mesh behave buggy in the worst case scenario (the route of that the bots would follow could be very unintuitive). A recompile of the map, or GZDoom rebuilding the nodes with a new node builder, would alter how the game behaves. In short: while it is tempting to use this shortcut, it is not a good idea.

[Graf Zahl]

In my opinion it would be better to triangulate the sectors in ZScript (using earclip or constrained delaunay triangulation) specifically for the purpose.

Triangulating sectors in Doom is a non-trivial matter, because there's no sanity checks for proper construction. How would you try to handle maps with open sectors, either due to mapping bugs or render hacks?

[dpJudas]

Triangulating sectors in Doom is a non-trivial matter, because there's no sanity checks for proper construction. How would you try to handle maps with open sectors, either due to mapping bugs or render hacks?

Personally I would just not support it. Automatic node layout of this sort assumes some level of sanity for the input data anyway - it will never work universally for any imaginable mod out there.

Keep in mind this entire thread is based on the premise that you can build a navigation mesh by placing points in the center of the subsectors and then do line tests to the centers of any touching subsector to see which paths are valid. That entire strategy only go so far. Also, as far as I know UDB uses an earclip triangulator for its sectors, so any map built in that thing would probably work just fine for this.

[Graf Zahl]

Some of the IWAD maps would be affected, there's several with broken sectors in there.

[JPL]

I kinda wish there were a highly portable (plain C?) library for triangulating Doom level geo, since I've seen enough people reinvent this over the years, that could be used in both engines and editors/viewers.

[dpJudas]

Some of the IWAD maps would be affected, there's several with broken sectors in there.

I'm not sure what your point is. It isn't trying to render the maps, so if it simply closes any subpath for a broken sector that would probably be good enough.

[Graf Zahl]

I kinda wish there were a highly portable (plain C?) library for triangulating Doom level geo, since I've seen enough people reinvent this over the years, that could be used in both engines and editors/viewers.

As long as all sectors are properly closed, any generic triangulator would do. All the problems here come from those maps which have mapping errors like several of the IWAD maps (id's original editor made it far too easy to create broken stuff), or use open sectors for render hacks. There's no simple way to even construct proper polygons here that could be fed to a triangulator.

[Nash]

If the goal here is to make bots that can navigate the IWAD levels, why not create LevelCompatibility fixes to close off those opened sectors?