Don't count decoration sectors in nodebuilder

[CblBOPOTKA]

Is there a way to tell nodebuilder that these certain sectors (segments) are for decoration purpose and are not the part of geometry (they are same floor and ceiling heights)? Say you have few steps of lighting, or nice texturing pattern. It would drastically reduce sectors count and improve playablility on big maps.

[SilverMiner]

I guess the structs of tiny pieces, into which nodebuilder fractures the map, can hold only one flatnum, and due to this, nothing can be done on the nodebuilder's side

[Dark Pulse]

That would literally fly in the face of how BSP works, so no.

 

It doesn't matter to the node builder that it's decoration - it's still a line, its visibility must be tested and accounted for, splits may need to happen because of it, and so on.

 

So basically, you'd need a completely different rendering method to make it work.

Edited October 24, 2023 by Dark Pulse

[CblBOPOTKA]

21 minutes ago, Dark Pulse said:

That would literally fly in the face of how BSP works, so no.

 

It doesn't matter to the node builder that it's decoration - it's still a line, its visibility must be tested and accounted for, splits may need to happen because of it, and so on.

 

So basically, you'd need a completely different rendering method to make it work.

 

Thats why i am asking. Yeah, BSP tests are used for checking collisions, but here we don't expect any. Even rendering should be seamless since all flats are on same level of height. So highly likely it's nice optimization, that with additional work on source port engine and nodebuilder can bring more performance.

[Dark Pulse]

43 minutes ago, CblBOPOTKA said:

Thats why i am asking. Yeah, BSP tests are used for checking collisions, but here we don't expect any. Even rendering should be seamless since all flats are on same level of height. So highly likely it's nice optimization, that with additional work on source port engine and nodebuilder can bring more performance.

The game isn't just using BSP for collision detection. Again, it is literally how it renders things.

 

If you have no BSP tree, you have no idea what lines are in front of what other lines, what does and does not need to be rendered in any given scene, and so on.

 

There's a reason I said what I said, and the simple fact of the matter is that to BSP, it dies not care if it's a line you will never step on or cross, or if it's the same lighting or textures (that matters for Visplanes, not BSP).

 

If it's there, it must deal with rendering it and all the other things related to it. And that will mean the count you want to go down, goes up.

Edited October 24, 2023 by Dark Pulse

[Xyzzу]

5 hours ago, CblBOPOTKA said:

Is there a way to tell nodebuilder that these certain sectors (segments) are for decoration purpose and are not the part of geometry (they are same floor and ceiling heights)? Say you have few steps of lighting, or nice texturing pattern. It would drastically reduce sectors count and improve playablility on big maps.

 

I think this is a thing ZokumBSP can do:
https://doomwiki.org/wiki/ZokumBSP#Geometry_simplification

YMMV depending on the map in question though.

[hobomaster22]

I'm not sure how this would improve rendering speed, even if what you were asking was possible. Rendering using the BSP tree requires that nodes are walked in order and adds blocking segs to the view clipper to determine what can be viewed. It would totally break software rendering. In hardware rendering if these sectors have one sided lines that would be used to block other nodes in the view clipper, then the performance is going to be decimated by walking nodes that would normally be blocked.

It would also require an implementation for rendering statically. At that point you may as well just not use the BSP for rendering at all which is exactly what Helion does.

Also, for clarity it seems like there might be some confusion as what deals with collision detection. Outside of rendering, the BSP tree is also walked to determine what subsector (and inherently the sector) something is in. The blockmap is used to determine what lines (other touching sectors) and things are hit for collision detection.

Edited October 24, 2023 by hobomaster22

[CblBOPOTKA]

19 minutes ago, hobomaster22 said:

I'm not sure how this would improve rendering speed, even if what you were asking was possible.

 

Yeah, i am totally forgot about blockmaps, it is already great optimization on collision test. So effort from initial proposal will not be as significant as i expected. Thanks to all for your answers! Anyway, nodebuilding is quite interesting theme to research.

[LoatharMDPhD]

 

[LoatharMDPhD]

 

[Dark Pulse]

7 hours ago, Χyzzy said:

I think this is a thing ZokumBSP can do:
https://doomwiki.org/wiki/ZokumBSP#Geometry_simplification

YMMV depending on the map in question though.

That's not quite the same thing the OP is asking for. What ZokumBSP does is "merge" linedefs in a sense that if one starts where the other ends, they have the exact same orientation, and many similar properties, it will tell the BSP tree that they are basically one line even though they are not for blockmap purposes, which is about reducing the blockmap. OP is looking to reduce the actual Sectors, which wouldn't be affected by a trick like this at all.

 

Also, most Doom maps rarely have this sort of thing. If one's at, say, a 90 degree angle, and the other is at a 75 degree angle, it will not do this trick. It's also potentially going to cause problems if the BSP is ever rebuilt but does not use ZokumBSP, since basically, the "new" line is done in the Blockmap for collision, and the original lines are marked only for rendering.

 

TL;DR: That's a niche trick to reduce the blockmap by a handful of bytes every time it can be applied, but it won't do jack for rendering speed, which is more what the OP is after.