object pooling in dots?

Hi,

I have millions of cubes in my game. Right now i spawn X cubes per frame, which keeps the fps high, but there will be some moments where i only need to show like 20 cubes. What do i do with the rest?

Just keep them there, but move them somewhere where the player cant see them? Is disabling better (eg adding Disabled Tag to them?)

What should be the correct way?

 

I think you can just remove the sharedcomponent RenderMesh from them.

I'm honestly not sure what the best way is, but if you use a remove query for the RenderMesh comp that has all the entities in it that are disabled in the current frame, performance should be still good.

Some don't even pool in ECS, just spawn how many they need and destroy too. I spawn like 10k monsters and it's done in < 1ms. Depending on how fast your cubes scale up in a single frame it might be enough.

 

What if i need to do this based on a simple condition (eg position > 10) ? Is there a way to extract a query out of a condition?

 

In my opinion, just check the condition inside the ForEach statement of your system. As far as I'm aware (would love to be shown otherwise), there's no faster way.

If your condition only matches for 10% of the entities in your query, the other 90% will just slide past super fast.

 

For this you need to set the component containing this value as SharedComponentData, this way you can still disabling them by query using filters.

I already asked for a feature which will make this case easier ( hope they at least aware about it ) post

 

Ohhhh that's nice, I stand corrected: https://docs.unity3d.com/Packages/c...ntities_EntityQuery_SetSharedComponentFilter_

 

I don't understand. When pooling, you know what you have all the time, you know the total of the objects, and you don't have to do operations to create/delete.

I would like to see some details and in-depth performance statistics on pooling vs. DOTS-re/creation.

 

Dots isn't actually creating or destroying anything. The data is just entries in an array. When you create a new entity it's just filling out data in an archetype. These aren't gameobjects with tons of initialization and setup code and memory to allocate. While there is a tiny overhead to entity management (adding it to lookup tables and such), any pooling system you write would most likely be slower than this by a lot, as you'd have to do logic to track what objects should be active, inactive, what pool the object is in, etc.. In short, ECS basically already has all the benefits of pooling without you needing to do anything.

 

What about if you're dynamically creating RenderMesh components at runtime, and they should be frustrum culled, but they're not, because as far as I understand it the normal frustrum culling doesn't work on dynamic meshes yet?

Even if it did work, if you had a game world where you were making terrain or a giant grid, wouldn't you be better off disabling or removing the RenderMesh components until you really needed them?

 

I have that issue. I am creating meshes during runtime for a randomly generated game world, both instantiating models based on imported FBX, but also parametrically created from scripts. Currently I am not using the HybridRenderer because of a few issues that must be fixed first (currently using custom mesh-combine/drawinstance-methods), but I plan on moving to that if they get fixed.

 

Sadly i'm not familiar with the hybrid renderer's internals yet, but yeah if you have external reasons to pool for your own logic it's different. I'm just saying that ECS by it's design doesn't create much overhead for creation and destruction, if you have lots of initialization/generation logic in your own code, disabling an entity would probably be a better option. Just don't do it to small/simple entities, it's not worth it.

 

This is a good point, but unity still needs to create/chunks to hold those entities. There is a cost for that (though minor compared to creating/destroying a GameObject).

 

@Joachim_Ante I'm really surprised to read not to worry about allocations.

Even ignoring the garbage collector and the potential hickups which are getting better, but used to be an issue, what would you say to a project that is already feeling memory pressure and already working with the most optimized textures and mesh and resource memory they can, to the point that even seeing less low-memory warnings on device by eliminating passing strings around and using foreach loops on dictionaries because of the extra allocations, or if you're developing on console where you need to be specific with every allocation.

 

@Joachim_Ante Thanks for clarifying. Just so I can explain that to my coworkers who are evaluating ecs, how much space is taken by the pooling of those chunks or how is that determined? like there has to be some number somewhere of how much memory usage the system takes, like total footprint? Is there a relationship on how much memory is allocated to how many systems you have or components you have or entities? While i remember the demo, i'm looking at a project that at one point had a 30% crash rate on older devices and some really annoying low-memory issues which was horrendous. we spent a lot of time optimizing, using the memory profiler to shrink our assets, we share as many resources as we can, we've found other areas where we can optimize like using StringBuilder instead of concatenating strings, using C-style for loops instead of foreach on collections. So you can imagine the first question my technical director is going to ask when i say "it's pooled internally by unity" is going to be "but how?"

you seem to be specifying no "GC" allocations, but what about "non-GC" allocations? do those even exist? does that mean they are all allocated on the stack instead of the managed heap? or managed internally by native code?

 

There's "non-GC"(Native) allocations when creating chunks(not creating entities) and chunks are pooled internally by Unity.Entities as @Joachim_Ante mentioned.