Show’s the work in progress and still very buggy physics engine I’m building for Mythruna:
http://www.youtube.com/watch?v=rX-MOerwQSk
At least the bugs are kind of entertaining. One of the more frustrating things I’ve ever worked on.
5 Likes
“where did it go? oh there it is” xD, good job
“Suddenly, walking around, doing your thing, you’re getting a chessboard right in the face, killing you instantly.”
Epic. 
Heheh.
And after I added a debug mode I found that some of the objects go into the ground. When I first added the debug mode I accidentally had the wire frame bounding box scaled up by a factor of four. So I had some fun going around the surrounding areas finding wire frames protruding from the ground and mountains and removing those objects.
I scaled them properly and made them draw on top of everything else… so now when I push one into the ground I can see it down their struggling to find which way to go. 
I dug to find one of the 4x4x4 cube objects I test with (the crates… which are not coincidentally 1 meter cubes) and when I dug around it the cube plopped neatly into the last hole, as if it were a real world block. I don’t know why but that made me smile.
That is hilarious. 
Maybe you should put that as an option.
Very nice. Building a physics engine is not easy, at all.
Was curious though, with all the jittering, have you seen this article?
http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/
jameskilton said:
Very nice. Building a physics engine is not easy, at all.
Yeah... learning as I go, in fact. I've read all of one book twice and half of another. I almost feel like I understand some of it now. ;)
jameskilton said:
Was curious though, with all the jittering, have you seen this article?
http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/
No, I hadn't seen that. I'll be reading it shortly. Thanks for the link.
A couple months ago I probably wouldn't have even understood it. :)
@pspeed : It’s a fun thing to watch indeed …
My first thought when I see this bug is may be it’s belong to the movement vector that you set to the object you holding is “not natural”!
Let’s me explain, as I want to create the effect of holding things in my game too, I try to think back to how I’ve done that before in another engine and sometimes that bug happened. I found a work around by set the movement vector of the object small…
So it will move slowly (by the physic movement vector) to the point that is the intersection of view ray and the plane has the center point of the holding object. Not just move immediately that will cause the bad result of the collision computing!
madjack said:
"Suddenly, walking around, doing your thing, you're getting a chessboard right in the face, killing you instantly."
Epic. ;)
Good one!
atomix said:
@pspeed : It's a fun thing to watch indeed ...
My first thought when I see this bug is may be it's belong to the movement vector that you set to the object you holding is "not natural"!
Let's me explain, as I want to create the effect of holding things in my game too, I try to think back to how I've done that before in another engine and sometimes that bug happened. I found a work around by set the movement vector of the object small....
So it will move slowly (by the physic movement vector) to the point that is the intersection of view ray and the plane has the center point of the holding object. Not just move immediately that will cause the bad result of the collision computing!
So the issue is that ultimately the object should also push back against the player. Right now it's a hard link to a point in front of the character that is treated as static for now -- and that's the issue. The point of the "hand" itself will move but nothing can push it back. It is trivial to create situations that are literally not possible to solve... all I have to do is push the chair into a wall and the contact resolver bottoms out trying to iterate towards a solution that will never come because there is no way to position anything so that constraints won't be violated.
A hard link is treated like any other contact point and so must be resolved like one.
Ultimately, the player's "hand" won't be static but will push back just like any other object. So if the player tries to push the chair into the wall they will just stop moving. In the mean time, it would be better for me to link the objects and the hand with a reasonably stiff spring... then formerly impossible situations just stretch the spring.
But if I ever want the player to stand on objects (and I do) or be able to grab and swing from them (and I do) then I will need to work out general object to player collisions and then the grabbing situation is just handled. Still, since there are ultimately issues with physics jitter feeding back into the camera and making the player sick, player to object contacts may always act like springs. Or at least the camera position will be tethered to the player's rigid body by a dampened spring.
...sorry... hadn't intended to ramble on so long. :) My head is way deep into this at the moment.
You are too intelligent … for the situation …
I say that because I’m totally don’t understand what you said about the object will push back (like the 2nd Newton theory :p) Anyway, I just tell you to add a movement vector to the object , the vector is toward the point that you decide your hand will stay, when the object reach the point, set the movement vector = 0. This movement vector help the physic engine move the object and also can compute it collision to decide it movable or stuck (prevent it continue to move).
May be you should take a look of how @nehon done in TestRagDoll. It’s kind of what I want to said.
Anyway, the things you said are just above my head T_T
The ragdoll uses jbullet and I’ve written my own physics engine.
Still, the ragdoll is made with joints which are similar to my hard links… If you were to pull the ragdolls arms apart attached to two static objects then I suspect bullet would go nuts trying to sort that out.
Essentially, I’m doing the equivalent of giving the player infinite weight. He shoves a chair into the wall but the chair cannot go but also cannot not go. In real life, things would just crush… but these objects can’t crush.
As you said, the situation cannot be solve literally… If I understand correctly
In real life : You push the chair to a wall, also the chair and wall are too solid and can’t be crushed. So you hand can’t move anyway.
But in your physic world : Your hand got the greatest power to make everything go to place where it want to place it. So the hard link (as it’s similar to joint in bullet) will be broken and make the object vanish but actually be in blow away by a great force.
Why this happen, the dilemma between : Everything can be crushed and every link between your hand and objects is hard link ! You have to remove one of the two. As I said, it’s not necessary to make a joint to simulate the effect of holding things… Just add a movement vector, consider the object you hold is tied with your hand by a rubber string. Then when you want to thow it away to cut the string, just remove the movement vector toward your hand. I don’t know how to do it in your physic engine but It’s how I do in JME bullet.
Yes, rubber string = spring. Which is what I confusingly described above.
Eventually I need the case where you push the object into the wall to push you back so you stop moving. So the link (either hard or spring) is the best way.
This would also allow the player to swing from ropes, stand on a boat, etc… it’s all the same kind of thing.
And besides, the other issue is that without any feedback into the player object then when they pick up something light like a lantern and swing it around then it tips over and moves tables, chairs, etc… which is bad. It should require force to continue moving your hand… ie: you have to move the mouse more or push longer.
May I ask, why you decided to write your own engine?
Can jbullet suit you for such purposes?
I wanted mesh accurate collisions and based on my reading jbullet wouldn’t have worked well for that… and I could not find any way to customize collision detection easily. I may end up borrowing the jbullet resolver now that I understand what all of these parts are.
Before I wrote my own engine, I didn’t have the slightest clue what any of these things were. So I read a book that described building an engine from the ground up. Then I read it again and implemented an engine. Now I’m reading another book, too. And I’ve spent about 4 weeks banging my head against a wall debugging math that I only half understood… but it was part of the learning process.
So now when I read the code of other physics engines, I have a decent chance of understanding it.
Collision Detection: in my case, I can take advantage of the fact that all of my objects are voxel grids to do smarter things than a straight triangle to triangle mesh collision would do. It’s not perfect but it seems to be pretty fast and I haven’t even tried to optimize it yet… though I still have yet to handle my non-cube block types yet. I can actually tolerate some of that not working in the object to object case and the object to world is easier.
1 Like
And I’ve spent about 4 weeks banging my head against a wall debugging math that I only half understood ...
Thumb up for your passion to learn ! :o
same question as above
actually I wonder whats the name of the first book you read and also the second one you read half through
moonkey said:
same question as above
Which question? I think I answered all of those.