Climbing Bug
Blitz3D Forums/Blitz3D Programming/Climbing Bug
| ||
| Hi, a long time lurker here. I need some help and ideas for a bug in my game prototype. Video is linked below. It's a third person action RPG, a bit of mash of Zelda and Jade Empire. Please forgive the temporary models and animations ^_^; As you can see, whenever the kid climbs up a ledge, he temporarily disappears. I didn't add a small version of code because editing a video is easier for me (I'm lazy that way). I could work out the code; what I need are more ideas on what might be causing this graphical glitch. Notes: -It happens only when the camera is very close and at level or lower than the player mesh model. That's why I added a workaround where the camera pulls back whenever he climbs. But the bug is still there, the you can see it if you happen to force the camera to a close in. -I'm pretty sure that the model actually disappears rather than getting displaced out of view. The broom in his back (long story) is attached to a bone in the model's spine, so if it gets displaced, the broom should follow it where it goes, shouldn't it? -It's not the camera range, and I've tested it with very low Near values. -If you must know how the climbing system works: The game detects whether the PLAYER CONTROLLER has collided with the level mesh, checks if the collision normal is 90 degrees upright, i.e. a wall, and if the PLAYER MESH is facing that way. The game puts an invisible sphere, way above and ahead of the PLAYER MESH, and drops it down until it hits the ground. If this sphere is at the right height above the PLAYER MESH, the game will allow the climb. At button press, the climbing animation is played (its canned, that's why the heights are fixed). The camera is then set to parented to PLAYER MESH (instead of the CONTROLLER). At the end of the animation, the game checks the x/y/z position of a PLAYER MESH's base bone, repositions the PLAYER CONTROLLER there, then resets the animation to idle and resets the camera back to the PLAYER CONTROLLER. That's why there's a very slight hiccup after the climb. I'm just out of ideas of what could be the reason for this. Thanks in advance! http://youtu.be/8nZ_nluFHf0 |
| ||
| Absolutely no idea ... Just some way to track the bug : Add a controll key to Stop the loop on keyhit create a simple stuff to create another camera (not the same, keep the scene original) and look the same scene with the debug camera. Like this you'll know if your model "disapear" from the camera because of the camera or because of the model. Second debug thing : create a type to store the full animated structur at each loop, store ALL positions and test the distance from the current positon to the old position. if it's "far" when the model disapear, it's that your model is bugged (in the animation or somewhere else, but it's a start) To be honnest, not sure, but I think about a "Frustum" bug. You have a main pivot (where all your player is attached) and your model is not centered on this pivot. On the renderworld, the pivot comes out from screen, and blitz hide it from rendering (so as the model) If it's a frustum bug, you'll notice it with a second camera. |
| ||
| This looks like Renderworld() thinks, that the model is already "behind" or "below" the camera's field of vision. In the video the figure always is depressed in this moments and the camera rises to a higher position. This might cause that the object in total is "deep" enough to be "out of vision" I would say, the model and/or the camera have pivots, that are not "in the center" of the figures. Or the handles of the entities itself are not at their middles. Check the distance between camera and figure with DEBUG commands. Write a "test situation" where you can rise the camera slowly, while the figure keeps ducked. Replace those invisible pivots with visible "Cubes", so that you can see them for a while. Often the dimensions of these pivots are not as exepected! Replace the figur with a "Cube", so that you can see its center for a while. Add a cube to the camera too! |
| ||
| I like games with jumping and climbing :) What i would do is to attach one separate cube to each bone in order to see if the skeleton is still here and is animating properly. Then i would try to add one separate cube (surface) to each bone inside you modeling editor and try again. the climbing animation is played (its canned, that's why the heights are fixed). If Blitz3d considers that the bounding box of the mesh is the TPose of the mesh, then if you move the bones and vertices of the mesh up when the character is climbing, it means the TPose mesh is out of view. So a way to avoid this is to move the origine of your mesh (the Parent bone) with the character or to add some hidden vertices childs of the parent bone at the maximum width, height, depth that your character can move. This way it will increase the size of the bounding box. |
| ||
| If Blitz3d considers that the bounding box of the mesh is the TPose of the mesh, then if you move the bones and vertices of the mesh up when the character is climbing, it means the TPose mesh is out of view. I think this is the reason, as others have said above as well. As you may have noticed when animating your character, the bones deform the mesh but the mesh's "pivot" or "peg" in your animation software remains still. Blitz3D guesstimates your character's bounding box based on the first pose of animation. When you're climbing, the pivot probably stays on the ground, and the bounding box goes out of view even though the mesh still is visible. With that farther-away cam like you're doing right now, the bounding box may be visible by some amount and that's why the character doesn't disappear. The command you can use to fix this is MeshCullBox(), setting an astronomically big cullbox size (since you'll always want your character to remain visible\renderable). PS: Nice game demo, it looks polished. PS2: To fix the hiccup you might animate the character jumping, climbing and falling "in place" (in other words, the mesh doesn't move away from the pivot). Then you move him only by code (since you know which height he has to get to etc.). This way the controller always remains at his feet and you don't have to rearrange things. |
| ||
| Blitz3D guesstimates your character's bounding box based on the first pose of animation. To be accurate i think it is the pose of the rigg, not the pose of the first frame of animation. But i guess it is what you meant. |
| ||
| Hmm, it's the mesh pose as it is described in the file's geometry section. This is up to the exporter. Most exporters take the first frame of the active timeline and write that as the mesh's geometry info. Then when loaded it looks like it's in the first frame. But the static pose (in the mesh description) and the first frame can certainly be different - you need to see in your exporter how you'd change that (it's usually in the frame-range export setting). |
| ||
| Hey, sorry for the delayed response guys. Got caught up in our local holidays (Catholic Holy Week). I think you guys not only gave me an idea of how to tackle the bug, but also the weakness of my climbing system - it's too fixed! And Kryzon, i'd like to try that MeshCullBox() thing you suggested, but Blitz can't seem to identify it and i can't find it on the manuals? I'm trying to come up with a more flexible climbing system, probably by raising the player controller near the edge of a ledge, then afterwards initiating the climb animation. Hopefully, it wont look to jerky. Thanks a lot guys! I'll post whatever i come up next. |
| ||
| Update your Blitz3D :) Account tab at the top of this page -> Product Updates -> Blitz3D v1.106 It'll add the MeshCullBox() command among others, but you still won't get the docs. You can search the forums for some discussions on this command. It's worth the effort, it'll solve your visibility problem. I'm trying to come up with a more flexible climbing system, probably by raising the player controller near the edge of a ledge, then afterwards initiating the climb animation. That's a great idea, I hand't thought of that. With this you can animate the mesh in your modelling software like this: on the first frame of the climbing animation the mesh is moved below the origin, leveling its head with the origin. Then you animate the character climbing back up, to return to the original position (with the origin at its feet). The moment you play this in your game you have to move the controller up by the same amount that the mesh is displaced downward in the climbing sequence, so the mesh stays in the same place, and is simply climbing up to the controller. For this, you'd do a.. TranslateEntity player,0, controllerHeight, 0 Animate player,[...],climbAnimation ...when the sequence finishes, the character will have the controller at its feet, and will be on top of the platform it was climbing. |
| ||
| Yeah, I'm thinking of the same thing, playing around with several ideas on how to do it -- either start the player below the origin as you said and follow it, or start it on the origin then just track the new position of the mesh's root and then reposition it there. Thanks for the tip on update, downloading it now. Never had any problems with Blitz before so I hadn't felt the need to update! Right now, the I'm still working on the timing and animation of raising the player controller to the ledge and making it look like he jumped instead of looking like he flew up there :-D |
   |