Project Surface Physics with Bullet

[dumbo2007]

Hi,
Here is a little toy to play with (if it works at all) :

http://www.megaupload.com/?d=BBBB0DAF

http://www.filefactory.com/file/cf29836/n/Upload.zip

So I have finished a basic version of an All Terrain Vehicle.

Thanks to CoolHand for the awesome mesh and for conceiving the whole idea.

I put the zip with the addon in the above file upload sites as its quite large...so please bear with the wait time. The download is about 9 MB basically due to a large texture for the rover hull.

Alternately you can also try the file attached with this post which does not include the texture and is about 3.3 MB

Its a zip containing the following :

1. A Physics folder which contains the Viewer.exe executable. It runs all the physics. You need to start it before you start Orbiter. On startup it will wait till you start the ATV scenario (explained next)

2. A folder called ATV inside the Scenarios folder will contain the ATV scenario after you paste it over the Orbiter installation - this is as you would any other addon. This scenario has 3 vessels only - Brighton2(Controlling base), ATV1(this is just the chassis) and ATVShuttle1 (ATV Shuttle)

3. You need to start the above scenario after you start the Viewer. Once the scenario loads, the Viewer detects this and will load the physics world. You will be able to see it in an OpenGL window. So its best to run Orbiter windowed for the moment. You can minimize the OpenGL window. There is also a black console window opened which prints some messages useful for debugging. You can minimize this too if you want.

4. The scenario will load a sample test terrain which is all green colored and you will be looking down at it from high above the Brighton Beach tank. At this point you need to press C to connect to the Viewer. You must ensure that the vessel Brighton2 has focus as the key press must go to it.

5. This will allow Orbiter to connect to the Viewer and you should see the ATV chassis rolling about on the green terrain. You can now change focus to ATV1 which is the chassis and move it about using the arrow keys. Up key is accelerator, DOWN is brake, W is gear up, S is gear down, A is neutral, D is reverse.

6. You can also reset the scene by pressing R

7. Now you may change focus to ATVShuttle1 which will be waiting in one of the landing pads. Press G to attach/detach it to the chassis. Press F1 to go inside the shuttle. Use the keys as in 5 to control the chassis + shuttle combined vessel

8. Possible problems if you are using Vista or Windows 7

If you are not running an administrative account then the Viewer.exe will fail to start. You will get an error in the black console window that says Unable to create shared memory file(5) ....or something similar.

For testing you need to run from an Administrative account or Run As Administrator, the Viewer.exe executable. You also need to start Orbiter as Administrator as it needs to access another program's data.

Alternately you need to assign the Create Global Object privilege to your standard user account. If needed I can explain how to do this later.

I understand that 8 is a security risk and a bit of a hassle, but unfortunately both programs need access to each other's data and thus needs certain elevated privileges.

The access is to shared memory files which have to be made in the global namespace to be accessible to all programs. If this is not an issue then I would like to continue to use shared memory as its makes transfers very convenient. Otherwise I can think of a socket based implementation but that may run into firewall issues(each approach has its tradeoffs).

Another problem may be that the vehicle movement is very slow or jerky. This is possibly due to obsolete OpenGL drivers. I am working to make the application independent of OpenGL, but as of now the OpenGL window is very useful to see and change things in the Physics world simultaneously.
You can play around with the Physics there too.

In the OpenGL window,
F10 is for changing camera, keeping ctrl pressed and moving the mouse with the left button pressed allows changing the view point. Use right button to zoom in and out. You can pick and move objects around and they will move in Orbiter too. I am working on making the interface similar to Orbiter.

This is purely a development release to see if the concept works at all on other computers.

Also , the rovers wheels will leave the Moon's surface at large distances as discussed here :
http://orbiter-forum.com/showthread.php?p=275384#post275384

Am on it !

Code included in OrbiterSDK.zip. clbkGeneric() is heavily used to pass data structures to vessels and other signals. BulletBase::moveAttachedVessels() is what actually applies the physics in Orbiter. Always nice to have some code peer reviewed !

 

