Theory of physics engines

**Actions:**View

**Abstract:**

This is just theory, but it's something I've been 'mulling' over for a while.

For a long while now, since GCSE, when I learned to use the Trapesium Rule for estimating the area under a curve, and learned that the area under a velocity against time graph was the distance I've been interested in "Physics Engines" as they've always been called, I've now done Mechanics 4, and the scale of "goodness of work" and "mechanics module number" is not linear, I loved it, coupled with all my (further) pure work I can now TRULY look at the world in a mathematical light, the work I'm about to highlight isn't particularly advanced - I can just see it now. The only way I could explain is it is: "Have you ever had an idea where you get something, but by trying to think over the components, check it works, forget or loose the idea?" it's been one of those, but now it's so pure, proof that mathematics isn't hard it just requires a lot of practice with each step.

ANYWAY, the idea!

this is more geared towards "Numerical" ways of 'doing physics' if you're looking for calculus methods or more general methods this is not it.

We all know about Force (Acceleration), Velocity and Displacement, weirdly, conveniently, although I suppose "could not be any other way"-ly we never need to bother with change of force with respect to time () or the unit above Displacement, "Meter seconds" () whatever that would be, this makes the most sense as meters is a fundamental or elementary unit so I could believe there's little use in "higher" units, however (To call upon philosophy) how could something like velocity and acceleration be considered meaningless? they are most certainly not, but why stop at 2? An extra side-thought refers to moment generating functions (Something I've just started from Statistics 4) Expectation or mean is first order, variance second, skew third, and some greek unit meaning flat-ness fourth, these are not 'derivertives' but strangely differentiation does get involved, perhaps mean and variance are our velocity and acceleration, a 0th order moment generating value (not sure on my terminology yet) must be one and that I suppose is analogous to "distance" what a lovely thought.

It should also be noted that centre of mass calculations and expectation calculations are IDENTICAL, and moment generating functions are - from what I can tell at this early stage - somehow similar to moment of inertia calculations.

enough of that off-topic-ness I just wanted to add the human element of some thought!

Force can change velocities, these can change distance, force is really 'all we need' to control distance however we like, also everything acts in terms of force, you don't see any devices that cannot be modelled using Newton's Second, or the third derivertive of distance, springs, force and extention, dashpots (the thing that slows doors down) apply a force against velocity, friction against velocity (drag) ... so forth, all force.

It therefore makes sense that any simulation should be defined purely (for simplicity, and at least, other functions are simply extending functionality) in terms of forces.

