Yes, this is provided anyway. It's currently implemented as an extended version of VESSEL::SetTouchdownPoints(), with variable number of points and additional parameters per point. I may also add methods to modify individual points. Additionally, I am thinking of allowing to bind touchdown points into animations similar to mesh groups, which should reduce the need of modifying points manually.
I don't think tying collision mesh to animations is a good idea, because as a result of animation some points that were "on the outside" of collision mesh will cease to be them - for example gears are parts of collision mesh when they are down, but they aren't when gears are up as they are now hidden inside fuselage, so instead fuselage's underbody is vessel's border.
The terrain engine sounds exciting, and I am happy to add any required API interfaces to Orbiter. In fact, this was already briefly discussed by Artlav earlier in the thread.
The interaction between Orbiter and the graphics client regarding terrain will need some careful planning, because this is a point where physics and graphics are closely connected.
How closely is the terrain engine tied into the DX11 graphics engine? Is there a way to keep the terrain engine isolated from the pure graphics routines, or does your terrain engine require some specific DX11 functionality? I am asking because currently Orbiter can run without a graphics engine attached, so API functions like the ones you mentioned aren't guaranteed to be available at runtime. This would either require a dummy graphics client that returns default values for those functions, or the terrain API could be separated from the graphics API, e.g.
DX11Client --> TerrainClient --> oapi::GraphicsClient
or, a bit more elaborately with a separate terrain API (oapi::TerrainClient?)
Code:
+-------------Orbiter------------+
+---------------+ | |
| DX11Client |---->GraphicsAPI |
+---------------+ | ^ |
| | |
+---------------+ | | |
| TerrainClient |---->TerrainAPI |
+---------------+ | |
+--------------------------------+
where the internal connection between "GraphicsAPI" and "TerrainAPI" represents passing elevation data for surface patches.
In general, I would like to avoid making the simulator physics too dependent on the graphics engine used. If the terrain engine can be kept independent of a specific graphics engine, this would also simplify the development of future graphics clients, because the terrain code wouldn't have to be rewritten or ported. Any thoughts on the practicality of this?
This feature was developed by another developer, Glider, so I will try to explain details to the best of my knowledge, but if you'll need more details, we can ask him for further clarifications.
Currently we have heightmaps for several celestials which are essencially the same as *.tex files, but consist of 129x129 16bit float png-encoded tiles containing a point's altitude within [-32k, 32k] meters, which appears to be more than enough to cover all celestials with more or less known real terrain. They are tiled in exact same way as regular *.tex files are, incliding different levels of detailing. We use those maps to dynamically morph initially-flat terrain using hardware tesselation feature available in DX11, which essentially is simply hardware solution that allows to subdivide initially-lowres mesh. This allows us to have great accuracy (Glider tells it's in 0.1 meter range at L18), while still having modest memory footprint.
Currently we have heightmaps for Earth, Moon and Mars. As far as I understand, it's a real data. For other celestials we're currently using a generated terrain using libnoise, but it's handled by the terrain loading, so as far as the rest of the client goes, the source of data doesn't matter.
As you can see, as far as raw data goes, it's completely independent from the GC itself, and can be separated with no issues as long as we still can gain access to raw data - while DX10/11 devices directly supports 16bit float textures, DX9 and OGL will possibly need to convert this some other format. If collision detection and aforementioned API implemented outside GC they only reason we'll need those maps is for rendering terrain itself, so this can totally be moved out of GC with little effort.
Even more, it's just occured to me that if we'll be able to settle down on inputs for the terrain engine (that's it, physical part of it), this engine could simply be integrated into Orbiter itself, or included as a standard extension since I don't see a reason for many different terrain engines to exist. Either way, I would be more than happy to help in this area, as that's exact this that prevents us from releasing new version of D3D11Client, and if your plans include 3D terrain support coming up with some stop-gaps would seems wasterful on our side.
I was also thinking about writing a small proof-of-concept terrain engine, just to figure out the best way to design the interfaces, but maybe it's more efficient to leave this to you guys and just provide the required interface support.
They way I see it, the TerrainClient is going to have just two responsibilities: loading/retreiving heightmap (and possibly landcover - such a feature is also in works now) data and feeding this data to graphics clients, and collision detection. If it's so, in can be implemented fairly easily, as the bits of this thing are already in our client.
Out of interest: what algorithms are you using for your terrain engine? Is it some ROAM-type approach? Do you have any references (online papers etc.) I could have a look at?
We use hardware tesselation to dynamically subdivide original low-res primitives, and subdivision factor (i.e. how fine to subdivide) can be manipulated for each primitive independently. For now we use hardcoded values, but there are plans to make them dependent of apparent primitive size, and smooth out tesselated primitives using Bezier curves, or N-Patch-like approach. It is technically ROAM-type approach, but thanks to advanced features in modern video hardware, we can do it entirely on GPU which provides for very and fast implementation. It isn't based on any specific paper, but rather is a fusion of ideas from different sources. There are still things to be done, but it's pointless to do them until we have resolved aforementioned major problems.
and :hail: you, Martin 
