After updating to 2018.3, I noticed some Raycasting issues where it seemed that I wasn’t getting hits when I expected to get them. Digging into this, I found the apparent reason: the Raycast in question was setting distance to 1, and not normalizing the direction vector. Until now, the following were equivalent:
I used the first approach in some cases as it seemed more performant, since I didn’t have to normalize the direction and get its distance. Those are both operations I perceived to be expensive. But under 2018.3, when you say distance: 1, it really means 1. Was this an intended change? Maybe it’s something that was fixed in PhysX itself?
I assume this might be related to the following from the release notes:
Physics: Fixed an issue where RaycastCommand would yield a wrong result if input ray direction was not normialized. (1035922)
However, the release notes specifically mention RaycastCommand, not Raycast, so maybe it’s unrelated.
Anyway, maybe the “result1” approach above was always wrong, but I wanted to see if there was some official response to this. My concern is that the need to normalize the direction and pass in a max distance offsets the performance gains I was hoping for under PhysX 3.4.
It doesn’t really matter if you or Unity normalizes the direction vector. I just hope sooner or later Unity will decide if they accept non-normalized vectors as direction or not in all RayCasts uniformly and update the documentation accordingly.
I would be fine with the normalized vector into direction restriction, because normalization should be done and I can do when I see fit rather than every time when I’m calling the RayCast.
Quite possibly it may be a change in PhysX 3.4 itself. The parameters for the PhysX query are the same as for Unity’s Raycast, so most probably they are passed unmodified.
Indeed, the PhysX documentation states that it expects a normalized direction vector: