Box2D Forums

It is currently Tue Oct 21, 2014 3:17 am

All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Jan 27, 2010 11:29 pm 
Offline

Joined: Wed Jan 27, 2010 10:45 pm
Posts: 6
Hi,

I would like to report an issue that is happening in my tile-based game. First, please have a look at following topics (that I looked into before going to post this) and you will understand what I mean:
viewtopic.php?f=8&t=3292
viewtopic.php?f=3&t=3069
viewtopic.php?f=3&t=3048
viewtopic.php?f=8&t=3456
viewtopic.php?f=4&t=4134

Ok now let me tell you that this bug WAS FIXED once! :D. Here is what I did to track the issue (sorry for my no internal knowledge of Box2D :oops: ):

1) I started to use Box2D after downloading 2.0.1 version (http://sourceforge.net/projects/box2d/f ... p/download) the bug was there.

2) Before I started to get annoyed, someone suggested me to update to latest (trunk) on SourceForge (the latest one there, right now). I did that and noticed that bug was FIXED. I was happy unless I received README_FIRST.txt that said to move Google Code.

2) I moved to Google Code (latest revision: 36) and bug again welcomed me there :twisted:

3) I further tracked down SVN revisions (on Google Code) and found this was re-introduced in revision 5 (for b2World.cpp). Here is code responsible :shock: to re-introduce the bug:
Revision 4: b2World.cpp: Line: 630-ish
Code:
      if ((minContact->m_flags & b2Contact::e_touchFlag) == 0)
      {
         // This shouldn't happen. Numerical error?
         //b2Assert(false);
         continue;
      }


in Revision 5, it got changed to:
Code:
      // Is the contact solid?
      if (minContact->IsSolid() == false || minContact->IsTouching() == false)
      {
         // Restore the sweeps.
         b1->m_sweep = backup1;
         b2->m_sweep = backup2;
         b1->SynchronizeTransform();
         b2->SynchronizeTransform();
         continue;
      }


(do a diff of b2World.cpp to see this change)

I know the code is not here to just introduce the bug ;) but it should have been here to handle some other cases etc.

I further noticed that changing "continue" to "break" in above revision 5 code, then the bug disappears (but I don't know the consequences of this on other things).

Then up to revision 31, this code segment stay here and after revision 32 everything get changed and I was lost to have a fix :D . Basically I just tried to track the cause, not root.

Any help is appreciated. Thanks.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2010 12:54 am 
Offline
Site Admin

Joined: Thu Sep 06, 2007 12:34 am
Posts: 2946
So you have some static boxes that are perfectly aligned and then you want to slide a dynamic box across the junction smoothly? Is that the problem?

To work around this you can:
1. create edge polygons along the border and don't use the static boxes. Merge connected, collinear edges.
2. don't try to slide boxes on this surface.

I suggest you use technique 1. It shouldn't be too much work and you should get good behavior.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2010 1:34 am 
Offline

Joined: Wed Jan 27, 2010 10:45 pm
Posts: 6
Thanks Erin.

Erin Catto wrote:
So you have some static boxes that are perfectly aligned and then you want to slide a dynamic box across the junction smoothly? Is that the problem?

Yes. :)

Erin Catto wrote:
create edge polygons along the border and don't use the static boxes. Merge connected, collinear edges.

I assume you mean converting interconnected boxes to a big polygon (this has been suggested in past topics as well). As far as I know, a polygon has 8 vertices (by default) and I will have to increase this number to create complex polygon, but how much? I think it won't be good to have 200+ vertices per polygon (performance wise ?) as I will have large maps.
And again I am not sure how would this satisfy the need. Here is an example of using polygons for boxes (take each digit as one tile. 0=empty area and 1=polygon-area) so there is one polygon here:
Code:
0011111000000
0001111100000
0001000000000
0001000000000
0001110000000


Above shows there will be a 13 vertex concave polygon. or suppose I separate these into convex ones, the joining points between those polygons will still block sliding. How should I handle this?

