Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter SDK
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter SDK Orbiter software developers post your questions and answers about the SDK, the API interface, LUA, meshing, etc.

Reply
 
Thread Tools
Old 04-15-2019, 05:47 PM   #46
fred18
Addon Developer

Default

Since I had the first move on this (but thanks to the capabilities of Face it is even possible to test this) I'll take the responsability and the pleasure to answer with my view. It can be right or wrong of course, but this is how I saw this possible feature:

Quote:
Originally Posted by martins View Post
 Just to be clear: the idea here is to flatten the terrain on the fly at runtime, rather than an offline tool that performs the flattening by modifying the elevation tiles, correct?
precisely this.

Quote:
Originally Posted by martins View Post
 And the flattening effect is simply a circular area of given radius around a given centre position, and possibly smoothing out the resulting sharp edges?
the circle was the easiest to code for testing, if I could choose a shape I'd choose a rectangle defined by 2 or 4 couples of longitude-latitude coordinates (2 are enough for grid aligned rectangles, 4 would allow for any rotation).

Quote:
Originally Posted by martins View Post
 What if users at some time decide that a circular area is not sufficient, and they want a more complex shape to include an oddly shaped base layout, or dig out a blast tunnel, or excavate a river bed through the base? Supporting complex shapes in real time might have a performance impact, so for these cases, manual editing of the elevation tiles might be preferable.
see above relevant to rectangle. If complexity is down to a small level a combination of rectangles can do the job. if it gets too much the user will always have the option to modify the tiles as you just correctly pointed out.

Quote:
Originally Posted by martins View Post
 What happens if two flattened areas with different elevations overlap? Should there be a defined order in which the requests are applied?
I'd say it will be users responsability not to make overlaps, so it would be either undefined behaviour or simply (if possible of course) the last call for that area wins

Quote:
Originally Posted by martins View Post
 If I do get to implement finer elevation resolution, should this be reflected in the functionality of the flattening function (e.g. allow linear slopes, or defining a spline surface), or is flat and horizontal all that is required? If you take Mojave spaceport for example, which is located on an inclined slope, flattening will always dig into the hillside on one end, and raise the terrain onto a platform on the other. Making this look natural would require some extensive earthworks. That is, the levelled terrain would have to drag the surrounding area with it over a larger distance. Doing that in real time could be a challenge.
I'd say that this function is 99% about bases creation and it is an option to allow for that in order to save from tiles patching. If users want to have a sloped runway or a particular requirement, tiles patching would anyway be always available. otherwise they can use the option for flattening and enjoy it as it is. maybe the users will decide that for a situation like that they want to make flat a big area so there is no feeling in sight of the uneven terrain. Or maybe they will try to put some rectangles next to each other with small height difference to see if that works. Experimenting would be on the users IMHO, I would just give the option to have a flat leveled terrain and for those who are willing to make complex shapes or different situations the tile patching would always be available.

That's my vision for this.

Thank you very much for your time
fred18 is online now   Reply With Quote
Old 04-15-2019, 07:56 PM   #47
Face
Beta Tester
 
Face's Avatar

Default

And OBJHANDLE detection is finished as well: https://bitbucket.org/face/ovp/commi...7393d6c96bcb98

So with this I will start to implement the following concept:
* On vPlanet creation, load all *.flt files in the folder /Textures/<planet>/Flat - these files can be distributed by developers for each addon.
* In every file, one or more of the following line entries is parsed:
Code:
ELLIPSE <height> <lat> <lng> <major> <minor> <phi> <falloff>
or
RECT <height> <lat> <lng> <width> <length> <phi> <falloff>
* Ellipse is with midpoint <lat>/<lng>, <major> axis radius in meter, <minor> axis radius in meter, <phi> rotation 0-90 tilted major axis, 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, <minor> defaults to <major>, the rest to zero.
* Rectangle is with midpoint <lat>/<lng>, <width> and <length> 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.
* Shapes are loaded in order of file and line position, last shapes overriding first.
* Shapes are preprocessed into a cascaded map, creating a GBody->level->ilat->ilng database. Whenever a shape touches a given path (so it has multiple paths due to higher levels), it is within that tile and will be taken into account. If a shape's tile contribution is below pixel size, it will not land in the path.
* The filter function will check the database, then do the drawing algorithm for all shapes in the path's list.

Let's see how that works out.

Last edited by Face; 04-15-2019 at 08:28 PM.
Face is offline   Reply With Quote
Old 04-15-2019, 08:14 PM   #48
kuddel
Donator
Default

