Jump to content

  • Log In with Google      Sign In   
  • Create Account


celloe

Member Since 21 Jan 2011
Offline Last Active Apr 07 2014 05:11 PM

Posts I've Made

In Topic: Swept AABB collisions and the crack problem

31 May 2013 - 07:24 AM

@ LorenzoGatti That was my instinct, too, which made me wonder as to the specifics of my implementation, and where I'd.. gotten it wrong. With constant forces such as the mouse joint, it would bounce off on an initial swing (if the response was made elastic) then sink straight through. Is it to do with the ordering of resolving collisions, applying outside forces / impulses, and the integration itself?

 

@Krohm I understand your point fully about tools and libraries already existing to tackle this problem (box2d suffers from this also, you have to use edge chains I believe for static objects in sequence). However I do also view this as a learning experience and I value the process of solving the problem. I don't have a tight deadline or anything, I quite enjoy getting lost in the intricacies of physical simulation!

 

The main issue I have at this point is that I've seen from SacredSoftware's implementation that it is possible to get a more general solution, through the use of sorting collision priority based on which collision has a greater surface area of penetration in a given timeslice (or rather, time step with a threshold, as of course CCD would only really solve one at a time so you have to step forward and test a little). What puzzles me is the two facts that a) It does not function correctly without positional correction, and b) It gets stuck on an edge even in the case of a single box. I suppose if it's correcting it to the EXACT edge position, when it moves back down it would maybe get snagged on a corner? But is that correct behaviour?.. It's not common to many others, which makes me think the penetration resolution isn't quite correct, in terms of initial contact times.


In Topic: Impulse based friction on line segment

27 February 2012 - 06:26 PM

Just as an update I figured out the cause of the problem, I was using the center of mass velocity as opposed to the contact point velocity.. silly. All fixed now!

In Topic: Continuous collision time subdivision

20 February 2012 - 02:49 AM

Hi Paul, I've tried working with speculative contacts before (consider me a fan.. I've even commented on the article!) but the inability to model elastic collisions is a bit too much of a downside to me. As a side note, can you implement friction with speculative contacts? I imagine it's possible but don't know how you could circumvent the same problems that prevent elasticity.

I'll take a look at Box2D's source, it's a little.. overwhelming at this point, but I'll keep at it. And I agree regarding deformable bodies, I was more just taking a look to see how he handled the TOI ordering. Turns out it breaks pretty easily with more than a few bodies anyway!

In Topic: 2D Rotational constraint impulse

27 November 2011 - 12:35 AM

That made things way clearer, thank you! Managed to get it up and running. I'd never thought of that way of converting torque to particle acceleration! Only thing I'm going to change now is to work on angles originating from a 0,0 position as opposed to.. "relative angles" between joints, if you know what I mean. For instance, if I make a square out of 4 joints, I have to set each joint min/max angle to 90 degrees, as opposed to however many degrees it'd logically be from the origin. Shouldn't be too difficult!

Thanks again. I wonder if I can somehow make it behave in a "continuous collision" sense, so that fast rotations don't distort the structures too much. Could be interesting to try.

In Topic: 2D Rotational constraint impulse

24 November 2011 - 06:39 PM

Thank you! That's genius.. I'd had the same sort of idea as the method you're using, just wasn't sure how to implement it. The code's a little difficult for me to decipher (not used to freebasic syntax) but I'm sure if I spend a bit of time on it I'll be able to crack it. 2 initial questions though:
In the "get angular spring angle" section, how did you derive the method to get the angle of the joint? And I assume dotnormal is just the normalised dot product, or is it literally "normal" to the dot product in the sense that it's geometrically perpendicular?

Another thing.. you mention the spring torque based on sine angle being less efficient but faster - what do you mean less efficient? It seems like it'd be overall better as an optimization to avoid having to calculate the atan2 which'd require the cosine and sine.

PARTNERS