irrlicht physics - what would it take?

[chronologicaldot]

Just to get the discussion going in one place, what would it take to set up a kind of plug-in-play sort of system for physics engines in irrlicht. i.e. is there some way things can be set up so as to make it easier to incorporate different physics engines into the irrlicht engine? Or would it be best to make things / leave things more opened up to allow people to do their own raw incorporation? Or do we just keep writing physics wrappers like we've always done?

[AReichl]

Maybe similar to the LightManager?

[cat.exe]

I've been thinking about writing my own physics engine for irrlicht. I'm kind of fed up with having all these wrappers, and I've always taken an interest in physics libraries.

[Granyte]

Well It really depends on what you are aiming for and a defined way to plug in physic engine done in the traditional irrlicht style would likely prevent me and others from running physics in a thread and rendering in an other

[AReichl]

Well - if the physics engine INTERNALLY is multithreaded, then let it do it's work.
I would go for Bullet.
IrrBullet seems like the best choice (has more features than other wrappers).

[cat.exe]

True - There are some great wrappers out there, but they're still wrappers. I agree with OP to some degree, that it would be nice if there was a physics engine for irrlicht, but it would be a lot of work.

[Granyte]

even if it is multithreaded internally (bullet is not yet) you still lose the time for the physic cycle to complete not rendering in my personal project this time could become as long as the time needed to render the scene moving that to it's own thread effectively doubled my fps

[devsh]

Bullet is internally multi-threaded, the newest version can even run rigid body dynamics on the GPU

What you guys are starting, is basically a discussion on how to package a simple physics engine with irrlicht.... I hate to bring bad news to the party but c'est impossible

You either make it easier to plug-in physics engines to irrlicht... or do nothing at all.

I will now make the case why its an idiotic waste of time to implement a physics engine...

A) Rigid-Body mechanics require someone with a university degree level knowledge to actually implement
This is not a discussion of "but you say the same thing about picking, and look how useful that is", picking requires really basic maths, intersections between rays and planes plus checking if an intersection point is surrounded by 3 lines. PHYSICS REQUIRES HANDLING OF ROTATIONS, now to calcuate rotation in 3d is not simple, it involves tensors (2nd and 3rd year university level maths) and calculating how much this weird roation quantity has to change in respose to a force acting at point X away from center of gravity and in direction Y is not a walk in the park (actually turning cubemaps to spherical harmonics and implementing sky scattering shader nested integrals of exponents is a lot easier). The 3d rotation is multiple orders of magnitudes harder than your high-school cacluations of moments in 2D cases.

B) This is not an argument equivalent of "lets ship a deferred renderer", its a case of "lets ship our custom software renderer because I hate OpenGL/DirectX wrappers"
Seriously, doing even just rigid body collision is a highly optimized and complex problem, which is matching in complexity to rasterization. Do not think you'll be able to produce something that could even provide the same level of functionality as Bullet in 2004. You need to handle collision detection EFFICIENTLY, AT LEAST between boxes, spheres, capsules, convex hulls and triangle meshes.. even the algorithm for construction of a convex hull requires meticulous consideration and an efficient implementation of one of MANY algorithms. Then you also need to optimize the collision detection and animation by differentiating between static and dynamic objects. Bullet can only handle 1000 dynamic boxes in realtime, and that with optimization (putting actors to sleep, waking them up, dynamic space partitioning algorithms for speeding up collision detection etc.), what makes you think you can achieve even 10% of that throughput??? What are you going to do with just 100 moving objects in the scene?

C) Collision Detection is not the only thing that goes into a physics engine/animation
You need to schedule, multithread, make the entire design thread safe (as of now nothing in irrlicht is thread safe). You need to be aware of typical physics engine issues and how to solve them, like tunneling. You may need to implement CCD! Anyway the collision Detection is the part that takes maybe the 3rd place in the list of most time consuming tasks of the physics engine, what actually happens is:
1) Update objects according to physics iteration timestep (like FPS) and their velocities
2) update acceleration structure ( octree or something )
3) run collision detection
4) wake up certain actors
5) RUN AN ITERATIVE CONSTRAINT SOLVER
6) Calculate the forces acting on dynamic objects and "listeners" and update their velocities accordingly

Steps 5,6 are even more complex than collision detection (which is already hard enough). The Iterative Constraint Solver is the heart of a physics engine, this is the thing which given a set of constraints must calculate how the forces will spread over the entire system of dynamic objects interacting with each other, as "for every action there is an equal and opposite reaction". Basically you cant look at just the two objects colliding with each other, you need to examine the entire chain/network/graph of objects colliding with each other and solve many simultaneous equations governing the effects they have on each other, this gets even harder with immovable (Static) objects such as the floor. This is worse than fluid simulation where the problem is pretty much the same but the graph/network at least can be arranged into a uniform grid and the iteration steps are relatively simple. Here you have a freely shaped graph and multiple links to other nodes in the graph which indicate interaction (in fluid dynamics you always have 6 neighbour nodes). This is a bitch to implement given special cases (character controllers, static actors and gravity) and one needs to be knowledgeable about iterative methods (discrete mathematics), the conditions for convergence for a solution and the speed of convergence. Sometimes you can pick the wrong iterative algorithm and not converge EVEN IF YOU THROW THOUSANDS OF ITERATIONS AT IT. Just to prove how much of a mindfuck this is, consider the following: There are 8 objects {a,b,c,d,e,f,g,h} all with their centres of mass and masses, some velocity (I wont even add angular velocity here) and these are the collisions between them {a collides with,f,g},{b collides with,d,f},{c collides with,d,f,g,h},{d collides with,b,c,h},etc. and you also have the static object of a floor which cant move (sometimes implemented as an object with infinite mass) and stops {f,g,h} which are touching it from going through it. Now please go and think about how you would calculate the net force acting on each object given that every collision pair needs to exact an equal force on one of the partners and the other needs to exert an equal but opposite force on the first one and all of them are linked in that way in the collision listing. Now think that this algorithm must handle an arbitrary mass, center of mass position, and velocity. Oh and did I mention you also have gravity force acting on all objects downwards?

