orxObject_ApplyForce weirdness

edited November 2012 in Help request
I'm trying to add simple forward, turn left, turn right info to my Missile class (BTW, I'm using Scroll now -- all is well).

I have some very weird behavior.

My object starts out pointing right (angle 0). If I press forward, it moves forward.

After rotating the object and then pressing forward, the object sort of gets "stuck" going that direction. Actually it seems it gets stuck going what amounts to a cumulative affect of how much it moves in a particular direction.

You can stop pressing forward, rotate to a new direction, but when you press forward again, the object "snaps" back to the original angle.

The body of the object is a basic rectangle, no frills. I have the angular and linear damping turned up to keep things from getting crazy, but it does the same thing without damping.

I've tried a _LOT_ of different things, such as originally passing NULL as the 3rd argument to orxObject_ApplyForce. Passing in the center of mass as the apply point made no difference.

I'm missing something fundamental here.

I've implemented something similar using Box2D and Pyglet in Python, and it worked as expected.

The relevant code section is here:
orxBOOL Missile::OnRender()
{
	static float forwardLast = 0;
	orxFLOAT torque = .004;
	orxVECTOR forceBase = {.1, 0, 0};
	orxVECTOR force = orxVECTOR_0;
	orxOBJECT * o = GetOrxObject();
	orxFLOAT rot = orxObject_GetWorldRotation(o);
//	orxFLOAT rot = orxObject_GetRotation(o);
	orxVECTOR pos;
//	orxObject_GetPosition(o, &pos);
	orxObject_GetMassCenter(o, &pos);


	if(forward) {
		orxVector_Mulf(&force, &forceBase, forward);
		orxVector_2DRotate(&force, &force, rot);
		orxObject_ApplyForce(o, &force, &pos);
		orxLOG("Rotation: %f Force: %f %f %f Ang Vel: %f",rot,  force.fX, force.fY, force.fZ, orxObject_GetAngularVelocity(o));
		orxLOG("Position: %f %f %f ",pos.fX, pos.fY, pos.fZ);
	}
	if(left) {
		orxObject_ApplyTorque(o, -torque);
	}
	if(right) {
		orxObject_ApplyTorque(o, torque);
	}

	return orxSTATUS_SUCCESS;
}

Comments

  • edited November 2012
    Can't see anything obvious right now, and as I never use torques/forces myself I'll have to test your code later on.

    One remark though: it's not a good idea to put any logic in OnRender() calls as you don't have access to the DT and your update is made in the wrong frame. It's better to keep any logic code in the Update() methods instead.
  • edited November 2012
    I copy/pasted your code almost as is (all I changed was to query inputs instead of your forward/left/right values) in an object Update() method and didn't notice any snap back to original rotation after doing the sequence you mentioned.

    My object behaved as expected, though it oscillated a lot when I applied both a torque and a force as I didn't have any dampening factors, but that's about it.

    I suspect your problem lies somewhere else. If you could post your whole test project, we should be able to find the issue more easily.
  • edited November 2012
    Actually, I was in a special case, so it worked for me.

    However I found a 4 years old bug on ApplyForce/ApplyImpulse that got partially fixed 9 months ago (not sure what happened and why the fix wasn't complete...).

    I think I just fixed it for real this time and if you pass orxNULL as the application point of your force, no torque should be generated anymore.
  • edited November 2012
    Sorry for the delay.

    I did an hg pull on orx; there were some updates, but I didn't see any code changes, unless they were in the plugin for box2d.

    Nothing I do on this end seems to help.

    I looked at my old Python code, and it turns out I was using applyImpulse there, but orxobject_ApplyImpulse seems to have no effect whatsoever, even using an impulse vector of 2 billion.

    I'm going to send you a zip of my source dir, maybe you could take a look?
  • edited November 2012
    The code changes are in orxObject.c, orxBody.c and the Box2D plugin, orxPhysics.cpp.

    Just got your project and I'm about to test it against the latest version of orx. I'll let you know what I find.
  • edited November 2012
    So, I made a windows version of your project and here what I found:

    - it asserts upon quitting as Missile::OnDelete() is not overridden, you might want to fix that ;)
    - everything works fine with the version I made last night, I can steer the missile and it behaves nicely :)
    - orxObject_ApplyImpulse() is indeed not working as it is because the linear velocity gets overridden during the physics update (evil necessary sub-step to allow hierarchy of objects to support physics for children), I'm going to fix that tonight.

    When you test on linux, make sure you locally use the v2837 of orx hg, that's the one containing the fix for orxObject_ApplyForce().

    If that's already the case, it might be a linux-specific issue but I'd doubt that, the code path with respect to physics is the same regardless the platform.
  • edited November 2012
    Ok, fixed the ApplyImpulse, worked fine in your test case.
    Let me know if everything is ok for you after update. :)
Sign In or Register to comment.