# Surface BaseApollo 11 Tranquility Base Scenery for Orbiter 2016

#### ggalfi

##### New member
Hi all,

I have created a scenery (only HD texture and elevation maps) of the Apollo 11 landing site and of it's few kilometers neighborhood. You may find everything for that on this page:
http://absimp.org/orbitersim/apollo11ls.html

Hope you'll have nice landings beside the Little West Crater!

Last edited:

Thank you!

#### Interceptor

##### Active member
Very nice,thank you.

#### n72.75

Tutorial Publisher
Donator
Cool! Was looking forward to this.

Alright, first person to land *in* the Little West Crater.

#### kuddel

##### Donator
Donator
Hey ggalfi,

I've taken a look at your patch and it looks reasonable.:thumbup:

But I have one question:

Why do you divide the parent elevation points by tgtres (mgr->ElevRes()) here, when converting them from float to INT16:
PHP:
// -----------------------------------------------------------------------

{
//...
if (elev_file) {
//...
}
else if (lvl > 0) {
//...
if (elev_mode == 0) {
//...
for (int i = 0; i < ndat; i++) pelev_temp[i] = (INT16)(pelev_file[i] / tgtres); // why ????
//...
}
}
}
Shouldn't it just be:
PHP:
			for (int i = 0; i < ndat; i++) pelev_temp[i] = INT16(pelev_file[i]);
as it was in the original (where no conversion was necessary)?

#### ggalfi

##### New member
Hey ggalfi,

I've taken a look at your patch and it looks reasonable.:thumbup:

But I have one question:

Why do you divide the parent elevation points by tgtres (mgr->ElevRes()) here, when converting them from float to INT16:
PHP:
// -----------------------------------------------------------------------

{
//...
if (elev_file) {
//...
}
else if (lvl > 0) {
//...
if (elev_mode == 0) {
//...
for (int i = 0; i < ndat; i++) pelev_temp[i] = (INT16)(pelev_file[i] / tgtres); // why ????
//...
}
}
}
Shouldn't it just be:
PHP:
			for (int i = 0; i < ndat; i++) pelev_temp[i] = INT16(pelev_file[i]);
as it was in the original (where no conversion was necessary)?
Hi Kuddel,

first of all, I am more than happy if you find my hack useful, however there are two issues you should know about:
1. It causes some black tiles in KSC scenery. The occurence of these tiles is a bit odd, because not the closest ones are they, but they appear when the POV is very close to the surface (Alt<1km). I haven't put yet any effort to investigate of the problem, but I still believe that it could be resolved easily.
2. That is the difficult one, because it is related to Orbitersim's physical engine: even if D3D9Client displays a high LOD elevation, Orbitersim calculates with a lower LOD elevation and the altitude difference could be up to a few meters. That means practically that e.g. in the case of Apollo 12, when the LM landed on the edge of a 200m crater, you will see in Orbitersim that the LM sinks in the lunar dust up to it's ascent stage. Pretty disappointing view. The only solution here seem to me to bargain with dr. Schweiger to allow higher resolution elevation maps in the physical calculations.

in the trunk version pelev_file is an array of integer and the unit for that is tgtres. In my hacked version it is an array of floats and unit is one meter. And when it is passed to some (at least for me) arcane part of Orbitersdk by that "mgr->GetClient()->ElevationGrid(...)" call, I didn't want to happen that with improper scaling, that's why I divided by tgtres (unit is 1m -> unit is tgtres). So I practically recreated the old pelev_file through that pelev_temp.

---------- Post added at 11:45 PM ---------- Previous post was at 11:24 PM ----------

Cool! Was looking forward to this.

Alright, first person to land *in* the Little West Crater.
That's one small prank for an armchair astronaut but one giant no-no for a real one

#### kuddel

##### Donator
Donator
Thanks ggalfi for the information!

I will try to look deeper into this, but first let's start with one piece at a time

1. It causes some black tiles in KSC scenery. The occurence of these tiles is a bit odd, because not the closest ones are they, but they appear when the POV is very close to the surface (Alt<1km). I haven't put yet any effort to investigate of the problem, but I still believe that it could be resolved easily.
I have applied a (slightly modified) version of your patch to the current trunk (HEAD version) of D3D9Client and I can not see that issue.
Maybe I accidentally fixed that problem

I will create a new branch for this in the next few days, so we can all look at the same code-base. Be patient, I might not have time for it ASAP

