Project Surface Physics with Bullet

[Artlav]

But then how will this function know which planet or moon this vessel is on ?

Nearest. Only nearest planet (to camera) have terrain generated for it.

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) ?

Pretty much so.

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.

No way at all. Orulex is Orbiter-bound system, you can't make it work with arbitrary input or outside of Orbiter.

If you need a terrain generation library, i can fork one, but how would you render it?

 

[dumbo2007]

If you need a terrain generation library, i can fork one, but how would you render it?

Awesome. Yah let me explain how I do the physics now.

So a terrain is basically a triangle mesh right. The data for the triangles is read from a mesh file (or in this case, Orulex can give me the altitudes for some fixed points and I can generate the triangles from this data by treating the points as the vertices)

So e.g. if Brighton Beach is at say (0,40,30) on the moons's surface, then I query the altitudes of 4 points around it and then I have 4 points which allows me to generate 2 triangles with a common side. This can be given to my physics engine.

The physics program checks for collisions of a vehicle moving on the terrain i.e. against the triangles of the terrain mesh. The collisions will cause the vehicle to orient itself in 3D space in a particular direction based on the terrain beneath it. I just send this orientation data to Orbiter using shared memory files. Thus the vehicle mesh inside Orbiter also dances around based on the incoming orientations and it appears that the vehicle is colliding with the terrain. However since the exact same terrain is also rendered in Orbiter the vehicle appears to be correctly colliding.

Now the rendering issue. Since Orulex will be running inside Orbiter as a plugin it will take care of rendering the terrain inside orbiter.

To render the orulex data in my physics program I render a triangle mesh using opengl (this already works, I have only to give the triangle data and the mesh will be rendered in opengl in a separate window from Orbiter).

This is useful for debugging the physics without having to start orbiter again whenever I make some change in the code and recompile.

You can try out the test program I have uploaded in the 1st post and then you will see how I do collision against the terrain and how rendering in the Physics program is done (independently of Orbiter)

 

[Artlav]

However since the exact same terrain is also rendered in Orbiter the vehicle appears to be correctly colliding.

Except that it does not. The terrain library would be separate from Orulex, and won't generate anything like what Orbiter is rendering.

Orulex is a legacy add-on, i can't recompile it in any functional shape, and i don't have the precisely matched generation code to make a lib out of. Current version of the lib is designed in a way to be separately accessed and configured, like in your case, but the Orulex won't be linked to it in any way, and the terrain obtained will be different.

 

[dumbo2007]

Hmm...ok but you do have the code for rendering Orulex inside Orbiter I hope. Then we can start afresh and have matching code for the external library and the plugin. Querying the altitude for a specific point should give the same value in both.

We can keep it simple initially if the above involves lot of refactoring.
So we can concentrate on just the Moon, or even just some area around Brighton, see if the thing works smoothly, before increasing the scope.

 

[dumbo2007]

So Artlav, what can we do about this. Do you have any other solution ?

 

[Artlav]

Short answer - i won't be anywhere near a computer with Orbiter capability until august.

Long one...
The rendering code was never perfected, it's a fun experiment to try, but is hardly usable - lots of people complain about low performance or sudden changes in landscape, or occasional bugs. I personally never use it for anything but making pretty pictures.

Reviving Orulex is possible, but it will never get better than it is now.
Even worse - O2010 version that i can dig out is apparently worse than the 1.2 one that i no longer have.

But first, i don't really see why would you need to have it in a separate application - most action happens on one planet at a time, so the current interface should suffice. For handling trips you can ignore landed vessels - terrain never change - and all would be fine.
Simultaneous landing of vessels on separate planets? Never heard of it - never been asked about it.
For debugging you can use a simple terrain generator just as well.

 

[dumbo2007]

hmm ok. Its in a separate application because mixing Orbiter code with Bullet code leads to subtle bugs which are difficult to debug unless I can see all the profiling information and the physics correctly rendered. Code for rendering the physics already comes with Bullet and is tested to work correctly. Rendering accurately the same objects in Orbiter can be tough as Orbiter does not provide an easy way to render primitives(boxes, sphere and triangle meshes) and I would need to convert OpenGL code to Orbiter equivalents and test it.

Also the thing is if a vehicle is close to the base then I can load a small patch of terrain into the physics. But as it gets further away the patch of terrain has to grow larger to support the vehicle. As the loaded terrain size grows, performance drops. So its better to load chunks of terrain and maintain them in different locations in 3D space so that each individual chunk is not too big. Debugging this technique can be tough and along with all the associated Orbiter plugin code , it becomes a mess.

Its best to keep separate subsystems as far apart as possible and debug them independently with a fixed interface in between them to allow interchange of data. This is present in the graphics and Orbiter core separation as well.

Well anyway I think there may be a way out. Perhaps I can request the triangle data in Orbiter and read it in my application. I don't think it would be too complex because I already transfer data in real time for the orientations of the objects.