hey all, im extremely pleased to announce that my second major attempt at rigid body dynamics has been a success.

http://binarydemons.com/~strike/files/lunar_physics.rar

enjoy =)



in the demo the only shapes you see are boxes, but the engine will handle polygons of any convex shape - even line segments with just 2 points.

Hahah, way cool.

It's cool but a bit buggy. When I put loads of objects in some would randomly fly up really high and eventually the whole lot exploded and almost all the objects ended up outside the blue box.

yeah LOL that does tend to happen


in a real game environment there would not be hundreds of objects piled on top of each other. if you have garry's mod, spawn a few hundred tiny objects inside a dumpster and see how well that works out


the reason it starts to get mad glitchy especially when there are a ton of objects and framerate starts to suffer is simply that: because the framerate starts to suffer. the delta-time value goes up and up meaning that the objects are not integrated and collided nearly as often as they should - and when they are, the range of mathematical error becomes exponential and all sorts of weird things happen.


a game would be pretty crappy if you could only have a couple hundred objects in the entire level, especially if the level itself were made out of objects. the real problem is that currently every object is checked against every other object for collision, even if they are across the level from each other. after i finish getting camera movement in, im going to work on a BVH (bounding volumn hierarchy) to sort collisions, which should drastically improve performance; at least in levels where there arent hundreds of objects stacked on each other

It's sad that the objects never come to rest. You should have a minimal value for bumpiness, and if the force is small enough, just don't apply it at all. Or you could add in friction, but I guess this is a bit more complicated...

explain.. if by 'bumpiness' you mean coefficient of restitution, then you have it reversed. a minimal value is 0, in which case the object does not bounce at all. these objects have a restitution of 0.3 (whereas the 'maximum' would be 1.0)


do you realize this also means that without handling overlap, objects would simply float through each other at low contact-point velocity because the collision impulse to separate them would be 'too small' ? with handling overlap, the objects would stay separated, but the force of gravity would still increase their velocity even though the object is not moving. this means that within a matter of minutes, objects would become very unstable and/or you would have to apply a larger force to 'pull' them off the ground the longer they sit there. no thanks.

the most popular solution to objects not coming to rest is to 'put them to sleep' if their velocity/angular velocity is below a small threshold. when another force is applied, they 'wake up' again.


both dynamic and static frictional forces are already being applied. the fact that frictional forces ARE being applied is why the smaller objects appear to be so unstable - the impulse applied to emulate friction against immobile objects (infinite mass) is simply too much for objects that small, or rather of that small mass/inertia. this really only happens against objects with infinite mass because the FULL force of the impact is imparted on the mobile object, rather than being split between the two objects. this is why the small boxes are reasonably stable when colliding with other mobile objects.


all of the instability you witness in the program is eliminated when the objects have a larger mass (or more importantly: inertia). this is why the yellow box and larger red box do not tweak out like the smaller objects. like i said, mass and inertia is the determining factor, not size. these objects have a very small mass because of the algorithm to calculate it based on polygon shape, size, and density value. simply increasing the smaller objects' density is the easiest way to mitigate these instabilities.


the only reason the little boxes are so small is because i wanted to make a funnel that they would pour through =)

heres proof that framerate is the real source of the instability problem:

in this screenshot, the world is running at an emulated 200 fps (despite the fact that my actual framerate was down to 5 at this point).

not a single 'explosion' has occurred, and not 1 object has flown through the walls. every single box is still there - you can count em if you like




integration is the process of updating the object position and rotation from its velocity and angular velocity.

this is currently being done with the cheapest model there is: euler.
there is a notable loss of accuracy when using euler.

by using a more sophisticated algorithm such as verlet or RK4, much of the instability due to framerate can be reduced.

Can you make it destroy objects that fly off the screen? Because right now, it just eats memory until it nearly crashes :p

hehe, i would rather reduce the instability as much as possible so it doesnt happen in the first place

there is not enough functionality built-in to do something like that yet, and although it wouldnt be hard at all to hack it in (a few halfspace tests) i dont think im going to bother simply because its a demonstration program


ive got to get a camera established and theres still plenty of work to be done.. now to figure out how to 'weld' objects together since it only supports convex polys... a trapezoid for a collision polygon for a 'T' shaped object would behave rather strangly

