Linepick and animated md2's
Blitz3D Forums/Blitz3D Programming/Linepick and animated md2's
| ||
| Does the md2 format suffer from the same problem as boned meshes. Say i fire a linepick at an md2, and it's in an animated pose, will it correctly hit the model, on it's current animation frame? |
| ||
| I think this is why I stopped using md2s a couple of years ago, because Linepick, EntityVisible() etc wouldn't work. Also very frustrating was the incorrect lighting from dx lights. Perhaps by now someone has found a way around these things? |
| ||
| Or perhaps by now md2 is completely out-of-date. |
| ||
| The workaround method I use for linepicking an md2 to get polygon perfect results is to use an additional camera, put it at your position where the linepick is from, point it at your md2, change the color of the md2 (to say bright pink), then read the pixel at the centre of the additional camera's viewport. If it is pink then you have hit the md2. Otherwise parent the md2 to a pivot if you don't care about hitting a specific point on the md2. |
| ||
| Huh, that's a clever trick. |
| ||
| Well, the reason i'm using md2, is it's miles faster than boned animations, and i'm planning on having a few md2's on screen. that trick might owkr, but i probably would need a render for each enemy on screen, which could defeat the purpose of using them for speed, unless i gave them all a unique colour... hmmmm... Thanks for that one matty! I take it md2's therefore, aren't considered meshes in blitz, and i'd need to use a pivot for collisions as well. Cheers guys :o) |
| ||
| Yes, you're right - md2s aren't meshes as we know them. I think when I did use them I parented a stretched cube to them (and alpha to 0) then the linepick etc worked on the cube. But as Joe says, yuk, isn't there another format you can use? I've been (badly) modelling in Milkshape, but the B3D export is good and seems very efficient. |
| ||
| Define "a few." That is, how many are you planning to have onscreen simultaneously? |
| ||
| I have tested the slow down of using boned meshes in blitz, over using md2 style animations. it's a hell of alot faster. I've got alot of things happening in this game, so speed increases such as this aren't to be frowned at. But for the sake of arguement, what other options are available, that use skinned meshes, other than b3d and md2, that can be animated? |
| ||
| I've been wrestling with this same question. There's a nasty catch 22 here. I did a stress test with 200 characters. Using B3d bones it was up & over 60 millisecs a pass. It's strange, just loading an object with bones with the loadAnimMesh command causes the slowdown. Even if there is no animation going on the slowdown exists. My second idea was to seperate the object into parts and manually rotate them to match the animation (this approach obvioulsy only works on segmented objects like robots :) ). The upside was I only had one loaded B3d anim. The downside was I now had a ton more objects loaded which killed the framerate. I dabbled with the idea of manually moving points but abandoned that approach as well. It might be do-able but I just don't think the framerate will hold up. As a result, MD2 became the defacto winner. The linepick thing is less of an issue for me since my game is a platform type and I can calculate collisions pretty well with just location checks. But the performace increase was major. My 200 character stress test had a millisec time which was nearly half of what the B3D anim approach was. So, unless someone can come up with a way to quickly manipulate lots of objects that were loaded with the loadMesh command... it looks like I'll be going with the MD2 choice. |
| ||
| Exact same situation here Dustin. I think i'll go with the md2's :o) |
| ||
| There's definitely food for thought here. Maybe I'll look again at MD2s when I need characters. Just another thought: I recently implemented one of the lens-flare libs, and I found that if it was a 'large level' then lens-flare could half the framerate. At first I thought it was the sprites etc, but by trial and error I found that the culprit was the use of a linepick every frame which determined if the sun was hidden behind a building. Worth knowing. |
| ||
| The longer the range of a linepick goes, the more time it takes. |
   |