Subscribe for a "consistent" upload schedule, also I'm aware that this video doesn't have the most elegant explanations, and I guess youtube compression really dislikes this video as well I just wanted to get it out as soon as possible so we don't reach 4 months without uploading.
There is a crate called bevy-spatial. It provides kd-trees that track marked entities as a resource. It supports fast lookups within a radius, nearest neighbor lookups and axis-aligned rectangle lookups (see pull request). It may help you outright or inspire you for your own version.
yeah it was pretty complicated and I’ve only reached the surface of full potential battle simulators like UEBS that can simulate millions of units ON TERRAIN AND WITH ANIMATION without that much lag.
I wonder if you could further improve on the quad tree idea using adaptive volumetric fluid simulation methods: Do you really need to calculate the precise movement of every single unit stuck in the center of a large crowd? Maybe it's possible to approximate via clusters. That way, the quad tree would have the opposite behavior: Large chunks of crowd would count as a single multiunit that can only move more or less in lockstep. No need to calculate every single collision there. The closer to "the surface" (the frontline, the backline, the flanks) you get, the finer the grid as motion is less restricted. One tricky bit there is how to calculate individual positions from the summarized one without generating more work than was saved in the first place, but I suspect it might be possible. You'd also have to be able to quickly recalculate based on selection but I think that's already a problem now so you probably already solved that
I've been making grass and am hitting a hard performance bottleneck, so I was thinking about trying a custom render pipeline to implement instancing as well. Fixed update might also be useful. Really cool stuff! Definitely relate to the "messy and inefficient" part, probably will have to rewrite it once I get all the pieces of my game working (gameplay tbd, but building a huge procedurally generated open world).
umm.. I think Bevy 0.12 already does batching & instancing for you without a custom shader? I can render 6.5 million blades of grass with: var model = mesh_functions::get_model_matrix(vertex.instance_index); (I did not define instance_index myself. it's built in to the vertex input)
this way i have more control and can remove features that I deem to be useless to my project, also I did not know that instancing was already built into bevy and didn’t want to test it out.
So i would like it to be but as you can probably tell from the last segment of the video, one side should not win by so much with equal units. The combat system is a really hacky system that I whipped up last minute so I didn’t really expect much either. Other than that the rest of the game should be completely deterministic as Its run on a fixed update.
Subscribe for a "consistent" upload schedule, also I'm aware that this video doesn't have the most elegant explanations, and I guess youtube compression really dislikes this video as well I just wanted to get it out as soon as possible so we don't reach 4 months without uploading.
There is a crate called bevy-spatial. It provides kd-trees that track marked entities as a resource. It supports fast lookups within a radius, nearest neighbor lookups and axis-aligned rectangle lookups (see pull request). It may help you outright or inspire you for your own version.
That so cool. I bet it not easy to run smooth for many units in game.
yeah it was pretty complicated and I’ve only reached the surface of full potential battle simulators like UEBS that can simulate millions of units ON TERRAIN AND WITH ANIMATION without that much lag.
I wonder if you could further improve on the quad tree idea using adaptive volumetric fluid simulation methods: Do you really need to calculate the precise movement of every single unit stuck in the center of a large crowd? Maybe it's possible to approximate via clusters.
That way, the quad tree would have the opposite behavior: Large chunks of crowd would count as a single multiunit that can only move more or less in lockstep. No need to calculate every single collision there. The closer to "the surface" (the frontline, the backline, the flanks) you get, the finer the grid as motion is less restricted.
One tricky bit there is how to calculate individual positions from the summarized one without generating more work than was saved in the first place, but I suspect it might be possible.
You'd also have to be able to quickly recalculate based on selection but I think that's already a problem now so you probably already solved that
Awesome video!
Great video! It would be nice if you explained the last part where you add shooting with some code and drawings
Yeah you are right but the video was getting a bit long, perhaps in another video further down the line?
I've been making grass and am hitting a hard performance bottleneck, so I was thinking about trying a custom render pipeline to implement instancing as well. Fixed update might also be useful. Really cool stuff! Definitely relate to the "messy and inefficient" part, probably will have to rewrite it once I get all the pieces of my game working (gameplay tbd, but building a huge procedurally generated open world).
thanks for sharing! traversing quad trees sounds super interesting
This is really awesome
umm.. I think Bevy 0.12 already does batching & instancing for you without a custom shader?
I can render 6.5 million blades of grass with:
var model = mesh_functions::get_model_matrix(vertex.instance_index);
(I did not define instance_index myself. it's built in to the vertex input)
this way i have more control and can remove features that I deem to be useless to my project, also I did not know that instancing was already built into bevy and didn’t want to test it out.
Super cool! Sorry if I missed it, but are you using a custom physics engine? Or are you using a crate?
its just a simple separation check which is made more performant through a spatial partitioning system through a quadtree. I didn’t use any crates.
I like
same
Nice, btw is it fully deterministic?
So i would like it to be but as you can probably tell from the last segment of the video, one side should not win by so much with equal units. The combat system is a really hacky system that I whipped up last minute so I didn’t really expect much either. Other than that the rest of the game should be completely deterministic as Its run on a fixed update.
always happy to see non ai gamedev vids :D
video is too hard to understand