ZDoom

by **edward850** » Sun Jan 04, 2015 4:59 pm

That wouldn't surprise me. Remember that polys were only attached to their subsector back then, and couldn't leave without causing rendering issues.

by **Enjay** » Sun Jan 04, 2015 1:57 pm

Graf Zahl wrote:Sorry, Enjay, but this would cause far too many problems with existing mods that take the current behavior for granted. A polyobject's light values are always that of the bounding subsector, not its neighbor.

No problem. Thanks for the answer. I guess, more than the inconsistency, I was worried that this too might be considered undefined. However, your post is a clear enough statement of what the rules for this kind of construct are are so that's fine. I know that I can certainly work with that. FWiW, I checked right back to ZDoom 1.22 and the poly doors were lit just like they are with the current version.

by **Graf Zahl** » Sun Jan 04, 2015 11:50 am

Sorry, Enjay, but this would cause far too many problems with existing mods that take the current behavior for granted. A polyobject's light values are always that of the bounding subsector, not its neighbor.

by **Enjay** » Sun Jan 04, 2015 6:00 am

Gez wrote:Instead of moving the polyobject by 128 units so it's just on the boundary, move it by 127 or 129 units so it's clearly on one side.

The lighting thing isn't about the movement though.

If you mean placing the poly, or changing its size, so that it is no longer gets placed on the boundary between two sectors, sure, that could be done and would be the most obvious mapping fix (although it may not always be desirable to do that). However, my point is that a normal 1 sided or 2 sided line that was right on the edge of a coloured sector would have the side facing the sector coloured by the sector lighting but this doesn't happen with the polyobject. So it's inconsistent. If the engine can't be adjusted to light the poly in the same way that a normal line in that position would be, then so be it. Mapping work arounds are required. But if the engine can be adjusted to handle it, it makes sense (to me) for it to happen.

by **Gez** » Sun Jan 04, 2015 5:31 am

Enjay wrote:Although the reasons are the same as the texture issue, I wonder if this particular manifestation needs consideration and a way of making it defined? The reason I ask is because, unlike putting two lines on top of each other, having a door separating two areas, one of which is coloured, is not an unusual or incorrect mapping situation. Expecting each side of the door (or any line with a texture on it for that matter) to respect the lighting of the sector they are facing, is the usual and expected result for normal architecture.

Instead of moving the polyobject by 128 units so it's just on the boundary, move it by 127 or 129 units so it's clearly on one side.

You're welcome.

by **edward850** » Sun Jan 04, 2015 4:56 am

Only with its actual renderer (due to the optimizations). The game logic is pretty hard to break if you know what you're doing, and the Dynamic BSP is all Randi, I believe (don't quote me on that one though). However, the issue here is with 15 years of ZDoom code, at what point do you start breaking existing maps with even the slightest change to the BSP.
It's definitely not code I would want to risk getting entangled with for that exact reason.

Now if you want an engine balancing on a pencil, Duke3D tends to be the go to example.

by **Enjay** » Sun Jan 04, 2015 4:48 am

edward850 wrote:At which point I wonder if anybody would be brave enough to try and change such behaviour.

I've heard the Doom engine and how it "works" being described as a pencil balancing on its point where the slightest change unbalances everything. It wouldn't surprise me if this was one of the areas that might destabilise the pencil if someone started poking around with it.

by **edward850** » Sun Jan 04, 2015 4:40 am

A shot in the dark, I wonder if what's happening is a seg is only compiling itself to one sector, and won't pick up rendering properties on both sides because it can only see one sector at a time? It would certainly make sense to change if it could be.
At which point I wonder if anybody would be brave enough to try and change such behaviour.

by **Enjay** » Sun Jan 04, 2015 4:34 am

edward850 wrote:... I thought the youtube video explained the whole situation, Enjay.

Yes, yes it does, very nicely.

I actually tried the containing sector lighting thing before I made my post about the lighting issue (the original one that has the pictures in it). I was just replying to Ichor's post saying that I had thought the effect might be due to the reason he suggested, I'd already tried it and it wasn't and I mentioned that you'd since said it wasn't due to that either.

Although the reasons are the same as the texture issue, I wonder if this particular manifestation needs consideration and a way of making it defined? The reason I ask is because, unlike putting two lines on top of each other, having a door separating two areas, one of which is coloured, is not an unusual or incorrect mapping situation. Expecting each side of the door (or any line with a texture on it for that matter) to respect the lighting of the sector they are facing, is the usual and expected result for normal architecture. I know that polyobjects are unusual so I don't know if this can be done but, if it can, it would make them more consistent with other, more traditional, constructs.

[edited slightly for clarity]

by **edward850** » Sun Jan 04, 2015 4:20 am

... I thought the youtube video explained the whole situation, Enjay.

by **Enjay** » Sun Jan 04, 2015 4:17 am

Ichor wrote:That's because the actual polyobject doors are in a different sector off on its own before it gets moved to this spot. Try coloring the sector where the polyobject anchors are.

That was my initial thought but I tried it and it didn't work (as edward said it wouldn't). Even if it had worked, then the other side of the door, the one facing the uncoloured sector, would presumably have been coloured and that would be just as bad.

by **edward850** » Sat Jan 03, 2015 10:28 pm

Actually, the problem is exactly the same as before: Undefined orders. It's right on the line between two planes, so either sector is correct.

by **Ichor** » Sat Jan 03, 2015 9:54 pm

That's because the actual polyobject doors are in a different sector off on its own before it gets moved to this spot. Try coloring the sector where the polyobject anchors are.

by **Enjay** » Sat Jan 03, 2015 2:49 pm

There is one final question that I have which is raised by this map; the poly door fronts run along the line bordering the sector with the coloured light but the doors themselves are not affected by the light colour. If these were regular doors, they would be coloured by the lighting. Should poly doors behave the same way? I don't even know if its possible, but I thought it was worth asking.

Poly Door

Regular Door

by **Kappes Buur** » Sat Jan 03, 2015 1:44 pm

Edward-san wrote:..... Still, why's it there?

Because the tutorial had been made many, many moons before the polyobject behaviour broke.
ZDoom at the time was in it's infancy, long before GZDoom came along.

Perhaps somebody could change the test pwad in the tutorial, or place a link to this thread for clarification.
I would do it ordinarily, but I cannot log into the WIKI to edit a page.

ZDoom

[????-g869864]Polyobj door merging with adjacent sector line

Post a reply

Expand view Topic review: [????-g869864]Polyobj door merging with adjacent sector line

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector

Re: [????-g869864]Polyobj door merging with adjacent sector