New Release D3D9Client Development

[Face]

If the terrain flattening was incorporated in D3D9Client the way it was implemented in the experiment (which I think it was), the format description done here should still hold.

 

[n72.75]

I know it's probably been asked a dozen times, and posted before, but where is the repository for D3D9 Client? Could we add a link to the post #1 in this thread.

 

[igel]

If the terrain flattening was incorporated in D3D9Client the way it was implemented in the experiment (which I think it was), the format description done here should still hold.

Thanks a lot - exactly what I was looking for! And yes, same format hods in the last release. Somehow did not spot this description in my search, though I saw that thread... guess I did not check all pages

 

[DaveS]

I know it's probably been asked a dozen times, and posted before, but where is the repository for D3D9 Client? Could we add a link to the post #1 in this thread.

If you're talking about the SVN repository, it can found found here: svn://mirror.orbiter-radio.co.uk/D3D9client/

 

[igel]

Another 2016 question. In the last 2010 client, mirror surfaces (full-reflection materials) are rendered as such both in outside and cockpit views. In the latest 2016 client, they render as mirrors only in the outside view. Or is there some flag-setting somewhere that triggers this internal rendering on/off? Did not find any...
This had sucker-punched me with new Vostok release - where I re-implemented Vzor (optical orienting device) with true mirrors, and just prior to release - way too late - discovered that is is useless in 2016. Any way to activate it or get it back in the next versions?

 

[igel]

I just realized that if I use something like tooledit to dig any "true" small pit in the Orbiter's space fabric, I'll have to forgo any use of this "flattening" feature and will lave to do all flattening "hard way" in the same tooledit. Otherwise the flattening will override the pit (which is always right in the centre of the flattened area area).

I already considered the 4throck's suggested way: to dig a bigger pit and cover it with custom mesh, and elevate all base objects to new "virtual" surface. But here is the (likely incomplete) list of what has to be considered or done for that in my case:

• My pack of bases contains over 50 individual files for bases, and the number of carefully placed objects in them is close to 2000. So, such update of height of every object can only be scripted.
• These base files are often copied between 2010 and 2016 instances, so height update script should be added to the (already automated) copy process, back and forth. (Note: I can't have two separate development sets for two versions, and can't abandon 2010 until I am sure the 2016 version looks and feels at least not worse than 2010... and until I abandon 2010, I can't benefit from any new 2016 APIs and features in the common codebase).
• "Live" launchpad "vessels" in scenarios have also to be updated for touchdown point heights (and also selectively only for 2016 version).
• In my scenarios, especially in LES/emergency scenarios, a lot of vessels land in the nearest vicinity of the launchpad. With this approach, they will sink through the "virtual" surface and end up deep down on the real one. I'll have to implement watching their flight and "sticking" (attaching?) them to the virtual surface (already doing this for Vostok pilot ejected on the pad, so it is possible to do). But if you take off or fly, say, in DG over the area (I have such scenario) - reported altitudes will be all miscalibrated. (Well, who of us had never ever taken off with miscalibrated altimeter )
• I already use "skirts" around the launchpad meshes to blend with the surroundings. However, with big dugouts (few kilometres across) the skirts should be extended really wide to cover them. And with close proximity of several bases on Baikonur, their overlapping may become messy...
• Not sure how shades will be rendered on "virtual" surfaces. Rendering from the distance is also a concern, though this part is tweakable, I guess.
• Another still outstanding issue is to convert all Baikonur meshes to a new format. As base meshes are not supported in 2016, those need to be somehow made "true" Orbiter textures, and, as they are of "old" sizes, and there are many of them, this probably also needs to be scripted... did not look in their direction yet, that's a different fish to fry... But it is still closely related to surface meshes - not much help if this converted texture gets hidden by "virtual" surface and will have to be duplicated in "virtual" surface anyway...

Most frustrating is... All this work is not to gain some new or exciting look or functionality - but to simply restore what already was there, and still works and looks almost perfectly in the previous version. Technology lock-in in its fullest...

 

[Face]

I think I am missing something here. Orbiter 2010's earth is a flat ball with MSL 0 everywhere, right? If you have something that works for this, what is the difference to 2016 with a big flattened circle (say 20km) to MSL0 at the base coordinates, and your addon from 2010 applied as it is? Sure, you'd have that flattening while closing in to the base (which could be compensated with fall-off), but at the base itself it should be fine, no? Also, what do you mean with base meshes not supported? I converted the old WIA just fine with the idea to flatten the area completely to zero, then using unchanged base elements upon that.
If you mean old base tiles, there is a solution for that with treeman's base conversion feature.

 

[igel]

" base meshes not supported " - yes, I meant base tiles, sorry. I'll indeed look at base conversion tool once I solve the 3D puzzle.

The thing that changed in 2016 is, I guess, simply the rendering order. In 2010, the "underground" portion of the mesh is rendered in front, as priority, still always visible, not covered by Earth's sphere surface. It even takes extra effort to hide undergroung portions that you do NOT want to see . In 2016, planet surface always has the priority - as far as I know. And that's all the change, I think.

Of course, 2010 implementation is also not fully ideal: if something lands in the flame trench pit, it will "land" on the invisible surface on the true planet's ground level, and will look like floating in the air above the trench floor. But that's a rare localized effect, not hurting visuals much - not more than if the same object land on elevated portion of the base mesh and sinks through it to the ground level. And, when absolutely needed, both things can be fixed with "smart sticking". There are a few other things, like shadows, or fully underground objects not getting sun, but once again those are local and less damaging than the trench filled with planet's surface.

 

[Face]

Ah, I see. Well, the collision and shadow thing you mentioned would indeed indicate that the "start-at-lowest-level" method to model the base is not a good approach. What about the other idea? Create simple high-res tiles for the area, dig the high-res trench with the flattening method (or even built-in to the high-res tile), then place the mesh over it. You don't have to create the trenches perfectly fine, just good enough to make way for the mesh not being filled up.

I think the show-stopper here is the stock (or even "high-res") earth terrain being too coarse at your add-ons location (Baikonur?).

 

[igel]

Hm. I did not think... maybe indeed the coarsness of .flt override is caused by the resolution of the tiles at that place? Which may be increased? Good idea to check.
What is the "minimum" size of the individual ground "cell-pixel" (in meters) on Earth-size planet? What ultimate accuracy can I realistically expect with the trench in the most fine tile resolution?

 

[Face]

Well, I know that the flattening feature is not changing the rendering operation, it just changes the data before it is used for the rendering (and collision checking). Therefore, if not more data is present, it can't create more details.
If my calculation is right, you can have - at max. level 17 - the resolution of 16384 tiles with 256 height points each. On the equator of earth, that would mean a resolution of approx. 10m. At Baikonur latitude (ca. 45°) the longitudinal resolution is approx. 7m, but the lateral resolution stays at 10m.

So, realistically I'd say the minimal trench you can dig is a quadratic pyramidal one with approx. 14 meters side length. But this only if the point you want to lower happens to fall right on a grid point of the terrain. In the general case, I'd calculate with double the size, so say maybe 30m.

 

[GLS]

Well, I know that the flattening feature is not changing the rendering operation, it just changes the data before it is used for the rendering (and collision checking). Therefore, if not more data is present, it can't create more details.
If my calculation is right, you can have - at max. level 17 - the resolution of 16384 tiles with 256 height points each. On the equator of earth, that would mean a resolution of approx. 10m. At Baikonur latitude (ca. 45°) the longitudinal resolution is approx. 7m, but the lateral resolution stays at 10m.

So, realistically I'd say the minimal trench you can dig is a quadratic pyramidal one with approx. 14 meters side length. But this only if the point you want to lower happens to fall right on a grid point of the terrain. In the general case, I'd calculate with double the size, so say maybe 30m.

So level 19 would be a quarter of that?

 

[4throck]

In the general case, I'd calculate with double the size, so say maybe 30m.

Small areas don't work visually because, as Face mentioned, they are not aligned with the terrain "grid".
So your hole will be uneven.
But you should still do it because of shadows and exhaust renderning.

II think it might work if you lower a larger area than the pit, then add a mesh for the entire Pad. Perhaps 500m all around.

Also, you can have multiple flatten areas if I'm not mistaken.
So you can have a large area for the entire base if needed, and a smaller one just for the Pad/pit depression.

 

[Face]

AFAIK, Orbiter supports elevation data only up to level 17. It is what the documentation says, at least.

 

[igel]

II think it might work if you lower a larger area than the pit, then add a mesh for the entire Pad. Perhaps 500m all around.

Yes, tha't what I am inclined to look at. 500 seems big , though - I hope to 100... and with near-vertical walls, otherwise footprint will be eve bigger. Or 200 if grid alignment is unfortunate. And, unfortunately, flattening around it will also have to be done manually in the tiles - otherwise .flt file will override the pit. I doubt I can put ,flt record accurately enough to just side with the pit but not touch it (remember I mentioned in a earlier post that my experimental hill was displaced off intended coordinates by good hundreds of meters if not a kilometer or so))

 

[Face]

And, unfortunately, flattening around it will also have to be done manually in the tiles - otherwise .flt file will override the pit. I doubt I can put ,flt record accurately enough to just side with the pit but not touch it (remember I mentioned in a earlier post that my experimental hill was displaced off intended coordinates by good hundreds of meters if not a kilometer or so))

The displacement was certainly an artifact of the coarse terrain definition. I'd propose the following approach:

1. create an elevation tile with plane information (i.e. one height for all points)
2. copy it for all the texture tree slots around the base to ensure L17 terrain resolution at the appropriate position
3. use flattening to first flatten the surrounding area (lets say 1km circle) to your planned zero level
4. use additional flattening to dig the trenches big and deep enough to make room for the mesh
5. adapt the mesh skirts to deal with the superfluous trench

If you give me your base position and approximate base size (or better yet: the link to the addon to try it with), I can help you with 1 to 4.

 

[igel]

Oh, thanks for the offer! If possible, that will be a great help - myself, I'll be able to start looking at it no sooner than weekend!
Addon file is here, just the bases. It may be best to experiment right with the most important one, Gagarin's Pad 1. Its coordinates are +63.3421845 +45.9203129, these coordinates are for the "centre" of the base, right in the centre of the pad's rotating ring. The best scenario to look at is probably Historical Spaceports\Baikonur\Pad 1\5. Soyuz Period.scn (this base has several implementations for its historical periods, over time, and Soyuz period has the maximum buildup, with most objects).

The displacement was certainly an artifact of the coarse terrain definition.

Good to know!

 

[igel]

Even more - once I create highest-res elev tiles in my areas - I want to retry digging trenches with .flt files. They might actually work for me! My early experiments were frustrating, but if the core reason was simply lack of proper underlying grid...

 

[Face]

This here will get you flat elevation tiles at height 45MSL for the area surrounding pad 1 in the add-on you linked me to. The included flat file will first flatten a circle 30km around it to 45MSL, then dig a hole big enough for the trench (it's 29m deep). Unfortunately, all base elements that are positioned in the hole, also "fall" into it, so you'd have to raise their Y coordinate appropriately. In addition, because the base itself is "in" the hole, all relevant shadows are also at that level, which makes it look awkward. I'd suggest to place the base coordinate somewhere to the side and change the element positions.

I also noticed a sort of race-condition, where Orbiter sometimes places the base elements at tile level, sometimes at flattening level. Not sure if this happens for everyone, though.

 

[Face]

Hm, come to think, perhaps we could add some flag to the shape definition that makes it visual only. Such shapes would be able to benefit from the bug we had with the flatting at first: being applied to interpolated data, such tricks as the with the artificial high-res tiles above would then be unnecessary. In your special case, the flattening is only for pure visuals, after all. In addition, not having the hole in the collision detection would make such situations much easier, because you wouldn't have to change element positions at all.

Technically, a second shape data structure only used by the call at the old "bug-position" would do the trick.