Now comes Step 6, you have to translate all these forces acting in all the different directions at all the given collision positions (which are different to centres of mass, otherwise no rotation), into increases/decreases in velocities. And here is where all these nice rotation tensors come in and the represenation of angular velocities.

OH AND DID I MENTION YOU HAVE TO DO THIS MULTIPLE TIMES PER FRAME WITH A TIME STEP OF LESS THAN 5ms AND EACH TIME RUNNING THE ITERATIVE CONSTRAINT SOLVER!?

D) Now find me a person who knows all this maths and can implement this, and has the time to do so and is not already an irrlicht dev?

E) all of the above are required just for the most basic usable physics engine with just translation and rotation

[Granyte]

No bullet is not internaly multithreaded it offers a multi-threaded solver and dispatcher to use but they are not the normal operating mode and do not work properly in every case
heck I found about this issue in 2012 and it's not yet working https://www.youtube.com/watch?v=svdpP1Z ... w&index=13

even better the lates bullet 3.0 I downloaded the multi-threaded solver and dispatcher are no longer even built

as for the OCL GPU implementation it's cute and really fast I got it around 150k bodies @ 45 fps wich is acceptable for such an amount of objects but it to lacks ghost object support and it even lacks double precision support so while the stresstest I did with it in my game engine where impressive it's still useless atm

[chronologicaldot]

lol. devsh, no one here is building a physics engine. That's not what I was asking. I was talking more about incorporating existing physics engines into the irrlicht engine or writing wrappers. As it is, irrlicht has its own mesh format, its own animation format, its own XYZ for doing stuff. Notably (while I'm not suggesting this), it would obviously be easier on people if classes of irrlicht were more aligned with some existing physics engine, and then dropping things in / slight modding would allow for easy incorporation of a particular physics engine that does its job without necessarily needing wrappers. On the other hand, it backfires when we want a different physics engine, maybe something 2D based. I said all that, and all I wanted to say was, "We're not making a physics engine."

[mongoose7]

Correct me if I'm wrong, but the main problem with integrating a physics engine is conveying an Irrlicht mesh, or some other shape, to the physics engine, which uses a different representational system. The problem is fundamental, so either you suck it up (if you can) or you use one of the wrappers, of which there are a few. It doesn't seem to relate to Irrlicht at all. Perhaps what people really want is an example in Irrlicht which uses a physics library?

[christianclavet]

I agree in some degree with devsh. It would be a waste of time having full physic in Irrlicht when there are already other libs and wrappers that exist. But I would really like that Irrlicht collisions and picking be improved more. Perhaps having only to deal with forces like gravity,and impulsion added for "really basic" physic. Irrlicht could account for a ball that hit a wall but not much more.

The current collision response animator is not worth using. I've tried using it on multiple characters and it kills the frame rate. Now, I'm using only ray cast tests and have basic navigation working on object. (Characters are "picking" the ground and in front of them when they walk to see if it's solid or not). Using ray-cast tests, it's more than 10 times faster than using a collision response animator that get stuck all the time.

What would be interesting to have for me that at some point, is that Irrlicht could have theses features (without having to resort to a full physic library/and/or wrapper)
- Improved picking (the current one we have is not too bad, but I'm sure it could be improved)
- Improved and much faster collision detection.
- MULTIPLE Character controller (Current collision response animator is not worth using for characters)
- Ability to define a collision mesh, or use a pre-defined shape for the collision model (sphere, bounding box, ellipse). Would use the bounding box by default. If using a custom mesh for collision, would do a bounding box first before checking the polygons.

My math skills are too poor for doing this, and I can't evaluate what I'm talking about is really possible. I know that implementing this is possible, but I don't know if once theses are implemented, it would have a "good enough" performance.

This would be enough to create simple games out of the box without going in "full physic".

[ralian]

That sounds like it would make a cool lib, for people that want a simple engine only
for basic things like acceleration but don't want to implement something like bullet.

Actually I find that interesting. I think it would be cool if someone wrote a 'plugin'
that used the irr::physics namespace and had things like traditional animators that
did simple physics operations, things like
[*]Acceleration
[*]Collision response
[*]Harmonics
[*]Joints
and maybe even multithreading for simple projects.

[AReichl]

Then have a look at the
"Irrlicht Dedicated Physics Engine"
http://irrlicht.sourceforge.net/forum// ... =6&t=42559
We could take it as a "starting point" and add more needed features as needed.

[ralian]

That looks pretty cool
I'll have to test it out this weekend. It so happens I've been looking at options for a new project of
mine, I don't want something so advanced as bullet but I definitely need more than just animators.
I could definitely adapt that for what I am doing, and if I do so I would be happy to release some
code for you.
I am a big fan of bullet though, but it isn't the right tool for every job