[BEHAVIOR] Chipmunk Physics

I think we as game designers always should pursue for mimicking the reality in most resource-efficient / minimal way... version 6.1.1 of Chipmunk is good enough for many applications... for example, it was used on inBits (and we got very realistic physics in the game) - you can check it out if you live in Brazil, Finland, UK and soon in Japan (we will soft launch the game in Tokyo Game Show).

R0jo got his hands full already, so I for one think he should only continue supporting this version and other works of his. He's done a wonderful job with it =)

R0J0hound

I've been trying to make one-way platforms & saw this: https://chipmunk-physics.net/unityDocs/ ... neway.html

Is this possible to set up with a pre-step event?

mattb

I don't think so, at least I can't think of a way off hand.

Update 2.3:

+Added "on pre collide" trigger. This is triggered before a collision response occurs. [see note 1]

+Added "ignore collision" action. This only does something under a pre collide trigger.

mattb

This allows for making a jumpthru behavior.

https://dl.dropboxusercontent.com/u/542 ... pthru.capx

note 1:

From both "pre collide" and "post collide" you can access all the collision expressions, although the impact and KE ones aren't calculated till a post collide.

Also both are subject to a limit in the chipmunk library where nothing can be added or removed form the simulation in them. This behavior works around that by delaying creation and deletion which works most of the time but is the cause of some of the latest bugs.

R0J0hound , maybe I'm getting confused with something. When I try to get the position of a sprite on post collision, the coordinate doesn't appear to match up with where the sprite is located. The coordinate seems to be from the previous gamecycle.

So based on this behavior, it seems the Post col. just references the previous gamecycle, even though the sprites are drawn in position with the current cycle?

That makes it difficult if I need to get the position of the sprite in the current game cycle inside the Post Col.

To summarize the problem: The collision data appears to be for the current game cycle, whereas the sprite data is from the previous gamecycle. So it becomes out of sync when trying to compare the two.

edit: you can test this by make the game speed 0 on post collision to see the disconnect. The disconnect is larger, the faster objects move.

edit: I just tried the pre-collision in the new update, and it has the same issue. I need to figure out a way to get the current sprite data during the collision events, because precision is important to what I'm trying to accomplish.

I tried updating the the position of a sprite everytick, and the coordinate matched the sprite position of the physics object, but I still need way to get the data on the collision.

For example, the contact point is always offset from the sprite. I need a way to get the correct position & angle of the sprite so that it lines up with the contact point. I'm not sure how to do this.

This is unrelated to the depth of the collision.

Here's a capx showing the issue I'm having: http://1drv.ms/1OghVND

I need a way to get the correct positions of the red sprites at the moment of collision, so that one red sprite would be overlapping the green sprite(collision point).

If anyone can help, it would be appreciated.

btw, I can't update the red sprites every tick, because I'm not referencing imagepoints- this is just a simplified demonstration of the issue. My other project uses a plugin that does calculations regarding the bounding poly of the sprite, and I don't want to run that every tick. So I need a way to get the position during the Post Collide.

Prominent

I've been trying to think of a good solution to that. What's happening is this is the order things are run:

1 update physics positions from c2

2 run sim step. This is where pre and post collide are run.

3 update c2 positions from physics.

So the issue is the c2 positions aren't updated at that point.

The quickest fix I may add is an action to update a object manually. But that's not ideal as intuitively it should be automatic.

The ideal solution would be to only update when retrieving the object angle or position. The issue is there isn't a way to do this with c2.

A third idea would be to update the c2 object every time the physics object moves. The issue with that is it may happen a lot per object so it will have an impact on performance.

I'll have to give it some thought I think. In the meantime I may just do the first idea so performance won't needlessly suffer.

Hm, that makes sense. Thanks for the clarification.

Yeah, I guess having an action to force an update to an object sounds like the most reasonable method from what you say.

ah, I just remembered I had this issue before and looked back through the thread and saw your post that helped me solve it:

I re-added it to the new version at line 6548 and now things are working like before.

I'll be sure to reference that bit. However as I recall that's an incomplete fix that only updates the two objects connected to a joint. I'll try to come up with a list of the situations you'll need to update positions manually. Hopefully it's not too though.

I think the implementation of those two lines updates the two objects that collided. I don't think it relates to any joined objects in that case. At least, that is the impression I get.

A list of situations would be interesting- the only place I've ran into the problem has been when objects are colliding, but I suppose there could be other situations too.

Maybe I've ran into the problem in other situations but didn't notice it or maybe I overlooked it.

Prominent

You're right that's what they do. I'll still want an action to update the object's c2 position or physics position for each other, but I need to do some refactoring, which is taking time, and i haven't been productive.

Here's a slight breakdown of the limits of those triggers. Some of it can be fixed, but not all.

pre step

• can set forces here
• setting position and angle is ignored here

pre/post collide

• setting forces is ignored here
• setting position and angle is ignored here
• position of objects aren't updated to correct locations at this point. The fix you linked only fixes this partially.

Ah cool, thanks for breaking that stuff down, I think I'm grasping the situation a bit more.

This chipmunk behavior is really great, I have had a lot of fun experimenting with it and I'm looking forward to any new progress you make with it!

I really like the accuracy of chipmunk physics compared to Box2D in most of the aspects (especially the way collisions happen). Thanks a lot for giving us this plugin...

R0J0hound, I wanted to show how the things around look like from a moving object (that has a behavior of chipmunk physics). More like a relative motion where I change the reference frame to a moving object...For example, the way the objects in the scene appear if I sit on a moving swing...

Are the utility expressions "Worldtolocal" and "localtoworld" the ones that I need to use to translate other objects in the scene?