So I’m confused by unity’s only current way of built-in mesh storage and rendering in entities being through a sharedcomponent. From what I know, these store entities in different chunks per data type. So if a bunch of entities all share the same mesh, this makes sense. But what about if you have a lot of differently meshed entities? Most games have maybe 30 at most of the same meshed object in an area at one time. This seems vastly wasteful for memory, because each uniquely meshed entity would get its own chunk. And because it’s nearly impossible to set the chunks to a different size than 16kb, that’d be 16kb of data per entity completely wasted. Am I just not understanding this system correctly, or has it changed or something from the info I read? Is there a better way to store a lot of diverse meshes?
That’s because most games are limiting how many objects they simulate at once. With DOTS, one can simulate way more entities but that doesn’t affect how many unique assets a team can create, so the assets get re-used more and those counts and efficiency go up.
Also, the Hybrid Renderer is not an all-purpose solution. It neither is completely finished, planned to be the final solution (hybrid in the name), nor does it cover all use cases. But that’s the beauty of the way Unity has built ECS. If a team decides that the renderer doesn’t solve their problems, they can either embed the package and modify it or throw it out and build their own solution.
If you have a huge asset library, you might consider manually doing instancing by having each entity reference a prefab RenderMesh entity.
In that case, what would be a good solution for dynamically created meshes? None of them will be the same, and it seems inefficient to separate all of my entities into individual chunks using a sharedcomponent to store the meshes. Would the blob builder be good for this? I heard it stores a big pool of static managed data, so that might be a good place to put all the meshes, but it seems there’s very sparse documentation.
Blobs don’t store managed data like classes and such. You probably just want a List<RenderMesh?> and store indices into the list in an IComponentData. Draw calls are a big concern though. You aren’t going to get the crazy rendering gains DOTS usually gives if all your meshes are unique and can’t be instanced. You might be able to do some incremental static batching in jobs to give you some boost, since it sounds like the meshes are static after generation.
I’m working on a voxel game much like minecraft, so although the meshes will be changing constantly, there will be large time gaps between changes. The main drawback I’m encountering isn’t really the rendering, as that only takes 6 ms and still could be greatly sped up via merging meshes to reduce drawcalls and greedy meshing. The main problem is how I store them. Without an “official” solution to it, I’m just not having an easy time weighing the pros and cons between methods available. I could try to save them all in a list or a hash map, or maybe in separate entities which would then all be chunked together and referenced by components in my actual entities, but I don’t know how to get the mesh out of the mesh generating job. It runs in parallel and will calculate 6859 times right at the start, so I need some sort of singular struct which can be stored in a native container and can store all the data. Or just some way to effectively have 2 dimensional storage of all the data. I’m trying to avoid putting a buffer on each entity to store the data because at this point that’s 6 buffers total, since there’s one for blocks, one for blocks from the previous frame to check if it changed last frame, and then vertices, uvs, normals, and triangles. Then that exceeds the maximum amount for the IJobForEach_B, BB, etc. clones and just isn’t pleasant to manage.
For now I’m going to try to store them all as a separate list of entities, which will all be referenced by one entity in a buffer. That should work for what I’m trying to do.