[Artlav]

Finally! The ghost of meshland is dead and someone is working on collision detection again!

Looks good, how do you integrate the physics engines?
I.e., the orbital mechanics of Orbiter and the collision stuff from Collada?

Or, do the just render in place?

 

[dumbo2007]

Well currently I run the physics engine in a separate thread and put the calculated positions in global variables. Then I just use Orbiter to render the objects. There is no connection with Orbital mechanics as of now. I was experimenting with shared memory as well so that I can run the physics in a separate application for maximum parallelism and thats real time too.

I am planning to write a plugin for 3d max or blender that allows a user to build up a ship or a base along with the physics world from more basic objects such as walls, doors etc. Then the plugin can export the C++ code and this can be compiled. Basically meshes have to be loaded and animated in Orbiter according to the objects they correspond to in Bullet.

Furthermore vessel can have objects inside them constrained by its hull. It can run its own physics world in a thread to allow the main rendering thread to continue.

I was wondering if anyone has any idea if a function for translation and rotation of attachment points like
void VESSEL::SetAttachmentParams ( ATTACHMENTHANDLE attachment,
const VECTOR3 & pos,
const VECTOR3 & dir,
const VECTOR3 & rot
)

is present in the API for meshes too. The current method of using 6 animations for each object for 6 degrees of freedom can get unwieldy for large numbers of meshes esp if I have want to delete meshes at runtime.

 

[dumbo2007]

Scrambling over jagged rocks

Well I finally got a basic terrain loaded into Bullet. I made the terrain following this tutorial which gives a quick and dirty way to do it :


http://www.delta3d.org/article.php?story=2005070111291094

Here is a video of a vehicle scrambling over the terrain :

I used the msh exporter to export the terrain out of 3DS and then wrote a MSH importer to only import the triangles in the first group into Bullet. Now the next step is to make a triangle mesh out of the Orulex heightmaps and to improve the vehicle rendering.

 

[Wishbone]

Yay! May I enquire if there's a way to go under the terrain? It will be great fun to ride a rover on Martian highlands, but somehow I miss the chasmas and gorges as well, and most of the lowlands, too.

 

[Grover]

will this be easy to use for developers? making custom vehicles and rovers sounds like an awesome idea. imagine deploying a custom rover from your future vessel of choice!

 

[Arrowstar]

I don't suppose this could be integrated as a module for Orbiter that would make it independent of vessels? It would allow for universal surface collision detection.

Great work! :tiphat:

 

[dumbo2007]

Thanks for the support everyone !

May I enquire if there's a way to go under the terrain?

Yah that can be done. The collisions are done against a triangle mesh so if the mesh is appropriately modified then it should be possible. Bullet supports concave triangle meshes so caves etc could be done.

will this be easy to use for developers? making custom vehicles and rovers sounds like an awesome idea. imagine deploying a custom rover from your future vessel of choice!

Well I have plans to use 3DS Max or Blender's SDK to make a custom plugin that will allow vehicles to be attached to a base when the mesh is designed. So the physics and the graphics can be developed together. Lets see what kind of algorithms and structures are needed to make it from scratch at the moment. Perhaps I can generalize it more as things progress.

It is important however to note that I use attachment points to attach the rover/Vessel object to the base(also a vessel). That is not really of any consequence except that the base must be fixed. Its movement will get transferred to the rover otherwise.

I don't suppose this could be integrated as a module for Orbiter that would make it independent of vessels? It would allow for universal surface collision detection.

Well its easy to make a basic plugin to do collision detection in Orbiter. Just keep track of the all vessel positions in the plugin and if the distance between them is = sum of their radii then apply a force along their line of contact in the opposite direction to their approach. I already have that working. But to make things more manageable and allow "Bullet enabled" bases that can control vehicle, characters etc what I am planning is to split up the collision into
1. near base collisions
2. collision far away from any base(in orbit or in space)

