Project Surface Physics with Bullet

[luki1997a]

:bananadance::banana::speakcool::jiggy:
Yea! Collision detection! Something better than meshland(and i think it's stable, sorry artlav) Please! Make it public!
Ok, now some normal speaking:lol:
Would you add your collision detection to orulex? It would be great.:thumbup:
If you are using a mesh of collision for your add-on, then in e.g. DG's collision mesh exclude docking port and it may fix some problems. You can also make a config file with defined places of each vessel, which won't have collision detection.

Congratulations

 

[N_Molson]

This is a little off-topic, but the drama I foresee concerning terrain rendering is that we now have a stable D3D9 client with an outstanding framerate performance but flat planet surfaces, and an Alpha version of Orulex (OpenGL) that displays very good looking terrain but isn't very stable and has performance issues. And both clients are by essence incompatible.

And "adding collision detection to Orulex" isn't something trivial you can do in a few days, I guess that Artlav worked for years on this. :hmm:

 

[Artlav]

I guess that Artlav worked for years on this.

I got stuck on a fundamental level - there is no way to alter the Orbiter's core physical engine, and it's not a kind of physical engine needed for collision detection in it's current state.
In essence, i failed at stable mating of Orbiter with another physics engine.

That's why i welcome this development - it's a fresh look, and it may not get stuck where i did.

---------- Post added at 23:07 ---------- Previous post was at 23:05 ----------

What are the chances of an OGLA/Orulex implementation?

Orulex provide an SDK for getting terrain elevation, so anything can be used with it. My own Collision/Meshland stuff is using this SDK, so could Collada.

 

[deltawing777]

I am crossing my fingers. I hope this could finally solve the collision detection hurdle. Good luck. Nice work

 

[dumbo2007]

Thanks for all the support everyone. Well things are moving along steadily, I 'll try and answer each question as best I can :

Orulex integration is possible. It needs some clever programming however. Bullet supports triangle meshes and terrain heightmaps. So I can use either. So the heightmap information in Orulex has to be converted into a bunch of triangles which I am guessing can be done easily enough since Artlav probably does it to create the Orulex terrain vessel. The whole terrain can't be loaded into Bullet in 1 go as its just too huge and there are too many triangles against which Bullet will try to check for collision thus slowing it down. So only the terrain in the immediate vicinity of a vehicle or a base has to be loaded. As the vessel/vehicle moves around, the triangle mesh is recreated(at least that's how its done in the demos, instead of just adding or subtracting triangles). Also there is another challenge that given a linear array of heights and their corresponding latitude and longitude, how to extract the data for a particular patch of ground quickly. But I can probably break up the heightmap data into patches on initial load anyway....so lets see. It comes down to evolving the best data structures.

Edit : Yes I will use the SDK probably

Well as of now I am working to finish automationP) of CoolHand's ATV mesh. Over the last few days I refactored the code to read more data from files and avoid hard coded paths, improved my MSH importer to import all groups in the file and built a physics model of a train running on a static railway line. So things continue to move along.

The physics should work with separate graphics engines as I use standard Orbiter features to force vessels into a particular orientation and position. The orientation and position calculation has nothing to do with Orbiter's engine currently nor does it run in the same process or try to hack into its binary memory image.

 

[Artlav]

I foresee one problem - triangle data in Orulex is in constant flux and is not available through anything.

My collision engine was working with an altitude function, not triangles.
Last time i checked, there were no such feature in Bullet.

In short, the data you can get from Orulex is elevation by position.
But you can build a local triangle mesh from that, just like it does.

 

[dumbo2007]

My collision engine was working with an altitude function, not triangles.

Ah yes I remember you telling me that sometime back. Well I haven't looked into the SDK functions yet but I am guessing there will be something like

double getHeight(double latitude, double longitude)

So I would need to call this function for all the latitudes and longitudes surrounding a vessel and get the heights which I can convert to points. Then pick adjacent triplets of points and convert to triangles or maybe just give the whole data directly to Bullet.

What I am thinking is do you load the whole Orulex data into memory in 1 go, so that the height for a particular (lat,long) can be got quickly ? Also how fast is this the function for getting the elevation/height because I will need to call it probably many times within the space of a single iteration.

But you can build a local triangle mesh from that, just like it does.

Edit : Ah ok you do build triangles using the SDK, so I guess its quite fast. Well I will probably need that code soon

One other thing is, Collision can be done against a coarser mesh and need not be as tessellated as the Orulex mesh. So I can probably ignore the height every 2 units or so and thus give Bullet lesser triangles to deal with it. The lesser the number of triangles the better it will perform.

This is the triangle mesh class I was talking about :
http://www.bulletphysics.com/Bullet/BulletFull/btBvhTriangleMeshShape_8h.html

This is the height field class :
http://www.bulletphysics.com/Bullet/BulletFull/btHeightfieldTerrainShape_8h.html

It has some annoying issues however like centering the height field around the origin always...but that can be worked around.

 

[Artlav]

Ah ok you do build triangles using the SDK, so I guess its quite fast. Well I will probably need that code soon

No, i meant the renderer. Collision detection works on terrain function directly.

I am guessing there will be something like

//Get elevation by 3D coordinates
double oru_getaltbyvec(VECTOR3 pos);

//Get maximum elevation (useful for altitude cut-off for collision detection checks)
double oru_getmaxalt();

//Check if Orulex is loaded or enabled (0==not)
int oru_check();

So I would need to call this function for all the latitudes and longitudes surrounding a vessel and get the heights which I can convert to points. Then pick adjacent triplets of points and convert to triangles or maybe just give the whole data directly to Bullet.

