Godot: RayShape collision on KinematicBody stopped workin in 3.1 beta 2

[MrCrowley2]

Godot version:
Godot_v3.1-beta2_x11.64

Issue description:
I have a KinematicBody 3D with a box and a ray collision shape.
It works perfect in 3.1 beta 1, but the same project in beta 2 ignores the RayShape.

Steps to reproduce:
Use a RayShape collision on a kinematic body. It is ignored. Change to box shape. It works.

Minimal reproduction project:
I attached a sample project.
In Beta 2:

• The red sphere has a box collision shape and stops on the static body floor
• the green sphere has a RayShape and falls through the floor.

in beta 1: the project is working.

RayShapeBug.zip

[groud]

Likely related to #25181. Might be fixed on master.

[reduz]

please try again

[reduz]

also if you re-saved a tilemap with a build from yesterday, you may need to untoggle all the one way collision flags on it manually

[groud]

please try again

I guess @reduz means here that you should try use to use the lastest master version, if you can build the engine yourself.

[Sslaxx]

25181 is fixed as of 4333a68.

[MrCrowley2]

I just build 4333a68 and the problem remains with the sample project I provided

[groud]

Likely related to #25181. Might be fixed on master.

Ah my bad, I misread, the problem is for 3D, not 2D.

[akien-mga]

That's interesting, I don't really see any commit between beta1 and beta2 that could have impacted this. I guess a bisect will be necessary. I can confirm the regression in beta2.

Should be bisected between f7de2c0cb (beta1, good) and 1efd37f1b (beta2, bad).

[akien-mga]

Well that was a boring bisect, first bad commit seems to be the first one after beta1:

$ git bisect log
git bisect start
# good: [f7de2c0cb3793bd289b8465bcc9af54157a54e91] Merge pull request #24830 from hpvb/fix-24752v2
git bisect good f7de2c0cb3793bd289b8465bcc9af54157a54e91
# bad: [1efd37f1b77d71c652fe28a50f42c5284d5ef4ec] Fix uninitialized memory error.
git bisect bad 1efd37f1b77d71c652fe28a50f42c5284d5ef4ec
# bad: [b3dc02b5df3ba645ff57d2e18a4417304721a0bb] Was not properly re-setting light uniforms, fixes #24976
git bisect bad b3dc02b5df3ba645ff57d2e18a4417304721a0bb
# bad: [bcd05c0d91da2651b08b9ed58859fffc9e96f527] Merge pull request #24886 from akien-mga/animatedtexture-frame-properties
git bisect bad bcd05c0d91da2651b08b9ed58859fffc9e96f527
# bad: [99757591c4917bc78ee19af5124baf644695cc78] Merge pull request #24863 from akien-mga/travis-osx-scons-pip
git bisect bad 99757591c4917bc78ee19af5124baf644695cc78
# bad: [e8f73d8c4c8482e01ece3d38571d53bb6f351406] Merge pull request #24842 from volzhs/fix-node-name-serial
git bisect bad e8f73d8c4c8482e01ece3d38571d53bb6f351406
# bad: [d8c40bccbbbf74001cbd085da5f71180e054e17f] Merge pull request #24831 from clayjohn/fix_nested_docs_tooltip
git bisect bad d8c40bccbbbf74001cbd085da5f71180e054e17f
# bad: [d23bce3ef2e8aabfa8bc81cd6995c731d4eb5560] Merge pull request #24828 from Calamander/patch-1
git bisect bad d23bce3ef2e8aabfa8bc81cd6995c731d4eb5560
# bad: [64e584a97e0505cec592d3c98a2899ba8426f35a] Update random_pcg.h
git bisect bad 64e584a97e0505cec592d3c98a2899ba8426f35a
# first bad commit: [64e584a97e0505cec592d3c98a2899ba8426f35a] Update random_pcg.h

I'll try a local revert to confirm that 64e584a97e0505cec592d3c98a2899ba8426f35a caused it, maybe collision logic used randd or randf and worked only due to it being swapped.

[akien-mga]

No, false positive. I suspect that rebuilding beta1 locally would also trigger the bug, it's probably related to differences in the build flags/build environment used for both. I'll investigate further.

[akien-mga]

I've built the beta1 commit f7de2c0c locally (tools=yes target=debug) and I can reproduce the bug there, even though it's not in the official beta1 build.
I also built alpha5 (b60939be8) to make sure that it's not a regression that happened just around the beta1 commit and was somehow not included in beta1. Same bug.

So the issue seems to be with the official buildsystem, and something that changed between beta1 and beta2 that made it expose the pre-existing issue.

CC @hpvb

To summarize:

• Official beta 1 works fine
• Official beta 2 and beta 3 don't work
• Alpha 5 and beta 1 commit self-compiled with target=debug don't work

So we need to look into official build options used for beta 1 and beta 2 respectively.

Could be LTO, or a change for target=release_debug. At any rate the bug should be fixed for target=debug and no-LTO too, but it would be useful to know why it didn't happen in official builds until beta 2.

[akien-mga]

The only change that impacted official builds is e5b335d367103f4052fc5fd435a54ad635ec447c, where we disabled the unsafe -ffast-math optimization which usually triggers this kind of bugs. Somehow it might have been hiding this bug.

If you test the example project with the Linux debug template from before beta2, the bug should appear too.
Edit: Wrong, "debug" templates are actually tools=no target=release_debug, so they also used to be compiled with -ffast-math.

[akien-mga]

It's not reproducible in debug builds with the GodotPhysics backend, so it's Bullet-specific.

To clarify the above debugging: the bug happens when building without -ffast-math, which was previously hiding the issue on release and release_debug builds (but it was still failing in debug builds).

An option could be to enable -ffast-math only for this code branch, but that's quite hacky and it would be hard to know if it will behave properly on all compilers, as -ffast-math is unsafe and unstable by nature.

[MrCrowley2]

doesn't sound like a good solution to me. Prone to break in the future if the compiler changes and just masks the bug. And when it breaks it's an even bigger headache to remember.

can't you set a breakpoint in the function that calls area_exit and see where the call is coming from when the object stops inside the area? Possibly find out why bullet calls the function in the first place rather than mask the bug with a random compiler optimisation ;)

[aqnuep]

Just in case this helps, the issue is also present on Win/VC builds (both debug and release_debug).

EDIT: That also means that the regression is actually unrelated to e5b335d367103f4052fc5fd435a54ad635ec447c and thus the -ffast-math option. I've verified it locally by reverting the change, but it's no surprise, considering that the option is not available on Win/VC builds. Thus the offending change is yet to be found.

[aqnuep]

I did some further testing and even if I went back to year old versions I still couldn't get @MrCrowley2's repro case working on Windows with Bullet. I even tried out the beta1 builds and still doesn't work which make me think that RayShape under Bullet never actually worked on Windows (at least with MSVC).

[MrCrowley2]

My machine is a Unix system with Kubuntu 18.04

[aqnuep]

Okay, so I managed to track down the offending change.

I found that fc50728d451e438db245d92698115cfc9c3720cf (pull request #21808) broke RayShape (not sure how on Linux it worked even in 3.1 beta 1), so it has been broken for exactly 5 months now.

[aqnuep]

I managed to find a proper fix in the end (see PR #25788).

[MrCrowley2]

yay! Good work!