New Release D3D9Client Development

[martins]

Interesting - I stand corrected. Maybe this is because the values of the 3 textures are fairly similar. My suspicion for too dark a result was because the second algorithm will bring the result down to 0 if any single microtexture has a 0.

Btw, why did you have to add the "abs" in the equation? Can the individual pixel values be <0 ?

Edit: On balance, I would probably still vote for the 2/3(cFar + cMed + cLow) version, just because the result is a bit more predictable. If the contrast of the result is too low, that could probably be mitigated by increasing the contrast of the textures themselves. Looking at the histogram posted by rstr earlier, there seems to be a lot of room for contrast.

But obviously I'll leave that decision to you. I'd just suggest to try out both algorithms on a selection of microtextures, to make sure they work reliably. Does the second version have any performance impact?

 

[jarmonik]

Btw, why did you have to add the "abs" in the equation? Can the individual pixel values be <0 ?

Yes, I got CTD without it. Compiler doesn't allow to pass "possibly" negative values to pow since it's computed via exp(y*log(x))

---------- Post added at 02:25 ---------- Previous post was at 02:20 ----------

Edit: On balance, I would probably still vote for the 2/3(cFar + cMed + cLow) version, just because the result is a bit more predictable. If the contrast of the result is too low, that could probably be mitigated by increasing the contrast of the textures themselves. Looking at the histogram posted by rstr earlier, there seems to be a lot of room for contrast.

Yes, I agree with that. There's no color change of any kind when zooming in from the orbit. I'll make the switch to that equation.

Does the second version have any performance impact?

Nothing really, it may cost a frame of two when running at 300fps. The screen shots might actually show that.
EDIT: checked the screen shots from the harddrive and showed an increase of +1 fps.:lol:

 

[rstr]

Looking at the histogram posted by rstr earlier, there seems to be a lot of room for contrast.

Yup - a mistake on my side. After applying the highpass filter, I should have increased the contrast again manually, but I missed that step :facepalm:. Also, I need to experiment with the radius for the highpass. And one more thing I learned: a highpass filter automatically shifts the overall image brightness to 0.5.
Here's my next attempt (_A V1.3) with re-established contrast after highpass:
This is a screenshot with D3D9 Beta 19, not Beta 19B.

replacement D3D9Moon_A.dds V1.3 for download below; full uT download in post #3473 has also been updated accordingly.


I am getting a less fine picture with 19B ... still checking why - see for yourself:
19B: :shrug:

19: :yes:

Hence, I'm staying on Beta19 for the moment.

Regarding additive vs multiplicative blending: could it be that in multiplicative mode near-black details in one texture darken the underlying textures when they get mipmapped ? Just a wild guess by a noob ... so never mind if I'm not making sense here.

And an apology as well: the ground area brightness in my _A test cases looks also "dark" against the brightness of the Mt. Hadely slopes without microtextures ... I feel like a fool now having waisted your time. On the positive side, I think the discussions above have brought additional valuable insight for all participants.


---------- Post added at 03:21 AM ---------- Previous post was at 03:14 AM ----------

I'll add MicroTex.cfg to the upcoming version to address that problem. It will let you to specify pixels/meter resolution for each level A, B and C separately.

Jarmo, this will be of great benefit. As of now, for the _A-uT (uT=microtexture) the pixels/meter value to me seems too low by a factor of 2 to 4 as the fine rock structures are perceived as being too large in D3D9 Beta 19b (it seemed okay in Beta 19 - see screenshots above). Of course on the downside of making the _A tile smaller the impression of repetitiveness will be higher unless I enlarge the texture size for compensation ... but this would be doable by blending-in similar images or cloned sections of the current source. We'll see - whatever the perception is, a MicroTex.cfg adds a lot of flexibility. If implemented that way, this cfg should be bundled to the uTs. I leave the decision up to you whether you want to bundle the uTs to the D3D9Client, or keep them separate.
I'm aware that the uT V2.x attempt with the Povray-generated artificial normal maps is going to be the optimal solution as I can both make it as large in size and as crisp in detail as needed plus have the overall benefit of true normal maps like correct shadow casts as Marg has emphasized. Hence I hope we can freeze proceedings with the uT V1.x interim solution soon ... but even these results were a major step forward, and were worth every hour of effort we all (reviewers, idea givers, and especially Jarmo at most :tiphat have invested.
Cheers - Rob

 

