FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Stability/accuracy
Goto page 1, 2  Next
 
Post new topic   Reply to topic     Forum Index -> Blaze
View previous topic :: View next topic  
Author Message
Ralith



Joined: 05 Nov 2007
Posts: 8

PostPosted: Thu May 08, 2008 11:50 pm    Post subject: Stability/accuracy Reply with quote

I've recently written some code that allows a user to draw a set of lines to form an arbitrary polygon (a series of mouse clicks are stored as vectors and eventually passed to Blaze to create a shape), but they always behave extremely strangely with respect to physics. If they're non-convex, they frequently fall through other objects (or vis versa), and even simple triangles tend to behave as if their center of mass were somewhere far different than the geometric center of the object (moment of inertia is generated using GeometricShape.momentForPoly), and sometimes even fall through the 800-by-10 block I use for a floor. Manually setting the Polygon's type to GeometricShape.SEGMENT_SHAPE led to a segfault. How should I be generating these shapes instead?

Addendum: Even simple hardcoded boxes behave very strangely; much like aforementioned custom shapes, they tilt and roll and slide sometimes even jump around of their own accord, often slipping through static geometry. Does this have something to do with the mysterious 'e' and 'u' values, which I can't find explained anywhere? I'm running at a very high framerate (no limit in place) with 10 simulation steps per frame.

Code here. Depends on these libraries, plus blaze. If you want to run it, you'll need this in a file named "gui.cfg" in the same directory as the binary, as well as all the files the hybrid test described here needs (be sure not to accidentally use its gui.cfg instead of mine).

I'm using the SVN version of Blaze.
Back to top
View user's profile Send private message
zzzzrrr



Joined: 17 Feb 2007
Posts: 139
Location: Washington, DC

PostPosted: Fri May 09, 2008 4:48 am    Post subject: Re: Serious stability/accuracy issues Reply with quote

Ralith wrote:
If they're non-convex, they frequently fall through other objects (or vis versa)


The collision detection in Blaze only works with convex objects. However, there is a way around this: non-convex decomposition. You basically create a non-convex shape with convex pieces. Check out the Jumble or Ship demo for a good example.

Ralith wrote:
Does this have something to do with the mysterious 'e' and 'u' values, which I can't find explained anywhere?


e = coefficient of restitution
u = friction coefficient

If you want good explanations of these subjects you can look on Wikipedia, or you can check out this page:

http://www.myphysicslab.com/collision.html

Since Blaze is closely modeled after Chipmunk, you can also read that project's documentation for good hints:

http://files.slembcke.net/chipmunk/chipmunk-docs.html

After you have a basic understanding of these principles, I would recommend taking a close look at the demos. If you would like a few game physics book suggestions I can send those your way as well.

I regret not having time to provide good documentation, but up this this point the project has been a one man show with the exception of initial help from Clay.

Best regards,
Mason
Back to top
View user's profile Send private message
Ralith



Joined: 05 Nov 2007
Posts: 8

PostPosted: Fri May 09, 2008 10:12 am    Post subject: Re: Serious stability/accuracy issues Reply with quote

zzzzrrr wrote:
The collision detection in Blaze only works with convex objects. However, there is a way around this: non-convex decomposition. You basically create a non-convex shape with convex pieces. Check out the Jumble or Ship demo for a good example.

Ah, I misinterpreted the feature list as implying that this was built in.

However, as I described, the problem is far from limited to non-convex objects. Drawn triangles, or even pre-modelled squares all exhibit extremely odd behavior, tilting, rolling, and even jumping around of their own accord, and usually soon (although not necessarily on first contact) falling straight through the rectangular static geometry I use for my floor. For some reason they don't ever seem to intersect with eachother more than reasonable, but all other unusual behavior remains.

The demos were instrumental in getting as far as I have, but I can't work out what I'm doing differently than them which results in this behavior. I've reviewed my values for 'e' and 'u,' and they seem to be reasonable in light of their meaning. Any ideas?
Back to top
View user's profile Send private message
zzzzrrr



Joined: 17 Feb 2007
Posts: 139
Location: Washington, DC

PostPosted: Fri May 09, 2008 11:20 am    Post subject: Re: Serious stability/accuracy issues Reply with quote

Ralith wrote:
The demos were instrumental in getting as far as I have, but I can't work out what I'm doing differently than them which results in this behavior. I've reviewed my values for 'e' and 'u,' and they seem to be reasonable in light of their meaning. Any ideas?


It sounds like the impulse solver is not performing enough iterations to resolve the collision constraints. I've taken a look at your posted code and don't notice anything glaring off hand. Is this the same code you are using to test your convex objects? Try completely removing the non-convex objects from the scene and stacking a few boxes on top of one another, all resting on a static platform. Also make sure that the object masses do not vary too much from one another, i.e. orders of magnitude.

