RayCast breakdown

I’m currently on a project that heavily uses RayCast (up to several 10 thousands times a second in worst cases), and I was wondering how optimized/implemented RayCast is.
I tried to dig into the engine source code, but I didn’t manage to get what I wanted.
Is it possible for someone to explain how RayCast is implemented (regarding complexity, what slows down/speeds up the process, optimizations, etc.) ?

I hope the question isn’t already answered somewhere else :sweat_smile:

It depends[TM] on many factors, including but not limited to the following:

  • How dense the broadphase is. (I.e, how complex + dense collision geometry is in general)
  • Type/complexity of geometry you’re tracing against. (Simple shapes are fast, triangles are expensive)
  • Amount of info requested by the raycast (physical materials, face indices, UV info etc.)

The most obvious answer is to profile it, and find out how much time it’s actually taking. If you’re spending a significant portion of your time on raycasts, maybe consider an alternative approach.

It smells of a design issue though. I’ve never know any system to really require 10K+ raycasts per-second, if you explain waht you want to achieve, somebody might be able to suggest an alternative approach that isn’t so extreme.

In terms of digging into the engine, I wouldn’t bother. The physics engine sits beneath layers of abstractions and templates that make it difficult to actually follow. Generally speaking however, there is an FImplicitObject defined for each type of geometry (sphere, AABB, Trimesh etc), which has a virtual Raycast function. You can dig into the internals and specifics from there.

1 Like

Thank you for your reply !

At the moment, the geometry of the assets I’m using is quite simple, but it can evolve so it’s always good to know that it can have a signifiant impact.

Regarding what I’m working on, I’m trying to create a simulation tool that computes the collision impact of thousands of little objects that have a really high velocity, so fast that the built-in collision detection of Unreal isn’t enough.
That’s why I need to compute collisions by myself, and raycast seemed to be quite a useful tool for a first shot to check if there was a hit between two points in space.

The engines internal physics sim uses the same functions/systems you are using ultimately, but ofc it’s designed for game-level simulations nothing crazy complex.

The Chaos physics engine is still relatively young and still measurably slower than it’s PhysX counterpart too. Newer versions of PhysX are likely orders of magnitude faster again, but last I checked NVidia sadly have no plans to maintain a PhysX branch of the engine as according to them, Epic’s abstraction API doesn’t make it easy. You might be able to find a PhysX branch on github somewhere though.

You could try experimenting with an earlier version of UE, but do keep in mind the engine is designed for game physics not extremely complex simulations. You might even have luck with Niagara since it’s a very highly programmable GPU solution, but that would take a fair bit of work ofc :slight_smile:

Thank you again !

I can be worth a try with an earlier version of UE to use PhysX indeed. Is it used by default with UE 4.27 (installed from the launcher) ? I read that starting from 4.23 (?), Chaos was introduced and both were usable, but I guess it isn’t as easy as just modifying a value in the project settings right ?

Also, I managed to do a test on another computer, more powerful this time, and I guess that handling 10k/20k Actors in a little space isn’t very conventional too… Neither my CPU or GPU was heavly computing at all, but performances were still poor. I think there’s also a design issue here I need to solve (switching to particles maybe, but I still need to handle each of them one by one and do my collision detecting stuff :confused: ).

Edit : I did a first rough test with UE 4.27, and I get slightly better performances. It’s a good start maybe ^^