Self-referencing sectors causing HOM

[Albertoni]

https://dl.dropboxusercontent.com/u/36933307/temp/texture_extravaganza.wad

Basically, in the room to the right, I get many HOMs in prboom, even though I've seen this same setup in other maps.

What am I doing wrong?

[scifista42]

Zennode apparently doesn't like something about these self-referencing sectors - maybe it's that they're non-convex, maybe it's that they contain other sectors within their area, or maybe it's a random quirk. Anyway, I've rebuilt the map's nodes with BSP-W32 and the HOMs went away, except for the HOM on the silver platform which is caused by a simple missing texture (the platform is not self-referencing).

[Albertoni]

Oh, alright. I'll try using other nodebuilders. Thanks a lot!

And to be honest, GZDoom Builder is acting pretty wonky with those sectors as well, more than with the usual self-referencing sector I've done.

[Kappes Buur]

Missing textures usually result in HOM.

[Bauul]

I'm literally having this problem right now - prBoom and Cripsy are chucking out giant HOM errors whereas more advanced source ports like Zandronum and GZDoom render them fine (weirdly it doesn't seem linked to software/hardware rendering).

I didn't think to try different nodebuilders, I'll definitely give that a shot. Thanks!

Alright, BSPw32 didn't fix it, but DeepBSP did the trick. I'm not particularly clued up on the differences between the BSP builders - is DeepBSP a suitable option for a large limit-removing (but otherwise vanilla) Doom 2 map?

[Graf Zahl]

Bauul said:

I'm literally having this problem right now - prBoom and Cripsy are chucking out giant HOM errors whereas more advanced source ports like Zandronum and GZDoom render them fine (weirdly it doesn't seem linked to software/hardware rendering).

That's because the hardware renderer does not use the standard nodes for rendering, it rebuilds GL nodes with an internal version of ZDBSP. And it also contains code to explicitly handle self referencing sectors, the software renderer just processes what it gets and if that doesn't look right, glitches will occur.

[scifista42]

Bauul said:

Alright, BSPw32 didn't fix it, but DeepBSP did the trick. I'm not particularly clued up on the differences between the BSP builders - is DeepBSP a suitable option for a large limit-removing (but otherwise vanilla) Doom 2 map?

DeepBSP generates its own type of nodes that are supported by only several source ports - so, as long as you don't mind that...

Graf Zahl said:

That's because the hardware renderer...

But Bauul said that the issue does NOT seem to be influenced by the type of the renderer - that both hardware and software renderer worked OK in Zandronum and GZDoom. That's how I understood it, at least.

Advanced ZDoom-based ports may decide to rebuild nodes by their own if the nodes in the wad seem flawed or if a specific option is set. So, Zandronum and GZDoom might have rebuilt the nodes regardless of their current rendering mode.

[Bauul]

scifista42 said:

DeepBSP generates its own type of nodes that are supported by only several source ports - so, as long as you don't mind that...

Oh, hmm, thanks. I tried ZDBSP ("ZDBSP - Normal") and tested it in Crispy, PRBoom+, GLBoom+, Zandronum (both software and hardware rendering), ZDoom, GZDoom and Risen3D (although I believe that rebuilds nodes every time anyway) and it appears to be working fine in all of them.

I know ZDBSP is technically built for ZDoom, but realistically are there any limit-removing source ports people use these days that don't support ZDBSP?

But Bauul said that the issue does NOT seem to be influenced by the type of the renderer - that both hardware and software renderer worked OK in Zandronum and GZDoom. That's how I understood it, at least.

Advanced ZDoom-based ports may decide to rebuild nodes by their own if the nodes in the wad seem flawed or if a specific option is set. So, Zandronum and GZDoom might have rebuilt the nodes regardless of their current rendering mode.

Yes that's exactly right. The software renderer in Zandronum and ZDoom rendered it fine, but Crispy and PRBoom+ had HOM errors. It seemed to be a quirk of some of the node builders.

[scifista42]

Bauul said:

I know ZDBSP is technically built for ZDoom, but realistically are there any limit-removing source ports people use these days that don't support ZDBSP?

ZDBSP is capable of building various types of nodes, including vanilla-compatible ones (if you use the "Normal (zero reject)" node builder config in Doom Builder), limit-removing-compatible ones (if you use the "Normal (no reject)" config) and ZDoom extended/compressed nodes (if you use the "Compress nodes" config). ZDoom extended but uncompressed nodes are supported by several non-ZDoom ports too.

[Gez]

There's an overview of the various node format and how much support they've got here.

[Bauul]

Ah, so even though ZDBSP is ZDoom's internal node builder, the "Normal" config doesn't make it incompatible with non-ZDoom based engines?

My map is way too complex for pure vanilla Doom (i.e. Chocolate) - I get visplane overloads within about 20 seconds - so I think ZDBSP Normal (no reject) is the best bet for this map.

Thanks for the help everyone! I was worried I'd have to rebuild map itself to fix the issue, simply changing nodebuilder was much easier!

[scifista42]

Just to avoid misinformation, the only difference between ZDBSP's "no reject" and "zero reject" config is that the former one generates an empty REJECT lump (nothing to do with nodes), which the vanilla engine (as opposed to advanced engines) expects to be non-empty and would crash upon encountering an empty one (and I'm not actually sure which ports accept maps with empty REJECT lumps and which don't - it's not in fact about being "limit-removing" or not). Regarding actual nodes, ZDBSP will process the map with the exact same node-building algorithm and produce the exact same nodes with both configs. So, using the "zero reject" config might be safer anyway (although it bloats file size a bit).

[Bauul]

scifista42 said:

Just to avoid misinformation, the only difference between ZDBSP's "no reject" and "zero reject" config is that the former one generates an empty REJECT lump (nothing to do with nodes), which the vanilla engine (as opposed to advanced engines) expects to be non-empty and would crash upon encountering an empty one (and I'm not actually sure which ports accept maps with empty REJECT lumps and which don't - it's not in fact about being "limit-removing" or not). Regarding actual nodes, ZDBSP will process the map with the exact same node-building algorithm and produce the exact same nodes with both configs. So, using the "zero reject" config might be safer anyway (although it bloats file size a bit).

Thank you! This does certainly clear up a bit of confusion I had. You're right about the file size, it adds an extra 0.5Mb, but going from 9.5Mb to 10Mb isn't the end of the world, so I'll roll with "zero reject". Thanks again!