# crashlander

Members

17

122 Neutral

• Rank
Member
1. ## Apply Torque At Point Other Than CM (@Joint Anchor)

UPDATE: It's all working perfect now. I just apply the torque to normally and all is good! @grhodes_at_work. Thanks for your help!
2. ## Apply Torque At Point Other Than CM (@Joint Anchor)

Here is how I apply torque in my Rigid Body system: (trimmed down to just the guts) public float AngularAcceleration { get { return _torque / _momentOfInertia; } } every loop: ... //angular velocity dw = AngularAcceleration * dt; _angularVelocity = _angularVelocity+= dw; ... //angle orientationChange = _angularVelocity * dt; Orientation = _orientation+ orientationChange; The torque I calculate from my Angular spring would be applied directly to the _torque parameter. The _torque parameter is zeroed out every loop.
3. ## Apply Torque At Point Other Than CM (@Joint Anchor)

Very interesting. So lets see if I undertand this correctly with respect to my main goal: Implementing an Angular Spring. My rigid body system already knows how to "ApplyTorques" by integrating about the center of mass. For the AngularSpring system I compute a torque using the formula: t = (SpringConstant * AngleOffset - DampningConstant * AngularVelocity) At this point, I assumed I had to apply the torque, t, at the anchor point of my hinge joint and this is what was confusing me. Are you saying I can actually just apply the torque, t, like I do all other torques, by integrating about the center of mass? Btw, my joint constraint is implemented using sequential impulses per Erin Catto's Box2D paper: http://www.gphysics.com/downloads/ So far all the responses have been very helpful. Thanks.
4. ## Apply Torque At Point Other Than CM (@Joint Anchor)

Ok, then this is where I'm confused. Do I integerate about the anchor in ADDItION to my normal integeration about the center of mass? Or does integration about the anchor replace my normal integration about the center of mass. Seems like I'd need to do one or the other else they would conflict with eachother. What happens if I allow an anchor/joint to "break". Do I then go back to integrating about the center of mass? Thanks for you help on this.
5. ## Apply Torque At Point Other Than CM (@Joint Anchor)

So then I needed to keep track of a second AngularVelocity about the anchor? Here is how I integrate about the center of mass velocity: dw = AngularAcceleration * dt; _previousAngularVelocity = _angularVelocity; _angularVelocity = _previousAngularVelocity += dw; rotation: orientationChange = _angularVelocity * dt; _previousOrientation = _orientation; Orientation = _previousOrientation + orientationChange; You are saying I should use this same type of logic for each anchor? I can look into doing that.
6. ## Apply Torque At Point Other Than CM (@Joint Anchor)

I'm having diffuculty with what seems like it should be a simple problem. I have a standard run-of-the-mill 2D rigid body system. I can create bodies and apply forces and torques and all is good and working properly. To this point all the torques are applied at the bodies center of mass. Now, however, I've created a 2D revolute joint (essentially a hinge joint since it's in 2D) and I want to create an Angular-Spring that acts at the anchor point. I can calculate the torque based on the angular difference, but my problem is I don't know how to apply the torque at the ANCHOR point. When I apply a torque at the center of mass, I simply integrate the AngularVelocity and Rotation using the angular equivalent of F=ma. But how do I do this when the torque is not being applied at the center of mass? -Jeff
7. ## 2D collision libs

What language do you use? www.flatredball.com is a nice c#/vb.net engine.
8. ## 2D Collision Detection Using Distance Maps

I'm looking for thoughts people have on implementing the 'Nonconvex Rigid Bodies with Stacking' paper in 2D. I'm considering using the 2D equivalent of both the collision detection and collision response. The collision response seems like it would transfer well to 2D. I"m less sure of how the paper's collision detction algo, which uses a distance function and trimesh (polygon for 2D), will convert to 2D. I can see that it would work, but I'm not sure if it makes sense to use this technique over others that are out there. (SAT, GJK) I'd mostly be using this engine for games, but I'd like to have a pretty robust collision detection system. My thoughts so far: -Handles non-convex shapes -Memory issues with using distance grid less of a problem in 2D -Distance grid computation less an issue in 2D. Could hopefully be done a load time or lazily. (no precomputation) -(very important to me..) It's more intuitive to me than the other algos and I love simplicity... :-) Any and all thoughts are appreciated. note: I double posted this to both this forum and the bullet physics library forums as I wasn't sure how much overlap there was between here and there. link to the paper: http://graphics.stanford.edu/~fedkiw/papers/stanford2003-01.pdf
9. ## Nonconvex Rigid Bodies with Stacking Question

I'm also interested in this algo for collision hanlding and I have a question. When there are multiple bodies (3 or more) are steps 2-13 done 2 bodies at a time from my list of "potentially" colliding bodies. Or are the steps done accross all potentially colliding bodies at once ? Put another way. In step 5, should I be finding all contact points accross ALL bodies in my system, then ordering All these contact points by deepest penetration? Or should I just be finding the contact points between 2 bodies from my list of potentially colliding bodies. Hope my question is clear enough.