Problem D3D9 Flattening Issue

Pioneer

Well-known member
Joined
Mar 2, 2012
Messages
407
Reaction score
168
Points
58
Location
The D
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.

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

Screenshot 2020-12-22 13.19.14.png
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,314
Reaction score
435
Points
123
Location
Vienna
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,314
Reaction score
435
Points
123
Location
Vienna
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

Well-known member
Joined
Mar 2, 2012
Messages
407
Reaction score
168
Points
58
Location
The D
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:

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

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

Code:
;;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
1608664688686.png

D3D9 Settings
1608664735162.png

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

Pioneer

Well-known member
Joined
Mar 2, 2012
Messages
407
Reaction score
168
Points
58
Location
The D
Works great now! Thanks for the help! Would love to see documentation included in the D3D9 manual.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
1,783
Reaction score
287
Points
83
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 :rolleyes:

@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
 

Attachments

  • D3D9Client.pdf
    312.5 KB · Views: 8

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,314
Reaction score
435
Points
123
Location
Vienna
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

Enthusiast !
Joined
Jun 19, 2008
Messages
3,328
Reaction score
606
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
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)
Code:
;;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

Addon Developer
Addon Developer
Donator
Joined
Feb 2, 2012
Messages
1,646
Reaction score
55
Points
63
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,314
Reaction score
435
Points
123
Location
Vienna
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.
 

yitianetie

Member
Joined
Mar 24, 2020
Messages
43
Reaction score
14
Points
23
Location
Brittany
Curious. Can we relate this issue to the elevation issue I have noticed on Mercury, through this thread ?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,314
Reaction score
435
Points
123
Location
Vienna
Curious. Can we relate this issue to the elevation issue I have noticed on Mercury, through this thread ?

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.
 
Top