ofxPhysics

ofxPhysics is a small project which i have been working on for the past couple of weeks. the problem i was having was making art that reacted in a realistic and efficient with itself (ie particles). at the time there were no specific physics engines for oF and any that were in c++ were complicated and used euler (im not fond of euler) so i wrote my own!

ofxPhysics aims to be simple and user friendly (still working on that) but also allows the user to control practically any aspect of the engine ranging from gravity to constraints. so far you can create particles, springs of infinite strength (sticks) and joints which offer some slack. so far i dont trust my code so everything is constrained in a 600 by 600 square. you can change this just by searching through the code and modifying anything that says 600. the current release is stable but still raw, so expect updates every couple of weeks. enjoi!

site: http://addons.openframeworks.cc/project-…-ofxphysics

also! don’t forget to visit addons.openframeworks.cc to host your addons there! it’s loud, it’s raw and it’s still awfully useful.

NICE!!! definitely something I can get into. I have been using a wrapped box2d to do physics stuff but this is definitely awesome. Once I get the box2d stuff better cleaned up I will release it as ofxb2Physics. Don’t forget to check out
http://www.cs.princeton.edu/~traer/physics/
if you haven’t al ready.

There is something wrong (maybe its me) with ofxPhysics-003. I dont see the ofxPhysics.h file and it looks like its missing some stuff. Would love to check it out though.

i have an addon called ofxPhysics too! :stuck_out_tongue: no problem renaming it… or maybe they can be merged. Its basically just like a traer lib for openframeworks. Been meaning to release it the past couple of weeks, but wanted to make sure there was no memory leaks. I intentionally used the same interface as traer so porting processing code to of would ‘just work’. It has particles, springs and attraction/repulsion etc… but not sticks or joints, so maybe could work together?

I wonder if it’s who ever gets there first, gets the name? I think it makes sense, though, to be more descriptive. for example, Artem’s library is using verlet integration, and for that reason, it be good to identify it as being of a certain style or flavor. I like how the libraries are named in processing (ie, sonia, proXml, etc) because they have individuality and express a bit the whims of their author…

we’ve had the same thing with the guis - so it’d be good to figure out a good system so there isn’t alot of collision and the author’s can get good feedback for their efforts…

on the non-compiling front, I’ve had to play a bit to get ofxPhysics to work, but I’ve got a version that compiles (removed references to ofxTouchLib, etc)… the example isn’t that explanatory, but its fun when you get it working…

take care!
zach

I vote for merging if all parties agree and the are compatible enough. I love the traer physics lib. I haven’t used it but from the examples I have seen it looks pretty neat. I think it is less of a load for more people to work on the same addon than for 2 people to work on 2 different addons that go in the same direction. I would suggest the same thing for the gui stuff but the codes are very different and seeing as the ofxGui is pretty much done it would seems like a huge pain to re-code. But I still would love it if the gui stuff merged. To me this seems like it is early enough for that to happen if memo’s work is compatible enough. It is great to see a push for this in oF. Good thing!!

BTW I havent got it to compile yet. Hopefully version 004 will be easier to compile :smiley:

I wonder if it’s who ever gets there first, gets the name?

lol, i’m happy to drop ofxPhysics, only chose it cos thats what traer calls its master class, and I wanted to keep the same interface. Actually the name ‘physics’ is a bit too general and isn’t the best name for what I have, as it is a small subset of physics (e.g. box2d is a brilliant physics library too, but is for rigid body physics). For now i’ll rename mine to something else. Gonna be a bit busy this week so won’t have time to look at integrating the libraries - compatibility is obviously gonna be important, but will try and post a clean sample in the meantime.

haha I actually wrote myself a physics lib too. It’s based on toxis verlet integration code he released in java. right now it supports basic particle system and springs. I personally like the feeling of verlet integration better than euler.

Ahhh!! rigid bodies. So thats why I have been using box2d. I forgot about that small point. Yes I definitely need collision detection and such. But the kind of physics addon being worked on here is definitely needed too. For some reason I thought that toxis verlet had rigid body integration. Am I wrong? What is confusing me is this
http://vimeo.com/1110950
looks like rigid bodies.

I’ve not used toxi’s lib, but I think it is just springs and nodes (judging by the Nokia vids). Though with verlet you can use constraints and build rigid bodies. I’m also using verlet (not RK4 like traer) and can build rigid structures with rigid springs and that works fine and i’m sure it would work with toxi’s lib too. And this ofxPhysics has a ‘stick’ connector, so I’m guessing you could with this one too. But I don’t have rigid body collision detection yet and I dont think toxi’s one does either (moka can correct me if I’m wrong), collision is only only on the nodes. More complicated collision can be integrated, but its not in by default. Thats where the difference with a rigid body engine (like Box2D) comes in. But Box2D is 2D :P) looks like nodes + springs. So not really rigid body. Rigid body is when you are dealing with entities which occupy space, and have no dimension changes on impact etc. (cubes, squares, cylinders, cones etc.)

No, his code released to the public does not have collision detection. I think collisiondetection is not that hard though. You can simply use ellipses (or ellipsoids for 3D) to create collision detection. It’s actually the technique used most of the time in computer games (as far as I know). I will try that in the near future.

BTW:
http://code.google.com/p/bullet/

this is great. i vote for integration of both libraries to make an amazing physics lib.

by the way… whats the difference between euler and verlet?

i use springs a lot, but usually use a technique by keith peters from his flash tutorials from some years ago.

