performance issue displaying 40000 basic cubes

Hi guys,

I want to display about 40000 cubes in Unity. I have a very powerfull PC but it is laging so much when the camera is moving !
I am surprised because complex objects could have several 1.000.000 of faces and Unity can handle it with any problem. So why displaying only 40000 cubes (arround 6*2*40.000 = 480.000 faces) is an issue ?

Thanks

Fabrice

 

the pc needs to send each mesh by itself to the GPU, ofcourse it's slow even if it's just a cube.

try turning on GPU instancing on the material, if the cubes aren't dynamic(but i bet they are) check them as static.

why do you need 40K cubes for?
sounds like you could use voxels.

edit: also, culling, unity doesn't have dynamic occlusion culling, only the camera angle thingy(forget what it's called), so if you can find a solution to this it's gonna speed you up

 

That is a GREAT question! Fire up the profiler (Window -> Analysis -> Profiler) and you can learn first-hand.

For extra points you can try some optimizations (see what @SparrowsNest above posted) and see if you can get it performant enough for your needs.

 

There are two issues here. Displaying 480,000 faces via your graphics card. And getting the 40,000 objects to your graphics card. If I was a betting man, I would say your issue is getting the 40,000 objects to the card. If you combine the objects into a single object, via voxels, a shared mess, instancing or similar, things should run fine.

Of course check the profiler. There is also the possibility that you've done something crazy like turn physics on for all 40,000 objects.

 

Thanks for your explanation !
My goal is just to display these 40k cubes and to make them moving and rotating independently. Each cube has its own color. I might want to put much more cubes if I success with 40k.
About voxel, I guess it is not what I need as my cubes need to have their own orientation in space.
I am going to start with GPU instancing and will come back to you with the result. I will check the profiler too.
In my case, I also understand there is no way to use dynamic occlusion culling.

 

Particle systems also come to mind. Might be worth having a look at.

 

Yeah, this sounds very much like the job of a particle system.

This gives me pause, and makes me suspect that you have a movement script on every cube. Is that accurate? If so, that is going to be tons of overhead processing.

As an alternative to the particle system approach, I'd say you should also check out the new/beta ECS System tutorials, which (along with the related Job and Burt Compiler systems) is specifically designed to accommodate comically large numbers of objects. By the time all three of these optimizations are implemented, the demo has 156k independently controlled spaceships moving onscreen at 30fps, (up from about 16k without the optimizations at the same fps) so I think your 40k cubes will be a cakewalk for that system unless they have particularly complex movement logic.

 

Huh, I hadn't even considered... but yeah, I bet that would be way more performant.

... makes mental note to check this in the profiler sometime real soon now...

 

Gonna have to compile me some Burt.

 

So quick things for you to check off:

- You want ONE script to be doing all of this. Rather than one per object (40000 monobehaviours running :O )

- If your not using a particle system (which you should be), then this is perfect for JOB system otherwise you will have some framerate issues either way
Some resources to help in this:

https://github.com/stella3d/job-system-cookbook

https://github.com/stella3d/job-sys...ter/Assets/Scripts/AccelerationParallelFor.cs


- You want GPU instancing and same material on each cube so they can be batched into combined draw calls

- You want to disable batching if using GPU instancing

- You also want to manage hiearchy depth vs batching

- What i mean by this is, the deeper an object hiearchy the slower it is to process changes as a change to parent means all children get iterated over, but at the same time not having them as shared objects will cause issues too.You need to find the balance

- You want to make sure you dont have realtime GI etc turned on, as that often defaults to ON in lighting settings

- You ultimately want to profile as no two apps, systems etc are the same

EDIT:

You also could gain massive FPS by drawing them using
Graphics.DrawMeshInstancedIndirect https://docs.unity3d.com/ScriptReference/Graphics.DrawMeshInstancedIndirect.html

Instead of actually having a gameobject per object. This would mean your heiarchy is nice and clean and your making massive use of batching optimisations etc

 

40k dynamic gameobjects is a distaser waiting to happen, with ECS and GPU instancing it will be a breeze

 

i am quite sure unity doesn't allow 40k yet. the highest i have seen is around 20k stable objects. but with the upcoming ECS system it should easily handle 100k +

 

As @GameDevCouple_I mentioned, DrawMeshInstancedIndirect works really well for this -- you can get over 100K cubes floating at 60 FPS.