Hmmm, so the "nervousness" of the objects is just floating point division inaccuracy? Because, you know, the large red box and the small yellow box do never come to rest, either. What I meant about a minimal value is that if the change in position and rotation of an object aren't large enough, just don't change them. If you understand a layman's explanation...
BTW: It's also impossible to fill the V-shaped blue blocks with small red boxes. I think it's above mentioned "nervousness" that's causing it.

zag: It's called entropy or something like that.

Instead of doing

!value

or

value1 == value2

for a condition test, you'd do:

value < entropy

or

abs(value1 - value2) < entropy

where entropy is a small hard coded value of your choice... usually large enough to make up for round off errors. If value1 and value2 are floats you might make it 0.001, if they're doubles you can make it 0.000001.

it wont run. Just crashes.

cause of most computer problems: user error

if you get a popup box saying "could not initialize application" or "fmodex.dll could not be found" then maybe you should try actually extracting the whole rar instead of just running the exe from it

if it does flat out crash, then.. well.. beats me. im checking the return values of directx, fmod, and win32 calls..

that was pretty entertaining

You guys all misunderstood! That's not a bug, those red things are electrons, and as they gain more energy the probability that they are outside the box gets larger!

Illegal Operation.

Sony rep?

OMFG i just realized a BIIGG reason why objects were tweaking, i cannot believe this lol..

i was working on setting up camera transforms and slightly more sophisticated rendering interfaces when i realized that i was calculating my rotation matrices for a right-handed coordinate system when the project is left-handed. not that this is really a problem, particularly for the physics code, but regardless it brought me to the collision resolution function for one reason or the other and i discovered this nasty foe:

CVector2(relativeContactPtB.y * -1.0f, relativeContactPtB.y)

which SHOULD have been

CVector2(relativeContactPtB.y * -1.0f, relativeContactPtB.x)




see what i mean about damn delicate?
needless to say things are a bit more stable now LOL.
still strange that this really only noticably affected smaller objects..

so no more jokes about how my objects defy the law of conservation of energy

Did you already update the rar? Because they still seem to be jittering about.

nah, not going to until i have some new goodies to show

UPDATES!!


http://binarydemons.com/~strike/files/lunar_physics.rar

ok.. new goodies came sooner than later i guess. not a terribly large amount added/changed.. MOST of the work has been low-level, internal stuff for rendering system, but here are the updates:

"gameplay" goodies:
-evil collision resolution bug fixed, objects are much more stable now (yay!)
-'player' object and spawned red objects are now random shapes
-rotating camera view will also rotate the force of gravity. provides an additional 6 minutes of entertainment, gauranteed
-objects that go outside of range of the 'level' are destroyed (thanx Cool Matty for suggestion)
-cannot spawn additional objects when framerate begins to suffer

rendering code updates:
-improved rendering performance (not that it really needed it; yet)
-implemented camera system
-established a rendering interface each for UI and world rendering, allowing for the new camera code to be implemented effortlessly
-changed background color




although the collision code has been updated and is much more stable, it is still not (and never will be) perfect physics so please dont repeat all the stuff that's been stated about objects not fully coming to rest, objects getting pushed through walls, etc.

there should no longer be any 'explosions' however objects can still be pushed through the walls due to the object separation code. if an object is being continually pushed at a high force at another object, it does not squash or break like a real-world object would. instead it remains whole and the velocity is increased due to the force and then decreased due to the collision w/ the wall. if the force causes the velocity to become high enough and/or framerate becomes low enough, the object will be translated past the 'centerpoint' of the wall in a single frame, causing the overlapping object separation code to eject the object from the other side of the wall. this would be fixed by simply making the walls thicker.

this version doesn't work for me, the old one did. The cursor is still there (although it is laggy), but the only other thing displayed is some fuzzy white boxes at the top of the screen, it's very jittery.

That's really cool man, though I managed to pull the yellow triangle out of the blue box and the whole thing crashed.

This is so fricking cool!!

The Runge-Kutta method has a much nicer result than Euler's method. I would definitely consider using RK4 unless the algorithm takes too long to get a decent result. I've only used RK4 when programming simulations of BEC experiments, so I'm not sure how well it will work in a physics engine.

I would comment on the demo, but I don't run Windows.

