DPMath is gonna contain some the same functions as the Direct3DX class, see here, from DirectX, only it will contain more physics based math functions, and will have just the vector, matrix, and quaternion math from the other library I have in the link. The reason why we must recreate these functions is because I don't want DirectPhysics to be dependent on DirectX in order to run the math functions. I also want to rename them to DP instead of D3DX.
Also, DPForce will contain functions that calculate Gravity, Air Resistance (aka Air Drag), Friction, Normal force, Magnetic, Applied, Buoyant, Electrical, Vacuum, Tensional, and Spring force. Torque, I'm not sure should go there or be in a separate class, but we will see. There will even be a function called Add, that will add whatever forces you apply to it, which in effect automatically puts it into Net force.
There will be 2 to 4 versions of each force, depending on whatevers possible between 1D to 3D. 4D is for when people use 'w', which is usually always 1.
Last edited by Jacob Roman; Feb 20th, 2006 at 06:09 PM.
oh all this math talk is confusing me... Not really but anyway...
I downloaded visual c++ 2005 today, I couldnt even see where to type in code! I might be willing to learn, if it will benifit me in the future. I do plan on seeking employment in this field, as I have not grown bored of it. Yet...
So if anyone has anygood links on good visuall c++ 2005 , that would be great.
I figure for this project, I might not have to learn to much, but I know it will be harder than I think
Software languages known: Qbasic - TI-Basic - Liberty Basic - Visual Basic 6
Software API's known: Directx 7 and 8
Internet languages, in the process of learning: HTML - JAVASCRIPT - PHP - CSS - MYSQL - AJAX
Ok, let's begin then. To help everyone code this, I'm gonna bring out a series of formulas for every force, or some of them for now. Some of them don't have any formula.
Table
N - Normal force
μ - Friction coefficient
m - Mass
g - Gravity
C - Drag coefficient
p - Air density
v - Velocity
A - Area
x - Position
x0 - Initial Position
k - Spring stiffness
Formulas
Gravitational: None
Friction: μ * N
Normal: m * g
Air Drag: 0.5 * C * p * A * v²
Spring: -k * (x - x0)
Last edited by Jacob Roman; Feb 22nd, 2006 at 03:22 PM.
Gravitational force: F(g) = GMm/r^2
The gravtitaional force between two objects of masses M and m, separated by r. G is the gravitational constant (very small). It acts along the line joining their centres of gravity.
Weight: F(w) = mg
For an object of mass m, the weight is mg where g is the acceleration due to gravity. On Earth, this is ~9.81ms^-2. On the local scale, this is always straight down.
Normal force: F(N) is of variable magnitude, but always acts perpendicular to the surface. When an object is on the tabletop and in equilibrium, then the Normal force is equal to the weight. However, things can get much more complicated....see diagram.
Friction: F(f) is the frictional force; usually F(f) <= uN where u is the coefficient of friction and N is the Normal force. F(f) acts to oppose the direction of motion. The frictional force does not increase forever, nor is it a constant and equal to uN.
Springs: F(s) = -kx where k is the spring constant and x is the extension of the spring. Only valid in the regime in which the spring returns to its initial length when released. Springs can be overstretched.
Actually zaza, GMm/r^2 is used to calculate the gravity of a planet or a moon, which isn't really that useful in a physics engine, and is hardly ever used.
Although Normal force and weight have the same formula m*g, they are not the same thing cause a normal force isn't always going straight down like weight is.
And in the Spring force equation -k*x, x is calculated (x - x0) to obtain the length of the spring.
I don't wish to be a nuisance, but it's worth getting these things right.
GMm/r^2 is used to calculate the gravity of a planet or a moon, which isn't really that useful in a physics engine, and is hardly ever used.
Actually, this is the Universal Law of gravitation. It applies to everything! For someone such as yourself, or any other object on the Earth, the gravitational force must be equal and opposite to the weight.
Hence:
mg = GMm/r^2
The m's cancel, leaving g (accel due to gravity) = GM/r^2. These are (more or less) constants, G = 6.67x10^-11 m^3/kg/s^2, M (of Earth) = 5.976x10^24 kg, radius (of Earth) = 6378137m. Fill these in, and you get g = 9.81ms^-2, exactly as we all know. So arguably, this formula is of more use than simply a constant g.
Although Normal force and weight have the same formula m*g, they are not the same thing cause a normal force isn't always going straight down like weight is.
Having re-read my post, I realise I didn't necessarily make it clear that the Normal force usually acts in the opposite direction to the weight. However, this should be clear from the diagram. They very much are not the same thing, and the Normal force does not have the same formula as the weight.
My point about the spring equation is simply that springs are not necessarily infinitely extensible. I realise that your x-x0 is intended to represent the extension.
Can I make the further plea - please consider putting universal gravity in. Your users will honestly love you for it, and it really isn't difficult.
Fine, I'll have that Gravity formula in, but since we already are gonna have many constants in our engine that will represent gravity for certain planets and our moon, not to mention the user can put in his/her custom gravity constant, I don't really see the need, but it'll be there.
By the way, weight and Normal force are the same equation, m * g. Just that Normal force has it as a vector, and optionally multiplied by an angle:
In the diagram above, for an object not on horizontal ground (as most objects will not be), the normal force is not equal and opposite to the weight. It is equal to the component of the weight force in the direction perpendicular to the surface.
It is clear in the diagram that the weight has no component in the x direction, but the Normal force does. Also, the magnitude of the Normal force is not the same as that of the weight. The motion of the object down the slope depends upon whether or not the component of the weight in the direction parallel to the slope is greatr than that of the friction in the other direction. Tilt your head to the left and it will be clearer. This also explains why the frictional force can vary - it can't be bigger than the component of the weight along the direction of the slope because otherwise the object would float uphill. It can be less, however, and so the object slides down the slope.
Okay just to break up all the serious talk here.. I have seen objects float Uphill...
Seriously.. So parts here we have some hills with very strong magnetic iron ore.. You stop the car, let go of the brakes and the car Slowly rolls UPHILL.. And just to check that it is indeed uphil, we dumped a drum of water on the road(Been non magnetic), it went in the opposite direction.
A compas in that area is useless.. From about a Km (2/3 Mile) away you still pick up residule effects of the magnetic field..
Sounds to me like we need to get a strong vector engine up and running before anything else.
Also, are we going to be inculding any non-physical physics (okay, that didn't make sense ). I mean are we going to be doing anything with light or sound or anything? I kind of doubt it, but I thought I might bring it up.
If anyone is interested I attached a .DOC that I made for my physics class. It has most of the basic formulas and some stuff that we won't use at all. I think it is pretty helpful. I will update it from time to time and post it here.
I've tried to hint at it before - this time I'll be more explicit. Why not just implement the general code to express any force in any direction? To get the direction, all you'd need is the vector joining one object to another object. To get the magnitude, you can then bolt on whichever "Force calc" you like. This gives maximum flexibility to the end user whilst still being easy to code.
In order to keep the speed up and the number of calcs to a minimum, you could give an object two properties for a force, e.g. Object.EmitGravity and Object.FeelGravity. When you work out the gravitational force on objects, you only calculate the force on those with Object.FeelGravity = True and calculate the magnitude in the direction of all those objects with Object.EmitGravity = True. This will be of much use when there are large numbers of objects, because you can set the FeelGravity = True property only when a collision occurs on an object. Hence as you are driving your tank towards a stack of crates, you don't need to be constantly calculating forces to check whether they are balanced or not - just set the FeelGravity property when the collision occurs and let DirectPhysics take over.
In this regime, all you then need to do is bolt in the expression for the gravitational force between objects and call it in when needed. Do the same for magnetic, frictional, etc.
To simulate gravity, you would then just need to create a point mass at a large distance below the game area and set its EmitGravity property to True. This would be the only emitting object (so you aren't calculating tiny forces between the player and a nearby tree), and the user could easily set the size of the mass, distance away etc. And hey presto, you've built in a fully functioning gravity simulator that will cover any circumstance. The same applies for all the other forces.
Suppose I have a stack of crates in the above diagram rather than just one. What is the Normal force on the bottom crate? You have not only the weight of that crate to worry about, but all the ones stacked on top of it, hence just arbitrarily bunging in an (mg cos theta) won't be correct. You need to calculate it for each crate in relation to the other crates - and hence you need to be able to swiftly do these sums. Clearly in this circumstance, as you iterate through all the objects in the game area and calculate all the forces on each one, you need to do them in the correct order otherwise you might not work out that the top crate is resting on the bottom crate. Or you have to do all calcs simultaneously - not great for speed. Or, you implement a "contact force" whenever two objects are touching and set the flag on this just as you do for any other force. Then, when working out the net force on any given object, you can trace back through the contact forces to work out the overall net force.
These are things you need to think about now, not in 3 months when the engine is halfway done and suddenly nothing is behaving as expected.
I understand the desire to get coding, but a few hours spent now will definitely save many weeks later.
Sounds to me like we need to get a strong vector engine up and running before anything else.
Also, are we going to be inculding any non-physical physics (okay, that didn't make sense ). I mean are we going to be doing anything with light or sound or anything? I kind of doubt it, but I thought I might bring it up.
If anyone is interested I attached a .DOC that I made for my physics class. It has most of the basic formulas and some stuff that we won't use at all. I think it is pretty helpful. I will update it from time to time and post it here.
Light and sound physics are not used in physics engines cause they are not needed. Just done in classrooms and labs. Nice Doc by the way.
Originally Posted by SAGremlin
I like what i see in the document..
Now we need to get these into fast code..
PS .. Jacob .. You must add that i'm the VB 6 class tester on the front page ..
Done.
@ zaza:
I already planned on adding angles for any of the forces.
Last edited by Jacob Roman; Feb 27th, 2006 at 03:22 PM.
The most important thing that is gonna be in our physics engine is the Integration class, which should be easy to code. It's gonna allow the user to choose an integration method, and will have a function to execute it. Some methods will be inaccurate and unstable, while others have their own pros and cons. It all depends on what you do. Like for example, Runge Kutta 4 would be perfect for spring simulations. While Runge Kutta methods (especially the higher order ones) are the most accurate and stable yet computationally expensive, Euler is the easiest to implement, yet is inaccurate and can easily become unstable. For future reference just incase I seem like I'm jumping the gun, here are some, which happen to be the most popular choices of integration methods:
x - Position
v - Velocity
a - Acceleration
dt - Delta Time Step Size
Euler Aliases: Forward Euler, Explicit Euler
----------------------------------------
x = x + v * dt
v = v + a * dt
2nd Order Euler
----------------------------------------
x = x + v * dt + 0.5 * a * dt * dt
v = v + a * dt
Verlet Aliases: Velocity-less Verlet
----------------------------------------
v = x - old_x + a * dt * dt
x = x + v
old_x = x
Time Corrected Velocity-less Verlet
----------------------------------------
v = (x - old_x) * (dt / old_dt) + a * dt * dt
x = x + v
old_x = x
old_dt = dt
Prescaled Euler Aliases: Newton Stomer Verlet Variant
----------------------------------------
v = v + a * dt * dt
x = x + v
Re-ordered traditional Euler Aliases: Semi-Implicit Euler, Newton Stormer Verlet, Backwards Euler
----------------------------------------
v = v + a * dt
x = x + v * dt
Velocity Verlet
----------------------------------------
x = x + v * dt + 0.5 * Old_A * dt * dt
v = v + 0.5 * (Old_A + a) * dt
Old_A = a
2nd Order Runge Kutta, Aliases: Midpoint Method, RK2
----------------------------------------
k1 = dt * v
l1 = dt * a
k2 = dt * (v + k1 / 2)
l2 = dt * a
x = x + k2
v = v + l2
3rd Order Runge Kutta Aliases: RK3
----------------------------------------
k1 = dt * v
l1 = dt * a
All this code is good.. IN VB its slow, Or too slow for multiple calculations..
And it uses a lot of floating point calculations.. Writing this in C++ and using some ASM to do some of the FPC.. Also using Ref. tables and Aproximation helps to speed up things..
sorry for no replies in past few days, but i am having some problem with my broadband connection, but i have started working on dpMatrix class (in C++), will try to post it for your views assp.
All this code is good.. IN VB its slow, Or too slow for multiple calculations..
And it uses a lot of floating point calculations.. Writing this in C++ and using some ASM to do some of the FPC.. Also using Ref. tables and Aproximation helps to speed up things..
Gremmy...
It was just an example on showing the results of each integrator. Of course it's gonna be rewritten for C++ and possibly some ASM.
Originally Posted by Harsh Gupta
sorry for no replies in past few days, but i am having some problem with my broadband connection, but i have started working on dpMatrix class (in C++), will try to post it for your views assp.
Harsh Gupta
Can't wait to see it. Hopefully it's got the same functions as DirectX's.
Speaking of no replies, it almost seemed as though everyone on the team gave up until you two replied.
Speaking of no replies, it almost seemed as though everyone on the team gave up until you two replied.
IMHO, this is the result of poor planning. You need to lay out a detailed plan and assign tasks if you want to see anything happen. Take a look at frogect rotamiton. The project was broken down into parts and each person was assigned their own task(s). You can't expect use to just read your mind and go off and get things done without some idea of what you want done.
Yes, you have given us some idea, but that is about all. If you don't break this project down into a detailed list of tasks and make goals about when you want things done then this project will remain paralyzed.
I'm not trying to be a jerk, I just want this project to succeed.
IMHO, this is the result of poor planning. You need to lay out a detailed plan and assign tasks if you want to see anything happen. Take a look at frogect rotamiton. The project was broken down into parts and each person was assigned their own task(s). You can't expect use to just read your mind and go off and get things done without some idea of what you want done.
Yes, you have given us some idea, but that is about all. If you don't break this project down into a detailed list of tasks and make goals about when you want things done then this project will remain paralyzed.
I'm not trying to be a jerk, I just want this project to succeed.
Maybe it's just me. No matter how hard I try and plan, it always ends up poorly planned, like what happened in LightFusion. I think it's best I leave that job to you, eyeRmonkey, since you know what you are doing. If you accept, then you are our new Project Planner.
I do know what I'm doing and all, it's just that no matter what plan I lay out, it doesn't seem planned correctly. Which is why I plan on leaving that task to eyeR.
Me and damasterjo know the DX syntax very well, and will be glad to assist on your syntax.
OK, here's something to get the ball rolling. It's a set of basic coordinate transform and vector algebra classes. There are cartesian, spherical-polar and cylindrical-polar coordinate systems and vectors in the cartesian system.
The global cartesian coordinate system has its origin at (0,0,0), and is easily replicated by:
VB Code:
Dim Global as CoordinateSystem.Cartesian
Other coordinate systems can be added in similar fashion. They can be offset in cartesian coordinates from the Global system using the XOffset, YOffset and ZOffset properties. They can also be rotated using the ThetaRotation and PhiRotation properties, where Theta is the angle in radians (0 to 2Pi) from the X axis towards Y and Phi the elevation towards Z (Pi/2 to -Pi/2). See picture.
If a system is specified as Spherical then the R axis is the Radius from the origin of the system, the Theta axis is the angle (0 to 2Pi) around from the local cartesian x-axis (as in the rotation above) and the Phi axis is the elevation (Pi/2 to -Pi/2) towards the local cartesian z-axis (again as above).
Similarly for Cylindrical coords, the R axis is the radius in the xy plane, Theta is the angle anticlockwise from the x-axis and Z is the z-axis.
Vectors can be specified in terms of two cartesian coordinates or in terms of x1, x2, y1, y2, z1, z2 values. The Length property retrieves the length or, if set, rescales the vector keeping the same x1,y1,z1 point.
Operations contains Angle operations to convert degrees to radians and vice versa, coordinate transforms and vector algebra. Coordinate Transforms include:
Converting a coordinate in one local system to an equivalent point in a different local system (e.g. (1,1,1) in cartesians to (sqrt3, Pi/4, atan(1/sqrt2)) in Spherical Polars etc). These are the LocalCartToSph etc functions.
Determining a new local cartesian point when the cartesian system is rotated by Theta and Phi. This is the RotateCartesian function.
Representing a coordinate in any one system in any other system. This is the overloaded Coordinate function.
There are also Vector operations, including Add, Subtract, DotProduct and CrossProduct. I plan to keep adding stuff to this, but it may be of interest now to some.
I have to respectfully decline the position of project planner. I am not the best at planning either and I don't have enough time to manage that right now. Sorry.
Maybe someone else would be willing to take up this role?
Hey im emersed in my project right now, and wont have time to help with this one, so you can take me off the team.
:EDIT: Sorry if that sounded rude, its just that, I am having so much fun with my projects and the graphics are really shaping up. So I wont really have time, although if you needed a small specific task or just wanted to ask a question or something, I would be happy to help.
Last edited by damasterjo; Mar 10th, 2006 at 12:29 PM.
Software languages known: Qbasic - TI-Basic - Liberty Basic - Visual Basic 6
Software API's known: Directx 7 and 8
Internet languages, in the process of learning: HTML - JAVASCRIPT - PHP - CSS - MYSQL - AJAX
Okay I still have no clue as to who's doing what here... Ermm, I'm not a coder in the project ( No C++ skills), but i'd like to know when to expect the first DLL to test...
Also something else i've been thinking about..
Do we realy have to do collision detection.. That basically meens that the Classes have to hold the entire body matrix.. this is a bit extreem... I recon rather hold only a reference X,Y,Z point (Center preferable..) ,Mass , X/Y/Z velocity, etc.. let the user do collision detection, And simply call a Collision with object function, with the details of the different objects that colided..
This will make it a lot easier to code the classes needed, and speed up the calculations.
Reply With Quote
Mark Thread Resolved
..
). I mean are we going to be doing anything with light or sound or anything? I kind of doubt it, but I thought I might bring it up. 
Originally Posted by eyeRmonkey
