Optimising performance of rigidbody type rigs on mobile (e.g. a car)

shanemarks

when creating rigid body style character set-ups (e.g. a car) for mobile platforms which of these two approaches would be better:

Import the model as seperate pieces (lots of drawcalls) and setup the rig

OR

Merge the mesh into one piece (so 1 drawcall assuming one material) and then skin it to a skeleton which would be driving either by animation or physics.

Any input would be greatly appreciated! I am tending toward the latter as it also means that the rig set-up is independent from the mesh keeping things a little more modular.

dislekcia

I would probably look at setting up the mesh the second way for most of the game. Then when you crashed or something, replace it with related meshes and have them interact on their own... I'm not sure what the performance implications are for mobile specifically, that depends on what's taking the most time - your draw calls, your physics calcs or your vertex data changes for skinning. Those vary according to the exact game situation.

shanemarks

Hey thanks for the reply -> Good idea re: mesh replacement, I would have (@Elyaradine) used that same sort of approach for film animation too, it just never occurred to me that the same thing would apply in a game.

Nitrogen

I dont have any experience with mobile unity, but it sounds like having a single mesh with skinning skeleton is going to be messy. The game is going to have to modify each vertex of the wheel to make it go up and down instead of just translating a single object every frame.

If you are aiming for mobile, your mesh should be pretty simple anyway - a body and 4 wheels I'm imagining. And if you keep the same material for all, but still separate them out into separate objects, I think that would be best.

Elyaradine

shanemarks said:

I would have used

Pet grammar peeve fixed! :D

--
I just want to emphasise that I don't think that there's a correct, generic answer here. What's best for you is highly dependent on loads of other factors in your game.

For example, if your game involves many, many cars in a race, then if each car is using skinned mesh renderers then each becomes at least one draw call. In that case having your cars be made up of many non-skinned meshes, assuming dynamic batching kicks in, can let you get away with much fewer draw calls. Alternatively, if your cars have a lot of verts, then dynamic batching might not kick in. (I'm not sure what the numbers are now, but the last time I checked the docs it was >300 verts, up to a max batch size of 1500; this is kind of suspect though, as I believe I've recently been able to dynamically batch much more than that...) Or perhaps you run into memory problems, and dynamic batching duplicating all of your meshes in memory is too much for you to afford. There's a lot that can sway which method is better.

What you might try is to set up a null hierarchy, as if you were going to skin the car, but then instead of skinning you parent everything instead. That way you can test both methods on your mobile device with minimal redoing of work (it's super easy to skin hard surface meshes), and see which actually performs better yourself depending on what you've got going on in your game.

shanemarks

Thanks Elyaradine. I only saw this post now. You raise a good point re: the null hiearchy. That makes a lot of sense that way I can simply switch between the two setups to see which will work best.


As it stands there will be a few but fairly detailed cars, which is why I opted for the skinning approach in the first place - I want to get as many verts as I can in one go to the graphics card. I have always found dynamic batching to be a little bit hit and miss, depending on how unity feels on the day (also, AFK, objects that are animated don't batch?).

If I have time over the weekend I might do some tests with a dummy hierarchy to compare how each set-up performs on a mobile and post it up.