I’ve been playing around with the physics in Codea, trying to see what the upper limits are.
I’m seeing that it looks like on A14 chip I can get around 500 boxes bouncing around and maintain 60 FPS granted there are no huge amount of collisions all at once, let’s say we spawn 100 boxes all in the same x,y position, these boxes will all collide and there is some massive churn for a few seconds as the collisions are resolved.
500 seems great for 60fps, but I’m greedy and bullish. Maybe we can get more?
Well when ever I try around 900 or more, the slow down is quite bad.
I wonder, what physics library is Codea using under the hood? Is it box2D, and is it the latest version? Just want to confirm if this is the best we can do from a software perspective.
@skar I think this will be possible with the new runtime @john is working on. That would allow compute shaders and physics to be evaluated on the GPU for orders of magnitude more objects
I’ve put some more play time into this and replaced the line drawing of physics boxes with a Mesh texture, performance is better, even at 900 there is still slow down but it’s not as bad as before and is primarily on the mass number of collisions situations.
I’ve tried using physics.iterations() with many different values but they don’t really seem to have a framerate benefit.
600 bodies + 600 mesh textures (each mesh texture is a separate mesh to assume each unique mesh in a real game) animating at 60 FPS
Personally this is really good results, it should mean that in a real game scenario, we could have tons of animating objects that respond to physics. Even more head room the less physics you have, I was able to get thousands of meshes animating and moving at 60fps, seems to drop to 30 around 6000.
My next goal with this mini project is to make that time scale option work, going to try and see how I can add “slo-mode” and a “speed up”
I’ve been putting some more time into this project and have managed to get loading screens working using coroutines for Threads.
I’ve also adjusted the mesh to fit the size of the physics boxes and added the boxes outlines again, which does impact performance a bit (as expected since it’s extra draw calls). I’m adding the project in its current state zipped here for anyone who wants to check it out (@UberGoober )
@Simeon hi Simeon, one thing about this project is that if you set physicsMultiplier to 7 to get 700 boxes and meshes, the performance has a drastic hit and then I will also get crashes of Codea. Is that expected because the demand is too intense? Or is there another problem?
Oh that’s a whoopsie… DemoSprite is meant to be a comparable renderer to DemoMesh. DemoSprite uses the 1-60 images each broken out into its own image, while DemoMesh uses a sprite sheet/atlas so it’s only 1 image. Here’s a working zip with all sprite images included but a hacky implementation using ‘assets.all’ (kinda unfortunate I cannot have sub folders in the project assets…@Simeon).
this will allow the project to run, if you end up wanting to use the sprite rendering just make sure you comment out line 11 in DemoSprite, I forgot to after debugging
That simulation is really cool, but it slows down a ton when it gets around 600 objects—if the work you’re doing could help boost it into the thousands that might really be remarkable.
i keep putting more and more work into this project. eventually i hope to use it as an all encompassing boiler plate for games i want to make…
anyway, i’ve now added my own z stacking algorithm and ability to use any 2D shader i find online (mainly from shaderfrog.com and shadertoy.com) maybe later on i’ll buy the shader pack from unity and see if i can import them into codea
as you can see, using a complex shader like this (it creates, draws, and moves around random circles with random colors) has a big performance hit, even with only 300 bodies and meshes we’re at 30fps,
hopefully C4 will have a massive improvement to this (fingers crossed)
@skar - very impressive, balancing features against the cost of using more advanced tech looks like it could be frustrating. Could you use this to simulate fluid flow?
Please keep us up to date with your progress.
@UberGoober i don’t mind sharing just keep in mind there’s still a lot of WIP stuff going on and i’ve reworked the Queue to just be a simple array but added an OrderedQueue which is like a hash table but with 2 dimensions that i use for z ordering
i’ve been working on this again and i now have time scaling working as well as a bunch of internal improvements that generalize the code more, as well as being able to drag and throw any body with a touch, still a lot of this is WIP especially around managing shaders but it’s getting really close to the point where i will have no excuse but to work on some actual gameplay
shows that the speed of frame animations and physics movements can be controlled with a timeScale variable that mimics the effects of slow motion and fast forward
)