@Face: Would the <height> be "radius" or "height above mean sphere" / MSL?
kuddel is offline   Reply With Quote
Old 04-15-2019, 08:27 PM   #49
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by kuddel View Post
 @Face: Would the <height> be "radius" or "height above mean sphere" / MSL?
Good question. It will be whatever the INT16 value represents, so I guess mean sphere.
Face is offline   Reply With Quote
Thanked by:
Old 04-15-2019, 08:29 PM   #50
Donamy
Beta Tester


Default

...And people think Orbiter is dead.
Donamy is online now   Reply With Quote
Old 04-16-2019, 12:03 PM   #51
4throck
Enthusiast !
 
4throck's Avatar
Default

ELLIPSE and RECT seem simple enough for me
Easy to use and good for runways, pads and taxiways.

Also easy to get coordinates off Google Maps, perhaps even converting from KML might be possible.

So thank you Face (and others) for looking into this.

Last edited by 4throck; 04-16-2019 at 01:50 PM.
4throck is offline   Reply With Quote
Old 04-16-2019, 12:24 PM   #52
gattispilot
Addon Developer
 
gattispilot's Avatar
Default

Is it working or just talk of how it would work?
gattispilot is online now   Reply With Quote
Old 04-16-2019, 01:47 PM   #53
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by gattispilot View Post
 Is it working or just talk of how it would work?
Both the visual and collision detection manipulation is working, see my posted link for a working D3D9Client with demonstration flattening at Cape Canaveral.

The discussion about file format is just talk as of yet, but the ground works have been done.
Face is offline   Reply With Quote
Thanked by:
Old 04-16-2019, 02:25 PM   #54
fred18
Addon Developer

Default

Quote:
Originally Posted by Face View Post
 Both the visual and collision detection manipulation is working, see my posted link for a working D3D9Client with demonstration flattening at Cape Canaveral.

The discussion about file format is just talk as of yet, but the ground works have been done.
There is one thing is not 100% clear to me about the actual implementation and the eventual final solution.

My understanding is that at the moment you made a "trampoline" to hook into the binary of orbiter_ng.exe so you manage to modify the collision detection function making it loading the values of the elevations loaded by D3D9, is that right?

So what surprises me a bit is about the general system that orbiter uses: the data are loaded and processed twice: one for collision detection and one for graphic representation. Before we stepped into this I always thought that the data were processed just once inside orbiter core and then the client queries the core for making the graphical representation.

So, since it seems that martin is interested in making this a part of final release (so I guess it will be included in the Beta some day?) then D3D9 should be updated in the same way? It does not just query the core for the data and that's it, is that right?
fred18 is online now   Reply With Quote
Old 04-16-2019, 04:19 PM   #55
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by fred18 View Post
 My understanding is that at the moment you made a "trampoline" to hook into the binary of orbiter_ng.exe so you manage to modify the collision detection function making it loading the values of the elevations loaded by D3D9, is that right?
Close. The trampoline hooks into the exact point where Orbiter_ng loaded the elevation data (and pre-processed it) for collision detection, then calls the FilterElevation function with the tile information. The FilterElevation function can then patch the height array or not. It has to decide if a given shape is on the tile, then "paint" the shape over it.

It is not feeding the elevation values loaded by D3D9 into the collision detection system, it reacts to on-going tile-loading (or pre-processing) operations of the core. In other words: it is passive filtering vs. active overloading.

Quote:
Originally Posted by fred18 View Post
 So what surprises me a bit is about the general system that orbiter uses: the data are loaded and processed twice: one for collision detection and one for graphic representation. Before we stepped into this I always thought that the data were processed just once inside orbiter core and then the client queries the core for making the graphical representation.

So, since it seems that martin is interested in making this a part of final release (so I guess it will be included in the Beta some day?) then D3D9 should be updated in the same way? It does not just query the core for the data and that's it, is that right?
This is my understanding as well. Orbiter_ng.exe loads the elevation data in order to process it for collision detection, and the OVP client (in this case: D3D9Client) also has to load it in order to process it for visual rendering. The code sure is written that way.

If a given OVP client is not interpreting the elevation data the same way the core does, you'll get collision/visual dissonance. This is less elegant IMHO.

BTW: I've implemented the shape drawing function, complete with factor, angle, falloff and "rectangle" support (actually I use the ellipse function with higher orders to simulate a rectangle with slightly rounded corners): https://bitbucket.org/face/ovp/commi...60187d109cb8b2

