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, 01:37 PM   #31
jarmonik
Beta Tester

Default

Quote:
Originally Posted by 4throck View Post
 So would it be possible to load a mesh and use its vertices as a terrain source?

It would be possible to have a patch utility that would take a mesh as an input and create a set of Elev_Mod files and Surf textures as output. Realtime solution is unlikely. Do you have any mesh candidates for testing purposes ?

Last edited by jarmonik; 04-15-2019 at 01:47 PM.
jarmonik is offline   Reply With Quote
Thanked by:
Old 04-15-2019, 01:38 PM   #32
Donamy
Beta Tester


Default

Would love to be able to land on the moon, and not sink in the mud. Oh wait...
Donamy is offline   Reply With Quote
Old 04-15-2019, 01:42 PM   #33
gattispilot
Addon Developer
 
gattispilot's Avatar
Default

Quote:
Originally Posted by Donamy View Post
 Would love to be able to land on the moon, and not sink in the mud. Oh wait...

Well you can do that now. Some sinkage is normal. If Ummu or what ever come out I hope for precise touchdown points,....
gattispilot is offline   Reply With Quote
Old 04-15-2019, 01:52 PM   #34
kuddel
Donator
Default

Just as a side-note for "flat":
For planet-sized bodies, matching a flat area onto the sphere is usually O.K. and exactly what one would expect,
but for small bodies a "flat-flat" area might be what a base-builder likes to have.

We should keep in mind that an "DONT_MAP_TO_SPHERE" option/flag might be needed.
Attached Thumbnails
FlatOnSphere.png  
kuddel is offline   Reply With Quote
Old 04-15-2019, 01:56 PM   #35
fred18
Addon Developer

Default

Quote:
Originally Posted by kuddel View Post
 Just as a side-note for "flat":
For planet-sized bodies, matching a flat area onto the sphere is usually O.K. and exactly what one would expect,
but for small bodies a "flat-flat" area might be what a base-builder likes to have.

We should keep in mind that an "DONT_MAP_TO_SPHERE" option/flag might be needed.
I surely agree.

Anyway I think that the base point is that we need access to the elevation data that the core has inside. If we get that from Martin then we can build whatever plugin is needed with whatever option.
fred18 is offline   Reply With Quote
Old 04-15-2019, 02:18 PM   #36
4throck
Enthusiast !
 
4throck's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 It would be possible to have a patch utility that would take a mesh as an input and create a set of Elev_Mod files and Surf textures as output. Realtime solution is unlikely. Do you have any mesh candidates for testing purposes ?

Realtime is not needed, but I think using Orbiter itself for realtime preview (and adjustments) might be interesting.
Just like Fred's Multistage and VBuilder, that has a GUI inside Orbiter.

Indeed I have suitable meshes, based on approximate real data for the Pathfinder landing site:
https://www.orbithangar.com/searchid.php?ID=6348


One covers a larger area, the other just the proximity of the lander, both have textures.
Have fun with them!
4throck is offline   Reply With Quote
Thanked by:
Old 04-15-2019, 02:29 PM   #37
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by jarmonik View Post
 I would support the idea that Face was working on as one option void FilterElevation(OBJHANDLE hPlanet, int lvl, int ilat, int ilng, INT16 *elev); But I would change the INT16 *elev to float *elev. It would sound logical that Orbiter would convert the INT16 data to float when loading it. This is not very far from the tile server idea I had.
It seems like Orbiter internally also uses INT16 arrays for the raw elevation data it operates on. This is also the case for the OVP code, so I guess it is best used in both cases with that signature.
Face is offline   Reply With Quote
Thanked by:
Old 04-15-2019, 03:49 PM   #38
fred18
Addon Developer

Default

So what do we do, we just hope that martin find the time and the patience to read this or shall we highlight, recapi and forward this to him in any manner? just to know how to do it properly, without making him lose time, or anything he doesn't like.
fred18 is offline   Reply With Quote
Old 04-15-2019, 04:15 PM   #39
Face
Beta Tester
 
Face's Avatar

Default

Good news, folks: I've made it! The trampoline is installed and hooks Orbiter's core collision detection, so you can overwrite it in a filter function similar to what you've seen before. You can then land vessels on the flat surface.

Debug example client that makes a pancake at Canaveral: http://snoopie.at/face/beta/D3D9Client.dll
Code is here: https://bitbucket.org/face/ovp/commi...8b720c8b1be467

