Page MenuHome

Another regression between 2.69 and current (related to rayCast)
Closed, ResolvedPublic

Description

System Information
Ubuntu 13.10 / Nvidia Quadro FX 880M

Blender Version
Broken: Blender current (666b54752c2e1bb0fff2a1abbd5a04612355d5de49)
Worked: Blender 2.69 / 2.66

Short description of error

Basically, rayCast fails to hit target in situation where it previously hit them in an repeatable way.

Exact steps for others to reproduce the error

Just launch the associated blend file and press p.

On 2.69 / 2.66, I have reliably

RedBox <Vector (-6.9924, 0.0000, 1.0000)> <Vector (1.0000, -0.0098, 0.0013)>

while on current, I often get

None None None

Sometimes, it looks like it hits something, but normal seems strange in this case

RedBox <Vector (-6.9861, 0.0000, 1.0000)> <Vector (0.7197, -0.2924, 0.6297)>

RedBox <Vector (-6.9861, 0.0000, 1.0000)> <Vector (0.9885, 0.0919, -0.1205)>
...

Thanks in advance.

Event Timeline

Arnaud Degroote (adegroot) raised the priority of this task from to Needs Triage by Developer.
Arnaud Degroote (adegroot) updated the task description. (Show Details)
Angus Hollands (agoose77) claimed this task.

This isn't a bug.
Your box is falling under gravity, and when it hits the floor it bounces slightly, causing it to rotate. This means the hitPosition differs slightly each time.
Closing.

Hum, I trust you, but why does it work properly in 2.69 (or 2.66a) ? All my unit-tests (https://github.com/morse-simulator/morse) using rayCast fails consistently in -current, while they success properly in 2.69.

The cause is self évident, the question is why the cube did not move upon collision in earlier builds. Try repeating your test, ensuring that the cube does fall under gravity and collide with the floor.

I uploaded a new scene which exhibit the issue. The red block is now 'static', so it does not move at all. I added some print of the position of both "robot.sick" and "redbox" to be sure they are the same in both version (2.66 and current).

The output in 2.66 is the following

scanner pos <Vector (-4.5000, 0.0000, 1.0000)> <Euler (x=0.0000, y=0.0000, z=3.1400), order='XYZ'>
box pos <Vector (-7.4973, 0.0000, 0.9600)> <Euler (x=0.0000, y=0.0000, z=0.0000), order='XYZ'>
rayCast hits RedBox <Vector (-6.9973, 0.0000, 1.0000)> <Vector (1.0000, 0.0000, 0.0000)>

while on current

scanner pos <Vector (-4.5000, 0.0000, 1.0000)> <Euler (x=0.0000, y=0.0000, z=3.1400), order='XYZ'>
box pos <Vector (-7.4973, 0.0000, 0.9600)> <Euler (x=0.0000, y=0.0000, z=0.0000), order='XYZ'>
rayCast hits None None None

If you move the box of one millimetre (from -7.4973 to -7.4974), it hits something, but the normal is completely wrong

scanner pos <Vector (-4.5000, 0.0000, 1.0000)> <Euler (x=0.0000, y=0.0000, z=3.1400), order='XYZ'>
box pos <Vector (-7.4974, 0.0000, 0.9600)> <Euler (x=0.0000, y=0.0000, z=0.0000), order='XYZ'>
rayCast hits RedBox <Vector (-6.9974, 0.0000, 1.0000)> <Vector (0.8097, -0.1518, -0.5668)>

Angus, can you check the last scene, check the issue, and at least reopen the bug if you can repeat the issue ? Thanks in advance.

The collision margin is set to 0, which is the reason it doesn't work in trunk.
However, I'm not sure why this has changed between 2.69 release and current git state so this should be reopened.

I had the issue too recently, took me about two hours to figure out that the way to fix it was to set the collision margin from 0 to 0.001.

Clearly, we need to make sure that the collision margin by default is not 0.000 and that one double-checks the code to make sure that it won't be reset to 0 on older files, otherwise we'll have more people asking if ray casting is broken and thus cannot work on their projects anymore.

There was a change in the bullet defaults to the way raycasting works. Now a more accurate (but slower) method is used.
The behaviour has changed, but I'm not sure whether it's wrong now since I'm not a GE user and it would take more time to look into.

To use the other method you can try this patch:

I can confirm that it works, as previously, with your patch sergof. Do you know how much overhead the new method have over the previous one ?

If we want to keep the current raycast setting, we must make it works properly on older scene, as stated by ace_dragon.

I'm not sure about the performance difference, it's probably not too big but will add up when doing many calls.

Since nobody complained about the accuracy before, I'll just apply the patch to stay compatible with old files.

Sergej Reich (sergof) edited this Maniphest Task.Jan 28 2014, 8:31 AM
Sergej Reich (sergof) closed this task as Resolved.Jan 28 2014, 8:31 AM

Closed by commit rB6fe5b3be38af.

Sergej Reich (sergof) edited this Maniphest Task.May 12 2014, 4:38 PM