yup i will likely be switching to RK4
euler is just so fracken simple to implement, hehe

BobTheMasher: very interesting screenshot LOL.. i admit i am a little stumped.. looks like texture resources are being lost or its failing to load the font, but the vertex buffers are fine if its still drawing the character rects and mouse cursor.. that screenshot scares me to be honest, ill have to investigate and see if i can figure out what could -possibly- be causing that, considering the 'staticy' looking rectangle at the top of the screen is a completely untextured quad =S
optimally it would be related to Tiberium_Empire's problem and i can kill two birdies with one stone. if either (or both) of you could tell me your computer setup, or at the very least what graphics card and version of windows you have, i might be able to have an easier time hunting down the source of the issue. i should probably also check device caps for assumed features and slap a few more checks for error conditions on the more menial d3d calls to be safe..


Acharjay: ya i definitely believe that lol.. when an object leaves an 800.0 radius from the center of the 'level' it is immediately and indiscriminently destroyed.. and im not checking to make sure the yellow object is still valid before trying to use the pointer returned via its ID (very bad coding practice) to position the camera; hence insta-crash not to worry, this is another example of something that could be fixed with 1 line of code but barely even worth the time due to it being a cheesy demonstration app

same problem as BobTheMasher. Radeon 9800 Pro Cat 6.6.

I'm running windows xp and I also have a radeon 9800...I'll give you more details tomorrow after i take my stupid history test, haha.

I get the same thing as Bob running it on my laptop, WinXP SP2 with a Radeon1300 or something like that.

Oh my goodness, that's silly. I lied to you, I'm on my laptop, not my desktop. It's Windows XP SP2 with an ATI mobility radeon x300.

yay that's fun

Let me know when you start putting together you own game, I'll be a modeller for you

I've got the same issue:

radeon 9800 sp
XP SP2

Here's the error log file:

Same problem, XP, 9500 pro.

I get the white boxes across the top, but everything else works fine. FX5700, XP.

yikes, i guess i really screwed something up in the new build, particularly if everything ran fine for you guys previously


ive got a quick little feedback class that ill implement into (primarily) the graphics system and just dump the results to file in hopes to track this problem down.

i was feeling a little sketchy creating a vertex buffer directly in graphics memory and locking it to fill the buffer with vert data, but there does not seem to be any way to copy a vertex buffer from a system memory copy as there is for textures/surfaces, so i figured it must be normal practice to modify the gfx copy directly (which may yet be the case). the other major rendering code that was changed was a completely different way to color objects using a texture sampler constant rather than vertex coloring. perhaps this screws up due to the graphics hardware not having an actual source texture or color to rasterize the triangles with

ill begin working on the error reporting system immediately; when it's ready i would very much appreciate any of you having the graphics and/or crash issues to run it and send me the log.

I'd be glad to help.

A. Managed to crash the program with a lot of objects on the screen upon zooming all the way out.
B. Managed to crash the program by making the player object move fast enough to translate through the wall. (I assume it dies when it is "destroyed" like all other objects)

while coding in new error reporting code into parts of the graphics code, i came to the realization that non powers of two sized textures were being generated for (and only for) high quality character sets. this could explain why some of you are seeing white rectangles at the top of the screen (as SOME graphics cards support non-power of 2 textures, but most do not).



if quality is 1, finalTextureSize is 256 (power of 2)
if quality is 2, finalTextureSize is 512 (power of 2)
if quality is 3, finalTextureSize is 768 (NOT power of 2)

just had to set FONTQUALITY_HIGH to equal 4


note that the uploaded rar does not include this fix. i will rebuild and reupload the project once more error reporting is in place.

and on that note, the error reporting should be very helpful for me in solving issues others are having. it keeps its own little call stack that is dumped whenever a function fails or a verbose report is processed.

heres an example


no gaurantees, of course, that this will immediately help me locate and fix problems u guys are having.. it is a useful tool though and im sure it will come in handy at one point or another when i wish i could run the debugger and look at the call stack on someone else's machine

I get the same issue with the second version.

its a hardware-specific bug, affecting primarily ATI cards (if not obvious enough from just about all of you reporting problems also having ATI cards lol)

i found the cause of the issue, rar wont be fixed until monday at the latest, probably tomorrow (saturday) but im goin to bed. nite