Poly Objects don't move slopes
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- Sir Robin
- Posts: 537
- Joined: Wed Dec 22, 2021 7:02 pm
- Graphics Processor: Intel (Modern GZDoom)
- Location: Medellin, Colombia
Poly Objects don't move slopes
When a Poly Object defined with slopes in ceilings or floors moves or rotates, the normals for the slopes are not moved or rotated along with them. This includes the initial move from the anchor point to the start point.
demo wad
demo wad
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Poly Objects don't move slopes
That's because polyobjects are just walls, they have no knowledge of sectors at all.
- Sir Robin
- Posts: 537
- Joined: Wed Dec 22, 2021 7:02 pm
- Graphics Processor: Intel (Modern GZDoom)
- Location: Medellin, Colombia
Re: Poly Objects don't move slopes
Right, but the wall heights are set based on the slope of the sector they were created with. So the polyobject must be storing those slope normals somewhere. What I'm saying is that those slope normals are not being updated as the poly object moves or rotates.Graf Zahl wrote:That's because polyobjects are just walls, they have no knowledge of sectors at all.
Look at the example I included, go "use" those objects and see their walls distort as the objects move.
Re: Poly Objects don't move slopes
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?
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?
Re: Poly Objects don't move slopes
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.
Re: Poly Objects don't move slopes
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.
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Poly Objects don't move slopes
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.
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.
Re: Poly Objects don't move slopes
k8vavoom does allow 3D polyobjects, specs are here. That may be an avenue worth looking into, too.
- Sir Robin
- Posts: 537
- Joined: Wed Dec 22, 2021 7:02 pm
- Graphics Processor: Intel (Modern GZDoom)
- Location: Medellin, Colombia
Re: Poly Objects don't move slopes
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?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.
- Caligari87
- Admin
- Posts: 6174
- Joined: Thu Feb 26, 2004 3:02 pm
- Preferred Pronouns: He/Him
- Contact:
Re: Poly Objects don't move slopes
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.
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.
Re: Poly Objects don't move slopes
That's why I was surprised that Sir Robin was able to get any kind of sloped appearance from a polyobject at all.Caligari87 wrote:Polyobects (at least in GZDoom) are infinitely tall walls, no matter the height of their control sector.
- Caligari87
- Admin
- Posts: 6174
- Joined: Thu Feb 26, 2004 3:02 pm
- Preferred Pronouns: He/Him
- Contact:
Re: Poly Objects don't move slopes
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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Poly Objects don't move slopes
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.
- Sir Robin
- Posts: 537
- Joined: Wed Dec 22, 2021 7:02 pm
- Graphics Processor: Intel (Modern GZDoom)
- Location: Medellin, Colombia
Re: Poly Objects don't move slopes
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?
Re: Poly Objects don't move slopes
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.