My project: I generate a bunch of tiny meshes. Those meshes are then dynamically modified by the user’s interaction (picture a maze that you can carve, if that makes any sense)
Current layout is like this: 1 entity per mesh. The archetype is basically a RenderMesh, a PhysicsCollider and a component that holds data used in modifying the mesh.
My problem: All meshes need to be unique. The RenderMesh component is forcing my entities to be in different chunks because it’s a shared component and all instances are holding different values.
My current “solution” is to remove the RenderMesh part entirely. Map the entity index to a mesh and modify it on the main thread when flagged for modification.
Is there a way that I can avoid that? Is there some sort of regular RenderMesh component, rather than a shared version? Is that even possible?
Nope doesn’t exist, gotta make your own rendering system. Starting with your idea of making an IComponentData with a mesh and other related fields then drawing your entities with the various Graphics.DrawMesh methods is a good start
This is so refreshingly blunt, but also disheartening considering the implications of having to do this in a commercial game engine development tool that is supposed to handle its upcoming functionality to the fullest extent possible. I guess “preview” isn’t enough to begin to describe this…
Yes from what I’ve seen, most people here, including myself, have written their own rendering system since RenderMesh V2 is too limiting right now. Hopefully V3 will cover more use cases while also improving performance, cause its performance also sucks right now. I’m sure it will happen, I’m just a little surprised that rendering of all things doesn’t have a higher priority.
Alright, I’m running into issues when trying to write my own system.
I have tried to run all the procedural logic through jobs and then update meshes binded to monobehaviours on the main thread. That didn’t work out for me since the flattened native array that I’m passing to the job exceeds the max size. It’s basically max vertices per cell * max cells per chunk * amount of chunks flagged * 12 bytes.
I tried to add the procedural data to the entities themselves with dynamic buffers but the entities became too large, to the point where only one would fit in a chunk, which I believe defeats the purpose.
I tried to create my own component but found out quickly about blittable types. I could not find a workaround.
The initial issue was that I can’t use RenderMesh since all my meshes are pretty much different, being procedural. All my entities end up in different chunks.
Could anybody give me more specifics on how to roll my own system?
I’m not ignoring this comment by the way. I downloaded a project with samples on their repo. Found out that’s a whole new thing to learn and I want a better grasp on the DOTS before I proceed to learn new things. Still, thank you for sharing.
Dynamic buffers can exceed their InternalBufferCapacity. When they do, they allocate onto the heap instead of inside the chunks. In your case, that’s probably what you want them to do most of the time, so you can set the InternalBufferCapacity to 1.
Thank you, I was able to get my system to work by doing this. I assign vertices/indices to buffer from within a job and then read buffers, assign to mesh and then clear those, post-job, on the main thread.
I generate a dynamic mesh for text purposes by doing this:
1- Generate vertices/indices using jobs and storing those in dynamic buffers for each text element (entity)
2- Batch all those vertices/indices toghether using jobs into one big dynamic buffer
3- Generate a single mesh with all of that in the main thread using new mesh API that supports native arrays
4- Render the mesh using DrawMeshNow in a camera attached MonoBehavior through OnPostRender()
The way you render in point 4 depends on your use case but i think this is somehow how you should do it.