It does use the jobs system - it should be commented so you can see what's going on!
There are actually no gameobjects at all, so pooling isn't needed. The bullets are all rendered with one draw call per bullet manager, it's about as optimised as I can make it at the minute. It should be ok with around 20,000 bullets on-screen and stay above 60fps 馃榿 obviously you'll never need that many, but it means you've got a lot of performance budget for other things like post-processing.
You're welcome to have a look and see how it works - that's half the reason I've put it up here and made sure it's so well commented 馃槀
it is actually intended for top-down 3D because that's the game I'm currently working on 馃槀 it should work with any meshes. The demo uses quads, but there's no reason you can't use a sphere or something else!
It uses DrawMeshInstanced, not InstancedIndirect. Couldn't get indirect to work before the jam, not going to have time unfortunately! That just means there's a cap of 1023 bullets per manager. I don't think you should need that!
I see! That's really awesome - I've been working myself on making ECS/DOTS (with Jobs and Burst) work in WebGL, which was an ordeal especially because the Hybrid Renderer does not yet support WebGL so I'm using Companion GameObjects for now (with all logic applied to entities and just the transform of the GameObject synced every frame).
There were a few other gotchas if you're interested, but at this point your approach seems way more feasible (also for not using preview packages~) Good work, thank you for sharing~!
it does use jobs, which is a preview package! But seems to be stable enough at this point 鈽猴笍
Sounds like we're doing mostly the same thing, essentially just rendering differently 馃槀 most of it should be commented pretty extensively (except the editor tooling) so you should be able to work out what I've done.
You're welcome to download it and check it out - it's all commented. Easier to answer specific questions when you've actually seen it 馃槀
As for some tips on making your own system more performant:
If that's still not enough, there are some major changes you can make to do it like I do:
If 20k bullets at 60fps isn't enough, you can go full ECS. You probably don't have to do any of the last section, though, the first lot should be plenty to get 1000 on any hardware :)
You might, for example, be using Linq in your object pooling code to check if there are any available bullets. I was doing that, removing that linq code sped it up about 3x
It is SUCH a shame that LINQ is so slow >_<
Especially if you then compare the performance of LINQ with what Rust offers and you see that in Rust using map/reduce is almost always as fast as a normal foreach loop and often faster than using a normal for loop to loop over your structure. And then there are even moments where it wins from both unless you try VERY hard.
Hello!
I was able to solve the bullet post-processing in WebGL by going to Project Settings > Quality. Then I just removed all settings except for High Quality so it was forced to use that. The problem was that for WebGL it was set to medium quality which made it not render the bullets (from playing around with it)
As an example, here is my WebGL build with the effect fully working. The framerate is also pretty decent Thank you so much for creating this package, it's amazing and looks incredible =)