2. That is the difficult one, because it is related to Orbitersim's physical engine: even if D3D9Client displays a high LOD elevation, Orbitersim calculates with a lower LOD elevation and the altitude difference could be up to a few meters. That means practically that e.g. in the case of Apollo 12, when the LM landed on the edge of a 200m crater, you will see in Orbitersim that the LM sinks in the lunar dust up to it's ascent stage. Pretty disappointing view. The only solution here seem to me to bargain with dr. Schweiger to allow higher resolution elevation maps in the physical calculations.
Not much we can do about this, I think. But hey, Orbiter BETA is still a BETA, right? So there's hope

in the trunk version pelev_file is an array of integer and the unit for that is tgtres. In my hacked version it is an array of floats and unit is one meter. And when it is passed to some (at least for me) arcane part of Orbitersdk by that "mgr->GetClient()->ElevationGrid(...)" call, I didn't want to happen that with improper scaling, that's why I divided by tgtres (unit is 1m -> unit is tgtres). So I practically recreated the old pelev_file through that pelev_temp.
Thanks for the clarification. But I can't seen any difference whether I apply the division or not (visually that is).
So I think ElevationGrid(...) just works "dimension less"...

We can hopefully evaluate this more precise once I've setup that feature-branch...

Stay tuned and keep up the good work!

#### kuddel

##### Donator
Donator
Finally I found some time.
You can find my current "work in progress" in this feature branch: svn://mirror.orbiter-radio.co.uk/D3D9client/branches/floatElevTest

#### jarmonik

Beta Tester
That means practically that e.g. in the case of Apollo 12, when the LM landed on the edge of a 200m crater, you will see in Orbitersim that the LM sinks in the lunar dust up to it's ascent stage. Pretty disappointing view.

That issue should be already fixed. But the fix only works with "linear interpolation" not with the "cubic" at a moment.

I did sent PM to Martin to ask if he has ideas/preferences on how to fix the issue but I didn't receive an answer.

The main problem appears to be that Orbiter's physics uses a floating point interpolation of elevation data but the interpolated results are handed over to the D3D9Client in INT16 format for rendering. We have our own code for bi-linear interpolation in float basis but we are still lacking the cubic one.

---------- Post added at 09:55 ---------- Previous post was at 09:22 ----------

If I recall correctly in Orbiter 2016 resolution for Lunar elevation is 1 meter per bit and in Orbiter Beta it is 0.5 meters per bit. So, I wonder is this "tgtres" due to mixing 2016 and Beta elevations ?

Last edited:

#### ggalfi

##### New member
Finally I found some time.
You can find my current "work in progress" in this feature branch: svn://mirror.orbiter-radio.co.uk/D3D9client/branches/floatElevTest
Hi Kuddel,

thanks for taking care of this. Generally it looks good (it is built and runs without any problem). However with Tranquility Base scenery it provides only a minor improvement compared to the main branch D3D9Client, so it practically looks same as the second set of screenshots on my scenery's page.

But if I "unscale" the elevation load algorithm, it provides the best LOD as I could achieve. So my two changes were
• In SurfTile::ReadElevationFile I've changed this
PHP:
if (e) {
if (scale != tgt_res) { // rescale the data
double rescale = scale / tgt_res;
for (i = 0; i < ndat; i++)
e[i] = float(e[i] * rescale);
}
if (offset) {
float sofs = float(offset / tgt_res);
for (i = 0; i < ndat; i++)
e[i] += sofs;
}
}
to this:
PHP:
if (e) {
for (i = 0; i < ndat; i++)
e[i] = (float)(offset + e[i] * scale);
}
PHP:
mesh = CreateMesh_quadpatch (res, res, elev, mgr->ElevRes(), 0.0, &texrange, shift_origin, &vtxshift, mgr->GetPlanet()->prm.tilebb_excess);
to this
PHP:
mesh = CreateMesh_quadpatch (res, res, elev, 1.0, 0.0, &texrange, shift_origin, &vtxshift, mgr->GetPlanet()->prm.tilebb_excess);
and it works nicely.
Maybe there is a more elegant way, probably in the tile LOD selection algorithm, but honestly I was too lazy to understand it to the level I'd be able to modify it.

#### ggalfi

##### New member
That issue should be already fixed. But the fix only works with "linear interpolation" not with the "cubic" at a moment.

I did sent PM to Martin to ask if he has ideas/preferences on how to fix the issue but I didn't receive an answer.

The main problem appears to be that Orbiter's physics uses a floating point interpolation of elevation data but the interpolated results are handed over to the D3D9Client in INT16 format for rendering. We have our own code for bi-linear interpolation in float basis but we are still lacking the cubic one.