[martins]

Thinking about this, the main problem of the additive blending is that a single texture can't force a real bright or dark pixel, because it gets only a third of the vote. Since after high-pass filtering the most likely pixel value is 0.5, the probability of all three textures agreeing on a very dark or very bright pixel is low.

One way to address this could be to stretch and clip the blending result, e.g.

cFnl = max(0, min(2, 4/3*(cFar+cMed+cLow)-1))

which gives a single channel more power to overrule the other two.

Another approach could be to emphasize the outliers, which might work well with the high-pass filtered textures:

hi = max(cFar, cMed, cLow);
lo = min(cFar, cMed, cLow);
cFnl = (hi-0.5 > 0.5-lo ? hi : lo)*2;

 

[jarmonik]

Here's a new build for testing. MicroTex.cfg has been added in Config folder and the configuration dialog has an option to enable/disable micro textures and normal maps. Texture filter options are also added. High anisotropy seems to cause heavy impact in performance.

Current implementation supports micro textures with and with-out normals. If normals are not used then all color channels will effect in resulting color. NORMALS parameter specifies which one of the supported types is used. All textures in a set must use equal format.

Currently all three textures must be specified. Although, it's possible to define 4x4 null texture with all channels set to 128 but it might be worth looking a better ways disable non-needed textures.

// BODY [<string> BodyName]
// NORMALS [<bool> 0-1]
// LEVEL [<int> 0-2] [<string> texture name] [<float> resolution pixels/meter]

BODY Moon
NORMALS 1
LEVEL 0 D3D9Moon_A.dds 20.0
LEVEL 1 D3D9Moon_B.dds 8.0
LEVEL 2 D3D9Moon_C.dds 2.0

BODY Mars
NORMALS 1
LEVEL 0 D3D9Moon_A.dds 20.0
LEVEL 1 D3D9Moon_B.dds 5.0
LEVEL 2 D3D9Moon_C.dds 1.0

 

[jarmonik]

Thinking about this, the main problem of the additive blending is that a single texture can't force a real bright or dark pixel, because it gets only a third of the vote.

That's mostly the reason why I ended up multiplying the textures. I didn't really realize darkening the results in a process.

Another approach could be to emphasize the outliers, which might work well with the high-pass filtered textures:

hi = max(cFar, cMed, cLow);
lo = min(cFar, cMed, cLow);
cFnl = (hi-0.5 > 0.5-lo ? hi : lo)*2;

That's an interesting idea. That should produce something different than anything we have tried before.

 

[SolarLiner]

That's an interesting idea. That should produce something different than anything we have tried before.

Tried it by changing the code in Surface.fx, but got weird results, like clearly defined changes in brightness, which I think comes the ternary condition.

 

[jarmonik]

Tried it by changing the code in Surface.fx, but got weird results, like clearly defined changes in brightness, which I think from from the ternary condition.

Yes, the results are somewhat unstable. Likely due to very different texture scales. Pixels from the high altitude textures will overthrow surface textures.

 

[SolarLiner]

Your implementation seems smoother than what I got, though. But I still prefer the 4/3 method.

 

[jarmonik]

A few shots from the latest experiments...

1st shot is without normals, 2nd shot is with normals, 3rd shot is taken at sunset. The sun lit sides of the rocks are a way too dim :facepalm:
EDIT: The normals are created with filtering and they are not exactly a good ones.

 

[jarmonik]

After making the normal blending a little more robust, the results likely improved.

float2 cMix = cFar.rg * cMed.rg * cLow.rg * 8.0f;

 

[Ripley]

Luna_A2.dds must go in textures folder right?

I get this view at Brigton Beach with D3D9 19b, and it does not look like jarmonik's screenshot at post #3499...

I keep on having strange results, but maybe (clearly) it's my fault. I have D3D9 19c and Orbiter beta rev. 50.
In order, here's what I did:
- Made sure I had both official LoRes and HiRes textures
- Installed latest rstr microtexture pack V1.3
- Updated surface.fx as per jarmo's post #3533
- Installed Luna_A2.dds


Moon looks gorgeous from the distance

Zooming in on Brighton Beach

Last screenshot before magic kicks in

Just few mousewheel clicks in, things get much darker

Down low. Distant features look lighter

Things look weird

 

[jarmonik]

Luna_A2.dds must go in textures folder right?

Yes, and then you need to edit MicroTex.cfg to assing Luna_A2 to the Moon

BODY Moon
NORMALS 1
LEVEL 0 Luna_A2.dds 20.0
LEVEL 1 D3D9Moon_B.dds 8.0
LEVEL 2 D3D9Moon_C.dds 2.0

Then you can either disable normals from the launchpad options. Or you can fill the red and green channels of D3D9Moon_B and D3D9Moon_C with 128.

 

[Ripley]

Thanks, now it looks better

But...did the random tile rotation got "lost in translation" somewhere?

 

[rstr]

edit MicroTex.cfg
BODY Moon
NORMALS 1
LEVEL 0 Luna_A2.dds 20.0
LEVEL 1 D3D9Moon_B.dds 8.0
LEVEL 2 D3D9Moon_C.dds 2.0

I'm getting by far unsatisfying results with the #3527 Beta19c plus #3533 surface.fx plus Microtex.cfg current settings compared to the previous Beta19 release.

Plz zoom in on the textured mountain slopes (Mt. Hadley).

This was Beta19 ... quite okay IMHO:
https://drive.google.com/open?id=0B_lJ8zRbeAbQajdQWkV4M29XeFE

And this is Beta19c - a horrible :uhh: sight - repetitive / striping / ... :
https://drive.google.com/open?id=0B_lJ8zRbeAbQU091azJTTF9yNGM

Plz advise. I'll try out some tuning on the microtex.cfg, but I'm not sure if its default settings explain the worsening.
Hope I don't sound blunt .. really no offense meant ... ... but we need to fix this, or change some defaults in the download set, so that we can get back the fine quality of the images your much appreciated great work had already achieved in Beta19 .. so apologies for asking for additional time ... it is worth it.

 

[Marg]

If in
LEVEL 2 D3D9Moon_C.dds 2.0
the last number 2.0 is changed to 1.0 repetitive striping decreases.

 

[rstr]

If in
LEVEL 2 D3D9Moon_C.dds 2.0
the last number 2.0 is changed to 1.0 repetitive striping decreases.

I come to radically different microtex.cfg settings in comparison to the defaults, to have at least a basically acceptable view while landed:
LEVEL 0 D3D9Moon_A.dds 250.0 or LEVEL 0 Luna_A2.dds 200.0
LEVEL 1 D3D9Moon_B.dds 0.25
LEVEL 2 D3D9Moon_C.dds 0.1

Looking down during a lift-off with Beta19c is a badly disappointing experience, compared to the wonderful view we had with the old Beta19.
See this MP4 video here: >>> lift-off sequence <<< with Beta19 - this is what we need to regain.

And just compare the two pictures downloadable from my above post #3537 ...

Don't get me wrong ... obviously I am fully in favor of the pixels/meter feature for the uTs, but something seems to have caused a significant worsening - IMHO, 19c is a no-no ... so just let's hope good ol' jarmonik finds some time to work on this .. the community will deeply appreciate what he's doing for us Orbinauts.
Rob

 

[jarmonik]

But...did the random tile rotation got "lost in translation" somewhere?

Yes, rotation is currently disabled. There was a problem with pixel normals. If the normals in a tile are biased 2deg toward south, for an example, and the tile below it is rotated 180 then it produces a pretty ugly edge. However, after passing the normals through high-pass filter and applying a small null range for the normals, they are working fine. So, we can use the rotations as Martin suggested.

---------- Post added at 21:28 ---------- Previous post was at 20:37 ----------

