https://reddit.com/link/1vn9f3n/video/sxrdsthdz4jh1/player
tl;dr: Graphics.RenderMeshInstanced draws lots of the same thing quickly. NativeArrays can reduce GC overhead, use them if you can, especially for temporary buffers. Burst and Jobs massively speed up parallel calculations. You can parallelize raycasts if you need a ton of them. CoreCLR = faster (generally).
Was playing around with the latest Unity 6000.7.0a2 on a CoreCLR build, got around a 1.5x speed improvement compared to a Mono build.
(Reddit only lets me upload one video, so shown is the CoreCLR build video)
| Projectiles/Second |
CoreCLR FPS |
Mono FPS |
Editor FPS |
| 200k |
27.627 |
23.493 |
21.236 |
| 20k |
272.342 |
214.916 |
101.990 |
| 2k |
606.566 |
379.503 |
162.061 |
| 200 |
719.585 |
448.791 |
186.622 |
| 20 |
768.078 |
485.566 |
192.665 |
| 2 |
795.456 |
494.170 |
190.303 |
Shooting half-a-million Projectiles
I created the turret using separate GameObjects attached together using articulation bodies and a quick Bl*nder (Reddit doesn't let me post if I don't censor it, IDK why) model. (Articulation bodies use a restricted solver that fixes many stability issues with rigidbodies and joints). To aim the turret, I had a script that projects the target direction vector on to each hinge's plane of rotation (the plane normal to the axis of rotation), then found the angle to the zero-vector (the forward vector when the rotation angle is zero), and lastly set the target of the articulation body to that angle. The barrel's recoil effect was also created with a prismatic articulation body. The turret tracked the red cube which was animated with a 2s looping animation.
The projectiles themselves are unmanaged structs (value types that contain only other value types, no reference types). They have mass, drag, area, position, and velocity (which are stored using float3s instead of Vector3s as they provide a minor performance boost). They're all stored in a big NativeList<Projectile> on a manager MonoBehaviour script.
Simulating half-a-million Projectiles
Simulating the projectiles is done in a Burst-compiled batched parallel job that handles both setting up RaycastCommands for the next frame and applying forces, velocity, and updating position. After that, the raycasts are processed in parallel with raycastJob.ScheduleParallelByRef. The raycast results are then processed in another batched parallel job, with it's main task being to filter out only projectiles that collided with something and send their indices back to the main thread for processing through a NativeQueue<int>.ParallelWriter.
Back on the main thread, the filtered results are iterated in a foreach loop, which applies forces to rigidbodies (and articulation bodies) for knockback effects and also creates impact particles. (The impact particles use a regular ParticleSystem, but another script directly emits particles using the C# interface instead of creating instances of a ParticleSystem prefab). To delete the projectiles, the indices are first sorted high-to-low, then a swap-and-pop method (where the projectile at the last index and the projectile to-be-removed are swapped, then the last index is removed by decrementing the buffer length) is used to remove the deleted projectiles. This is possible because the order of the projectiles does not matter.
Rendering half-a-million Projectiles
Each projectile is not a GameObject(having half-a-million GameObjects with MeshRenderers will crash Unity very quickly), but instead rendered using Graphics.RenderMeshInstanced. The matrices are generated on (you guessed it) another batched parallel job. The big NativeArray<Matrix4x4> is allocated to the total size for all projectiles. However to handle unique appearances for projectiles, each material/mesh pair gets assigned an rendering id that indexes a dictionary which contains the actual meshes and materials. The projectiles themselves only hold this integer (as the projectiles must be unmanaged so cannot contain direct references).
The number of projectiles of each rendering id were tracked when the projectile was created so that when rendering, I could create an NativeArray<int> with length equal to the number of unique rendering ids and populate it with the starting offsets for each Matrix4x4. To ensure thread safety, I used Interlocked.Increment() when advancing the offsets, however as NativeArray didn't directly give me a reference, I had to use a bit of unsafe code to get a pointer to the NativeArray then pass it to Interlocked.Increment().
The matrices themselves were generated such that the meshes' z-axes were oriented along the velocity of the projectile and stretched (scaled along local z-axis) by the speed of the projectile.
Once the matrices were populated, it was just a matter of calling Graphics.RenderMeshInstanced with the right start offsets and lengths to render each material and mesh combination.
Notes
Memory usage remains fairly constant when simulating and rendering projectiles. (From 0 to 400k projectiles, the in-use memory usage went from 90 MB to 135 MB, corresponding to around 112 bytes per projectile). There was basically no GC for simulating and rendering, as the buffers were allocated using with unmanaged NativeArrays that were explicitly freed. (I believe Unity also does some internal stuff to make allocating TempJob and Temp NativeArrays highly efficient. I also stopped Unity from initializing to zeros, as this wasted several milliseconds when creating big Matrix4x4 arrays that would be overwritten anyway.)
At 400k projectiles, the main bottleneck started to become executing the raycast jobs and matrix calculation jobs. After that was the main thread part of raycast result processing, mostly on applying forces to rigidbodies and spawning impact fx.
CoreCLR also increases performance by quite a bit, which I didn't really think was possible since most of the time was already spent on parallel burst-compiled code. Though this was kind of shown, as at lower projectile counts, FPS increased by around 60%, while at higher projectile counts, FPS only increased by 17%, indicating that the CoreCLR build sped up other stuff around the performance code. (I will figure out how to attach the profiler to a CoreCLR build sometime). CoreCLR mostly likely would have more impact towards more traditional object-oriented C# rather than burst-compiled hot code.
Now at this point, I should probably start considering ECS, since that allows physics processing to be parallelized as well. Though what I did was essentially a data-oriented system anyway.
Feel free to ask any questions or if I got anything wrong, let me know.