That is a viable method if you can only work with triangles.
Be advised that the function is not the fastest thing in the world, so the less calls you have per frame, the better.

What I am thinking is do you load the whole Orulex data into memory in 1 go, so that the height for a particular (lat,long) can be got quickly ?

Such data does not exist.
It's a procedural generator that can have multiple functional and heightmap inputs. Just imagine the size it would take to store it all as a bitmap.

---------- Post added at 17:00 ---------- Previous post was at 16:54 ----------

Btw, it can be found here:
http://orbides.1gb.ru/orbf/OrulexSDK-allvers.zip
To spare anyone the hunt through old Orulex threads and obsolete orbides pages.

 

[dumbo2007]

Ok so how do you manage to merge the heightmap data with your procedural generator ?

For example suppose you want to generate the terrain around Brighton Beach. Then you will need the heights from the heightmap file as input to you terrain generation function.

So do you read the heights from the heightmap file for only this region when you need to generate it ?

You will need the height information in some form or other, for all the points above the surface, otherwise the surface produced will not be accurate.

 

[Artlav]

Functions.
There can be several heightmaps at different locations, zoom level or meaning.
Heightmap (which is stored in memory) is a function - for each position there is elevation.
You add that to the random terrain function - a set of continuous fractals like perlin noise.
Then you add crater generation function - distance to base wrapped into a crater shape.

The result is a compound terrain function.

 

[dumbo2007]

Ok. About the random terrain function - I am guessing it gives a random height when given a x,y co-ordinate. This is added to the heightmap function, so something like :

final height = randomterrainfunction(x,y) + heightmap(x,y)

Well, since randomterrainfunction(x,y) will give a random height even for the same x,y location each time its called, wont the final height vary randomly ?

 

[Artlav]

Fractals.
For every x,y it gives a continuous random value.
It's random, but it's fixed.
You call again, it gives you the same value - it's only random once.

Try reading about perlin noise and fractals if that is confusing.
That is what make the adjacent values continuous.

 

[jedidia]

Well, since randomterrainfunction(x,y) will give a random height even for the same x,y location each time its called, wont the final height vary randomly ?

Computers aren't really able to produce true randomness, only aparent. So, if you seed a random generator with the same seed, you will get the same values back every time (as long as you stick with the sequence). That's pretty much how all procedurally generated content works, since the earliest days of Nethack.

 

[Rtyh-12]

This site claims to give you "true" random numbers, based on atmospheric noise from their radio stations... anyway, even this "fake" random numbers are OK for me for all purposes...

 

[N_Molson]

anyway, even this "fake" random numbers are OK for me for all purposes...

It can be a problem for rendering something visual because you can have repeating patterns or other things that will not look natural.

 

[Wishbone]

I will be downloading Fert's terrain next week, and can say I don't care about random numbers...

 

[dumbo2007]

Is the Orulex SDK dependent on Orbiter header files in any way ? I will be using the SDK in an external application where VECTOR3 is not defined for example. Though I can easily replace it with equivalent types like btVector3 from Bullet's vector definition.

 

[Artlav]

No, it links directly to the DLL.
You would have to define types, however.

 

[dumbo2007]

A test version of the rover addon is updated in the 1st post. It includes the Bullet Physics engine. Hope it works!

 

[dumbo2007]

Hi Artlav,

I was looking at the OrulexSDK code today and I saw in the Delta Glider sample code ...the function for updating Orulex data to the MFD :

void DeltaGlider::clbkDrawHUD (int mode, const HUDPAINTSPEC *hps, HDC hDC)
{
    // draw the default HUD
    VESSEL2::clbkDrawHUD (mode, hps, hDC);

 /*<ORU>*/
 if(ORUCheck()){
     int cx=hps->CX-hps->Markersize*2,cy=54;
     char s[256];

     //Rectangle(hDC,cx,cy+100,cx+hps->Markersize*4,cy+hps->Markersize*0.64+100);    

  //Global planet-relative position
  VECTOR3 vv,pv;
  oapiGetGlobalPos(GetSurfaceRef(),&pv);

  GetGlobalPos(vv);
  vv-=pv;

  //Elevation measured from the center
  double e=ORUGetElevByVec(v32v4(vv))-oapiGetSize(GetSurfaceRef());
  double a=GetAltitude()-e;
  
  sprintf(s,"Oru_Ele=%.3f",e);
  TextOut(hDC,cx+2,cy+1+100,s,sizeof(char)*strlen(s));
  sprintf(s,"Oru_Alt=%.3f",a);
  TextOut(hDC,cx+2,cy+1+120,s,sizeof(char)*strlen(s));
 }
 /*</ORU>*/
...
....
}

So I guess you pass the global position of the vessel i.e. vv to ORUGetElevByVec(). But then how will this function know which planet or moon this vessel is on ?

I saw the declaration of ORUGetElevByVec :

//Get elevation by global planet-relative position, in distance from center
double ORUGetElevByVec(VECTOR4 pos)
{
if(!oruisinit)return 0;
return porugetaltbyvec(pos);
}

I want to generate the terrain around Brighton Beach. So can I pass it the co-ordinates of brighton beach in planet relative co-ordinates(i.e. the co-ordinates wrt the frame which assumes Origin is at planetary center) ?

Also when I am running the SDK in an external application, how will it be able to take a heightmap as one of the inputs for its procedural terrain generation function ? I did not find any function that takes the heightmap path as input.

Note : I am not running my code as a plugin, I want to use Orulex to generate terrain for my external Physics application.