New Release D3D9Client Development

igel

Addon Developer
Joined
Mar 28, 2008
Messages
192
Reaction score
30
Points
28
Website
www.pin-plus.ca
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

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,138
Reaction score
65
Points
73
Location
Vienna
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

Addon Developer
Addon Developer
Joined
Mar 22, 2008
Messages
4,000
Reaction score
106
Points
88
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

Enthusiast !
Joined
Jun 19, 2008
Messages
3,008
Reaction score
124
Points
88
Location
Lisbon
Website
orbiterspaceport.blogspot.com
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

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,138
Reaction score
65
Points
73
Location
Vienna
AFAIK, Orbiter supports elevation data only up to level 17. It is what the documentation says, at least.
 
  • Like
Reactions: GLS

igel

Addon Developer
Joined
Mar 28, 2008
Messages
192
Reaction score
30
Points
28
Website
www.pin-plus.ca
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

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,138
Reaction score
65
Points
73
Location
Vienna
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

Addon Developer
Joined
Mar 28, 2008
Messages
192
Reaction score
30
Points
28
Website
www.pin-plus.ca
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

Addon Developer
Joined
Mar 28, 2008
Messages
192
Reaction score
30
Points
28
Website
www.pin-plus.ca
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

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,138
Reaction score
65
Points
73
Location
Vienna
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

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,138
Reaction score
65
Points
73
Location
Vienna
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.
 
Last edited:

igel

Addon Developer
Joined
Mar 28, 2008
Messages
192
Reaction score
30
Points
28
Website
www.pin-plus.ca
Thanks a lot - will try right away.
Before that... I tried to play with tileedit myself. Used the precompiled version published in another forum - maybe also not the freshest build, but reported workable. However, in my case, I was not able to save edits. Tile gets geneared, I edit it, walk to neighbouring tile (to save it), walk back - nothing was saved, tile not existing again, re-generated, nothing on HDD. Well, almost nothing- neighbouring tiles are written, but the one that I was trying to edit, is not on HDD. Not sure what's causing it. Level 17 or level 19 - just the same.
 

Face

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,138
Reaction score
65
Points
73
Location
Vienna
I don't know much about tileedit, sorry.
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
192
Reaction score
30
Points
28
Website
www.pin-plus.ca
With the newly provided elev tile set I finally got some hands-on with tileedit. Now I can edit tiles. The difference with past unsuccessful run is that I have both Elev and Elev_mod folders. Before, only Elev_mod was being created. I guess I just need to re-read the Orbiter doc regarding these tiles tree in general (rather than continuing asking dumb questions :) )

