ZDoom

by **Sir Robin** » Tue Jan 11, 2022 9:10 pm

Rachael wrote:
Sir Robin wrote:So is this a bug that can be fixed in the zdoom code? Or can it be scripted around? Does zcsript have access to the polyobj vertices and normals? Maybe i could just write my own polyobj movement routines to get around this bug?
Unfortunately calling this a bug is a bit of a misnomer. The behavior is correct as coded, even if the end result is not what the user expects. The real issue here is a missing feature that would have allowed to keep the planar information in sync with the polyobject's movement.

Yes, this is what I've been saying since the beginning. The slope normals are not getting updated while the polyobject is moved. And you're now saying this is an intended behavior. So the answers my first question. My second question was whether the slope normals are exposed to zscript - would it be possible for me to write my own polyobj movement script that would update those slope normals?

by **Caligari87** » Mon Jan 10, 2022 9:31 am

Graf Zahl wrote:Polyobjects are just walls. Nothing implies they are infinitely tall.

My bad. I guess it'd be more accurate to say that they typically behave as though they're infinite because in normal use they fill floor-to-ceiling in whatever sector they occupy. But obviously as this thread indicates, there's exceptions.

For what it's worth I would adore canonical 3D polyobjects, even if they can't be sloped. The workarounds I've seen over the years to support equivalent functionality are kinda yikes.

by **Rachael** » Sun Jan 09, 2022 11:15 pm

Sir Robin wrote:So is this a bug that can be fixed in the zdoom code? Or can it be scripted around? Does zcsript have access to the polyobj vertices and normals? Maybe i could just write my own polyobj movement routines to get around this bug?

Unfortunately calling this a bug is a bit of a misnomer. The behavior is correct as coded, even if the end result is not what the user expects. The real issue here is a missing feature that would have allowed to keep the planar information in sync with the polyobject's movement.

by **Logan MTM** » Sun Jan 09, 2022 10:47 pm

I'm a layman in the PolyObj subject at code level but, who knows (maybe) a model combined with ActorMover should solve your need and even make things easier for everyone: For You, Graf, DevTeam, etc.

by **Sir Robin** » Sun Jan 09, 2022 9:45 pm

So is this a bug that can be fixed in the zdoom code? Or can it be scripted around? Does zcsript have access to the polyobj vertices and normals? Maybe i could just write my own polyobj movement routines to get around this bug?

by **Graf Zahl** » Sat Jan 08, 2022 5:47 pm

Polyobjects are just walls. Nothing implies they are infinitely tall. So if you got a back sector with a defined shape it can be rendered. But the polyobject won't be aware of that as it is just walls. And even if 3D polyobjects were implemented they wouldn't be supporting slopes anyway because that'd open up a really dirty can of worms I wouldn't want to bother with ever.

by **Caligari87** » Sat Jan 08, 2022 4:11 pm

As noted with the 3D floors bit I mentioned, I'm certain there's some undefined edge cases where something "works" by happenstance even though it's not intended to. I haven't looked at the map yet to see how it's constructed, but realistically this is probably the kind of situation where either a bug needs fixed or a new feature needs to be codified, and I think it's going to lean toward the first option before people start using it.

by **Enjay** » Sat Jan 08, 2022 2:28 pm

Caligari87 wrote:Polyobects (at least in GZDoom) are infinitely tall walls, no matter the height of their control sector.

That's why I was surprised that Sir Robin was able to get any kind of sloped appearance from a polyobject at all.

by **Caligari87** » Sat Jan 08, 2022 11:53 am

Your understanding is off, unfortunately. Polyobects (at least in GZDoom) are infinitely tall walls, no matter the height of their control sector. It's possible to fake polyobject height in GZDoom by using 2-sided (walkthrough) lines with collidable textures for the polyobject, but it's not quite the same as a true 3D floor (which conversely is an infinite plane with no walls, the shape only being bound by the target sector).

I seem to remember someone experimenting with a novel exploit where a 3D floor is targeted to a polyobject control sector or vice-versa, but it's almost most certainly undefined behavior liable to break at any time.

by **Sir Robin** » Sat Jan 08, 2022 8:41 am

Graf Zahl wrote:The big part of the problem is that polyobjects are just walls, not sectors. They have no logic included that can move sectors at all.
In the Build engine it is a lot easier because it has sector-aligned flats and slopes auto-align to the sector's orientation - the downside is that the math for both is rather shit.

Your title says "Lead GZDoom+Raze Developer" so I don't doubt you know the code much better than I possibly could. The way I understand it is that polyobject are just walls, but they did originally have a sector telling them how high to make those walls. Even if the polyobject is no longer aware of that sector, it retains the height information to draw it's walls. And if that sector was sloped, the polyobject obviously maintains the surface normal for that slope to determine how high to draw the walls. So that surface normal has got to be stored somewhere, right? I imagine that your polyobject moving/rotating routine is already updating the vertex positions and line normals, it just neglects to update the slope normals. That's why I see this weird effect when moving a sloped polyobject. So I guess the question is how hard would it be to add code to update those stored normals? Or is my understanding way off?

by **Gez** » Fri Jan 07, 2022 8:37 am

k8vavoom does allow 3D polyobjects, specs are here. That may be an avenue worth looking into, too.

by **Graf Zahl** » Fri Jan 07, 2022 7:58 am

The big part of the problem is that polyobjects are just walls, not sectors. They have no logic included that can move sectors at all.
In the Build engine it is a lot easier because it has sector-aligned flats and slopes auto-align to the sector's orientation - the downside is that the math for both is rather shit.

by **Gez** » Fri Jan 07, 2022 7:49 am

However, the downside of using polyportals is that it will also affect the floor and ceiling, which can be distracting.

A big part of the problem is that the engine does not support dynamically changing a slope (other than up and down but without changing the angle). For what Sir Robin wants to make, the best is to have a model for the visual, and a regular (non-sloped) polyobject for the collision.

by **Rachael** » Thu Jan 06, 2022 12:50 pm

Another option would be to stick the slopes behind portal lines. This has the advantage that no matter how the polyobject moves, the flat and slope alignments will never change, since flats are aligned to the planar level grid, but moving portal polyobjects would give the illusion of that moving.

by **Enjay** » Thu Jan 06, 2022 12:30 pm

Interesting. I'm actually surprised that they even show the slopes that they do (I would have expected the slope not to have appeared at all unless the play sector was sloped and thereby determining where the texture was cut off..

However, that being said - given that they do appear - the way that they "work" is entirely consistent with how other slopes created via control sectors do (.e.g 3D floors created using a sloped control sector). i.e. what you see in the play area is aligned and extrapolated from the slope and position of the control sector.

i.e. although I hadn't even expected them to show as slopes, the way that the sloped polys behave is how I would expect them to. I'm not saying that it's what you want, or that it is likely to be particularly useful, but it is what I would expect.

I'd be surprised if this is going to change (though, it is not my call at all) so, for your project, would using models as your doors be an option?

ZDoom

Poly Objects don't move slopes

Post a reply

Expand view Topic review: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes

Re: Poly Objects don't move slopes