---------- Post added at 09:55 ---------- Previous post was at 09:22 ----------

If I recall correctly in Orbiter 2016 resolution for Lunar elevation is 1 meter per bit and in Orbiter Beta it is 0.5 meters per bit. So, I wonder is this "tgtres" due to mixing 2016 and Beta elevations ?
Hi Jarmonik,

I guess, the problem is not with the vertical resolution rather the horizontal one. Seem to me that orbitersim does not goes up to LOD18, only 14. D3D9Client uses 4 notches finer LOD in linear interpolation mode, that's why it is possible to display the finest elevation map. However the physical calculations are still using LOD14. In case of the (yet unpublished) Apollo 12 scenery you see the landed and sinked LM-6 on the edge of the Surveyor crater on the attached images. Also the floating rocks of AMSO are not made of unobtanium rather they are flying because their position is based on the physical elevation, and not the rendered one.

#### Attachments

• 162.9 KB Views: 85
• 72.1 KB Views: 76
Last edited:

#### jarmonik

Beta Tester
Hi Kuddel,

• PHP:
if (e) {    if (scale != tgt_res) { // rescale the data        double rescale = scale / tgt_res;        for (i = 0; i < ndat; i++)            e[i] = float(e[i] * rescale);    }    if (offset) {        float sofs = float(offset / tgt_res);        for (i = 0; i < ndat; i++)            e[i] += sofs;    }}
You might be on to something, I'll have to investigate that more closely. Mean while, If the physics is limited to level 14 then could you try to increase "MaxPatchResolution = 16" from Moon.cfg. If I recall correctly the elevation grid is two levels lower than that.

Last edited:

#### jarmonik

Beta Tester
I have looked into this and there is a new version of client uploaded to SVN (Trunk). I came to the same conclusion as you did, it looks like the physics doesn't go beyond level 14 and there's not much I can do about it.

So far I get the best results by disabling level 17,16,15 elevation (by renaming the folders) and adding the following line in AMSO/Moon.cfg "ElevationResolution = 0.25". That enables the physics to work in 0.25 meter increments in elevation instead of 1 meter. Going below 0.25 might cause other issues.

#### n72.75

Tutorial Publisher
Donator
Just wanted to say that I'm super excited for your Apollo 12 scenery.

#### ggalfi

##### New member
Just wanted to say that I'm super excited for your Apollo 12 scenery.
I'm aware of the attempt of subconscious influencing The reason why I haven't published it yet is that I am very unsatisfied with the "sinking LM" phenomenon. However I have an idea how to cure it: I think if I adjust (or "fake" if you will) the lower LOD elevation maps to reflect the altitude at the exact landing spot of LM-6, then - provided you execute a precise touchdown - the physical and displayed elevation will fit well. Just please give me some time to crawl through the problem.

#### NukeET

##### Gen 1:1
Donator
I'm aware of the attempt of subconscious influencing The reason why I haven't published it yet is that I am very unsatisfied with the "sinking LM" phenomenon. However I have an idea how to cure it: I think if I adjust (or "fake" if you will) the lower LOD elevation maps to reflect the altitude at the exact landing spot of LM-6, then - provided you execute a precise touchdown - the physical and displayed elevation will fit well. Just please give me some time to crawl through the problem.
What is the source of your data for the location of A12 landing site?

#### ggalfi

##### New member
What is the source of your data for the location of A12 landing site?
I've used LRO NAC imagery (to be specific: M1119029214L and R) for the textures and on them the descent stage of LM-6 is clearly visible. You can use it as a landing cue (e.g. in AMSO you point the LPD into it, or in NASSP you may rely on your piloting skills). It is similar to what you can do with the Apollo 11 scenery.

#### NukeET

##### Gen 1:1
Donator
I've used LRO NAC imagery (to be specific: M1119029214L and R) for the textures and on them the descent stage of LM-6 is clearly visible. You can use it as a landing cue (e.g. in AMSO you point the LPD into it, or in NASSP you may rely on your piloting skills). It is similar to what you can do with the Apollo 11 scenery.
Ok. When AMSO for Orbiter 2016 was released, I tried all landings, and noticed that the original numbers used in the scenario for A12 was a bit off for both Intrepid and Surveyor 3. I used LRO data to fix it.

Last edited:

#### 4throck

##### Enthusiast !
Haven't checked the current AMSO landing site coordinates, but these should be quite accurate:

They are derived from LROC imagery, so should match any LROC derived surface textures.
Still uncertainty for Apollo 12 LM is 2.2 meters