But I still have one not so dumb question. Here is the screenshot from my tile editing experiment. Don't worry for distortions, they are expected.
BaseAlt.PNG
Here, I elevated the portion of the base (including base coordinates point - that's important) to 107m - this is closer to average AGL of Baikonur area. The remainder of the tile is still at 45 AGL. Flattening is commented out after initial testing, to get it out of the picture. What surprises me here is that base is still rendered at 45m, not at 107. As my edit only touched tile at level 17, when I zoom out to next level (16 and up), my distortion is gone, and the whole area gets back to 45m rendering. So, at level 17, while surface rendering is taken from the tile 17, base elevation is still taken from... well, apparently, from some other level tile. I guess this also causes shadows awkwardness in other runs...

I hope, these effects will go away once all elevation levels are properly aligned. But may be a helluva lot of work... And there comes the next question: is there an easy way to change elevation of the whole tile? tileedit only allows you to paint with a maximum 5-pixel brush, and any accidental move of mouse out of the window will CTD... Is there an easier way to set the elevation to the whole tile? Maybe with elev2png?
 

Face

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,138
Reaction score
65
Points
73
Location
Vienna
For base elements and shadows, what I found is that the elements are placed on the height corresponding to their element position. They follow terrain, so to say. Shadows are placed on the level of the base location point for all elements. However, with my own tests with the new D3D9Client, I have also observed some kind of race condition, where it is not determined at what level the base elements get placed. In general, though, mismatching level tiles (17 edited, but 16 not and so on) produce many visual artifacts and problems.

As for ele2png, all it does is converting ELV files to PNG and back again. You can edit those PNGs with an image editor and e.g. fill the whole picture with a color that represents your height. Note that the tiles I produced for you are probably not convertable with it, because those tiles were special flat tiles of type 0 (which makes them super small due to the single height being used from offset).
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
192
Reaction score
30
Points
28
Website
www.pin-plus.ca
I finally have some real progress, with hope to improve the look for 2016 to more or less acceptable level. The best result came from flattening a few key tiles in level 17 in tooledit, and then flattening a rather small area in .flt file:

; flat 3 km radius circle at Baikonur-2
ELLIPSE 107 +63.3176154 +45.9151219 3000
; minimum pad 1 dugout
RECT 70 +63.343 +45.9193 150 50

Just a small 3 km circle centered at Site 2 flattens 5 or 6 most important areas, including Pad 1. With converted surface textures, this produces quite nice result even without pits. Some texture work is still needed - dynamic texture look with changing zoom is still quite uneven and jumpy.

Digging pits, however, is still a long shot. Test dig finally looks promising, and shows that the task can indeed be achieved... in principle:
Dig1.PNG
Even at the minimum possible intervention at a wide base, shadows get still distorted even at perimeter distances (red lines). Guess this is because fence runs close to the pit right close to its placing point. Even though I got pit as small as 150 by 50, I am still having too inclined "ramps", only about 30 degrees:
Dig2.PNG
This leads to... well, we already discussed that base coordinates should be moved away from the pit to some "neutral" place. Far from ideal (base coordinates are selected for a reason), but in my case will lead to moving hundreds of objects (each base has up to 5 partially repeating variations). Though this can be scripted, the next thing can't: as the dig gets under the centre of the pad, each object within it ends up either on pit or on a slope. Incidentally, this is the most built-up area, so the dig will affect elevation of way too many objects of the base. And those will have to be adjusted manually. In up to five configurations. Only for 2016 (looks like I still can't do a full switchover within at least another year).

So, to summarize: the trench-digging approach may already be a great option for new development. But still not quite suitable for converting existing intensely-populated bases. So, I'll probably exclude pitting from my current iteration of 2016 improvements, and delay a shot for a full switchover. This should still get me ~70% of what is needed for that - not bad at all. Thanks a lot for all your help, much appreciated!
 

Face

Addon Developer
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,138
Reaction score
65
Points
73
Location
Vienna
Nice to see you made progress at last.
As I wrote before, it would be possible to implement a "visual-only-flag" feature, where the D3D9Client renders some flattening (the trench) only visually, without doing the same for collision. This would on the one hand get rid of the additional tile problem AND on the other remove the element and shadow problem (because the the hole is only visual).
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,008
Reaction score
124
Points
88
Location
Lisbon
Website
orbiterspaceport.blogspot.com
...shadows get still distorted even at perimeter distances (red lines).
Have you tried the no shadows flag on the meshes ?

... that base coordinates should be moved away from the pit to some "neutral" place. Far from ideal ...
Please keep them at their correct placements. Otherwise things will never match (terrain, satellite imagery, open street map data ;) , etc)

Anyway, looking very very good! Your hard work is paying off!
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
192
Reaction score
30
Points
28
Website
www.pin-plus.ca
Have you tried the no shadows flag on the meshes ?
Those are true base objects, not meshes. I think I have this flag already for launchpad meshes (for 2010), and should probably keep them that way.
Please keep them at their correct placements. Otherwise things will never match (terrain, satellite imagery, open street map data ;) , etc)
No, the look and proper placement is not a concern here. "Moving" the base will mean moving the base coordinates to some flat place - but then moving all the objects on the base in the opposite direction to offset the coordinates move. So the visuals won't change. Totally out of reach if done manually, but scriptable, and doable (in principle). Much easier if done for any newly developed base, started from scratch. For existing bases - not for this development iteration, and who knows: maybe D3D9Client will support easier options by the time of next iteration.
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
192
Reaction score
30
Points
28
Website
www.pin-plus.ca
With elevation and tiles more or less covered, I'd like to return to my earlier, totally different question. Er haven't got to it yet, and it got lost in the past pages, so I am just quoting it here, rather than retyping the whole thing:

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