How much do bones slow things down?
Blitz3D Forums/Blitz3D Programming/How much do bones slow things down?
| ||
| Maybe someone has some info, or more preferably actual tests and calculations to tell me how much do bones within b3d files slow things down? I haven't had any experience with massive scenes yet or anything, and I didnt find any other forum topics covering this, so I'm interested. Is there a big difference between having 20 characters on screen when they have 10 bones each compared to when they have 20 or 30? It should slow things down to at least some extent since bones influence vertexes which need to be calculated real-time i suppose. But then again i obviously don't know b3d format well enough :) |
| ||
| don't know, but it probably has more to do with how many vertices those bones are transforming. I doubt the bones themselves are that expensive. |
| ||
| ok. I'm writing this and i didnt even test it myself! I guess i might do that in the next few days and post some results. I also hope that b3d can recognise how 'baked' vertices are so that joins appear smooth. I am just clueless ain't i! |
| ||
| heh, I'm not a coder but an Artist so I can't help to much as far as coding. But BLitz does now support vertex weights, whick blennd the influence of a vertex between bones giving you the smoothing I think your talking about. You can have Rigid or weighted vertices, the weighted ones are going to be more expensive though. And if your using freeware and shareware modeling tools, it might be tricky to find one that does weights. |
| ||
| Bones slow everything down, A LOT. Use the fewest number of bones possible. |
| ||
| Yeah, use md2's if you can get away with it :o) You don't even need to animate the entity. Bones will slow things down, even if the entity isn't animating. |
| ||
| hmm interesting about the non animated bones slowing things down. So in my car game, would it be worth having a single bone for the rear axle that drives both rear wheels? rather than one each? that way with 8 cars you have 24 bones instead of 32 in the game at any time. Currently Jeremy has wheels that are children to a bone, and he rotates the bone in code to rotate the wheel. Probably woudl have been better to have a node that positions the wheel and then rotate the wheel entity, but I'm no coder so maybe there's a reason he didn't do that. |
| ||
| Can't you just forget bones and do the same functions to a Pivot? I don't see why you need bones for a car game. I'm not using any in my car game. I just link things together with Pivots. Although, interestingly, maybe a car with bones could allow you to do some interesting things like mesh deformation in a crash... |
| ||
| please don't get mixed up with bones and hierarchical animation. A car would not have "bones". It would merely have keyframed hierarchy. If you're exporting the car with the skin modifier and it's a boned mesh then thats a seriously slow mistake. If you're exporting the car as a hierarchy then thats the correct thing to do and will not slow your game down. Certainly you will use one surface per wheel, but blitz does do minor optimisations and it's nowhere as bad as if each wheel used a different texture (!). |
| ||
| Bones slow everything down, A LOT. Use the fewest number of bones possible. Ok thanks halo, i trust you know what you're talking about. I reallllly have to use bones for character animation. Tho i could use the old system where arms and legs actually go into the torso, they end there, and their pivot is in there at the top, but the animation will be visibly worse. Dont wanna go there... |
| ||
| It's not doing mesh deformation. Or at least that's what I wanted. I simply wanted a hierarchy where I could manipulate children. I didn't export the model so actually I couldn't tell you how Adrian assigned the wheels to the bones (which are really just pivots when it comes down do it, unless you're doing vertex animation). Anyway, we had a demo last year and the max number of animated characters we could have at once was about 25. Not sure how many bones each one had but I'd guess they each had 5. After 25 of these things the game would really get slow. |
| ||
| Yes, please mention bones when talking about mesh deformation :) |
| ||
| heh yeah, ok Just checking as it sounded earlier on that bones regardless=, slowed things down. We simply have a wheel as a child to the bone, no vertex assignment. I just got a bit concerned by one of the earlier posts. |
| ||
| That only is a seperate object issue. Here is the lowdown: 4 wheels with 4 different textures = 4 surfaces and more changes. 4 wheels with 1 same texture = 4 surfaces with less changes. So it's not that bad! :) |
| ||
| yeah, I think we may go back to Instanced wheels via copyentity since jeremy modified the extension a little. It seemed to work before but its off for now, still thats a real good point, with 8 cars we will have 32 surfaces just for wheels, the way it is now lol, will have to talk to jeremy about that . Anyway don't want to steal the thread anymore :) |
| ||
| Sorry guys, but I don't understand why you need 4 surfaces for the wheels. Can't the wheels all be part of the same surface? I don't see why not. Maybe a little more work but I'm sure it can be done. In fact, if you got really crazy, you could have EVERY tire in the game be part of the same surface. I wonder if their would be any speed advantages to doing this? I'm currently (I think) using four surfaces, because I haven't optimised anything yet and am just creating four seperate entities (cylinders) for the tires in my current racing game. |
| ||
| Do you have trouble rendering four tires at a good speed? |
| ||
| Even a simple 32 sided cylinder for a tire requires 128 polys per tire, 512 polys per vehicle. It can add up, especially if you have more complex tires. At the moment I don't have any speed issues but near the end of my project I may be looking for things to tweak to get that extra ounce. |
| ||
| We're not having speed issues yet ... but all this talk is worrying Ad a little as he wants to keep it as optimized as possible and really why not? How would you make each tire part of a single surface? Wouldn't they need to be part of the same mesh? |
| ||
| yeah, I think we may go back to Instanced wheels via copyentity That only saves on memory, nothing else. |
| ||
| I don't think 4 different surfaces for each wheel, is that big a deal. 5 surfaces per car. Say 7 cars, 35 surfaces. I don't think that too bad at all. |
| ||
| After 25 of these things the game would really get slow. What was the polycount on those, do you remember? This doesn't sound good.. :o( |
| ||
| well surfaces make a difference on low spec systems, so if your targeting sub 500mhz CPU's with Geforce 2 or lower cards, its an issue. |
| ||
| I actually meant vertices. More vertices for a given bone to push means heavier calculation, so if each 5-boned mesh had 200 polygons then deformation would obviously be faster than 2000 because of the also lower vertex count, not taking into account the render speed for the surfaces themselves. That's why I'm interested in the polycount. Hope I'm making sense here. |
   |