View previous topic :: View next topic |
Author |
Message |
Ralith
Joined: 05 Nov 2007 Posts: 8
|
Posted: Thu May 08, 2008 11:50 pm Post subject: Stability/accuracy |
|
|
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 |
|
|
zzzzrrr
Joined: 17 Feb 2007 Posts: 139 Location: Washington, DC
|
Posted: Fri May 09, 2008 4:48 am Post subject: Re: Serious stability/accuracy issues |
|
|
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 |
|
|
Ralith
Joined: 05 Nov 2007 Posts: 8
|
Posted: Fri May 09, 2008 10:12 am Post subject: Re: Serious stability/accuracy issues |
|
|
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 |
|
|
zzzzrrr
Joined: 17 Feb 2007 Posts: 139 Location: Washington, DC
|
Posted: Fri May 09, 2008 11:20 am Post subject: Re: Serious stability/accuracy issues |
|
|
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 |
|
|
Ralith
Joined: 05 Nov 2007 Posts: 8
|
Posted: Fri May 09, 2008 2:06 pm Post subject: |
|
|
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 |
|
|
h3r3tic
Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland
|
Posted: Sat May 10, 2008 12:36 pm Post subject: |
|
|
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 |
|
|
h3r3tic
Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland
|
|
Back to top |
|
|
zzzzrrr
Joined: 17 Feb 2007 Posts: 139 Location: Washington, DC
|
Posted: Sat May 10, 2008 1:41 pm Post subject: |
|
|
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 |
|
|
h3r3tic
Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland
|
|
Back to top |
|
|
Ralith
Joined: 05 Nov 2007 Posts: 8
|
Posted: Sat May 10, 2008 3:05 pm Post subject: |
|
|
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 |
|
|
h3r3tic
Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland
|
Posted: Sat May 10, 2008 4:01 pm Post subject: |
|
|
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 |
|
|
zzzzrrr
Joined: 17 Feb 2007 Posts: 139 Location: Washington, DC
|
Posted: Sat May 10, 2008 5:35 pm Post subject: |
|
|
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 |
|
|
h3r3tic
Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland
|
Posted: Sat May 10, 2008 5:38 pm Post subject: |
|
|
How about #team0xf on irc.freenode.net ? |
|
Back to top |
|
|
zzzzrrr
Joined: 17 Feb 2007 Posts: 139 Location: Washington, DC
|
Posted: Sat May 10, 2008 5:40 pm Post subject: |
|
|
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 |
|
|
h3r3tic
Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland
|
Posted: Sat May 10, 2008 5:48 pm Post subject: |
|
|
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"
Quote: | By the way, I like the GUI! |
Thanks! So you've compiled it? I'm currently working on the docs and planning to release it on the 20th of May. |
|
Back to top |
|
|
|
|
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
|