Question Collision detection

[wil]

To add 3D terrain and collision detection should i install orulex or meshland. I have wideawake installed and want to know if they will work for the volcanoes on orbiter

 

[asbjos]

I believe it's meshland. Orulex makes terrain, as far as I know...

 

[Spacethingy]

It's a tough question.
Orulex makes terrain appear, Meshland is supposed to allow you to land on it.
There's also lurking somewhere "Visosad" that allowed vessel-vessel collisions.

However, these were all kinda experiments really - see Artlav's comments in here:
http://www.orbiter-forum.com/project.php?issueid=590

That said, there's quite promising progress being made by Dumbo2007 here:
http://www.orbiter-forum.com/showthread.php?t=25176

 

[N_Molson]

I think that Martins is seriously working on that.

Could be part of Orbiter 2014 ? (Orbiter 2006, 2010, 2014 ?)

 

[jedidia]

I think that Martins is seriously working on that.

There's no indication of that. If I remember correctly, he once said that he is not interested in including collision detection in the core. Although that statement might have only applied to vessel-vessel collisions. Seeing that he is updating the ground collision model quite a bit currently, it might be possible that he intends to adapt it to be used with terrain, especially as he himself suggested a further separation of graphics client and terrain client, but I have no idea whether that assumption is true.

Anyways, dumbo2007 did a very impressive proof of concept for the integration of bullet into orbiter, and judging by his recent posts in the SDK forum he's at work like mad to make it into a full-blown addon, so there's a good chance he'll beat martin to it...

 

[N_Molson]

There's no indication of that.

Let us dream :lol:

 

[Artlav]

Let's take a look.
Dumbo2007 seems to be taking the lead now, and Martins is presumed to make some sort of collision detection as well, but i'm not familiar enough with details to comment.
I'll mostly describe what i was working on, which is almost all of the legacy stuff out there.

Maybe add this thread to a FAQ?
To avoid periodic confusions on what Orulex-Meshland-Bullet physics-etc is.

So, there is collision detection and there is collision handling.
First determines if two meshes/whatever intersected, second makes the appropriate alterations in the state vectors.

These two tasks go hand to hand, but are quite separate.

Orulex is a terrain generator.
It does not provide any collisions, but it can feed the terrain data into any of the add-ons below that can receive it.

This task is absolutely separate from the other two.

Collision detection
What collides?

Terrain and vessel (orulex-collision, moonland, bullet).
Terrain is a heightmap, vessel is points.
+Extremely simple detection.
-Specific to that one task

Vessel and ummu/pilot (Shukra engine).
Vessel is a geometry, ummu is a sphere/OBB
+Not too hard to detect
-Specific to that one task
-Needs defining geometry

Vessel against vessel, high velocity case.
Vessels are bounding boxes or spheres.
+Easy to detect, easy to handle
-Only works when at hight speeds or in other situations where accuracy is not required

Vessel against vessel, generic case.
Mesh against mesh
+No need to alter stuff
+Realistic collisions
-Highest complexity of detection known, beyond capabilities of home PCs
Convex mesh against convex mesh
+Realistic collisions
-Nearly the highest complexity of detection known, existing real-time solutions are large projects by respectable teams
-Needs defining of collision meshes with non-trivial rules
Geometry against geometry.
+Doable level of complexity
-Average accuracy
-Needs definition of said geometry

Collision handling
The actual response generation to collisions detected.

Can be solved analytically, but that requires a deep integration with the core (variable time step, exact formulas for every perturbation, etc) and well-developed system. Not worth considering.

Situations:

Vessels in space (Meshland 1.9.2, Soyuz collision demo?)
No such thing as resting on or wedging in.
Response with basic newton's laws.
+Easy, needs no special cases, just push away
-Only works in space and with sharply defined collisions

Walking on the ground, single point (Meshland 1.2, Moonland, Orulex-collision).
An object is constantly in contact with another object.
Repulsing will produce shaking.
Time acceleration or low FPS turns the shaking into chaos.
-Needs handling for non-moving objects, at rest with others - freezing. Core support helps a lot (that is what LANDING in Orbiter and Spaceway is - core handled, super stable), or some hard tricks to emulate (attachment points to Orulex planet vessel - Moonland, newer Orulex-collision).
-Needs prior knowledge of next time step length - core integration, can be skipped at cost of some precision.
+Simplistic to implement, makes sufficient illusion of collisions (Meshand 1.2, abuses Orbiter LANDED system by extending touchdown points)

Walking on the ground, multiple points (Meshland 1.9.2, bullet).
Same as above, but harder.
-Needs basic constraint solving - sitting on a curved terrain, push one point, another gets in deeper, push that one harder, first gets even deeper, runaway bouncing.
-Needs next time step information
-Needs freezing, absolutely
-Time acceleration provides a challenge - no freezing=every landed vessels jumps into space at 100x.

Walking on another vessel (Shukra engine, Collision SDK, Meshland 1.9.2).
Same as above, only without any easy trick like using LANDED points.
Freezing can be implemented by attachments.
Single-point system of walking a ummu is actually kind of easy.
Multi-point is the next one

Arbitrary collisions between arbitrary vessels
Everything above plus full constraint solver
+Maximum realism

Solutions (chronologically)
Meshland legacy:

 

[N_Molson]

That post deserves to be stickied somewhere :thumbup:

 

[BruceJohnJennerLawso]

With regards to the various projects mentioned here, could we create a thread listing links to Orbiter projects not located on the forums? (ie AMSO, NASSP, XR rolling repair-just for the downloads)

 

[Artlav]

Maybe i should start a separate thread?
This was kind of off-topic here.

