Discussion Developing Addons for different Orbiter Versions

[Face]

I think that if this somehow comes to orbiter suddenly all the bases could be imported with a very little work and that would be super!

I think this idea can be incorporated in the D3D9Client by community effort. The code is there, just plug this in (perhaps with some proprietary extra config file), then test and see how it goes. If it is any good, Martin could back-port it into MOGE.

 

[fred18]

I think this idea can be incorporated in the D3D9Client by community effort. The code is there, just plug this in (perhaps with some proprietary extra config file), then test and see how it goes. If it is any good, Martin could back-port it into MOGE.

I surely agree here. I have no idea of how it works in actual D3D9 code, so it is up to Jarmo, kuddel and all the (amazing) D3D9 team. I offer myself from now to support this for help and the description of the idea in details.

 

[Face]

I surely agree here. I have no idea of how it works in actual D3D9 code, so it is up to Jarmo, kuddel and all the (amazing) D3D9 team. I offer myself from now to support this for help and the description of the idea in details.

Don't be so humble there, I'm sure you are more than capable to figure it out as well.
Take a look, in essence there is a TileManager2 class that loads and interprets the proprietary tile format, then does the tesselation. If this class also loads some base flattening config file, it could work out the coordinates and override the given vertices.
Sure, it would be a D3D9-only solution, but if it is any good, I'm sure Martin would consider using it in the stock engine as well.

 

[gattispilot]

Can't flattening happen now? I remember trying it and some how to do it. But maybe it needs to be refocused.

 

[fred18]

Can't flattening happen now? I remember trying it and some how to do it. But maybe it needs to be refocused.

What I am saying is to NOT modify the terrain tiles. But simply at rendering time if there is a specific base which has in cfg that it is at altitude X and with a size of Y, the render process will render INSTEAD of the regular terrain elevation a square flat area of side 2Y at altitude X.

So there will be no need to edit the tiles or whatever to make the bases work

---------- Post added at 14:48 ---------- Previous post was at 14:47 ----------

I'm not sure if it can be only a matter of graphic anyway: if I land on a runway in that base the surface contact must be there

 

[Urwumpe]

Sure, it would be a D3D9-only solution, but if it is any good, I'm sure Martin would consider using it in the stock engine as well.

And what if you don't want it to be flat?

Why flatten Vandenberg? Or such a pearl like Andoya?

Sorry, but I don't think the graphics engine should do the thinking for a human...

 

[Face]

And what if you don't want it to be flat?

Why flatten Vandenberg? Or such a pearl like Andoya?

Sorry, but I don't think the graphics engine should do the thinking for a human...

Hey, I just outlined how fred18's idea could be implemented. I think it could be worth a try to see how it helps the ecosystem of 2016.

 

[4throck]

Yes, I wonder if a similar tool could also be made for Orbiter, just using a selected Orbiter data set as terrain reference.

Orbiter is using free data sources, so you can get altimetry and landsat images from elsewhere and they should match.
The latest Sketchup version is still able to get terrain and images from Google Earth.
I haven't' tested but it should be a decent match to Orbiter. So we might already have a tool to work with existing terrain.


On some cases flattens makes sense, like pads and runways.
Even on Andoya I bet those pads are flat and perhaps a bit raised.
My view is that this should be handled automatically, as an option associated with those base objects on the base definition.

 

[Urwumpe]

Orbiter is using free data sources, so you can get altimetry and landsat images from elsewhere and they should match.

The latest Sketchup version is still able to get terrain and images from Google Earth. I havent' tested but it should be a decent match to Orbiter.
So we might already have a tool that works.

I might give it a try if I could extract the data from Orbiter instead - not the whole planet texture - just enough data to produce a reasonable heightmap around a base for editing. Then editing real planets or using custom planets would be still possible (for example making a Kubrick Memorial Moon, since he filmed 2001 before the Apollo Landings).

---------- Post added at 16:04 ---------- Previous post was at 16:03 ----------

Hey, I just outlined how fred18's idea could be implemented. I think it could be worth a try to see how it helps the ecosystem of 2016.