I would compile your code myself and run a few tests, but unfortunately my Linux machine is down right now.

Have you tried using Blaze 1.0 or RC1? Sometimes things can tend to "break" in the trunk.... I use it as my sandbox for new ideas, so you would probably be better off using an official release unless you want to work on development.

Send me some screenshots (mason.green at gmail) or compile a Windows binary for me. In the meantime I'll work on re-installing Linux over the weekend.

The only other recommendation that I can make is to fully study the demos. I know they work well!

Regards,
Mason
Back to top
View user's profile Send private message
Ralith



Joined: 05 Nov 2007
Posts: 8

PostPosted: Fri May 09, 2008 2:06 pm    Post subject: Reply with quote

zzzzrrr wrote:
Is this the same code you are using to test your convex objects? Try completely removing the non-convex objects from the scene and stacking a few boxes on top of one another, all resting on a static platform. Also make sure that the object masses do not vary too much from one another, i.e. orders of magnitude.

The program allows for easy testing of both, and I've tried numerous times using nothing but boxes and triangles, with the same strange results. All objects have equal mass (1).

zzzzrrr wrote:
I would compile your code myself and run a few tests, but unfortunately my Linux machine is down right now.

Both my program and the libraries it depends upon are portable to Win32, Linux, and FreeBSD, so you shouldn't have any issues compiling if you have a window dev environment. I can easily provide a binary to you in a few hours, though. Also, h3r3tic on IRC should have one on hand, if you feel like getting ahold of it beforehand.

zzzzrrr wrote:
Have you tried using Blaze 1.0 or RC1? Sometimes things can tend to "break" in the trunk.... I use it as my sandbox for new ideas, so you would probably be better off using an official release unless you want to work on development.

Not yet; will do this afternoon. Thanks for the advice.

Oh yeah, I had a thought. Do polygons have to be defined with vertexes in a particular order? (CCW vs. CW) I haven't paid any attention to that yet.

Edit: Vertex order appears to have no effext. Blaze 1.0 behaves similarly to Blaze SVN.

Edit: Circles are just as erratic as everything else, and perhaps even more frequently intersecting eachother. Code used:
Code:
auto rb = new RigidBody(1, GeometricShape.momentForCircle(1, 0, 10, Vector2D(0, 0)));
rb.addShape(new Circle(10, Vector2D(drawing[0].x, drawing[0].y), 0, 1));
space.addRigidBody(rb);
bodies ~= rb;


Edit: I've updated my code to involve the location of the spawn as little as possible, and yet the stability of the generated object seems directly proportional to its proximity to the origin (the center of the space/window); boxes spawned there behave mostly normally until something touches them, while boxes spawned near the edges fall through the static geometry or start spinning or jumping around almost right away.
Back to top
View user's profile Send private message
h3r3tic



Joined: 30 Mar 2004
Posts: 261
Location: Torun, Poland

PostPosted: Sat May 10, 2008 12:36 pm    Post subject: Reply with quote

When you change the rigid body init in onClicked to e.g.

Code:
            vec2i pos = winToGL(size, e.pos);
            Vector2D[] shape = createRectangle(20, 20);
            auto rb = new RigidBody(1, 1000);
            rb.p.setTo(pos.x, pos.y);
            rb.v.setTo(0, 0);
            rb.w = 0;
            rb.setAngle(0);
            rb.addShape(new Polygon(shape, Vector2D.zeroVect, 0, 1, true));
            space.addRigidBody(rb);


Then the craziness goes away. Yet some boxes can still fall through the floor. Seems most common when the box is standing on one corner and another one hits it or it falls down to the floor slightly rotated. This is much less frequent at the center of the floor.

The phenomenon may be related to another funny behavior: when you set the box's 'bullet' field to true, it gains angular velocity when hitting the floor anywhere but on the horizontal center. Making the floor much wider alleviates the angular velocity issue, yet boxes still sometimes fall through the floor.

Thus, if both bullet and non-bullet boxes exhibit the same problem, my bets are on the solver and floating point errors creeping in.

BTW, I've tried fiddling with bounciness and friction parameters and it didn't seem to affect the problem.

Cheers!
Tom
Back to top
View user's profile Send private message MSN Messenger
h3r3tic



Joined: 30 Mar 2004
Posts: 261
Location: Torun, Poland

PostPosted: Sat May 10, 2008 12:42 pm    Post subject: Reply with quote

http://paste.dprogramming.com/dpf42xst <- the code I'm using
Back to top
View user's profile Send private message MSN Messenger
zzzzrrr



Joined: 17 Feb 2007
Posts: 139
Location: Washington, DC

PostPosted: Sat May 10, 2008 1:41 pm    Post subject: Reply with quote

h3r3tic wrote:
Then the craziness goes away.


