RaycastCommand gives incorrect results when direction isn't normalized

[cameron_oltmann]

I’m loving the C# job system so far. In the process of doing some investigation toward jobifying AI sensor code, I ran into a bug with RaycastCommand. Incorrect results are returned if the direction of the raycast isn’t normalized. I’ve submitted a bug report with a sample project. Case number is 1035922.

Keep up the great work, guys! I’m loving the direction Unity has been moving lately.

[Baste]

Did you ever get anything back on if this is a bug or not?

I can totally understand it if it’s our responsibility to normalize the input direction, but there’s nothing in the docs about this.

[ShilohGames]

I agree. If this intentional, then the docs should be updated to reflect this behavior. I wasted a lot of time debugging this tonight.

RaycastCommand is currently unreliable if the direction vector is not normalized. This behavior is different from the Physics.Raycast function, which does not require a normalized direction vector. It seemed like RaycastCommand was completely ignoring the max distance value when the direction vector was not normalized.

Here is a link to another thread about this bug (or undocumented behavior):

RaycastCommand maxDistance doesn't work ?

EDIT : Fixed, normalize the direction. Hello, started experimenting with the new Job System (Thanks for this awesome tool btw) and for few hours now i try to fix this bug and i can’t figure out a logical reason for it, the code is simple. I have a NativeArray of RaycastCommand and RaycastHit instantiated each frame with the Allocator.Temp. I fill up the RaycastCommand Array in a job based on the current and the old position of some vector3. This is a quick reproduction = [WriteOnly] NativeAr…

[tertle]

I think forcing a normalized direction vector is a good idea but it should throw an exception when it’s given a vector that isn’t normalized, rather than just returning unexpected or undefined results.

[Scott-Michaud]

@tertle

I think forcing a normalized direction vector is a good idea but it should throw an exception when it’s given a vector that isn’t normalized, rather than just returning unexpected or undefined results.

That would mean that it would have to perform the normalization at run-time to check, which would slow down inputs that are already guaranteed to be normalized. If they are okay with this performance hit, then they should just force normalization on everything. If not, then they should leave it to us to sanitize our inputs and make sure it’s normalized. (They could also give us a parameter to choose but things like that should be done sparingly.)

But, yes, at the very least it should be well documented.

[ShilohGames]

I agree the focus with this command should be only on performance. All I really want is to have the docs improved. I am happy to provide a normalized direction vector, but the docs should tell me that is expected.

The two pages that should immediately be updated:

Unity - Scripting API: RaycastCommand

Unity - Scripting API: RaycastCommand.direction

If Unity updated those two pages and did nothing else, I would be completely satisfied on this topic.

Instead of saying “The direction of the ray”, it should say “The direction of the ray as a Normalized Vector3”.

And in the code example, they need to add a comment. Something like this:
Vector3 direction = Vector3.forward; // direction must be Normalized

[tertle]

@Scott-Michaud

That would mean that it would have to perform the normalization at run-time to check, which would slow down inputs that are already guaranteed to be normalized. If they are okay with this performance hit, then they should just force normalization on everything. If not, then they should leave it to us to sanitize our inputs and make sure it’s normalized. (They could also give us a parameter to choose but things like that should be done sparingly.)

But, yes, at the very least it should be well documented.

This can just be an editor only check though. Basically just how it is atm with an Assert.AreEqual(direction.normalized, direction)

It’ll be stripped at at runtime.

[Necromantic]

To be honest, a “direction” vector is always a unit vector else it’s not really a direction vector but just any vector with a direction and a length.
So if you don’t pass a direction vector into a method that expects a direction vector you can’t expect the outcome to be right. The vector length can have an effect on different mathematical functions or optimizations.

[ShilohGames]

@Necromantic

To be honest, a “direction” vector is always a unit vector else it’s not really a direction vector but just any vector with a direction and a length.
So if you don’t pass a direction vector into a method that expects a direction vector you can’t expect the outcome to be right. The vector length can have an effect on different mathematical functions or optimizations.

The problem with that mindset is that the Physics.Raycast accepted and worked with non-normalized direction vectors. When coders migrate existing Physics.Raycast code to RaycastCommand, they will run into this issue. Improved docs and an editor assert would save people a lot of time on this issue.