On the other hand, polygon solution may not serve best in situations where we need to create/destroy/activate/de-activate or update each tile (its underlying body) individually. Having all of them in one polygon may require regeneration (of polygon(s)) whenever a box has to be updated. Also I want to have some boxes with more restitution and some with less and other properties etc. What about that?

I also have a question why Edge shapes are gone off :?:

Thanks for your time though.
Regards


Top
 Profile  
 
PostPosted: Thu Jan 28, 2010 2:08 am 
Offline

Joined: Fri Apr 17, 2009 9:01 pm
Posts: 143
Regarding edge shapes, in the newest version of Box2D you would just use polygons with two vertices.

For large non-convex polygons, yes, you'd have to decompose those into multiple convex polygons. I haven't dealt with the 'sliding across aligned boxes' problem myself, so I can't comment directly on that, but given the scenario you describe it seems that using 'edge' polygons might be a reasonable solution.

As for how best to handle different surface properties and changes in the tile configuration, I think that would depend largely on the details of the application (e.g. how often changes occur, under what circumstances, etc.). It wouldn't be entirely trivial, but I imagine you could construct an algorithm to rebuild and modify edge shapes locally in response to tile additions and removals (if it came down to that).


Top
 Profile  
 
PostPosted: Thu Jan 28, 2010 2:16 am 
Offline

Joined: Wed Jan 27, 2010 10:45 pm
Posts: 6
Thanks Jesse. I will try with edge polygons.

BTW, as we are talking about workaround the issue. What is, if any, reason to not to classify this as bug/issue and try to fix someway? I have idea that it might hard to fix, that's why it is still there.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2010 11:11 am 
Offline
Site Admin

Joined: Thu Sep 06, 2007 12:34 am
Posts: 2946
You should have edge polygons around the boundary. Since you would be making a series of line segments, the overall shape can be non-convex. Don't bother trying to merge your tiles into larger convex polygons. Just trace the boundary.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2010 9:43 pm 
Offline

Joined: Wed Jan 27, 2010 10:45 pm
Posts: 6
Thanks Erin. I will give it a try this weekend.


Top
 Profile  
 
PostPosted: Thu Feb 11, 2010 5:36 pm 
Offline

Joined: Wed Oct 28, 2009 6:14 pm
Posts: 132
Just out of curiosity, what causes this bug anyway?


Top
 Profile  
 
PostPosted: Thu Feb 11, 2010 6:22 pm 
Offline
Site Admin

Joined: Thu Sep 06, 2007 12:34 am
Posts: 2946
It is not a bug, unless you expect Box2D to have pixel perfect collision, which it does not. I don't know of any rigid body physics engine that has pixel perfect collision and it probably isn't possible when shapes are allowed to rotate.

Here is a box sitting on two connected, collinear edges. The gap is exaggerated.

Attachment:
temp1.png
temp1.png [ 513 Bytes | Viewed 6295 times ]


Polygons have a skin region that overlap (because collision isn't pixel perfect). So the collision system does not see a smooth surface when the box travels horizontally over the gap.

Attachment:
temp2.png
temp2.png [ 2.6 KiB | Viewed 6295 times ]


If the box is not allowed to rotate (fixed rotation enabled), it will get stuck because you can get a horizontal contact normal.


Top
 Profile  
 
PostPosted: Sat Feb 13, 2010 7:06 am 
Offline

Joined: Mon Jan 07, 2008 10:51 am
Posts: 1911
In my pre-Box2D days, I had a rigid AABB engine. I fixed this problem by allowing a certain (extra) amount of lateral translation, if near the wrong side of a corner wrt velocity. I subtracted the magnitude of the translation from the motion of the body, so it was as if the box was slipping around another. Highly non-phsyical, but good for games. By turning up the parameters, it also worked for stairways, tile based games with players the width of 1 tile, etc. Do you think similar detection could be done in Box2D? I'm thinking yes, but I've not had the motivation to try.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group