Next stop: file parsing.
Face is offline   Reply With Quote
Thanked by:
Old 04-16-2019, 04:30 PM   #56
fred18
Addon Developer

Default

Quote:
Originally Posted by Face View Post
 BTW: I've implemented the shape drawing function, complete with factor, angle, falloff and "rectangle" support (actually I use the ellipse function with higher orders to simulate a rectangle with slightly rounded corners): https://bitbucket.org/face/ovp/commi...60187d109cb8b2

Next stop: file parsing.
May I be of assistance? the trampoline and the relevant hook were surely out of my knowledge, but the rest I am pretty confident I can be helpful with. If you need/want, just let me know

---------- Post added at 17:30 ---------- Previous post was at 17:24 ----------

PS: A curiosity-> I made a test with Cape Canaveral. Of course it works amazingly. What was curious is that I tried to jump from the cliff with the DG, running at full speed on its gear towards the platform edge, but when I got there the vessel tried to follow the terrain under the cliff and did not jump but tried to go down like on a rollercoaster.
fred18 is online now   Reply With Quote
Old 04-16-2019, 05:25 PM   #57
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by fred18 View Post
 May I be of assistance? the trampoline and the relevant hook were surely out of my knowledge, but the rest I am pretty confident I can be helpful with. If you need/want, just let me know
Be my guest. The code is there at Bitbucket.

As of now, the FilterElevation function uses the static example for Canaveral, but already puts the relevant shape declaration into a fake vector (which should come out of the cascading unordered map). There is some commented code at the top of FilterElevation that shows how it goes through the map to find the shape definitions for the tile at hand.

My approach would be to get that map filled by the vPlanet class by means of iterating over the appropriate /Texture/<planet>/Flat folder to find *.flt files, then load them, parse them for definitions and create FlatShape objects on the heap. Perhaps first into a vector, then after the complete planet finished, copy them to array for stable pointers and create the map out of it.

The map creation should be so that the tentative tile coverage should be generated, i.e. which tile at which level is touched by the shape. I'd do so by means of calculating lat/lng of the corner points of the shape (this could be a simple worst case guess like e.g. using hypotenuse of the 2 shape dimensions for square coverage). Then follow all corner points up to sub-pixel level of the shape size. At each level, for all tiles between the corner points, generate the map path for the shape.

We should be able to get away with this sloppiness, because the brute-force shape drawing will take care of the finer details. Worst case is that we iterate over all tile pixels for nothing. Still it should sufficiently rule out no-matches pretty fast. This way, even big shape-lists all over a planet will not hamper tile-loading too much.

The shape object holds pre-processed values. E.g. the dimensions are converted to lat/lng via a decimal degrees guess, <phi> is converted to appropriate sin/cos values, falloff is in double fracture (not percent), type is 1 for ellipse, 4 for "rectangle".

---------- Post added at 18:49 ---------- Previous post was at 18:45 ----------

Quote:
Originally Posted by fred18 View Post
 PS: A curiosity-> I made a test with Cape Canaveral. Of course it works amazingly. What was curious is that I tried to jump from the cliff with the DG, running at full speed on its gear towards the platform edge, but when I got there the vessel tried to follow the terrain under the cliff and did not jump but tried to go down like on a rollercoaster.
Observed that, too! Two idiots, one thought... off the cliff! Yuppeeeeeh

I guess it has something to do with the algorithm that calculates collision plane according to elevation data. If it is something with bsplines, it could well overshoot by the sudden elevation jump between two data-points.

---------- Post added at 19:25 ---------- Previous post was at 18:49 ----------

Hmm. Perhaps it is not a good idea to do it in the vPlanet class. AFAIK, those objects are created for visuals only, and could be destroyed if they go out of visibility. I think it is best to stick to the client class itself, then.
Face is offline   Reply With Quote
Old 04-17-2019, 12:45 PM   #58
Donamy
Beta Tester


Default

I assume this could be adapted for the moon, as well. I would love to make a crater base.
Donamy is online now   Reply With Quote
Old 04-17-2019, 01:17 PM   #59
gattispilot
Addon Developer
 
gattispilot's Avatar
Default

I think it can be adaptable for any planet. I am not sure how to test it?
I guess for finding lat and Long we just land a vessel there and get the values? MAybe even like a Bulldozer mesh
gattispilot is online now   Reply With Quote
Old 04-17-2019, 01:34 PM   #60
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by Donamy View Post
 I assume this could be adapted for the moon, as well. I would love to make a crater base.
It works on any planet with new texture mode.
Face is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter SDK


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 04:15 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.