LoginLogin

Need help with physics+wireframe cube.

Root / Programming Questions / [.]

CodeTrooperCreated:
CodeTrooper#1
I need help on making a physics engine, but I don't want a bunch of IF statements for collisions. Also, I'm going to try to make the physics engine work with vertexes on a wireframe cube so it can spin if a vert hits the edge. Pretty much I need a regular physics engine, with a lot of comments, and I can apply that to vertexes, maybe. I have not started on a physics engine though, becuase I'm so bad at this stuff. Any physics project/DEF library that has a lot of comments that I can base my physics engine on? Or you guys can just post below with help on physics.
glennxserge#2
Geometry + Physics is hard. They are both tricky problems to solve and on a limited console like the 3DS, it'll be difficult. However, collision detection/resolution is one of the more interesting problems in game development, and one that everyone should try to solve at some point as a learning exercise. If I lived anywhere near you, I'd let you borrow my copy of this book, but otherwise, I'd recommend picking it up on amazon: http://www.amazon.com/Real-Time-Collision-Detection-Interactive-Technology/dp/1558607323 It's a little pricey, but very extensive and handles just about every type of collision you can imagine, from complex, concave polygonal shapes to the standard bounding box overlap tests. I dust it off every time I need a refresher on a specific collision task. That aside, if there are specific questions you have. Feel free to elaborate, and I'll try my best to respond.
ezman#3
glennxserge is correct that what you asked is complicated. Modeling an unconstrained rigid body simulation isn't too difficult, but modeling collisions is tricky, and doing it all in three dimensions is tough. If you really want to approach this, then start off with a 2D rigid body simulation. Your question inspired me to do exactly that, and you can implement one quite quickly (mine's about 150 lines of code). Start off by modeling circles: they're the simplest shape to do collision detection on, and you don't need to bother calculating angular rotation from torque. You'll need arrays to store: x position, y position, radius, mass, x velocity, y velocity, x force, y force Create a function that will take a directional force, multiply it by the mass of the object, and add the result to the object's force property. The resultant velocity is calculated by taking the current velocity, and adding the object's force divided by its mass and multiplied by the time elapsed since the last update (typically 1/60, though you may want to try updating your physics twice per frame to increase accuracy). This function can be called several times before the object's position is updated - once to apply player input and a second time to apply gravity. Finally the objects' positions can be updated by incrementing them by their velocity multiplied by the time elapsed. At this stage the forces property needs to be reset to zero for the next frame. Then you need to see if anything's colliding and resolve that collision. This is where you'll need some IF statements :-) With this, start off by assuming each object has a mass of 1 and simply swap the objects'velocities.
Mariominer#4
The way that I lower the required variables to store if you have a lot of objects is by using trigonometry. Instead of X velocity and Y velocity, I use a direction and magnitude. So instead of Y_velocity=1 it would be more like DIR=90:MAG=1. The most difficult part is getting added force to be added to this number. What I do is I keep a variable for X added and Y added, so I can know how much force goes in all the directions, including the inertia from the previous direction and magnitude. Then I use ATAN to find the direction that it goes in, while using basic distance formula to find the magnitude that the force goes in. If you want to have just one IF statement for collisions, I would recommend storing each object's position in an array, then using a FOR statement to find it.
FOR I=0 TO LEN(X)-1
IF I==OBJECT THEN CONTINUE 'Object being the object that you're trying to find collision for
IF X[OBJECT]==X[I] AND Y[OBJECT]==Y[I] THEN 'handle the collision
NEXT
You can work with larger radiuses by detecting distance, or work with longer objects in just one way by detecting longer ranges. You can use these ideas for lots of different physics, but obviously the more you add, the harder it will be to control. You can also add other variables depending on the physics you add (so if you add friction, texture would be important)
ezman#5
That's a nice trick, I like it! :-) I usually create an array for each property i want to store, but when trying to code a solution to this question the other day, it had been quite some time since I last used smilebasic, and I've recently been programming in an OO language, so I decided to use a single array to hold all properties of an object. By the time is realised what language i was writing in, I had written too much, so ended up accessing the array using OBJ[ (ID * number_of_properties +index_of_property], which made for some pretty messy-looking code, but enabled some tricksy shortcuts, like x and y velocity both being the same number of indices above x and y positio, for instance. I'm the process of rewriting my physics library: I've been studying the box2d source code and reckon I can get something similar working in SB. I'm not sure how many objects I'll be able to get moving simultaneously without it getting too slow, but with the simple physics engine I wrote the other day I could comfortably process and update 12 boxes twice per frame on an old 3DS, using AABB collision detection and applying gravity; so I'm aiming at having at least ten objects at the same time with my new version.