Spatial hash bug is back...

Discuss any Chipmunk bugs here.

Spatial hash bug is back...

Postby Beta Carotene » Fri Sep 05, 2014 12:42 pm

Hi Scott. This bug seems to have disappeared for a *very* long time, and now its suddenly returned somehow, though I do have a bit more information about symptoms this time, and many things that I am certain are correct. I'm still using the same version of chipmunk that I was when this bug first occurred about a year ago.

So here's a video of the bug in action:

<iframe width="640" height="360" src="//www.youtube.com/embed/z3cpvsb8Ce8" frameborder="0" allowfullscreen></iframe>

EDIT: ok.... I can't seem to figure out how to post a video, so here's the raw link: https://www.youtube.com/watch?v=z3cpvsb8Ce8

What's happening is that the turret is waiting for the player to enter to enter one of 4 lines of fire (up, right, left or down). When he does, a ray is cast from the center of the turret to the players center. If there are any physics shapes in the way, the turret does not fire. In the first part of the video, this works correctly.

In the second part, after the edit, the turret is moved to where its y position is at 0, and so the ray is cast from y=0. The x coordinate seems to be irrelevant. When the start point of the segment query is on the y axis, tha'ts when it seems to fail. Interestingly, it seems that while casting a ray downward from y=0 fails, casting a ray up still succeeds.

Another thing to note is that the ray's direction is *not* straight, but rather pointed towards the player, so then the endpoint of the segment does not seem to matter as much. Maybe the quadrant it's in matters? I really don't know.

Again, with no other changes to the code at all, disabling the spatial hash makes everything work just fine, but the amount of segment queries that I'm doing becomes prohibitively expensive .

Here's a link to the old thread describing the problem, which contains an even older link to the original thread which brought it up.
Beta Carotene
 
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm

Re: Spatial hash bug is back...

Postby Beta Carotene » Fri Sep 05, 2014 1:32 pm

Ok, so in an attempt to try and help, I traced through a run of a time when it fails. Hopefully you might be able to spot something outrageous in the values here:

I just set breakpoints in various spots and kept an eye on the locals. I traced up to the hash loop and that looked perhaps a bit too tedious to trace unless we determine there is a need to. Hope these help:

Image
--------------------------------------------------------------
Image
--------------------------------------------------------------
Image
--------------------------------------------------------------
Image
--------------------------------------------------------------
Image
--------------------------------------------------------------
Image
Beta Carotene
 
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm

Re: Spatial hash bug is back...

Postby slembcke » Fri Sep 05, 2014 2:43 pm

Double checking that I have the facts straight: The bug only seems to occur when the ray start is y=0 and the direction is generally downward?

Questions: Are the static collision shapes segments or polys? (What about the player?) You are sure the raycast doesn't start inside of a shape, like is it possible that the ray isn't starting where the bullets are? How are the bullet collisions checked (shapes or raycasts)? If you were to guess, would the first collision happen in the initial hash cell or not?
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
User avatar
slembcke
Site Admin
 
Posts: 4164
Joined: Tue Aug 14, 2007 7:13 pm

Re: Spatial hash bug is back...

Postby Beta Carotene » Fri Sep 05, 2014 3:23 pm

In this case, y=0 is the only thing triggering it, but I remember many occasions where it was simply whole numbers in general. Those seem to be much, much harder to trigger, however. Also, I have only ever seen the bug happen with a downward ray, but most of my rays starting at whole numbers go downward for one reason or another, so that may not be significant.

The shapes in this scene are static polygons and I am 100% sure that there is no shape that the ray is starting inside. Im actually not even sure how that would cause this result since any ray hit causes it to *not* fire. The player is not a physics object at all. he uses a different set of systems.

It is not possible that the ray is not starting where the bullets are. The tracing I did inside the function indicates that the ray is indeed starting at 0,0. Again however, the bullets are not at all related to anything about this test. I could just as well have the word "fire" printed in the console and the result would be the same.

I think one of the keys here is that all of this works completely correct if I don't use the spatial hash, so that should alleviate most questions unless there's some implementation quirks I'm not aware of (which there probably are).

Can you explain what you mean by "initial hash cell"? Do you mean that the origin of the ray and its collision are both located in the same cell? If that's the case, I think that's right since the grid cell size I set to 10 and the distance between the gun and the player is... oh... 7 units or so?
Beta Carotene
 
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm

Re: Spatial hash bug is back...

Postby Beta Carotene » Fri Sep 05, 2014 3:29 pm

Update: I just set the cell size to 3 and that made it stop happening on the y axis, although I would bet my last dollar that the issue is just going to trigger somewhere else now.

Its important to note that moving the start point just ever so slightly, even just by 0.0001, seems to mask the bug. Apparently I am not the only one who had this issue viewtopic.php?f=3&t=2340&p=10345&hilit=SegmentQuery#p10345
Beta Carotene
 
Posts: 123
Joined: Sat Aug 04, 2012 6:34 pm


Return to Bugs

Who is online

Users browsing this forum: No registered users and 2 guests

cron