Well, and I just say my concerns once and now - and not later with the prefix "I have always known this was a bad idea." :lol:

 

[gattispilot]

Orbiter is using free data sources, so you can get altimetry and landsat images from elsewhere and they should match.

The latest Sketchup version is still able to get terrain and images from Google Earth. I havent' tested but it should be a decent match to Orbiter.
So we might already have a tool that works.

So are yiou saying use the terrain in Sketchup and match a mesh of a base in Orbiter?




But sometimes you want a flat surface like in Moonbase Alpha interiors,....

 

[Urwumpe]

But sometimes you want a flat surface like in Moonbase Alpha interiors,....

Yes - for that you should consider having either a special moon elevation model (since it is not the real moon, but an artistic interpretation of the moon) or making the base a vessel so having the interior meshes underground causes no rendering problems.

 

[Face]

I'm not sure if it can be only a matter of graphic anyway: if I land on a runway in that base the surface contact must be there

Good point. I'm not sure, but I think this will indeed not work with only the graphics side filtering the base area. However, it might still be worth to at least show how it would look like in the end. Even with vessels sitting like sparrows on the ghost terrain :lol: .

 

[fred18]

And what if you don't want it to be flat?

Why flatten Vandenberg? Or such a pearl like Andoya?

well if you don't want the terrain to be modified you can set a keyword or a flag and the terrain does not get overridden, or the other way around, it doesn't matter much. Anyway it can also be about sub items which are surely flat: buildings, runways, pads... I know you know cities skylines, think about it as the mechanism I have in mind...

Yes - for that you should consider having either a special moon elevation model (since it is not the real moon, but an artistic interpretation of the moon) or making the base a vessel so having the interior meshes underground causes no rendering problems.

you can always make the base a vessel to avoid that, but they won't appear in the base list with all the relevant consequences, but, most important, what about runways and pads. that's the real topic. I need a flat terrain to land on a runway... that's what the big issue is. It's not a problem to make a building, translate it to a vessel and put it on the ground... even though it will be subject to statevectors update which is not good, the land texture won't be there if you want a smooth terrain that matches the terrain underneath etc.

---------- Post added at 15:38 ---------- Previous post was at 15:30 ----------

I honestly don't see why the 3 areas I marked here cannot be 3 flat areas. It would mean to have the possibility to make the base with just a cfg file without touching a single elev file, preserving the original earth with all the good that comes with it (conflicts and everything related).

What kind of issues could be there with such a system? I can't see any potential problem, but just benefits...

In the end what is needed is just a tool that allow to flatten a certain area at runtime, that's it.

 

[Urwumpe]

well if you don't want the terrain to be modified you can set a keyword or a flag and the terrain does not get overridden, or the other way around, it doesn't matter much. Anyway it can also be about sub items which are surely flat: buildings, runways, pads... I know you know cities skylines, think about it as the mechanism I have in mind...

I know - but its map is many orders of magnitude smaller than the smallest possible planet elevation model in Orbiter.

you can always make the base a vessel to avoid that, but they won't appear in the base list with all the relevant consequences, but, most important, what about runways and pads. that's the real topic. I need a flat terrain to land on a runway... that's what the big issue is. It's not a problem to make a building, translate it to a vessel and put it on the ground... even though it will be subject to statevectors update which is not good, the land texture won't be there if you want a smooth terrain that matches the terrain underneath etc.

The runways are the biggest problem, because Orbiter uses large discrete steps along the way, instead of smoothing runways. That is something the graphics client could likely even fix without additional keywords, just with knowing there there is a runway.

For a underground base with pads, it should be easier... LANDING underground would require some serious digging though.

 

[Face]

I honestly don't see why the 3 areas I marked here cannot be 3 flat areas. It would mean to have the possibility to make the base with just a cfg file without touching a single elev file, preserving the original earth with all the good that comes with it (conflicts and everything related).

What kind of issues could be there with such a system? I can't see any potential problem, but just benefits...

And this is why a demonstration is necessary IMHO. If we can get the OVP engine to at least render such definition capabilities, the discussion would not be hypothetical anymore and better show the potential of the idea.

 

[Urwumpe]

What kind of issues could be there with such a system? I can't see any potential problem, but just benefits...

Its just not necessary there.

If you use a less selective system to flatten the whole base area, it would be too much impact.

If you flatten for every building, installing more add-ons and having multiple vessels in different places of the universe will become a massive performance killer (After all, we need this data also for vessels not controlled by the player!)

The smart middle ground would require a public interface for add-on developers for THIS specific graphics client again. And still be terrible for the resources.

In the end what is needed is just a tool that allow to flatten a certain area at runtime, that's it.

I don't like at runtime, for the reasons you can see above. We are wasting runtime resources for something add-on developers should do offline.

Can't we have a tool that simply applies "terrain patch files" to Orbiters elevation model when an add-on is installed and undos the changes, when uninstalling an add-on?

 

[fred18]

I know - but its map is many orders of magnitude smaller than the smallest possible planet elevation model in Orbiter.

yes, but I am not saying that an entire planet should be flat, I just say that some hundreds square meters defined shall be just rendered flat, like the terrain around a building or below a runway. AFAIK the render is made in the following way: as soon as the view gets the details because it gets closer to an item, the level of the rendering of the item increases. So from space we don't see small hills, but we see them if we get close to them. In the same way, when you get close to a "flattened" area, at the moment its rendering is triggered the area is rendered flat instead of the full terrain of that. that's it. Just limit the flattening size in order not to have artifacts and that's it.

And this is why a demonstration is necessary IMHO. If we can get the OVP engine to at least render such definition capabilities, the discussion would not be hypothetical anymore and better show the potential of the idea.

I agree, I gave a look at the tilemanager class but I really need the ones who know what it do precisely to help because to start from zero it will take a year to get the full grasp of it.

 

[Face]

We are wasting runtime resources for something add-on developers should do offline.

You are right on the concept, but unfortunately, the developers just refuse to do that extra work. That's why they are not interested in 2016, which is the reason why this discussion started.

 

[fred18]

If you flatten for every building, installing more add-ons and having multiple vessels in different places of the universe will become a massive performance killer (After all, we need this data also for vessels not controlled by the player!)

how can it have more impact than the actual terrain rendering itself? one is flat and the other is not, if one is rendered the other shall be rendered too, if one is not, the other shall not be rendered as well. So how can this be different?

The smart middle ground would require a public interface for add-on developers for THIS specific graphics client again. And still be terrible for the resources.

I think that what Face was proposing was to have the system tested with D3D9 to see if it's interesting or not, since D3D9 team is reasonably available, while we can't force martin to do anything to the core. But if it works we can kindly ask him to at least think about it.

I don't like at runtime, for the reasons you can see above. We are wasting runtime resources for something add-on developers should do offline.

again: how can the resources be more for a flat terrain comparing to a non flat one? the flat part can be one square, with one normal... the mountain in its place could have 100000 polygons... how can it be worse than better performance wise??

Can't we have a tool that simply applies "terrain patch files" to Orbiters elevation model when an add-on is installed and undos the changes, when uninstalling an add-on?

what if I want a base to be there in one scenario and not be there in another? like a moon landing site. shall we patch the tiles each time? it's dangerous: tiles are some tons of GB of data, really difficult to touch, you miss something and you'll have to redownload everything

---------- Post added at 16:01 ---------- Previous post was at 15:59 ----------

just to add that if a vessel is landed somewhere its state vectors relevant to the planet are just frozen and not updated anymore unless needed, so it will only be about what is in the main window that is seen. To me is a 0 performance impact or 0.0000000001% if anything is there....

 

[DaveS]

Can't we have a tool that simply applies "terrain patch files" to Orbiters elevation model when an add-on is installed and undos the changes, when uninstalling an add-on?

That's how it is officially right now, with those "terrain patch files" stored in a special "Elev_mods" subfolder.