New Release D3D9Client Development

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
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
252
Reaction score
119
Points
43
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
252
Reaction score
119
Points
43
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
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
252
Reaction score
119
Points
43
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
I don't know much about tileedit, sorry.
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
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
252
Reaction score
119
Points
43
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
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,502
Reaction score
1,008
Points
153
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
252
Reaction score
119
Points
43
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
252
Reaction score
119
Points
43
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?
 

Donamy

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Oct 16, 2007
Messages
6,904
Reaction score
195
Points
138
Location
Cape
Could the ability of the view on generic camera include a way to rotate the view ? Reason being, some of the cameras on the station point down, and would be useful to be able to change the view, to right side up.
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Dumb question, but one I couldn't find by searching.

Are we still limited to 8 local lights?
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Dumb question, but one I couldn't find by searching.

Are we still limited to 8 local lights?
Yes and No. The number of local lights in a scenario is unlimited. Then each mesh picks 4 or 8 lights those are most relevant to it for rendering. So, each mesh can have it own set of local lights. (4 or 8 depends on settings used. "Partial" lights only compute diffuse part of the lighting and "Full" lights do specular part too)
 
  • Like
Reactions: GLS

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
Yes and No. The number of local lights in a scenario is unlimited. Then each mesh picks 4 or 8 lights those are most relevant to it for rendering. So, each mesh can have it own set of local lights. (4 or 8 depends on settings used. "Partial" lights only compute diffuse part of the lighting and "Full" lights do specular part too)
I don't know if that info is already in the D3D9 manual, but I think it would be a nice addition.
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Hmm. So making a light for every thruster wouldn't be possible, but two or four main engines would be okay?
 
Top