I would like to start troubleshooting the code, although I'm having Tango 0.99.6 and Rebuild setup issues on Linux.

I'm sure I would be able to diagnose your stability problems fairly easy if I could just get the damn thing to compile....

-Mason
Back to top
View user's profile Send private message
h3r3tic



Joined: 30 Mar 2004
Posts: 261
Location: Torun, Poland

PostPosted: Sat May 10, 2008 1:57 pm    Post subject: Reply with quote

Sorry, I've missed the point where you had asked for a Windose binary. Here it is: http://h3.team0xf.com/fizziks.7z . Here's one with alternative timing (but no extra files): http://h3.team0xf.com/fizziks2.7z
Back to top
View user's profile Send private message MSN Messenger
Ralith



Joined: 05 Nov 2007
Posts: 8

PostPosted: Sat May 10, 2008 3:05 pm    Post subject: Reply with quote

If you can get on IRC, I'd be happy to help you get everything working.
Also: Right now, the big problem is that things seem to penetrate the floor very easily if it's not very thick. With a thickness of 10, it's common for objects (especially one polygon sliding down the side of another) to drop right through. With a thickness of 1, boxes fall through it very frequently. WIth a thickness of 10 and the box angle initialized at 0.175, boxes fall through always when on the right side of the space, sometimes when on the left, and almost never when in the middle. h3r3tic also tells me that when so-aligned boxes contact the right end of the floor, they shift further to the right at the instant they contact and begin to penetrate the floor.
Back to top
View user's profile Send private message
h3r3tic



Joined: 30 Mar 2004
Posts: 261
Location: Torun, Poland

PostPosted: Sat May 10, 2008 4:01 pm    Post subject: Reply with quote

Same thing happens with blaze-demos. E.g. change injectBlock in BasicStack.d to:
Code:
void injectBlock(Number x, Number y)
{
    y = abs(y - SCREEN_HEIGHT);
    Vector2D  mousePos = Vector2D(x, y);

    RigidBody projectileBody = new RigidBody(1, 1000);
    projectileBody.p = mousePos;
    projectileBody.v.setTo(0, 0);
    projectileBody.w = 0;
    projectileBody.setAngle(0.174532925);
    projectileBody.addShape(new Polygon(createRectangle(50, 50), Vector2D.zeroVect, .9, 1, false));
    space.addRigidBody(projectileBody);
}


When you drop the box at the right side of the floor, it falls through. When you slow down the time and use a ruler (e.g. another window), you can observe that the box moves a bit to the right at the time when it should hit the floor. The behavior changes slightly when the box is a bullet, but it doesn't go away completely.
Back to top
View user's profile Send private message MSN Messenger
zzzzrrr



Joined: 17 Feb 2007
Posts: 139
Location: Washington, DC

PostPosted: Sat May 10, 2008 5:35 pm    Post subject: Reply with quote

Ralith wrote:
If you can get on IRC, I'd be happy to help you get everything working.


Great, which IRC channel and server?
Back to top
View user's profile Send private message
h3r3tic



Joined: 30 Mar 2004
Posts: 261
Location: Torun, Poland

PostPosted: Sat May 10, 2008 5:38 pm    Post subject: Reply with quote

How about #team0xf on irc.freenode.net ?
Back to top
View user's profile Send private message MSN Messenger
zzzzrrr



Joined: 17 Feb 2007
Posts: 139
Location: Washington, DC

PostPosted: Sat May 10, 2008 5:40 pm    Post subject: Reply with quote

h3r3tic wrote:
Sorry, I've missed the point where you had asked for a Windose binary. Here it is: http://h3.team0xf.com/fizziks.7z . Here's one with alternative timing (but no extra files): http://h3.team0xf.com/fizziks2.7z


Thanks. I've taken a look, and it appears as though most of the issues stem from drawing objects with the mouse. The blocks that I inject with a right click seem to be stable.

Ideally I would like to get setup on Windows so that I can compile your code, as it will be much easier for me to troubleshoot.

By the way, I like the GUI!
Back to top
View user's profile Send private message
h3r3tic



Joined: 30 Mar 2004
Posts: 261
Location: Torun, Poland

PostPosted: Sat May 10, 2008 5:48 pm    Post subject: Reply with quote

zzzzrrr wrote:
Thanks. I've taken a look, and it appears as though most of the issues stem from drawing objects with the mouse. The blocks that I inject with a right click seem to be stable.

Hmm... unfortunately not, they fall thru the floor sometimes, when tilted, like I posted further with the initial rotation "cheat" Wink

Quote:
By the way, I like the GUI!

Thanks! So you've compiled it? Very Happy I'm currently working on the docs and planning to release it on the 20th of May.
Back to top
View user's profile Send private message MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Blaze All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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 vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group