This is because Bullet uses single precision(C++ float) to represent its distances and Orbiter's absolute distances cannot be represented directly. Nor is it really needed. So assume that 2 vessels are colliding some where in orbit. Then what I do currently is use their relative velocities to do the collision and set their velocities afterwards from the result of the physics. For vessels near a base, if the base is "Bullet enabled" it will detect the vessels near it and manage collisions. It needs some work however.

 

[Wishbone]

Thanks for your effort, since it is going to transform Orbiter putting it on a higher realism level (while also tipping hat to Artlav :tiphat. Maybe one day we can succeed in putting together various pieces for a full realistic manned mission to Mars

 

[N_Molson]

This looks very promising ! Thank you for your efforts on this ! :thumbup:

 

[Artlav]

So assume that 2 vessels are colliding some where in orbit. Then what I do currently is use their relative velocities to do the collision and set their velocities afterwards from the result of the physics. For vessels near a base, if the base is "Bullet enabled" it will detect the vessels near it and manage collisions. It needs some work however.

So, you basically cancel out Orbiter physics locally and replace them by Collada physics?

What would happen when two vessels collide in orbit - how would you add up Orbiter's trajectory and Collada's collision response?

Same thing on the ground - if something is about to land, what gravity would it feel - O's or C's?

Who's gravity pushes the rover into the terrain it drives on?

 

[dumbo2007]

So, you basically cancel out Orbiter physics locally and replace them by Collada physics?

Well I havent experimented with the plugin for vessels in orbit yet. But this is what I am planning to do. I will set the vessel's velocities using DefSetState() and let Orbiter take over again. If the vessels collide again then the process repeats. Now I just use relative velocities(Vrel) in the physics. So that means if 2 vessels are approaching each other with Vrel of 100m/s then I instantiate in the physics, 2 sphere of mass = the vessel's respective masses, and radius = the radius of the respective vessels along the X axis with the origin in between. Each vessel has half the relative approach velocity, so 50 m/s in this case. After collision the physics gives me the change in the velocity. So if we assume the simple case where the objects rebound along the same direction along which they collided(and not at an angle) then the velocity vector of one vessel needs to be increased by the same amount that the physics gives me, along the direction of contact. The velocity vector of the other vessel needs to be decreased along the same direction.

So basically the X axis in the physics is the line defined by the position of the 2 vessels. The velocity of each vessel will be changed along this direction based on what physics gives me. So the orbital velocity remains intact with small changes to show the collision.

I can also use the absolute velocities of the vessels and set them to the new velocity after collision which may be easier I guess.

The case were the vessels rebound in different directions is more complicated and probably easier to handle if I just use absolute velocities.
Orbital collisions will be handled by a plugin.

For near ground collisions I plan to support physics only near Bullet enabled bases for now. So assume that a vessel is approaching a Bullet enabled base(vessel that is running physics). Then I attach the vessel to the base by positioning an attachment point at the approaching vessel's current location above the base(in base relative co-ordinates).

The Orbital plugin does not interfere anymore when it sees that the vessel is attached to a base.

Now this would immediately transfer the total resultant force acting on the approaching ship to the whole ship-base system(as they are attached) and try to move it. If we assume the base is immobilized by setting a very high mass value(or any other way in which a vessel can be immobilized), then the approaching ship would nearly freeze at its position.

However at this point I intend to instantiate an object inside the physics(of the base) at the same position and with the same velocity vector and mass as the vessel. Also importantly it will have the same Moment of Inertia(to take care of rotational accelerations). Now I get the total force vector acting on the vessel from Orbiter and apply it to the object in the physics. I move the vessel now according to the position given to me by Bullet(thus overriding Orbiter for the duration that the vessel is near the base and attached to it). The vessel's movement should be approximately the same as I am applying the total force acting on it(which includes thrusters and gravity). The total torque acting on the vessel can also be got from Orbiter and applied on the object inside the physics to get the same angular acceleration as Orbiter would produce. Thus thruster effects will continue act on the vessel but via Bullet physics and not via Orbiter's physics. It would move from Orbiter's domain to Bullet's domain.

So to answer your question, the vessel would feel the gravity force applied by Bullet.

All objects near the base are inside the base's physics world, and are attached to the base in Orbiter. They all move according to the corresponding positions of their objects inside physics and so collisions will happen with terrain and with each other accurately.

When the vessel is taking off then forces continue to act on it via Bullet by moving the attachment point and orienting it as needed. When its at the base's maximum range then the vessel is detached and its velocity is transferred to Orbiter via DefSetState() thus transitioning from Bullet to Orbiter's domain.

-------------------------------------------------------------------------------------------

The above method of applying forces via Bullet is one way to do it. The user may feel a sudden change in the responsiveness of the vessel when it transitions from Orbiter to Bullet.

The other way would be to use ghost objects in Bullet. Ghost objects(also called phantom objects in Havok) are user controlled objects that can move inside Bullet's physics world and affect non-ghost objects. But they are not affected themselves as their positions are controlled externally by the user.

So if we take the case of a vessel approaching a Bullet enabled base again, then I do not use attachment points anymore but I do instantiate the vessel as a ghost object inside Bullet. However the vessel continues to be in Orbiter's control and its position is transferred to Bullet(so its basically the other way around now!). However that raises the question of collision response for the vessel itself. Collisions of ghost objects can be detected in Bullet. So when I detect such a collision I can apply a force. But this method may not work when the vessel is landed on the terrain or entering a hangar so I may ultimately have to use attachment points again to keep the vessel stable.

Disclaimer : All this will require more experimentation to validate and is mostly speculative at the moment.

 

[Wishbone]

You could also use the step-by-step approach - first release the module for surface operations, collect feedback and "thank you"s and then plan for orbital collisions...

 

[dumbo2007]

Yes I am planning to stay near the surface at the moment and finish the vehicle addon first before I think of more stuff.

 

[mc_]

But what will happen with docking?

 

[dumbo2007]

Yeah for docking a more accurate concave triangle mesh is needed instead of a sphere. The triangle mesh can be a bit deeper inside the docking port so docking occurs before collision.

By the way I have setup the physics such that it is a separate application that communicates with Orbiter via shared memory. That bring up some synchronization issues with key presses that needs to be fixed. Also I am working on automating somewhat the initial connection that Orbiter makes with the physics application like for example attempting a connect every 10 seconds etc so that the user is not bothered much.

I thought that putting the physics in a separate application would be good as it makes Orbiter a truly distributed and parallel application. The core runs in 1 processor, the graphics engine in another and the physics in yet another one !!

Also it makes it easy to view the physics world and debug it via an OpenGL rendering window independently of Orbiter.

 

[Fert]

:hello:
Hi !
It's very good! :thumbup: It's very important work!
Will be fine if this come out.
:tiphat:

 

[ghostrunner01]

One question: What will this do to the framerate?

 

[dumbo2007]

The physics is a separate application and a plugin or a vessel is used to import the data to move other vessels. So the overhead is only in terms of accessing the physics data from Orbiter through shared memory. So it should not affect the frame rate. I run both Orbiter and an OpenGL rendering window(for independently viewing the physics world) simultaneously on Intel onboard GMA4500M with a Pentium Dual Core. It runs smoothly.

Oh did I mention that if Bullet lacks some features then I can swipe out the engine with Havok or ODE or GodKnowsWhatElse without changing a thing in the Orbiter part, as the Interface to Orbiter via shared memory will be respected by any external physics application powered by whatever physics engine.

Currently I am working on developing this interface sufficiently so that on startup, Orbiter connects to the physics app and gives it a physics file(to be mentioned in scenario file). The physics app reads this file and loads the physics objects while Orbiter loads its own corresponding meshes and attaches controlled vessels - in parallel. Then when both are ready its time to simulate !

 

[jedidia]

absolutely glorious!

What are the chances of an OGLA/Orulex implementation? From what I gathered from your posts, dynamic meshes could prove rather tricky for the model used. However, if it could be made working, it would be more win than I've seen for some time!