Godot: There is no way to set one-way collision directions

[leoddd]

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Windows 10 (x64), Godot 3 Alpha 2

Issue description:
In Godot 2.x, one-way collision was exposed in the form of a direction vector and a number for the maximum depth inside the body, which was great and fully customizable.
In Godot 3, all that is replaced with a boolean checkbox. Enabling it will make the shape only collide from the top, with no way to change this, at least none are exposed in the editor or outlined in any documentation for code. It always points up.

When the body rotates then this direction changes with the rotation just fine, meaning it can handle rotating the direction it's solid from.
Is there a reason the directional setting was removed?

As an aside, the documentation for CollisionShape2D's one_way_collision member states that you can somehow choose top or bottom, but it is always only solid from the top.
Which, by the way, is strange because the giant arrow that is drawn in the editor window always points down.

Steps to reproduce:
1) Create any CollisionShape2D, CollisionPolygon2D or TileSet tile with One Way Collision enabled.
2) Struggle to find a way to change the direction it is solid from.

[reduz]

It's currently the way it is for simplicity, you can rotate the shape
though, as this option is now per shape.

On Thu, Nov 9, 2017 at 8:33 PM, Tim Schellenberg [e-mail]
wrote:

Operating system or device, Godot version, GPU Model and driver (if
graphics related):
Windows 10 (x64), Godot 3 Alpha 2

Issue description:
In Godot 2.x, one-way collision was exposed in the form of a direction
vector and a number for the maximum depth inside the body, which was great
and fully customizable.
In Godot 3, all that is replaced with a boolean checkbox. Enabling it will
make the shape only collide from the top, with no way to change this, at
least none are exposed in the editor or outlined in any documentation for
code. It always points up.

When the body rotates then this direction changes with the rotation just
fine, meaning it can handle rotating the direction it's solid from.
Is there a reason the directional setting was removed?

As an aside, the documentation for CollisionShape2D's one_way_collision
http://docs.godotengine.org/en/latest/classes/class_collisionshape2d.html?highlight=collisionshape2d#member-variables
member states that you can somehow choose top or bottom, but it is always
only solid from the top.
Which, by the way, is strange because the giant arrow that is drawn in the
editor window always points down.

Steps to reproduce:

1. Create any CollisionShape2D, CollisionPolygon2D or TileSet tile
   with One Way Collision enabled.
2. Struggle to find a way to change the direction it is solid from.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12791, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z29S0EPoQjFUs4NG9XrAorwv8luNCks5s04vcgaJpZM4QY10P
.

[leoddd]

Would performance take a hit from re-adding a way to set the direction for each shape?

I'd mostly prefer not to have to rotate everything because when I programmatically create polygons, having to rotate the location of every vertex each time just to counteract the rotation I'll have to give the shape to set the one-way direction is time consuming. And having to misalign the collision objects in Tiled on purpose to account for the rotation that will be applied, unless I want to actually rewrite the importer for this, isn't ideal either.

Which I think is a bit of a heavy expectation for something that used to be possible pretty easily? I suppose it depends on how heavy on the processing implementing this would be, but given that one-way directions are generally not even enabled on the majority of shapes I can't imagine this being a terrible processing sink.
But that's coming from someone with very little clue of how this is actually implemented, if there's solid reasons that speak against this then I'll have to accept that.

[reduz]

I was thinking of adding a one way collision rotation to Shape, this may be
a bit better and easier than the previous system.
Still, there are many more priorities over doing this. If you want to give
it a try I can point you to the right places in the source code.

On Thu, Nov 9, 2017 at 11:18 PM, Tim Schellenberg [e-mail]
wrote:

Would performance take a hit from re-adding a way to set the direction for
each shape?

I'd mostly prefer not to have to rotate everything because when I
programmatically create polygons, having to rotate the location of every
vertex each time just to counteract the rotation I'll have to give the
shape to set the one-way direction, as well as having to misalign the
collision objects in Tiled on purpose to account for the rotation that will
be applied, unless I want to actually rewrite the importer for this.

Which I think is a bit of a heavy expectation for something that used to
be possible pretty easily? I suppose it depends on how heavy on the
processing implementing this would be, but given that one-way directions
are generally not even enabled on the majority of shapes I can't imagine
this being a terrible processing sink.
But that's coming from someone with very little clue of how this is
actually implemented, if there's solid reasons that speak against this then
I'll have to accept that.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/12791#issuecomment-343355056,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z291ahG_m5mrjt9ATKR5-rC9swk88ks5s07J1gaJpZM4QY10P
.

[leoddd]

I can give it a try, sure. Can't promise I'll have results because I've never looked deeper than a method or two into the source and am not terribly well versed in the language, but I understand that there's more important things with the release of 3.0 approaching (missing features, bugs, what have you).

If anyone else thinks they can handle it then don't let me trying to look into it deter you though!

[eon-s]

Rotating and/or having more than one (rotated) shape and disabling now should work, I liked the old way though, it was easy to modify on the script side.

[fossegutten]

rotating a tile with one way collision in tilemap does not rotate the one way collision in 3.0.2. Would be nice to have the option of choosing direction, maybe even multiple directions? E.g. collision in vertical movement, but no collision in horizontal movement

[eon-s]

@fossegutten there is already an issue opened about tilemaps and 1 side (which has many problems), multiple directions can be achieved with multiple shapes, won't work on tilemap, though.

[henriiquecampos]

Hey guys, I'm testing the rotation for the shape to set the one_way_collision direction and even tho I'm rotating the CollisionShape / CollisionPolygon the one_way_collision is always Vector2(0, -1)

[akien-mga]

It's currently the way it is for simplicity, you can rotate the shape though, as this option is now per shape.

@reduz It doesn't seem to work though, as #18493 and #20204 confirm that one-way collision shapes don't work properly when rotated.