[BEHAVIOR] Chipmunk Physics

how do you force a rotation to a point with this behavior?? ive got overlapping parts all joined together using the physics joints someone posted in this thread but when rotating using built in behavior some of my parts start spazzing out since i guess they need to rotate naturally through physics?

any help would be appreciated

It probably depends on what you're trying to accomplish. You could try maybe setting the velocity after you rotate it to the velocity it was before the rotation. Maybe setting angular velocity to 0.

Do you want the rotations to have momentum, so after they are rotated they continue moving?

Hi. How can I set Chipmunk2D 7.0.1 to construct 2?

Hi. How can I set Chipmunk2D 7.0.1 to construct 2?

I assume this is the latest incarnation? If so, you would need to do what R0J0hound has done and use the SDK to integrate it into C2, which is not a small task.

The other option would be for R0J0hound to update his code, but that would be entirely up to him.

jeebroniz

Here's how I would handle rotating to a target angle using torque:

https://dl.dropboxusercontent.com/u/523 ... mping.capx

It uses the same principle as the magnet thing I posted here the other day: apply torque proportional to angle difference of object to target, then add an opposing torque proportional to the object's angular velocity to act as damping.

It'd crude & fairly math-free, but completely force based so won't cause the issues you get when directly setting velocity or position.

Rojo gave a better example here which uses proper torque calcs involving inertia:

viewtopic.php?f=147&t=122190&p=871121&hilit=physics+rotate+towards+angle#p871121

navel35

Rojo's behavior is built on a javascript port of Chipmunk2d 6.1.1 & I think that's unlikely to get updated.

navel35

Only version 6.1.1 will probably be used for the lifetime of this plugin. To use version 7, I would have to port it to Javascript myself, but I don't have the time for that. The only additional feature it would have is rounded shapes, but it's not essential.

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.