I imagine you have a bit of code in there similar to this:
Code:
if (distance_from_center < radius)
height = target_height
else
height = original_height
might I suggest the following:
Code:
if (distance_from_center < radius)
height = target_height
else if (distance_from_center < (radius + falloff_distance))
float fac = (distance_from_center - radius) / falloff_distance
height = original_height + (fac / (target_height - orignal_height))
else
height = original_height
That will give linear falloff. Other falloff types can be obtained by modifying the fac calculation.
Looks good!
How about doing it based on landed vessel coordinates ?
» Have a landed vessel define a flat area radius and the desired altitude.
Also it would allow something like the Soyuz pads, where you have the trench with negative altitude. And if base objects go away on future orbiter versions it would still work.
Thanks guys, I am very happy that the idea is welcome. Anyway the full development it is not much about us (I add Face to this party, since it seems to me that he likes the idea as well and is helping a lot about it).
What we are trying to do is to demonstrate that flattening of easily defined local areas is possible, without performance impact and that produces good results.
It seems to me that this has already a confirmation from the video above.
The issue is that the example is just about "graphics" since we are playing with the code of D3D9, so the collision detection system of Orbiter Core actually uses the original terrain instead of the flattened one. That means that it can be basically just a demonstration of the potential and of the absence of performance impact.
I think that what Face is trying to do is to hack the collision detection directly through the binaries, but this becomes a bit of reading chinese for me so I can't be much of assistance and anyway still is just about demonstration.
If Martin (or anybody who has the idea on how to do it) would take this in consideration, I'd simply suggest to have the possibility of having flat areas defined in dedicated cfg files, and each one will state:
- planet
- center point coordinates
- type of shape (rectangle, circle, other options)
- side / radius
- shape factor (for rectangle to deform the square and for circle to make ellipsis)
- altitude
- optionally falloff distance and degree (for smoothing the edges if necessary)
when Martin said that base objects are going to be removed at first I thought that it was a show stop for this, but actually it could be the opposite, that it is even more needed.
as said, it would allow to have objects on ground like pads, runways, buildings etc with just a few minutes, without having to do complicated patches to the elevation files. Basically suddenly it would be possible to create inifnite number of places to land on or to take off from, with just a few parameters, and that everything will be removable, transferrable etc very very easily.
It seems to me that it would be a big addition because it would be so easy to populate planets with custom objects and "sight seeing" points and more important landing locations
---------- Post added at 18:05 ---------- Previous post was at 17:55 ----------
Actually if there would be an interface/access to the elevation data manager also to set the data and not just to get the data, it would be very easy to implement the plugin that does what said above, I would candidate to do it. The issue I see is that at the moment we just have one way access to the data, so we can get them and eventually use them but cannot set them if not via elev files.
