Intriguing developments

[Enjay]

Perusing the recent development logs I note 2 interesting things.

Graf has opened a "[polyobj branch]" and cleaned up things for some work on polyobjects in Zdoom.

and, in the GZdoom code, Gez has "Implemented rudimentary parser for GLBoom+'s Detail blocks in GLDEFS".

I was just interested to find out if there was any more information about where these were going and what the intentions with them were.

[Graf Zahl]

The polyobject branch was created a few months back but it took me forever to clean out the garbage Raven created. The goal is to implement dynamic splitting like Eternity.

The Detail block parser is just to skip such definitions to prevent error messages. No actual feature implementation is planned.

[Enjay]

Thanks for the reply.

The goal is to implement dynamic splitting like Eternity.

The advantages to this are? I'm guessing an end to bleeding, polyobjects being less temperamental and allowing further/more complex polyobject movement?

[Ceeb]

If so, then squee.

[Mikk-]

May this lead to '3D' and more advanced PolyObject Structures? (Slopes etc)

[Zippy]

The goal is to implement dynamic splitting like Eternity.

The advantages to this are? I'm guessing an end to bleeding, polyobjects being less temperamental andallowing further/more complex polyobject movement?

Basically that.

PolyObjects are the way they are because they're basically just walls. In Doom the nodes are built ahead of time so that when the map is loaded the engine can know the order to render the scenery correctly; so that walls closer to the camera appear over walls behind the camera, etc. That's why PolyObject begin to look funny when you move them out their subsector; you putting things out of the correct order so the engine may not render it right. That's why you'll see things like it rendering the wall behind the PolyObject in front of the PolyObject. Keeping it in a single subsector works because a subsector is the smallest possible unit in the node tree. As long as the PolyObject is inside it then it's guaranteed to be in the right order and will always be rendered correctly.

"Dynamic splitting", just by the name, presumably means that instead of relying on the completely static built nodes (by splitting sectors into subsectors) ahead of time the engine would be able to, in some degree, dynamically split the sectors around the PolyObject during runtime, ensuring the PolyObject is in the right order for rendering every frame and thus giving it more freedom of movement.

Theoretically the same principle would make moving sectors possible, though that would lead into some dabbling with the mysterious, enigmatic physics portion of the engine. The Mountains of Madness, as it were.

[Gez]

It's not the sectors that are dynamically split. It's the segments.

The following is what I've understood of the issue. (I may be completely wrong, but I think that's how it works.)

Sectors are split into subsectors for easier rendering. A linedef that spans several subsectors is split into segment, so that each segment remains in a subsector. This information is created by the node builder and is therefore static. A segment is not supposed to get out of its subsector.

Polyobjects have only one segment per linedef, so if they cross a subsector boundary, the segment becomes partly outside of its subsector. If it moves out of the subsector entirely, the segment is out of the subsector entirely.
This creates glitches when the subsector is rendered and it tries to render a segment that's not there. Or the segment physically is there, but since it's supposed to be in another subsector, you get glitch too.

Well, to solve the rendering issue, you have to have polyobject segments be dynamically split, so that if a polyobj is crossing a subsector boundary (or even a sector boundary), then the linedef is split and resplit in real time into segments that are given to the appropriate subsectors. (That's what Eternity does, which is why Quasar named his polyobject fix "DynaSegs"). Since these segments are going to be created, updated, and destroyed all the time, you cannot rely on segments to define the polyobject, though. Before you could, since one segment == one polyobject linedef, but that is not going to be the case anymore.

[Graf Zahl]

Since these segments are going to be created, updated, and destroyed all the time, you cannot rely on segments to define the polyobject, though. Before you could, since one segment == one polyobject linedef, but that is not going to be the case anymore.

Actually that's not quite true. Polyobject lines could be split by a node build - and that's what was creating a mess here. The code to build polyobjects was hideous because it used the segs from the node build, not the linedefs or sidedefs. Needless to say that such an organization didn't help with implementing this cleanly. And Raven's code was an utter mess. It's still a mess but I'm going to clean this up after it works again.

For dynamic splitting it is much better to use sidedefs as the main data the code operates on.

[Zippy]

It's not the sectors that are dynamically split. It's the segments.

The following is what I've understood of the issue. (I may be completely wrong, but I think that's how it works.)

<<explanation>>

Actually that's not quite true. Polyobject lines could be split by a node build - and that's what was creating a mess here. The code to build polyobjects was hideous because it used the segs from the node build, not the linedefs or sidedefs. Needless to say that such an organization didn't help with implementing this cleanly. And Raven's code was an utter mess. It's still a mess but I'm going to clean this up after it works again.

For dynamic splitting it is much better to use sidedefs as the main data the code operates on.

Ah. Well that'd be because you're starting from the sidedefs to dynamically re-split things down into renderable elements again as it moves, right?

[Salad Viking]

Could this maybe be a step towards polymost rendering a la Build?

[Ceeb]

Doesn't Build operate completely differently than Doom, like constantly refreshing the map which allows for moving structures, wheras Doom is static?

I remember Graf (or maybe Randy) saying that, with the sheer complexity of modern Doom maps, such a method of rendering would require computational power that was astronomical.

Also, @ Salad: Nice, paper mache came face.

[randi]

The main difference between Build and Doom as far as rendering is concerned is that Build sorts the walls on-the-fly, whereas Doom does it beforehand through the BSP tree.

I remember Graf (or maybe Randy) saying that, with the sheer complexity of modern Doom maps, such a method of rendering would require computational power that was astronomical.

That was Graf, and it was in the context of a GL renderer. In the Build-based renderer I had worked on before losing it to Seagate, I had tested Phobos: Anomaly Reborn with it. I hadn't gotten to texturing the walls yet, but I found performance to be reasonable enough. No, it wasn't as fast as the BSP, so that's a tradeoff the map author would have had to make: lots and lots and lots of lines in view at once, or fully dynamic map geometry. But I think saying Build is unsuitable for current Doom maps is a bit overstating the case.

Incidentally, this whole polyobject business was what got me to start the Build branch. Quasar had just announced his dynasegs, and I toyed a bit with doing something similar, but ultimately had the thought to just skip it and go straight to Build wall sorting, since that was an eventual goal anyway.

[Graf Zahl]

The map I tested was Hellcore MAP09 which is something I frequently use as a stress test for the renderer. That map contains a few extremely large sectors and has basically no view blocking geometry whatsoever. Processing those is just way too costly with Build. It has nothing to do with the GL renderer. The time is all lost in the line sorting which Build needs to perform.

I still have the Build based code, of course and in general it's working. However, with the current way ZDoom maps are made it's just a dead end. Most would be too slow.

[randi]

Were you doing line sorting with bunches, too, or just per-wall?

[Graf Zahl]

I pretty much used Build's sorting algorithm for bunches unaltered. It works fine for small and medium sized maps, of course, but some of the more demanding Doom maps just accumulate too much data for an algorithm that constantly has to do distance comparisons with larger sets of lines.