Tokamak MAV due to FREEing RBs?
Blitz3D Forums/Blitz3D Userlibs/Tokamak MAV due to FREEing RBs?
| ||
| I'm messing around with more Tokamak stuff, currently I'm respawning ragdolls in a sort of Operation:Wolf style testbed, but after perhaps 1000 rigid body respawns and deletions I'm getting a MAV on the ADVANCE instruction. I've looked it up on the Tokamak forums and it appears to be the stacking bug when deleting rigid-bodies, and I think I've solved it using their method of adding a very small timestep advance before freeing a ragdoll, but can anyone (Sweenie?) explain how many stacked deletions cause it to fall over and if there are other methods of avoiding it? I want to try an mimimise the number of extra simulation advances that I need to keep the speed up. |
| ||
| Hmm, I haven't solved it - it's still MAVing at random on the advance command. Bugger :( |
| ||
| Ah, solved it again - seems there is another bug related to creating and then deleting an RB without advancing the simulation in between, which I was doing by accident. Removing that seems to make it better. Fingers crossed for no more crashes. I feel like I'm talking to myself here.... |
| ||
| I haven't used Tokamak for a long time now but I remember something about crashes when removing bodies. I think you had to make sure that a body hadn't been involved in a collision in the previous timestep before removing it, or something like that. |
| ||
| I have a 'big' tokamak system coded in my game. Sweenie, I have to say you did an excellent job with the wrapper, ... you are on my Credits :) It has happened a lot of time since I had a toka-bug, and it is working pretty much stable. One tip when working with ragdolls (or whenever you use Joints) ALWAYS delete the Joints BEFORE the RigidBodies, the next is INCORRECT: TOKRB_Free(RB) ;<- this is the RB connected with the joint TOKJOINT_Free(Joint) the next is the right way :) TOKJOINT_Free(Joint) TOKRB_Free(RB) ;<- this is the RB connected with the joint But, to make it better, in my code, after freeing the Joints I'm leaving the RBs alive for one more tick, and then I delete them. If you free a joint after the RB that are connected to it, sooner or later you will get a MAV at the TOKSIM_Advance(). This way, I have tested spawning and deleting more than 200 ragdolls and everthing work fine, no memory leak, no MAVs, ... :) Hope it helps! Paolo. |
| ||
| Thanks Paolo, I am already removing the joints first, but removing the RBs straight after rather than waiting for a while, but I've set it to remove the geoms a little bit before the ragdoll is deleted, thus removing any collisions from all the RBs. This seems to be working OK at the moment. Edit : I've just tried your method of removing the joints first, leaving the RBs alive for 1 timestep, and that seems to work also (so far), and is neater than removing the Rbs (which was leading to some dodgy spinning limbs) so I'll leave it that way for the moment. |
| ||
| Nope, it's still MAVing :( Back to removing the geoms first then.... |
| ||
| Ok, I forgot to say that I'm also DEACTIVATING the RBs before delete them... may be that could do the job... so basically: TOKJOINT_Free(joint) TOKRB_ACTIVE rb, FALSE TOKSIM_ADVANCE() >> wait 1 tick << TOKRB_FREE(rb) Paolo. |
| ||
| Nope, still getting a MAV, this time on the TOKRB_SetLinearDamping command when creating a new RB. This is damn annoying, renders Tokamak useless unless you want to create everything at the start - why the hell don't they fix such an obvious fault? Looks like I might have to go back to ODE. |
| ||
| Seems to happen only after a while, not straight away - the program needs to create and remove a total of perhaps 1000 RBs before the MAV occurs, even though they are all being FREEd correctly, almost as if there is some memory limit that can never be reset or exceeded even if everything is deleted. Humph, getting fed up with this now >:( |
| ||
| Doh, a quick check of the number of Rbs revealed that I had managed to create a logic system that allowed a ragdoll TYPE to be removed without removing the RBs associated, leading to a quick increase in the number of RBs active. Chanegd the logic and the number of RBs never climbs over 100, which seems to have fixed the crash. Silly me :) |
| ||
| This is damn annoying, renders Tokamak useless unless you want to create everything at the start - why the hell don't they fix such an obvious fault? I'm pretty sure that won't happen. It seems Chris & co abandoned Tokamak a long while ago. If you check the forums it's totally infested with spam. I think someone recently wrote a blitz3d-wrapper for Newton. If that one works I would totally recommend it instead. |
| ||
| Yeah, I've seen the forums, completely hacked. Shame really, I have found that generally Tokamak is much nicer to use than ODE. I've just tried Newton and quite frankly the so-called car physics thing is abysmal - a teflon car with teflon wheels driving on ice - woohoo. Anyway, seems I have solved the issue with Tokamak which was partly due to my crappy code, so fingers crossed it seems to be working at the moment. Sweenie, do you know how I can position a couple of reference objects at a joint's position (parented to the first attached object) to show the axes it works in for the 2 joint-limit parameters? I was thinking perhaps of a couple of very thin long cubes to show these axes, but I'm not sure how I would orient them relative to the parent object? |
| ||
| Normally you would probably just define the joint position and orientation in local space and then transform the position and orientation into the body's global space. This is simple with matrices but how to do it in Blitz3D with pitch, yaw and roll is probably not as easy. :( |
   |