The set up of this simulation therefore must be nothing but a list of "what forces act upon" I call these particles, the alternative was "masses" but that is an attribute of a particle and also for future development, you could define a stationary particle that ignore all force applied to it (yes this breaks conservation but consider modelling a bridge, you'd need the two ends to be stationary, or the floor they're on to be stationary, if this were to move, it'd not only reduce the accuracy of the simulation but make everything oh so complicated)

It should also be familure to draw static things in diagrams for actual problems, like the point a spring is attached to, or the ground, so forth.

So we have these particles, each movable (from now on, just particles, I'll say static where I mean it) particle can have forces applied to it and each one must have a mass.

The simulation, being numerical in nature must be "summations not integrals" that is, dt () must be useful in the form where is our timestep, the integral comes from the limit of this towards zero, that sum is the midpoint rule yes, but you get the idea.

The first "talk" will be of a simulation of a bridge, springs will stop collisions, while I actually studied collision first it actually makes more sense this way.

Our bridge will just be a "rope" basically, this rope will be a numerical rope (Hyperbolic geometry and intrinsic equations can be used to describe hanging ropes but remember this is a numerical simulation, the hyperbolic models come from the limits of gaps between particles towards zero, summations becoming integrals) so will be particles a length apart, each particle will be linked by a kind of rope, I say a kind because there are some useful properties, more later.

I call (I made a few letters up for common tasks) each particle in this rope an "Ersis" (say ur-sus) and each bond between particles a "Co-ersis" or "Coersis" for simplicity, say "Co-ur-sus".

In a "perfect" rope each Ersis would always be the same length from any other Ersis as the Coersis between them could not change length, the rope is "inextensible"

Each ersis is a particle, and to have motion on such an ersis we exert a force, because forces influence velocity which influences displacement, to exert a velocity (impulse) would be silly because we've already said how every (I would say most, I talked about this above, to play it safe) system must work in terms of forces, I am sure there is further 'proof' in that to only influence Displacements second derivertive we keep it "smooth" and controlled, I cannot yet justify this, it could just be simply to avoid the constant of integration, exerting a force affects the velocity but does not require us to know the velocity of the particle we're exerting it on.

So lets assume an ersis linked to a stationary particle by an coersis falls under gravity, and that our coersis is inextensible, this means the ersis will not fall down but will curve, tracing the arc of a circle of centre the stationary point, this means that for sufficiently big coersises we get more of a chain than a rope but something much more noteworthy occurs, simple harmonic motion, the ersis will occilate about the lowest point (1 coersis length below the static particle) as a pendulum would, meaning that a definition in terms of force is valid. for each time step we must apply a force to the object proportional to the extension of the co-ersis, ideal such that the force would do no more or less work than required to bring the coersis exactly back to its natural length.

This sounds like a spring to me, this will also lead to occilations, this is a simple spring trying to get into equilibrium problem. Dampening is a thought that should occour, more later.

One of the lovely things about force, as mentioned, is it means we need not know the particle's velocity.

We also know that the net force on an object is the sum of all the forces (forces are of course, vectors)

Our particle object will need some parameters, namely,

mass - an unsigned float,

static - boolean

position - vector3 [vector3 being a 3 part vector, vector2 being 2...this is 3 dimensional]

velocity - vector3

force - vector3

acceleration - vector3 - not strictly nessasary, but helps "see" this system

A vectorN is N float value corrisponding to N perpendicular unit vectors times float scalars, it is 3 floats in storage terms.

A particle will need the following functions or methods

add_force(Vector3 Force)

simulate(float timestep)

this is not a programming guide, so I will not go any further with definitions.

Every timestep the accleration vector of a particle must be set to zero

particle->force_add(force_vector) must be called by everything that exerts a force upon this particle

simulate must be called only after all forces have been added, it will take this net force, work out accleration and apply it (using the timestep) to the velocity and position vectors, it must then reset the force vector to zero.

By Newton's second:

where A, B, C ... are forces

hence

(if you are unsure you shouldn't be reading this, but by dividing all the terms by M we get which can be written (by taking a factor of out) as

therefore we need not calculate the acceleration change with each force, we can simply sum the forces, and divide by mass, I know from m4 work that the change in force over "dt" (change in impulse as delta t -> 0 of a system at t and t+delta t) is just the force, we do not need the derivative say of the force, just the force, so - given over a timestep the mass stays constant - which it does - the above is fine, sum the forces, divide by mass, * timestep add to velocities, so forth (midpoint rule usage from the summation integral link defined at the start)

the add_force method accepts a force, and adds it onto the particle's force vector, vector addition is computationally easy. the simulate function on a static particle will do nothing

Now let's consider the rope, a coersis "model" will know which two ersises (or particles, as ersises are particles just named ...) are on each end, it will have to get their position, and calculate the distance (another vector3) between the first and second ersis, this is a vector so also has a direction.

The coersis will then have to exert a force proportional to the length of this vector (by pythag in 3d) subtract its own natural length (which will be a scalar, positive or negative).

If the first ersis is on the left, the second on the right, and we move from left to right, by stretching these apart we want the force on the left to be towards the right (along the distance vector) we want the one on the right to be against the distance vector - towards the left, if these are the other way around, the signs all flip, everything still works.

let x be the extension of the coersis, k be some constant and D be the unit vector of r, where r is the vector distance of ersis1 to ersis2. D is hence a direction vector.

ersis1->add_force(Dxk)

ersis2->add_force(-Dxk)

Newton's third states that for every action there is an equal and opposite reaction, this keeps with that, it would also make NO sense to apply 2/3rds of the force to one, and the 'standard' amount to the other, if you put a spring between your fingers and stretch it, both feel the pull, this conserves momentum (by impulse methods)

if ersis1 is a stationary particle, forces wont affect it.

now you can link ersises with coersises and 'springs' between them will keep it in shape, given the lack of calculus (as integration is numeric) you can make k, not a constant but a function of x, you could make it so the bigger the displacement from equilibrium the more it pulls, (use x^3 for example) by stability of equilibrum "methods" oscillation will have a much lesser amplitude, remember, if you used x^2, the signs would be wrong, I take multiplying vectors here to mean multiplying their scalars together.

as EVERY force will be added to every particle before simulate is called particles do not move around during the timestep frame, if we did the force calculations on one ersis, and simulated it, that'd move, then the next ersis would have a larger extentsion, it'd be stupid meaningless and chaotic, applying all forces (by looping over the coersis list - of springs linking ersises then calling simulate on all ersises) this way is much cleaner, and true in the limit of delta t towards zero, as expected and required.

the length of a coersis must be small, using Intrinsic methods to get a hyperbolic equation for a rope uses infinitesimal length-steps, thus extension is infinitesimal, and the spring model is hidden by limits tending towards zero. much in the same way a cylinder with a cylinder cut out, so a radius of r+dr and r of two circles being the area extruded down (where dr means delta r) as dr->0 the area of top side becomes 2(pi)r, but keeping with delta r (dr) we actually have:

(pi)(r+dr)^2-(pi)r^2 = (pi)[r^2 + 2rdr + drdr -r^2] = 2(pi)rdr + (pi)drdr, notice how we can sum this over dr, to get an integral, the other expression has a 'spare' dr, which would limit towards zero, thus being zero * a summation, leaving us with just the sum of 2(pi)rdr term. as expected. this term that went with (dr)^2 in it is the springs that would pull mass units together, but they are not needed and complicate things when using hyperbolic methods.

That is how one could simulate a rope.

Lastly, and now much more simply (kind of) colissions, frictional forces (sliding / toppling) is something I've not really thought about yet, does it act with surface area, a rigid body cannot have a corner dig into it so a pointy object would need special modelling to be pushed (as if the point were to puncture the surface) - as this would exert great presure. BUT if you are pushing a box against a curb (a right angle on the floor) you would expect it to stop. there's a lot to be thought about here, if you really are interested, I'm playing with the friction <= coefficent of friction * normal reaction force model.

if a particle - which are now objects as they have surfaces, dimensions, sizes and so forth - is say a cube, and it's on a table, we all know that there's a force acting upwards to balance the force acting downwards to create no net force, and keep it still, but if you throw it at table (modeling the table as static) it must bounce, or the table must apply a bigger normal reaction force, this is better modelled using momentum methods, and the impulse of a force is force*time (formally ), we know over an infinitesimal timestep rate of change of force is not important so we can model this as F*timestep, given timestep is small (and or that the force is pretty constant over the time interval).

The way I model this involves defining vertexes of the objects, corners, 3d co-ordonates or bounds of the things that define faces of the object, a cube has 8 of these.

One must then test to see if a line between this vertex and any one its connected to (in a cube each vertex would have 3 connections, as 2 make an edge and any corner has 3 edges meeting at it) - which would form a line - intersects with the FACE (region enclosed by vertexes) of any other object.

Consider dropping a cube with a point down onto a plane, lines between the vertex and connected vertexes will pass though this plane when the objects intersect, to intersect (at any point, even if it is right on the vertex - not the lines from it) they must have collided, this means a normal reaction force needs to be applied, if there are no intersects, no force need be applied (or the object is going so fast and the timestep so big it passed right though the plane in one timestep)

The force applied needs to be enough to keep the density of the object * the volume bounded by the plane it intersected the vertex that passed though and the faces of the object that have partially or fully intersected with the plane off the plane, a simple model is to apply "mg" as the force up where m is the mass of the interesecting volume, as this will balance the mg down of the intersecting part of the object, as more falls this will get greater + a little bit to move it up slightly and stop it intersecting with the plane in the first place, otherwise it'll just stay still.

this's a formal way of saying "with the cube, pointing down, the pyramid made by using the plane to cut the corner off where they've intersected should be pushed up with enough force to balance out that bit and push it back up so it's not intersecting.

this method is VERY jittery, and due to the errors of floating points can make the object jutter violently then fly off. ALSO how much force do you apply to push out the intersecting mass? mg would keep it where it is (but then the object moving down would move it further in anyway) I think, where m is mass of the intersection, m^2g would be better as for fast moving objects its a bigger shunt up, but for small values m^2 is smaller, so it may converge with the object being "in" the plane so far as the mass (not weight) of the intersection is a force of 1 newton (m^2g = mg where m=1).

I think Impulse methods (using the coefficient of elasticity) would be better these methods could only yield a bounce if the upwards force was "quite high" this implies a constant is needed to describe the upwards thrust, more being more bouncy, this could be (related) to the coefficent of elasticity.

It boils down to: if I apply mg, that'll just negate the weight of the intersection, if the object is placed on a plane so that it is at rest when on the point of intersecting -only then does this model work.

force, we must remember is mass * accleration, and accleration is change in velocity over time, which given we have a numerical time step means we are "numerically differentiating" velocity, so an impulse method involving altering velocities could yield a force (which we could then equally and oppositely apply to both bodies)

That's just my thoughts, I have yet to write a single line of code.

Alec.

alec-teal.co.uk development update - 1st of April 2012

**Actions:**View

**Abstract:**

Just a dev. update.

This is just a development update, but I've been working on the blogging system the article below was "written" a while back, hence the title, but now I can edit blogs, change them at will, it's starting to come together.

The biggest change is the way it parses tags, I'm using a block parser similar to that of the Mercury shell it'll hopefully be more efficient then those changes may be mapped onto the shell, I have found no documentation on my parsing method, which given its (proven) efficiency is a good thing!

Alec.

Calculus on x^x like functions and k^x 29/3/2012

**Actions:**View

**Abstract:**

This is a bitch of a question I encountered just now, and I've just worked out how to solve it.

It's actually really simple, you just need to get it into a useful form, firstly

now we can do things with it.

**Differentiating**

let

then:

I prefer this form

**Differentiating**

same logic, let

then:

alec-teal.co.uk development update - 29th of March 2012

**Actions:**View

**Abstract:**

This is just a generic post about what's new, and proof that things are happening.

THERE IS STUFF GOING ON, finally I've forced myself to create the membership system, and this blog or messenger system. Currently it's just a strip of posts BUT the plan is to make it so posts can form "tree" structures this will allow for responses and proper things to be done and ideas developed, especially if I get someone else on board.

Each blog post will support comments, but comments cannot be put into a tree (due to the fact of how would you express that) but I will create a system for using @[username] meaning people can respond directly to comments at themselves.

I've also been working on a math parser, but it's not very general case, here's an example:

and that has come from:

(math)v(T)={m(0)v(0)+int{0}{T}{(F(t))}dt+int{0}{T}{({dm(t)}/{dt}u(t))}dt}/{m(T)}(/math)

where the () around the math tags are actually [], like BB code.

That's my fourth-law-of-motion, a rather tongue-in-cheek take at Newton's second being unable to handle (or at least that ways I tried, it still kind of is his, it uses momentum, evidently) a system expelling mass at a variable velocity (variable being not constant, or not constant in relation to the objects velocity (like a rocket expelling mass at a constant relative velocity)

but! that's for another post.

Stay with me.

PS:

Registration works; and I've not done a SONY, be assured passwords are stored securely/properly.