Surface Base Apollo 11 Tranquility Base Scenery for Orbiter 2016

ggalfi

New member
Joined
May 31, 2020
Messages
17
Reaction score
9
Points
3
Location
Budapest
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:

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,491
Reaction score
19
Points
38
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:
// -----------------------------------------------------------------------

bool SurfTile::LoadElevationData ()
{
	//...
	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
Joined
May 31, 2020
Messages
17
Reaction score
9
Points
3
Location
Budapest
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:
// -----------------------------------------------------------------------

bool SurfTile::LoadElevationData ()
{
	//...
	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.

So to answer your question:
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
Joined
Apr 1, 2008
Messages
1,491
Reaction score
19
Points
38
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 ;)

So to answer your question:
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
Joined
Apr 1, 2008
Messages
1,491
Reaction score
19
Points
38
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

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,108
Reaction score
64
Points
48
Website
users.kymp.net
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
Joined
May 31, 2020
Messages
17
Reaction score
9
Points
3
Location
Budapest
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);
    }
  • In float SurfTile::Load this
    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
Joined
May 31, 2020
Messages
17
Reaction score
9
Points
3
Location
Budapest
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

Last edited:

jarmonik

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,108
Reaction score
64
Points
48
Website
users.kymp.net
Hi Kuddel,
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;    }}
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

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,108
Reaction score
64
Points
48
Website
users.kymp.net
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.
 

ggalfi

New member
Joined
May 31, 2020
Messages
17
Reaction score
9
Points
3
Location
Budapest
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
Addon Developer
Donator
Joined
Oct 16, 2007
Messages
1,003
Reaction score
31
Points
48
Location
UT_SLC
Website
sites.google.com
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
Joined
May 31, 2020
Messages
17
Reaction score
9
Points
3
Location
Budapest
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
Addon Developer
Donator
Joined
Oct 16, 2007
Messages
1,003
Reaction score
31
Points
48
Location
UT_SLC
Website
sites.google.com
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 !
Joined
Jun 19, 2008
Messages
2,987
Reaction score
102
Points
63
Location
Lisbon
Website
orbiterspaceport.blogspot.com

jarmonik

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,108
Reaction score
64
Points
48
Website
users.kymp.net
The reason why I haven't published it yet is that I am very unsatisfied with the "sinking LM" phenomenon.
Since you have invested a lot of efforts to create a nice environment for Apollo 11 and 12 landing sites, Have you tried to contact Martin via PM and talk about the issue ?
 
Top