Problem D3D9 Flattening Issue

[Pioneer]

I'm trying to flatten a base I have on Mercury, Myron Base to be more specific. The immediate base area was flattened, however, I am having an issue specifying at which elevation I should flatten. Below is an image of my current situation and my flattening code.

;;MyronBase
Ellipse 9 -84.679001 71.227997 700 700 -20000 -10000

 

[Face]

The integer height value is MSL, but nothing should stop you from going below MSL. Looks like -90 should bring you closer to the bottom of that crater?

 

[Face]

Judging by the negative values for fall-off and angle, perhaps you don't know what those values are for. It is like so:
ELLIPSE <height> <lng> <lat> <major> [<minor>] [<phi>] [<falloff>]

So the first value is the height value, followed by longitude and latitude, then major and minor ellipse length, then the angle, then the fall-off. A more detailed description is here: https://www.orbiter-forum.com/threads/area-flattening-experiment-success.37074/post-557220

 

[Pioneer]

The integer height value is MSL, but nothing should stop you from going below MSL. Looks like -90 should bring you closer to the bottom of that crater?

Tried various combinations here, but to no avail:

;;MyronBase
Ellipse 9 -84.679001 71.227997 700 700 -90 0

;;MyronBase
Ellipse 9 -84.679001 71.227997 700 700 0 -90

;;MyronBase
Ellipse 9 -84.679001 71.227997 700 700 -90 -90

I'm not sure what the last two integers mean exactly. I know that they're elevation related, but nothing about it is specified in the D3D9 documentation. Can't find proper documentation on it anywhere. I just copied and modified it from the Starship SN8 thread.

Visual Effects Settings


D3D9 Settings


EDIT: Didn't notice the second post. Will try it.

 

[Pioneer]

Works great now! Thanks for the help! Would love to see documentation included in the D3D9 manual.

 

[kuddel]

Judging by the negative values for fall-off and angle, perhaps you don't know what those values are for. It is like so:
ELLIPSE <height> <lng> <lat> <major> [<minor>] [<phi>] [<falloff>]

So the first value is the height value, followed by longitude and latitude, then major and minor ellipse length, then the angle, then the fall-off. A more detailed description is here: https://www.orbiter-forum.com/threads/area-flattening-experiment-success.37074/post-557220

And (as usual) the D3D9Clients documentation was/is lacking behind

@Face : Could you be so kind and peek over the documentation (especially the "Terrain Flattening definitions" chapter on page 23)?
It would be nice if you could double-check whether it's O.K. / missing something / can be improved ....
Thanks in advance,
Kuddel

 

[Face]

Looks good.
There are some minor typos (I guess they are in my text as well) and a suggestion:

• "ELLIPSE is difined with the midpoint at <lng>/<lat>, ..." - here it should be "defined".
• "RECTANGLE is with midpoint at <lng>/<lat>, <width> and <length> in meter,tilted with <phi> 0-90°, flattened to <height> in meter with <falloff> percent (of full radius seen from edge of shape) gradual transparency merging with actual height. Only the first 4 parameters are necessary, <length> defaults to <width>, the rest to zero." - here "width" and "length" should be swapped.
• I think that it might be good to include a short hint regarding resolution, perhaps something along the lines of "The resolution of the flattening shapes is only as high as the tiles they operate on. I.e.: if you have low resolution terrain, too small shapes could be invisible or distorted."

 

[4throck]

I'd add some more information to flattening, using common language:

• Height equals altitude in meters relative to mean surface level. Ex: on Earth, 8 means 8 meters above the ocean. Altitude is displayed on "Surface MFD".
• When in double about terrain resolution, start with a large area (2 or 3 km) and lower it until you get a good results.
• Terrain interpolation mode (linear, cubic) will impact the results.
• An example of a .flt file for the Atlas pads on Cape Canaveral (because we have good resolution there)

;;LC11
Ellipse 7 -80.5405960 28.4752030 1000 1000 0 20

;;LC12
Ellipse 7 -80.5430260 28.4805330 1000 1000 0 20

;;LC13
Ellipse 7 -80.5454560 28.4857930 1000 1000 0 20

;;LC14
Ellipse 7 -80.5478960 28.4910830 1000 1000 0 20

Hope it helps. Feel free to add/change as needed.

 

[fred18]

Looks good.
There are some minor typos (I guess they are in my text as well) and a suggestion:

• "ELLIPSE is difined with the midpoint at <lng>/<lat>, ..." - here it should be "defined".
• "RECTANGLE is with midpoint at <lng>/<lat>, <width> and <length> in meter,tilted with <phi> 0-90°, flattened to <height> in meter with <falloff> percent (of full radius seen from edge of shape) gradual transparency merging with actual height. Only the first 4 parameters are necessary, <length> defaults to <width>, the rest to zero." - here "width" and "length" should be swapped.
• I think that it might be good to include a short hint regarding resolution, perhaps something along the lines of "The resolution of the flattening shapes is only as high as the tiles they operate on. I.e.: if you have low resolution terrain, too small shapes could be invisible or distorted."

Sorry to jump in. As you know i ve been out of the loop for months, but i just came across this. So have this feature become a standard d3d9 feature? It seems so and i am very happy about it! Well done!

 

[Face]

Hy fred18, welcome back! Yes, thanks to some dedicated users like 4throck here, the D3D9Client team decided to include the feature. I hope that a bigger momentum and the already done code base helps to convince Martin to include this or a similar feature in the core and/or API (e.g. via explicit filter function override). Unfortunately the collision part is still subject to reverse-engineering and assembler hacking.

 

[kuddel]

Thanks @Face & @4throck for the input and sorry for the delay .
For anyone interested in the latest revision (of the documentation), here it is:

 

[yitianetie]

Curious. Can we relate this issue to the elevation issue I have noticed on Mercury, through this thread ?

New Release - D3D9Client Development

Is this for the high-res Mercury textures? I remember the description on those mentioning that they only work with the latest beta. That may have something to do with it.

www.orbiter-forum.com

 

[Face]

Curious. Can we relate this issue to the elevation issue I have noticed on Mercury, through this thread ?

New Release - D3D9Client Development

Is this for the high-res Mercury textures? I remember the description on those mentioning that they only work with the latest beta. That may have something to do with it.

www.orbiter-forum.com

You wrote that the issue is showing up with flattening disabled as well, so I don't think that it has something to do with the intended mechanism. However, according to the D3D9Client code, the hooking of the terrain engine in Orbiter's core is always done, even if the flattening is disabled. Of course the actual manipulation of the tile data is skipped with an early return in the function, so nothing should happen there. There could be some subtle bug within the trampoline, though, even if I can't imagine what that should be after reviewing the small amount of assembler code.
As a quick test, the version you use could be recompiled with the hooking explicitly deactivated by means of commenting the code and forcing the config flag to false. That should suffice to check the theory of flattening having something to do with it or not.
You could also try version 4.6, where terrain flattening was not incorporated. However, if it is not happening with that old version, it doesn't necessarily mean that flattening is the culprit, either. If it is still happening in that old version, it certainly means that flattening is NOT the culprit, though.