Defining slopes through UDFM sector fields

[boris]

There are multiple ways to set slopes using lines, things, and combinations of both. But there's no way to define a slope by means of UDMF. Therefore I propose to add several new fields to sectors that define the floor and ceiling planes.

Here's how it could look like for floors:

Code: Select all

plane_floor_p1_x			= <float>;	// X coordinate of point 1. No valid default
plane_floor_p1_y			= <float>;	// Y coordinate of point 1. No valid default
plane_floor_p1_z			= <float>;	// Z coordinate of point 1. Default: sector floor height
plane_floor_p1_z_relative	= <bool>;	// true = Z coordinate is relative to sector floor height. Default = false

plane_floor_p2_x			= <float>;	// X coordinate of point 2. No valid default
plane_floor_p2_y			= <float>;	// Y coordinate of point 2. No valid default
plane_floor_p2_z			= <float>;	// Z coordinate of point 2. Default: sector floor height
plane_floor_p2_z_relative	= <bool>;	// true = Z coordinate is relative to sector floor height. Default = false

plane_floor_p3_x			= <float>;	// X coordinate of point 3. No valid default
plane_floor_p3_y			= <float>;	// Y coordinate of point 3. No valid default
plane_floor_p3_z			= <float>;	// Z coordinate of point 3. Default: sector floor height
plane_floor_p3_z_relative	= <bool>;	// true = Z coordinate is relative to sector floor height. Default = false

Should be pretty straightforward.

Pros:

• No crutches like line specials or things needed
• Very flexible; floor and ceilings planes can be completely different from each other without much hassle

[Nightfall]

You can already do this for triangular sectors by defining z height for vertices. See here: https://github.com/rheit/zdoom/blob/mas ... om.txt#L87
Having an universal solution like this for non-triangular sectors could be handy though.

[Graf Zahl]

12 values for each sector is a bit much. It'd make more sense to store the plane equation instead. That's only 4 values per plane, not 12.


@Nightfall: You can do that: for triangular sectors - but not for all others!

[boris]

12 values for each sector is a bit much. It'd make more sense to store the plane equation instead. That's only 4 values per plane, not 12.

You mean a vector and the distance to the plane? Makes sense. Of course that makes it even harder to do by hand, but with the right tools in the editor that should not be a problem.

You can already do this for triangular sectors by defining z height for vertices. See here: https://github.com/rheit/zdoom/blob/mas ... om.txt#L87
Having an universal solution like this for non-triangular sectors could be handy though.

This method is very limited. This feature request originates from this thread: http://forum.zdoom.org/viewtopic.php?f=3&t=45344

[Graf Zahl]

Of course that makes it even harder to do by hand,

Who creates UDMF maps by hand? Depends on how an editor implements the feature to see what is more useful.

[boris]

What I'm doing in my plugin right now is to show a 2D representation of 3 points on the plane:



I'm setting the Z coords of those points, and the points can be dragged around. The distance between the points defines how steep the slope is (the shorter the distance, the steeper the slope). So when I want to make a sloped sector longer, but not change the height difference you just drag the points further apart. Of course, that would not work with a slope just defined by a vector and a distance.

[Gez]

Not "by hand" as in using a text editor to create the map, but by hand as in setting the values for the properties directly in the editor instead of adjusting heights and letting the game compute the equation automatically.

[boris]

Here's another shot with some numbers to clarify what I mean:



Unfortunately I don't see a way right now how this information can be stored without 3 x/y/z coords. At least for the editor for user-friendliness, if not for the engine.

[GooberMan]

They really don't need to be stored. If you have the plane equation, you can derive the points you need for the editor by projecting points along the plane. If you have the points, you can get the plane equation with a cross product and a dot product.

The plane equation is the simplest, most useful method for storing such information.

[boris]

If you have the plane equation, you can derive the points you need for the editor by projecting points along the plane.

Yes, but which 3 points on the plane do you chose to get what the user actually wants?

[GooberMan]

That's up to you to work out. Using your example there, the points are along the X and Y axes from the midpoint of the sector. If you think that's not enough and want to store extended information, then store it as user variables inside the UDMF sector. The engine only needs to care about the plane equation, and since this is a request for an engine addition that's what will most likely be implemented.

EDIT: It's also worth pointing out that if you take the store-extended-information route that you won't need to store the Z for your points - those values can be obtained by projecting the X/Y positions on to the plane using the stored plane equation.

[boris]

From the engine point of view you're absolutely right. Just storing the equation for the engine and custom fields for the editor is fine by me (that's what I'm doing right now anyway).

[Graf Zahl]

Ok, since you are fine with that, I'll add this by using the plane equation.

[Graf Zahl]

added