Why is the rendering performance when using ecs worse than when using monobehaviour?

It worked for me. I guess it gets converted automatically. All game objects are in a subscene. The missile prefab has a regular Collider component, not Physics Shape.

 

So you use a "Physics Body" component and a "Collider" component instead of the "Physics Shape" one? Interesting, I have been using Physics Body and Shape for those two. I'll try it with just a collider.

 

@SteffenItterheim Just wanted to provide some more notes for you or anyone else that is interested on what I've tested to try to get closer to 90 FPS with 100K missiles.

• I've tried it with just a Box Collider as well as a Physics Shape. Neither makes much a difference to the FPS as far as I can tell.
• The missiles aren't colliding with anything at the moment. Even if I take the collider/shape off the FPS is still low.
• Tried both Unity and Havok physics without much impact on the FPS.
• Changing the physics solver iteration count from 4 to 1 didn't make much impact.

My PC has an intel 8 core/16 thread CPU, 64GB RAM, and a 2070 Super. So it seems like our PCs are comparable although your CPU might be giving you an increase.

• So I started a new project to try to URP instead of HDRP. Surprisingly it seems like URP performs better. Maybe I just set up something wrong in HDRP?
• I also found that changing Edit -> Project Settings -> Time settings had a big effect. What values were you using for your 90 FPS video? I set Fixed Timestep and Max Allowed Timestep to 0.1666666 and Time Scale, Max Particle Timestep to 1.

So with the above couple changes I am able to get to 50K missiles at 115 FPS. 100K missiles is at about 56 FPS. Both of those are with Physics Body and Shape components. I am wondering if there is still something else I could tune to get better performance that is closer to what you saw.

Edit: This benchmark between our CPUs shows Cinebench (when using all cores) performing almost 50% better than my CPU. So if you take my 56 FPS and add another 28 FPS you'd get 84 FPS, which is pretty close to what you saw. Throw in RAM speed differences, maybe for the rest? So maybe I am finally seeing the performance you did.

 

HDRP has a higher CPU overhead, which makes a difference in small scenes, but should scale better than URP in larger, complex scenes.

 

@programmer119 - I think DOTS in general is not ready for mobile platforms. There are several ECS/Jobs/Physics bugs that myself and others have run into, and I have noticed the same HRV2 problem you are describing with my terrain. Last year when I was testing I was lucky to get Android to display just the terrain by itself without crashing, and when it did display, it was so slow that it was unplayable. It's not a large terrain - just 500x500 with a detail resolution of 256. Unity on Android was so broken at that point that I gave up and haven't tested since then, but hopefully most of the issues will get fixed in our lifetime.

So in summary... the current situation sucks. In all fairness, Unity has specifically stated in some of their official posts in the forums that DOTS on Android is not supported, so technically we're trying to do something that isn't officially blessed.

 

Have you tried static batching + bulding the chunks like a single big calculated mesh?

You could identify and render only the surfaces on a chunk instead of single voxels.
That's more like a real case scenario rather than cubes for voxels.

It's probably still cheaper to render one single 64k vertices mesh than rendering 16k "objects" with 4 vertices each (just an example).

You could surely use DOTS for processing it quick with small data chunks and split the work on all your threads.

You could squeeze even more performance like that

EDIT: a nice reading on that
https://learn.unity.com/tutorial/pa...255bedbc2a2e590fbe60#62ab4d42edbc2a03e2f695ad