Poly Objects don't move slopes

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

Poly Objects don't move slopes

Postby Sir Robin » Wed Jan 05, 2022 8:09 pm

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
User avatar
Sir Robin
 
Joined: 22 Dec 2021
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: Intel (Modern GZDoom)

Re: Poly Objects don't move slopes

Postby Graf Zahl » Thu Jan 06, 2022 6:18 am

That's because polyobjects are just walls, they have no knowledge of sectors at all.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Poly Objects don't move slopes

Postby Sir Robin » Thu Jan 06, 2022 12:18 pm

Graf Zahl wrote:That's because polyobjects are just walls, they have no knowledge of sectors at all.

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.
Look at the example I included, go "use" those objects and see their walls distort as the objects move.
User avatar
Sir Robin
 
Joined: 22 Dec 2021
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: Intel (Modern GZDoom)

Re: Poly Objects don't move slopes

Postby 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?
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Poly Objects don't move slopes

Postby 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.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Graphics Processor: nVidia with Vulkan support

Re: Poly Objects don't move slopes

Postby 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.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Poly Objects don't move slopes

Postby 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Poly Objects don't move slopes

Postby 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.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Poly Objects don't move slopes

Postby 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?
User avatar
Sir Robin
 
Joined: 22 Dec 2021
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: Intel (Modern GZDoom)

Re: Poly Objects don't move slopes

Postby 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.

8-)
User avatar
Caligari87
User Accounts Assistant
 
Joined: 26 Feb 2004
Discord: Caligari87#3089
Github ID: caligari87

Re: Poly Objects don't move slopes

Postby 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.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Poly Objects don't move slopes

Postby 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.

8-)
User avatar
Caligari87
User Accounts Assistant
 
Joined: 26 Feb 2004
Discord: Caligari87#3089
Github ID: caligari87

Re: Poly Objects don't move slopes

Postby 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Poly Objects don't move slopes

Postby 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?
User avatar
Sir Robin
 
Joined: 22 Dec 2021
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: Intel (Modern GZDoom)

Re: Poly Objects don't move slopes

Postby 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.
User avatar
Logan MTM
I can see you...
 
Joined: 16 Jan 2006
Location: Rio de Janeiro - Brazil

Next

Return to Bugs

Who is online

Users browsing this forum: No registered users and 2 guests