Random Arena Wars

[unborn wharf]

hi, this is my first time posting in this server, i really needed a place to share this project and talk about it, please let me know if it's not appropriate.

It's vulkan/c++20 game in arena style multiplayer, thematically it's incoherent at the moment i thought id finish the game logic first. all the models can be replaced with any model in a glb file with atleast 1 mesh and a skeleton with atleast 4 actions preferably in this order:[attack,death,idle,run], since the models here are only placeholders as i wanted to stress test my engine with models that have multiple meshes,alpha layers and more than 256 joints.

i started working on this project a month ago because i wanted to learn to use the vulkan api, the project is an absolute mess atm, but im working on it everyday and im also making things up as i go.

libraries used:
• fastgltf (incredibly fast gltf parser)
• imgui (mainly for debugging)
• glfw (simple cross platform api to handle the windowing and events)
• stb (for loading textures)
• simdjson (needed for fastgltf)
• glm
• valve's gamenetworkingsockets (simple enough to handle networking efficiently)

game logic is currently a total mess and 60% of the features arent implemented yet. but if u want to run it yourself here's the link.

binary downloads (google drive):
windows
linux
• fastgltf and gamenetworkingsockets libraries have to linked first for linux

I'd love any feedback/help/ridicule/suggestions if u have any please feel free to tell me.

[unborn wharf]

i stress tested models because i feared the animation calculating/blending and applying slows down the frame rate alot which was true so i tried a couple different things, i tried to memoize the node matrices but it takes too much memory for little benefit maybe i did it poorly, but i experimented with different approaches aswell, i tried offloading the matrices calculations to a parallel thread but it was too glitchy as the drawing rate was faster than the matrices were upading so alot of frames were rendered with t-posing models because of the way i update the matrices maybe storing multiple vectors for the matrices would be helpful but i havent experimented with this yet, i tried syncing the threads with a mutex but that wasnt much improvement as they still slow down the frame rate, and finally i settled for updating/blending the animation every odd frame and applying it to the nodes/joints recursively every even frame so they alternate which improved the frame rate by a lot more than i thought it would, maybe i could upload the entire array of local node matrices and the node number as an ssbo to a shader that does the recursive calculation every frame maybe could be better, ill have to test this next. I could also just drop the whole each instance has its own animation but that'll lose on death animation and maybe the running animation would look too in sync as all instances would have the same animation.

[ebon oracle]

neat

You should not multithread things like animation on a different timeline than your engine though

If you want to thread pose calculation you either need to run it in parallel with other systems and sync before rendering, or you need to dispatch a thread pool on it and wait for it to sync

This could also be done in compute

[unborn wharf]

yea i havent thought about compute for the animations that's smart

[unborn wharf]

sourcecode

[unborn wharf]

sorry for late ping but how would this be done in compute i tried again doing it but most i can do is use the cpu computed bone matrices to skin the verts in compute before the vertex shader gets them but that already required the final bone matrices which are calculated recursively on the cpu because of how parent child bone nodes work idk if there's another way to do it from a gltf file.

[ebon oracle]

Gltf doesn't really impact how you implement any of this, you can do whatever you want with the gltf data

What you described is the normal way of doing compute skinning, usually you still do the posing on the CPU

Since you want to be able to pose stuff programmatically

[unborn wharf]

but the pose calculation is the slowest part

especially when i have 200+ different models/instances each with a couple hundred bones doing their own animations it becomes the one thing slowing down the whole process

makes me wonder how 3d games with swarms of stuff did it so efficiently

[ebon oracle]

Couple hundred bones is insane, games with a bunch of characters are only going to have like 20 bones

[unborn wharf]

i tested this with models from world of warcraft and overwatch they do have alot of bones for some reason

[ebon oracle]

Wow might have more for your own character than for others

Anyways

Are you talking about computing the skinning matrices or the pose itself

[unborn wharf]

no, the pose

which has to be done almost every frame from delta time correct?

[ebon oracle]

Yeah but if you're just playing an animation straight then it's essentially just a memcpy

[unborn wharf]

like ignore the interpolation type from the file and just do step animation for all?

lol i didnt think of that

[ebon oracle]

You can add interpolation on top if you want but that can be fairly cheap especially if you are lazy and just interpolate components

I think I'm mixing up this thread with another one, I didn't see my own messages I expected above

I thought I told you in the past to eliminate the recursive structure of the nodes

Maybe that was someone else though

[unborn wharf]

yea

idk how i would do that

[ebon oracle]

Mathematically

You'd just put all the transforms into rig space

Rather that bone local space

[unborn wharf]

yea i thought if that was possible id be able to just put it on compute easily

[ebon oracle]

That way you pay the expensive cost (transforming into and out of bone-local coords) when you programmatically pose the rig but otherwise it's very cheap

[unborn wharf]

but i couldnt figure out how to flatten out the bone structure yet

[ebon oracle]

It's just a change of basis just like what you already normally do when computing your skinning matrices from the pose

[unborn wharf]

alright ill look into that, tyvm

[unborn wharf]

just to be clear, u dont mean making a dispatch call for each layer of parent child nodes because i think that would be too many dispatch calls and even worse performance correct?

[ebon oracle]

I was talking about just flattening the transforms on import

that would involve doing the same for the animation tracks too

and then at runtime you'd just apply a single animation pose matrix directly to the bone without needing to consider its parent

Hm now that I look at my animation code though I do see some evidence of the parent in there

so maybe I'm spreading misinfo

My joints are just updated in order I think