[BEHAVIOR] Chipmunk Physics

By the way Rojo, the raycast query doesn't seem to work if chipmunk is used as a family behavior. Not a big deal but I thought I'd mention it.

That is a big deal if it's true, because families are an important feature. Any more info on this?

Updated to version 1.5

Download in first post.

* Change: Renamed the conditions in the "Query" group to with more intuitive titles.

* Fixed: query conditions now work with families.

* Fixed: some of the query conditions were not working with concave polygons or tilemap.

mattb

That's a cool example. Also thanks for the family bug report.

Prominent

It's now fixed.

mattb , seems like the line isn't hitting one of the tiles in the tilemap- looks like a bug. Just tried it with the 1.5 version as well. Seems like it happens when a tile shares a corner with another tile and isn't flush with any other tiles.

My guess is it's due to the way the lines are being generated? I know that you could essentially create lines around each tile, and then if a line overlaps another line in the opposite direction just remove one of them.. Then cycle through all and if one line extends from another line, add the length of one to the other and then delete the shorter one.. In the end, you'd have the lowest number of lines constructing the collisions for the map.

you could probably do the calculation before making the lines too..

edit: actually, you'd remove both lines if they overlap in opposite directions..

You're right, never noticed that. Here's a pic showing a similar thing happening in a different tilemap. It only happens on that one tile - the rest work ok.

[attachment=0:1anivlxd][/attachment:1anivlxd]

(not a great example, but what happens is the normal arrow sprite hits the tile below the top one)

Btw Prominent, I played some of your game the other day (cool stuff) & have been meaning to give you feedback - will do tomorrow if I have time.

mattb , thanks!

also, here's a shot of the tile issue- I think this shows what's happening more clearly.

[attachment=0:v5zeloow][/attachment:v5zeloow]

I'll look into it tomorrow, it's probably some typo in my code. I'm guessing the shape for that tile wasn't created. Can a body drop through it?

R0J0hound , appears as if bodies don't drop through.

mattb

Hey, thanks for the raycast example.. just what i needed

and R0J0hound thanks for the hard work on Chipmunk especially concave objects

Another bug i think unless i am missing something.. the orange box should be connected to the purple box but it is obviously connected to the green one.

spongehammer

When you use "imagepoint" it just takes an imagepoint number. So 1 for the first imagepoint, 2 for the second...

0 currently uses the object's center of mass instead of the origin. The built in physics does this, but I think it may not be very intuitive. Thoughts?

So with "imagepoint" use

1, 0 for the first imagepoint

0, 0 for the center of mass

If you use "layout" you can use:

Sprite.ImagePointX(0), Sprite.ImagePointY(0)

or

Sprite.X, Sprite.Y

Prominent mattb

It looks like a bug in the js library itself, so it may take longer for me to debug. If you move the tilemap 1 pixel to the right it works flawlessly, oddly enough.

R0J0hound

Ah ok ,thanks. I suppose it doesnt really matter in the end once you know how it works

It looks like a bug in the js library itself, so it may take longer for me to debug. If you move the tilemap 1 pixel to the right it works flawlessly, oddly enough.

You have to move it both in the x and y axis one pixel to remove the issue completely. Doesn't seem to matter which direction either.

Updated to version 1.6.

Download in first post.

* Fixed: The "Query closest line segment" condition would fail to hit some tiles of a tilemap. See note [1]

* Added: Changing a tilemap with this behavior will now update the collisions. NOTE: If the tilemap also uses C2's included physics behavior then whichever behavior runs first will update, the other won't.

* Change: The "imagepoint" option for attaching joints now attaches to the "origin" if 0 is used and the Center of Mass (COM) if -1 is used. Previously 0 would use the COM. spongehammer

Note [1]:

Prominent mattb

The bug would occur if PointA x was the same as the left or right of the tile, or if PointA y was the same as the top or bottom. Strangely enough the bug is also present in the original c library too.

Also I don't generate the collision polygons for the tilemap. I use the polygons that the tilemap provides, which looks very decent.

If I instead used a polyline instead of boxes there would be the possibility to get stuck inside.

R0J0hound , ah cool. The way the map polys are organized is interesting- That's a good point about the possibility of objects getting trapped if they were polylines- If anyone really wanted to use lines instead, they could generate that themselves anyway I think.

Any plans for a document or something where all the nuances of the behavior can be found?

An interesting side note: Chipmunk has recently updated to version 7, which has all the pro features built in, and is being released free and open source.

https://chipmunk-physics.net/chipmunkPro.php

Apparently, v7 can take advantage of vector proccessing on mobile (NEON), which can give a huge speedup for physics. Though, a javascript port couldn't take advantage...yet. Here's hoping SIMD.js makes it to crosswalk sometime this year...

javascript error!

uncaught error: assertion failed: this addition/removal cannot be done safely during a call to cpSpaceStep() or during a query. Put these calls into a post-step callback.

How do I delete joints on post collide? I get that message when I try to do that. Not sure how to get around it.