To answer wil's original question:
-If you want volcano on wideawake to be landable, you'll need Meshland or Moonland, and to configure it manually.
-If you want global landable terrain, then you'll need Orulex and Orulex_Collisions_UCGO, working out of the box.

 

[BruceJohnJennerLawso]

Maybe i should start a separate thread?
This was kind of off-topic here.

To answer wil's original question:
-If you want volcano on wideawake to be landable, you'll need Meshland or Moonland, and to configure it manually.
-If you want global landable terrain, then you'll need Orulex and Orulex_Collisions_UCGO, working out of the box.

What box?

 

[Artlav]

What box?

Idiomatic box:
[ame="http://en.wikipedia.org/wiki/Out_of_the_box"]Out of the box - Wikipedia, the free encyclopedia[/ame]

 

[dumbo2007]

I am still reading Artlav's post but....

Highest complexity of detection known, beyond capabilities of home PCs

I beg to differ . Both the vessels can be represented as triangle meshes and Bullet does a pretty good job of colliding triangle meshes of considerable complexity together. In fact Bullet is now openCL acelerated and 100% on GPU :

110,000 colliding cubes.

I am actually looking at Cal3D for the walking realistically part :

Apparently it can work with Bullet. No need to start from first principles when something is out there already.

 

[Artlav]

I beg to differ . Both the vessels can be represented as triangle meshes and Bullet does a pretty good job of colliding triangle meshes of considerable complexity together.

Except that COLLADA reduces them to a set of convex meshes?

In any case, beyond capabilities of home PCs might be an overstatement, but collisions of polygon soup are more complex than collisions of convex bodies, AFAIK.

---------- Post added at 21:34 ---------- Previous post was at 21:22 ----------

Yeah, last time i dealt with Bullet and COLLADA was 2007, before GPU proliferation for such tasks.
Nowadays it should be well within the reach of home PCs, and then some.

So, detection solved.
Would you also solve handling for Orbiter?

 

[dumbo2007]

Yeah that part is done....I can smoothly transition states between Bullet and Orbiter now. Maybe I ll put up a video soon as soon as I can get the DG's wheel's moving.

Here is some code out of the blue and the class which handles that :

http://code.google.com/p/surface-ph...unk/Bump/Library/Bump_VehicleCollider.cpp#592

I agree convex shapes are easy to collide and Bullet uses convex triangle meshes. For concave shapes, its easier to use compound shapes which are simply
simple shapes arranged such that they approximate the concave shape correctly and are treated as one rigid body.

http://www.bulletphysics.org/mediawiki-1.5.8/index.php/Collision_Shapes

For those that want to specify arbitrary triangle geometry for dynamic collision shapes, there are two options:

The ConvexDecomposition demo shows how to procedurally break a concave shape up into a composition of convex shapes using some utility code in the Extras folder.

I think there is some algo called the HACD which does fast convex decomposition. Well the time will come soon when I ll need to look into that.

 

[Artlav]

Here is some code out of the blue and the class which handles that :

http://code.google.com/p/surface-ph...unk/Bump/Library/Bump_VehicleCollider.cpp#592

                case CS_FROZEN:
                {
                        // Freezing not implemented yet, maybe just freeze the base
                        break;
                }

What will happen if i up the time acceleration while the DG is rolling across the terrain, or sitting on it?

 

[dumbo2007]

That piece of code is for freezing vehicles on Mars or any other planet when the focus is on some other planet like say the Moon. Thats because terrain generation is stopped for a planet thats not in focus. So I dont want to get wrong terrain data and try to apply it to a different planet etc etc.

Now the way I deal with time acceleration is this :

say 10x acceleration, I do 10 times more physics iterations before sending the final results to Orbiter, so the eventual output is correct. For 100x, 100 times more physics iterations. Now I have capped this currently at 10 times since otherwise things may slow down a lot (it may not, haven't tried it yet)

I cannot tell yet what adjustments I ll need to make for 100x + time accelerations. What I just tested right now was that as the time acceleration increases the collision mesh lags the DG by an increasing amount but this could be because I am not allowing Bullet to do higher that 10x iterations as of now.

I can still nearly force the DG into the position that Bullet is giving me till 1000x acceleration. Beyond that I may need to use attachment points and remove the Orbiter engine's control completely. Then apply all thrusts through Bullet.

But I haven't reached that stage yet. I am currently trying to figure out a general purpose collision mechanism for all default ships in Orbiter that's stable at 1x.

If the DG is sitting then it stays sitting at 10000x.

Bullet has support for continuous collision detection which needs to be turned on and may be a solution for high speed collisions. Haven't reached orbit yet, still working near the surface at normal speeds. Bullet wasn't designed for orbital speed collisions so may need to make some custom extensions there. We'll cross that bridge when we come to it. Probably sphere-sphere collision and loads of destruction should suffice . Even I can write such a routine.

 

[Artlav]

So, basically you're still fighting the Orbiter physics engine?
What about freezing at landing?
No reasonable amount of precision would make a vessel collide properly with proper terrain at 10000x or so - you'll have to freeze it somehow.
1x to 100x is rarely used in a space flight simulator.

I would have considered this part of the problem a priority - if it can't be done, no point figuring out the rest.

 

[dumbo2007]

Why would landing at 10000x be so important ? There is a lot of stuff that can be done in Orbiter that does not happen at 10000x.

 

[Artlav]

Why would landing at 10000x be so important ? There is a lot of stuff that can be done in Orbiter that does not happen at 10000x.

You landed a vessel on a planet, let it sit here, and switched to another vessel still in interplanetary space. Cue 100000x and first vessel being either properly freezed or shot into space.