Will Physics.Raycast cause desync in this situation?

:) Hey any 2 cents on this greatly appreciated!

I am worried/curious about this scenario:

I am Raycasting from a V3 towards a collider. Neither the V3 or the collider are moving, at all. The V3 has its position set using fixed point math and is deterministic, so does the collider. There is a wall that is literally just barely on the edge of hitting the raycast, so close that its within floating point precision.

Is there a chance that a Raycast in this scenario on one machine could hit (the wall), and miss (hit the collider) on another machine with different hardware? Any method of ensuring that it would always hit or clear on different machines in this nutty fringe scenario? (Outside of using additional redundant raycasts, such as 2 or 3)?

Thanks very much

The question is basically asking about determinism using a different form. so yes of course, they might give different results if it's within the realm of differences in floating-point handling of the hardware on the devices in question, assuming they are different devices. But so would the same thing if you were talking about some calculation in a script, it's not a physics thing.

The workaround, just like when you don't compare floats directly is to give it a margin of error so back-off it a little so minor float differences won't be a factor. Of course, it might not be minor because of other accumulated differences due to non-determinism from float handling.

I can see your mentioning of fixed-point but in the end, you're setting the Transform and other things which don't use that, nor does the physics engine obviously.


[quote=“MelvMay”, post:2, topic: 868753]
I can see your mentioning of fixed-point but in the end, you’re setting the Transform and other things which don’t use that, nor does the physics engine obviously.

Thanks a lot for weighing in on that. What you don’t realize (because I didn’t give you enough info) is that actually the Transform is purely for the visuals in my simulation, and the actual ‘positions’ of the units are in fact determined entirely by fixed point math (baked into the map with a file), and there is no ‘setting’ the transform to the fixed point. It uses a spatial hash grid, so the Vector3s would be 100% unchanging.

But as you point out, raycasting could clip one collider on one machine and hit on another with obstacles in the way barely within floating point precision as I suspected, even when raycasting from Vector3s that are baked into the map with fixed values and never move. I will have to bake LOS information into the map also seems like, for each possible unit position or ‘cell’ in the grid to each other.

1 Like

I know this is an older post, but it is very important knowledge to share. I just want to say this discussion really helped me. I ended up baking all the line of sight data into my maps as well, though I wish there was some fast deterministic way to do raycasts in real time as this limits my ability to deform maps on the fly. It's not that bad in my case as constraints just make us devs get more creative...