to cut a long story short,
euler is the simple and logical:
new velocity = old velocity + force * time diff
new position = old position + velocity * time diff

For most simple cases this works fine, but is not very accurate (especially if timediff is not very small) because it assumes you are moving with a constant velocity for the duration of the timediff which is rarely the case. So when you have many interacting objects (such as springs and forces), systems have a tendency to explode (go nuts).

So many alternative ways of determining a new position from forces has come up which involve calculating the position and velocity etc at inbetween points in the given timestep. The more sample points you take in between, the more accurate, but computationally expensive obviously. 4th order Runge Kutta (RK4) is pretty industry standard for realtime purposes (video games etc.) as its quite stable (the system rarely explodes) and reasonably fast - but still quite heavy to compute compared to euler. Verlet is another higher order method which does away with the concept of velocity altogether and just updates everything based on your previous position and current position. Because of this there is never the fear of velocity and actual movement going out of sync and it is easy to apply constraints and is quite stable while being computationally very fast. Its not the most accurate (you wouldn’t use it to calculate trajectories when sending a satellite into space, i hear Nasa uses 8ht order runge kutta for that), but for such particle systems its pretty much the most efficient. Theres many tutorials and sample code out there discussing the methods.
http://www.forums.evilmana.com/index.ph-…-53.msg8587
is the best summary I think (LMelior’s post says it all).

P.S. I had a quick look at ofxPhysics, the features look good but I couldn’t get it to compile, and didn’t have the time to sort it out. I think it is 2D though?

1 Like

hey! thanks for the feedback!

ofxPhysics 003 is out and now it actually works. i forgot i made it an actual addon so i didn’t throw the right folder in the first time. also this is 2d so far. i am thinking about extending ofxVectorMath a bit and make my own pointmasses which i can modify however i want to. also i’m thinking about using LP_Array to hold my pointMasses and springs since LP_Array is a dynamic static array (if that makes any sense). basically it’s a static array that expands if 1 too many objects are pushed into it.

i’ve been hearing some noise regarding springs and that could make it into the next update. i also hope to give people more control over the engine through how much precision they want. currently i loop the joints and sticks 15 times to get the best solution. obviously when you have hundreds of sticks and joints this gets nutty, so maybe a little formula to give more precision if the number of springs + joints remains low and take away precision as more joints and sticks appear. it’s a speed over precision thing.

RK4 is insane, if you look at the integrator that traer wrote it’s about 100 + lines, i got close to 80 for the entire verlet engine. RK4 is fun and stable but it’s not friendly with a crowd. i have 2 xeons running at 3.06 and RK4 started getting choppy at maybe 400 particles plus springs. verlet runs smooth no matter what.

collision will be 90% verlet, and it’ll be the good precision, with projections and penalties. the other 10% will be paul bourke and his point in polygon test which i’ve been dying to implement! look forward to the next few releases.

ps. the first few releases (001 and 002) were relying on ofxTouch, 003 doesn’t, so get 003 instead and drop the previous releases.

pps. a stick is just a spring with infinite strength (firmness just sounds so wrong)

nice paper with code on collision detection
http://www.peroxide.dk/papers/collision/collision.pdf

very nice paper but i’m way too tired to read it. maybe i should go the way traer did and make you guys come up with your own collision code… nah, that would be mean. im going to look around more and see what i can get for pure verlet and in 2d so far. when im comfy with the code, i’ll make my own classes (extensions of ofxVec, or not) and then port everything over to 3D space. im still a fan of 2d cause that’s where it’s at. :stuck_out_tongue:

get ofxPhysics 003!! i need feedback so I can fix it if necessary

cool. I’ve renamed my classes to ofxMSAPhysics, obvious but safe :P. I actually did extend ofxVec3f for the particles and am quite liking the usability of it.

By the way, I had ofxPhysics on google code - dunno if you use googlecode or not - if you do, i’m not sure how I can delete or transfer ownership of the project or something :S

don’t worry bout it. my engine is still going through a shit load of changes so it’ll take a while. i have some hacked code (aka ripped and modded) that actually does collisions with sticks however if a stick is parallel to another stick on the ground then there’s an explosion and everything gets jammed into the bottom right corner.

Hi all,

Thinking about the name clash on the libs… and that both addons provide (if I understand it correctly) basically the same functionalities but with different implementations, would it be too much work to throw in some CS and define a common interface that is implemented by the two addons?

That would be a clean way to join both while -at the same time- allowing each developer to improve their own implementations…

all the best,
–k

we could, or just use a basic #define, eg:

  
  
#define OF_ADDON_USING_OFXPHYSICS  
#define OFXPHYSICS_FLAVOR_VERLET  
  

or

  
  
#define OF_ADDON_USING_OFXPHYSICS  
#define OFXPHYSICS_FLAVOR_EULER  
  

that would be the simplest because then all we would have to change is the ofxPhysics.h file to:

  
  
#ifndef OFXPHYSICS_H  
#define OFXPHYSICS_H  
  
#ifdef OFXPHYSICS_FLAVOR_VERLET  
#include ...  
#include ...  
#include ...  
#else  
  
#ifdef OFXPHYSICS_FLAVOR_EULER  
#include ...  
#include ...  
#endif  
  
#else  
printf("no flavor specified! \n");  
  
#endif  
  
#endif  
  

see not that hard… but i think we both need to work on our engines more before we can call this merger.