Please use it only with stock Orbiter 2016, not with a beta.

Note that at the moment I don't have forwarded the proper OBJHANDLE from the core hook, so don't use this just yet.
Face is offline   Reply With Quote
Old 04-15-2019, 04:21 PM   #40
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by jarmonik View Post
 It would be possible to have a patch utility that would take a mesh as an input and create a set of Elev_Mod files and Surf textures as output. Realtime solution is unlikely. Do you have any mesh candidates for testing purposes ?
I think this would be an excellent test case, the main SLC-6 area mesh we use in SSU: https://www.dropbox.com/s/z45mnfipmr...6_STS.zip?dl=0


Mesh and textures are included.
DaveS is online now   Reply With Quote
Thanked by:
Old 04-15-2019, 04:40 PM   #41
jarmonik
Beta Tester

Default

Quote:
Originally Posted by Face View Post
 It seems like Orbiter internally also uses INT16 arrays for the raw elevation data it operates on. This is also the case for the OVP code, so I guess it is best used in both cases with that signature.

Yeah the raw data is in INT16 format but it gets converted to a float at some point later on. When I was working on the surface micro-texturing I got an idea of micro-elevation. The interface function you presented could almost do the trick. The data would need to be returned as floats due to detail requirements. Also, instead of returning 'void' it should return 'int' the maximum level of detail that is available for Orbiter to acquire. Nice idea but might be too much 'forward' looking, I'm afraid.

An other option, more consistent with current implementation, is to let the Orbiter todo the flattening. For an example, Orbiter is already manipulating the data in ElevationGrid() function, so, why not flatten it too for a better consistency. (not in ElevationGrid() of course). Orbiter would need to do the flattening for the inline engine without help from D3D9 anyway.
jarmonik is offline   Reply With Quote
Thanked by:
Old 04-15-2019, 04:42 PM   #42
gattispilot
Addon Developer
 
gattispilot's Avatar
Default

Quote:
Originally Posted by fred18 View Post
 So what do we do, we just hope that martin find the time and the patience to read this or shall we highlight, recapi and forward this to him in any manner? just to know how to do it properly, without making him lose time, or anything he doesn't like.
I would show that it can be done. And if users want it. Then pass on to Martin.
gattispilot is offline   Reply With Quote
Old 04-15-2019, 04:52 PM   #43
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by jarmonik View Post
 Yeah the raw data is in INT16 format but it gets converted to a float at some point later on. When I was working on the surface micro-texturing I got an idea of micro-elevation. The interface function you presented could almost do the trick. The data would need to be returned as floats due to detail requirements. Also, instead of returning 'void' it should return 'int' the maximum level of detail that is available for Orbiter to acquire. Nice idea but might be too much 'forward' looking, I'm afraid.

An other option, more consistent with current implementation, is to let the Orbiter todo the flattening. For an example, Orbiter is already manipulating the data in ElevationGrid() function, so, why not flatten it too for a better consistency. (not in ElevationGrid() of course). Orbiter would need to do the flattening for the inline engine without help from D3D9 anyway.
My comment was merely in the context of the current experiment. Here the INT16 comes naturally due to the already defined data-structures within Orbiter's core.

IMHO, there shouldn't be any API at all in the end. Just a definition format that Orbiter reads and uses accordingly. Perhaps the current duality between core reading of the elevation data for OVP collision detection and OVP graphics rendering is sub-optimal. I guess it would be better if Orbiter holds the tile information in whatever detail is necessary (there your floating point proposal would fit), then transfers it to the OVP client for rendering. As it is now, the client has to do the same work as the engine in parallel.
Face is offline   Reply With Quote
Thanked by:
Old 04-15-2019, 05:21 PM   #44
martins
Orbiter Founder
Default

I'm monitoring this thread, but I am unlikely to find time to do much on this for a few weeks.

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? 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?

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.

What happens if two flattened areas with different elevations overlap? Should there be a defined order in which the requests are applied?

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.
martins is offline   Reply With Quote
Old 04-15-2019, 05:28 PM   #45
gattispilot
Addon Developer
 
gattispilot's Avatar
Default

So it sounds like flatten can be done already, right?

Maybe a how to flatten would be good. I thought this was mentioned before
gattispilot 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 05:12 AM.

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.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.