Looking down during a lift-off with Beta19c is a badly disappointing experience, compared to the wonderful view we had with the old Beta19 plug Marg's Surface.fx modification from #3459.
See this MP4 video here: >>> lift-off sequence <<< with Beta19+#3559mod - this is what we need to regain.

So, what's been changed between Beta19 and 19c:

1) The X-axis in a pixel normals was pointing in opposite direction that it should have. With some luck, that might have produced a nice view.

2) The texture blend equation has been changed from float3 cFnl = (cFar+0.5f) * (cMed+0.5f) * (cLow+0.5f) to float3 cFnl = max(0, min(2, 1.33333f*(cFar+cMed+cLow)-1)) this can be toggled from near the line 560 from Surface.fx

3) Texture levels (i.e. A, B, C) were toggled on/off based on camera distance. Now the on/off control is the mipmap level.

4) Texture level resolutions were hard-coded in Surface.fx now the resolution comes from MicroTex.cfg

So, is the problem:

1) Normal direction issue ? (Use time acceleration and observe surface behavior based on sun-light direction) (Beta 19c also has on/off toggle for normals in config dialog)
2) Texture blend problem ?
3) Texture level visibility problem ?
4) Texture scaling problem ?

 

[rstr]

So, is the problem:

1) Normal direction issue ? (Use time acceleration and observe surface behavior based on sun-light direction) (Beta 19c also has on/off toggle for normals in config dialog)
2) Texture blend problem ?
3) Texture level visibility problem ?
4) Texture scaling problem ?

In comparsion to the video link (>>>lift-off sequence with Beta19<<<) I designated as being "realistic" above,
here is the same sequence with Beta19c: >>>lift-off video with Beta19c + Luna_A2.dds / default microtex.cfg <<< which I feel is by far disappointing.

There's an issue with 4) texture scaling, see e.g. the mountain slopes, or the view downward during ascension ... this could be easily adapted, though in experimenting with the scale I had CTDs and VC++ faults popping up when nearing the before-mentioned radically changed microtex.cfg pixels/meter settings.
There's an issue with texture blending - when comparing the view downward in both videos, Beta19 view looks far more realistic in the gradual fade-out of the A to B to C levels.

Here's a re-run of the video with the above-mentioned radical pixels/meter setting changes in Beta19c. The view is better from looking around while landed now (mountain slopes), but even worse when looking down in the ascension stage, and the blending from A to B to C are not as gradual in transition, and also C fades out too early while the high altitude standard view is still blurry - so IMHO there is a also a correlation between pixels/meter settings, texture size, and the altitude where the textures kick-in resp. fade-out which we need to parameterize.
>>>lift-off video Beta19c with radical microtex.cfg settings<<<
BODY Moon
NORMALS 1
LEVEL 0 Luna_A2.dds 20.0
LEVEL 1 D3D9Moon_B.dds 0.25
LEVEL 2 D3D9Moon_C.dds 0.1

Btw: isn't there also a difference in the additive vs. multiplicative blending between Beta19 and Beta19c shader program ?

In a nutshell: Beta19 looked pretty realistic, Beta19c even with mods feels severely unrealistic.

Anyway - thanks for caring, jarmonik ... I am hesitative to ask you for investing even more time in a new client release resp. adaptations .. but I feel it is necessary.

 

[jarmonik]

Btw: isn't there also a difference in the additive vs. multiplicative blending between Beta19 and Beta19c shader program ?

Yes, there is a difference between additive and multiplicative blending and you can easily test them by using one of the following lines in Surface.fx while leaving rest of them commented out

//float3 cFnl = (cFar+0.5f) * (cMed+0.5f) * (cLow+0.5f);
//float3 cFnl = (cFar + cMed + cLow) * 0.6666f;
  float3 cFnl = max(0, min(2, 1.33333f*(cFar+cMed+cLow)-1));
//float3 cFnl = pow(abs(cFar*cMed*cLow), 0.33333f) * 2.0f;

Let's take one step at a time. If you observe the surface (while landed) during one full lunar day cycle, is it properly lit by sunlight ? In Beta19 and 19c ?

Edit: What _B and _C textures you are using ?