Corgi Async Raycasts - Move your raycasts off of the main thread! [Released!]

[funkyCoty]

Corgi Async Raycasts allow you to easily leverage Unity’s built in Jobified raycasts system. It provides an extremely simple to use API for moving your raycasts off of the main thread.

~Documentation~
~Asset Store~
~Discord~

Features:

• Simple to setup and easy to use. Drop in a prefab and the API is ready to use!
• VERY fast and provides an alternative API which is a bit slower but even easier to use.
• Works on all platforms Unity supports!
• Includes a simple demo scene to explain the API!
• Includes full source code!

[funkyCoty]

It’s finally live!

[funkyCoty]

First update is live.

1.0.1:

• Fixed incompatibility with Unity 2021. Should work fine on both 2021 and 2022 now.
• demo scene now shows how to do async callbacks
• there’s now validation for querying async raycasts from a different update loop
• improvement to async callbacks

[iddqd]

Hey @funkyCoty

Once again a great asset!

Do you have any idea why I’m not seeing a difference in performance?
I’m using 50000 cubes and am getting around 5-7fps with all three methods.

I added:

private void OnRaycastHit(RaycastHit hitInfo)
{
            return;
...

in DemoCubeRaycastGround.cs - so the cube doesn’t actually move and I also remove the Rotation of the whole Circle.

It would be interesting to have a pure benchmark Scene to see the actual performance difference.

Thanks

[funkyCoty]

@iddqd

Hey @funkyCoty

Once again a great asset!

Do you have any idea why I’m not seeing a difference in performance?
I’m using 50000 cubes and am getting around 5-7fps with all three methods.

I added:

private void OnRaycastHit(RaycastHit hitInfo)
{
            return;
...

in DemoCubeRaycastGround.cs - so the cube doesn’t actually move and I also remove the Rotation of the whole Circle.

It would be interesting to have a pure benchmark Scene to see the actual performance difference.

Thanks

Can you post profiler results? getting 5 fps with 50,000 cubes… you might just be bottlenecked by cube rendering lol. Also, as the documentation suggests you should avoid that API in particular, use the one that gives tickets and it’ll be faster overall

[funkyCoty]

small update just pushed

1.0.3:

• Fixed minor issue with update loop

[vapgames]

It’s neat but I’m not getting performance increase (at least in editor).
Seems like overhead for scheduling gives worse performance.
10000 raycasts
default unity ~55ms main thread 17fps
raycast tickets ~65ms main thread 15fps
async callbacks ~80ms main thread 12fps

Nonetheless, I wanted to try jobified raycasts, and this is a good performance test.

[funkyCoty]

Would you mind repeating your test in a build? I’ve been using this plugin in real projects and have only had gains from it. Profiling within the editor is often misleading.

[funkyCoty]

Dropping a small update now:

1.1.0

• Updating project to Unity 6.3 LTS

• Removed support for Unity 2022.3 (updates beyond here will not be backported)

• Added Async Overlap Sphere support

• Added Physics Scene support for Async Raycasts and Async Overlap Spheres

Async Overlap Sphere: Watch Unity_nazUhweOGh.mp4 | Streamable

[funkyCoty]

By request, adding a few more:

1.2.0

• Added Async Overlap Box
• Added Async Overlap Capsule
• Added Async Spherecast
• Refactored internals to allow slotting in these new types with minimal code.
• Introduced RaycastTicket, SpherecastTicket, OverlapSphereTicket, OverlapBoxTicket, and OverlapCapsuleTicket as new ticket types. This makes using the plugin’s API less error-prone, as using the wrong ticket in the wrong type will now be a compiler error.

Edit: I wanted to comment on some of the performance comments above in the thread. The demo scene included IS the performance test scene, by the way. You can toggle the raycast mode and see the difference. Even in the editor, it should be significant. If you have a use-case that doesn’t get better performance, please explain it here and I can try and help.

Regular raycasts:

Async raycasts (RaycastCommand usage):

You can see that yes, there is overhead for scheduling, but the overall time should be much smaller. (The jobs are happening in the job threads at the bottom).