How to have 25 thousand moving objects in one scene ?

Hi, i am creating simple space shooter in 2D, and i need to have many objects moving and colliding with each other, even that they are not in mine viewport. The goal of mine project is to have many objects moving and colliding with each other, and i can't below 60 FPS. I created an asteroid prefab, with simple box collider 2D and rigidbody attached to it. On instancing that asteroid i am adding a force to it. I am instancing mine asteroids in a grid. Mine question is how can achieve that goal of mine, is good way to use many rigidbodies or only on transform operations. Or i have to change my way of thinking to achieve this goal ? Thanks in advance for every answer.

 

look for unity ECS (or DOTS) https://unity.com/dots

examples, like:
https://software.intel.com/en-us/ar...tem-ecs-c-sharp-job-system-and-burst-compiler
https://github.com/Unity-Technologies/UniteAustinTechnicalPresentation
https://github.com/paullj/unity-ecs-instanced-sprite-renderer

 

I was thinking about it, from begining of the project, but i was wondering, if there is another way to achieve that project goal without using ECS or C# Job System.

 

drawing that many objects it not really a problem in old system (on desktop), using instancing,
but i'd guess using physics would be.. so might have to make custom physics/collision checking then.

is this going to run on desktop or should work in mobile too?

and check with Profiler which part is the bottleneck..

 

It should on desktop, but if can i should also test it on mobile. The main problem is physics and the big amount of calculations about it, when i check in profiler.

 

I am going first to implement own physics and collision in game. And with that second thing i got a bit of problem. I decided to use bounds.intersects() method, but how to get the closest obstacle, efficiently ?

 

bounds.intersects x N will definately not be faster than the in built physics engine.

Honestly ECS really is the way to go about this.

Otherwise, you could use ClosestPoint https://docs.unity3d.com/ScriptReference/Physics.ClosestPoint.html to get the point closest to the thing that was hit

 

need to look for some quad/octtrees to make it faster to find nearest objects.

also many unity methods are usually slower than making your own,
so making custom bounds and intersects method can be faster too.

 

Definitely ECS.
I stress tested other day 5k colliding objects with each other at the same time and Unity really struggled with few FPS. Mind that was yes with 3D dynamic colliders and OOP (not ECS/DOTs).
While usually won't get 5k collisions at the same time, definitely many collisions will generate bottleneck. However, with 2d you may get much more performance.

Either way, I suggest watch demo of the thousands fighting minions from 2017, presenting capabilities of ECS. Also watch technical talk, of how the did it. You may find better way, than using colliders.

 

OP a quad or octree like mentioned here would indeed mean you could *potentially* use standard OOP and still get reasonable performance. That said, if you recieve a high amount of collisions at once like @Antypodish mentioned, then you will still bring your PC to its knees.

Ultimately I would opt for ECS. You can still use a structure such as a quad/octree with ECS, just ECS will also mean the rest of the data usage + passing around is actually efficient and able to be run multithreaded

Alternatively you could do what I call "aproximated distance based physics culling" which is basically only having things nearby you actually fully collide and do full physics calculations, and then the further away the object is the less calculations you do until the far far stuff is not colliding at all. Most of the time you wont notice that in a big crowd of colliding things, and it will save you performance at the cost of realism. You could factor in the users view fustrum so that anything behind them beyond X distance also does not collide, and so that things in the distance that you are focusing on are able to collide while being looked at

 

The big problem of that project that every object even if it is visible or not, it have to be still moving and colliding with other objects, which is the big bottleneck of that project.
Currently i was wondering about efficient way to check, if it collides with any object from perspective of one object.
But even if i do that, there will be still that problem, because every of that 25 thousands of object will do that too.
Can you tell more about that quad or octree way, i don't really not much know about that stuff ?

 

I should also mention that, when this two object collides with each other, they got destroyed and being re-spawned. So the amount of object is not decreasing during the game.

 

Well if your destroying objects instead of pooling them ,and instantiating too on collisions then you are making it even more of a bottle neck than it needs to be. Thats very inefficient, you should look into object pooling instead.

EDIT: I also think based on the way your talking that this is not the right project to be doing for you right now. Custom physics is difficult and if you dont know what a quad or octree is, your probably not ready to also write your own physics in an efficient way. Im not trying to be mean, just realistic.

 

Honest opinion is a good opinion . This project is too learn new stuff, so i don't feel dissapointed. What will be, better to do in your opinion, write own psychics or go for ECS instead ?

 

ECS 100x, its more future proof and you in general will be learning a new and awesome way of programming that is thefuture Also both will take equal amounts of time so may as well go ECS as you can do more with it than just physics

 

i'd still try with the old system first,
i mean pretty early you should be able to see if its even possible or not.

because:
- easier to find examples and help if get stuck
- you'll still need similar optimizations / concepts in ECS eventually too
- get nice benchmark project to compare against ECS version if you decide to make that next


also,
can you post screenshot of your current version Profiler, with deep profiling on?

 

@Zizajer, unfortunately I think @GameDevCouple_I is right, regarding weather you are ready jump on such deep waters. Not to be discouraged. Bot definitely need more background. No need for writing custom engine however. There existing tools and solutions are fully capable.
But you need to know about them. And that only comes with experience.

ECS samples like boid fish school of 25k fish.
Watch at least 2 min. And preferably whole talk.

And Unite Austin 2017
Massive Battle in Spellsouls Universe

 

Just want to chime in and say that @mgear is right that you will find it easier to get examples and help for non ECS.

And also you would have to use a quadtree or octree in ECS anyway so I guess start with normal OOP programming and try implementing say a quadtree to start with for collisions, to ensure that only things near things are being checked so your not iterating all 25k objects and comparing them against all 25k objects each time.

Then profile like crazy and optimise as much as you can with that first, and only then if you cannot squeeze the required FPS out of it try to uplift it to ECS and jobified stuff.

And yes a screenshot of the profiler, would be useful, to see what is actually taking up the resources. I imagine if you stop instantiating and destroying stuff and use pooling you will already be at a good performance rate, as 2D I can get 25k rigidbody2D balls bouncing around no problem with very little optimisation other than GPU instancing, and decreasing the physics tick rate slightly (from 0.2 to 0.3 or something similar). If I try and destroy and respawn each ball as they collide I suddenly go down to a crawl (and ofcourse that would happen as a ton of garbage etc is being created and memory being inefficiently used)

EDIT: oh and definately also test in a build, editor performance is not a good benchmark. if it runs fine in build and not in editor then its not a problem

 

Ok i will try first with QuadTree like you said. The current version of project only destroys the asteroids and don't instatianting them again. I will use pooling soon. Here's the screen of the profiler and in these version of project i am using unity 2d psyhics, and i am only instatianting a 70x70 grid, because is easier to test for me, this screen is from editor test, in further work i will only test on builded version of project.



[Edit] This screenshot is from builded version of project and with creating 160x160 grid.

 

easier to see with Hierarchy view,

then can see exact parts or operations where time is spend, by opening these:

 

Thx, it's way better.


And when i see now that information, i got one question, why i got such number of calls, when in game is only around 25600 of 2Drigidbodies ?

 

Not sure.. also tested on 2019 alpha, ticking the [x] job options, cuts about 120ms from 25k objects.

if @MelvMay is around, he can probably say whether having 25k 2d physics objects would ever work?
(without doing tricks like disabling colliders outside of view or something else)

 

Currently i am more focusing on the ECS way. In terms of OOP i think only quadtree can help with object pooling.

 

Projekt na staż?

 

English please.

 

Sorry, I have the same project so I've assumed that author of the post and me are same nationality