Hi, I’m working on a little project that uses bits of old Unity’s approach (GameObject, …) for some non-core things (setup, debug, Input, UI, …) but does most things through a custom ECS-like system build on top of Job system. I.e. we store all of data in NativeArrays we manage, process systems through mostly burst’ed jobs, have our own compacting for dead entities, etc.
We chose this approach instead of ECS because due to the game design we don’t plan on using much of unity’s other offerings (Physics, …), wanted to learn how to do stuff ourselves, and ECS (and/or docs for it) also wasn’t as mature as we would prefer at the time we started.
It all works fine and we’re actually really happy with it. It provides us with the ease of use, things integrate nicely together, there’s no magic glue involved, and thanks to burst the performance is amazing.
Unfortunately there’s one caveat, rendering. Since we want to be rendering thousands of extremely simple meshes, just at different locations, we’re using DrawMeshInstanced. Creating the mesh/matrices is non-issue, the mesh is done once, the matrices are computed in a lovely burst’ed job. The problem is actually calling DrawMeshInstanced.
Due to the fact that it doesn’t accept NativeArray/Slice and you can only draw 1023 instances at once we have to have relatively elaborate code for it work producing garbage but it’s still one one the biggest bottlenecks (just filling & submitting the batches) we currently have.
Googling, we’re hardly alone . We know that there’re pointer-based unsafe workarounds but we’d rather not use them (as I’m not sure how defined they’re on various platforms). It’s also been promised that
“Making graphics related API compatible with the JobSystem is very high on our priority list. While doing this, we are also creating overloads for most of the API to deal with NativeArrays”
in 2018 but - and I might just have missed it - I haven’t seen anything new about it.
Should we expect any change on that front or has the focus shifted 100 % on DOTS/ECS, i.e. using job system without ECS is/won’t be supported in the sense that there will not be much QoL improvements on that API front?
We’re fully aware that we could just switch to ECS and it’s not out of the table but as I said, our current way of doing things fits us really well so far.