Animation and collision
Blitz3D Forums/Blitz3D Programming/Animation and collision
| ||
| Hi, I have some chests in my game. You can jump on them and the collision works perfectly (it's of type 2, meaning sphere-to-polygon, the player using spherical and the chest using polygon collision). You can open the chest, this is using bones. The lid turns 90 degrees and stays open. And this is causing the problem - now the player can jump trough the lid. I'm guessing blitz is still using the original unanimated mesh to do the collision detection, but I could be wrong. Anyway, is there a way to fix this? Thanks! |
| ||
| I have had the same problem and would also be very interested if there is a fix for it. I have spent many long hours trying to figure it out but quite unsuccessfully i must say. Sorry i couldnt help you fall_x. |
| ||
| One solution would be to replace the entity with an opened version when the animation is done, but I would prefer it if I could keep it dynamic - I don't want to create more models than necessary (especially because if I change the chest, I would have to change the opened version as well). But if no one knows of a better solution, I'll do it like that. |
| ||
| The only thing I can think of is surrounding the chest with an invisible box or cylinder and collision-checking THAT... it wouldn't be exact though. Or, you could do the animation manually, by creating seperate meshes for the lid & the bottom of the chest, and then rotating the lid. If I may add, collision checking with animated meshes is a complete pain in the rear end. I've NEVER done it sucessfully. |
| ||
| Will it work if you make the chest out of 2 boxes instead of 1? That way you can have a seperate entity box around the lid and base. So when the lid opens it is not outside the collision area. |
| ||
| I had the same problem with doors... I had a door that I animated OPEn with bones... That way it could open and close... I had to use PIVOTs instead... AND delay so it would not open too fast. -RZ |
| ||
| Actually, the potential of this problem is quite scary. So it would seem that Blitz only keeps the original shape for collision calculations? The ramifications of this for anything more than a shoot-em-up are quite significant. I hate the idea of Blitz coders have to crowbar new methods into their games, where in fact Blitz should already be taking care of this. In the future I will also need opening chests, opening doors etc, and did intend to use bones. If I now have to attach a pivot and specify no. of degrees, which axis rotation, how long for etc, then uurrgghh. |
| ||
| If you make the door in Rhino you have to put it with the HINGE EDGE on the axis... I have made a few models and posted them on my site: http://www.silverimports.com/web3ds/ You can simply click that link to access... the adoor.b3d is animated. Most of them are 3ds files... -RZ |
| ||
| could it be this simple? ________ |________| | | Closed chest. Collision box is roughly | | chest sized |________| ________ _________|________| | | Open chest. Collision box is roughly | | chest sized therefore player can move through |________| the lid Solution - Resize and reposition the collision box so that it encompases the chest + the lid? |
| ||
| @Rook: 1) Are you saying that your door's collisions are as they should be - i.e. you _can_ collide with the door when it's open? 2) Nice models! Can we help ourselves? :) |
| ||
| I think my solution would be to not give the chest/door geometry a collision value, but attach an invisible cube and move/resize it when the door/chest is opening/closing. You may also need to move the player back until the process is finished |
| ||
| John it is worse than that. I used adoor1.b3d there on my website. I also had it as pickable and collideable... pickable so it could be opened and collideable so if it was CLOSED you could not just walk through it. Everything was great until I clicked it open and it swung open like in my animation... beautiful... but I could not walk through it. The doorway was clear but it was still blocked by the door. I eventually used an idea like the one presented by madjack... I just had to check if the door was open or closed... IE what frame the animation was on. I did that by a flag... -RZ |
| ||
| As I mentioned in an other thread, for such things without vertex deformation, you can use the 3DS or X format. You only need to apply Collision to the children, they will be handled as individual Meshes. Only when you use B3D, blitz will use the Vertex positions of the initial pose. There may be some Apps other than 3DS Max that are capable of exporting animated 3DS, I only know CharacterFX. Maybe blender or truespace can do this as well, I don't know, any ideas? |
| ||
| Thanks jfk, I'll try it when I get home from work. I use milkshape, I don't think it can export 3ds, so I'll use a .x file. Just wondering, is this documented in the Blitz help? Or is it something you found out by trial and error? |
| ||
| Ok, this is weird. I opened my model in milkshape, exported as a directx file (with the "dirextx 8.0" option, but I also tried "directx jt", whatever that is), and then my chest was very tiny - so I scaled it 10x and it was correct - however, there's NO collision with it! So it displays corretly, only ten times as small, and I can't collide with it. What should I do? |
| ||
DirectX 8 surely won't work since this is the bones-x format that Blitz doesn't support. "DirectX JT", well this is rather strange, never heared of that one, but what you need is DirectX 7. Well, "7" looks a bit like "jt", maybe it's your glasses or the monitor :P. Wrong scaling is easily possibe since many apps are not very precise when it comes to format implementations. Anyway, if your .X is animated, then it will have a hierarchy. You will need to apply collision to all children in the hierarchy, recursively! Use a function like this:Function EntityAnimType(m,ty) If EntityClass$(m)="Mesh" EntityType m,ty Endif For i=1 to CountChildren(m) ww=GetChild(m,i) EntityAnimType(ww,ty) Next End Function To apply a Collision Type Number to all Children in the hierarchy, eg. mesh=loadAnimMesh("thing.x") EntityAnimType(mesh,3) collisions 1,3,2,2 But you need to use an Animation that is compatible with DX7, that is based on Rotation, Scaling and Moving of Mesh-Children only. No Vertex-Deformation or Bones allowed here. It was a logical conclusion of the way 3ds and X Animation work. It was more trial and error when some people realized that it's NOT possible to get the collisions right with animated .B3D. you'll get Collsion and LinePicks, but only on the initial pose. this may look rather strange when the bullet decals are floating in the air while the enemy is falling down on the floor. O_o |
| ||
| Well this is quite a mess.... @fall_x: Can I suggest that when you have finishewd your tests you pass the results to Blitz Support with a request that changes are made to the collision system for the next release. Thanks for all the work you've done so far. And thanks to jfk for the possible solution involving setting each child's collision. |
| ||
| I haven't tried this yet, but a simple solution for doors would be to create them as a seperate entity, and parent them to the bone of a mesh (the house, for instance) that contains the animation for opening it. That way, they should follow the animation of that bone, but you will be able to collide with it correctly. Just an idea. |
| ||
| Hang on... Ideally one wants to create a door containing a bone, then rotate the bone (like a hinge), 'recording' the animation (I also use Milkshape, so in the future I'll be trying to do what you're doing). Do you mean to say that by this method you end up with an open door that you can't walk through? Is a mesh's collision area _not_ updated as it moves? |
| ||
| Either you didn't understand my post, or I don't understand yours ;) All I was saying was this (and I didn't test it but I'm pretty sure it should work) : Create a house without the actual door, but do include the bone for the door and add the opening animation to this bone. Create a seperate mesh which represents the door. In blitz, loadanimmesh() the house, and loadmesh() the door. Parent the door to the bone in the house. The if you start the aniumation for the house, the door should move with the bone. I believe since this is an actual mesh that is moved/rotated, you will collide with this as you'd expect. |
| ||
| Well I really wouldn't load a house with a door animation because all you can do is "playing the door". Alternatively I'd save the house with no door meshes at all, and no animation as well. Then I'd make the Door (probably with a frame) a seperate mesh that is loaded additionally and positioned in the house. Now it's up to you if you use a 3DS Door Animation that can be used directly, or as fall_x suggests, a Bones animation that does not contain the door Mesh, but a Door Bone with a certain name (eg. "add_door_here"). WIth fall_x's method you would then load a simple static door mesh and parent it to all door bones. You could then play the Door Animations, but the Door Mesh would be an individual static Mesh with it's own Collision Settings. Nevertheless, you should notice that when you use a swinging door and when the door swings towards a walking player, the player may walk right trough the Door Mesh. I solved this problem by adding an invisible box to each door, and when a door is in motion I check the box with Meshesintersect against the player, and if they intersect then I pause the door-opening animation. |
   |