Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Visualization Project Orbiter external graphics development.

Reply
 
Thread Tools
Old 02-26-2016, 08:52 PM   #3511
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
at least it makes folks like jededia happy
Hey, don't load any extra work on your shoulders because of me. I happen to be a very patient man
jedidia is offline   Reply With Quote
Thanked by:
Old 02-26-2016, 08:52 PM   #3512
martins
Orbiter Founder
Default

Quote:
Originally Posted by rstr View Post
 No, it indeed doesn't sound right. I thought at first I've done a buzz job, but ...
- mean value is close to 0.5:
Okay, then, assuming that the surface patch in the image isn't actually that dark (you did compare the intensity with an image of the same scene without microtextures, right?), this would indicate that the blending operation was not RGB1*RGB2*2. We'll have to pass this on to Jarmo to clarify.
martins is offline   Reply With Quote
Old 02-26-2016, 09:44 PM   #3513
jarmonik
Beta Tester

Default

The blend equations is simply:

float3 cFnl = (cFar+0.5f) * (cMed+0.5f) * (cLow+0.5f);

So, the albedo from each texture is offset upwards by 0.5f resulting that each texture will range from 0.5f to 1.5f and then the results are multiplied.

If all channels of every texture is filled with 128 then the equation will become

1 * 1 * 1 = 1

Meaning that no change will occur to the color from a tile textures.

I noticed that some of the lowest mipmaps in _A texture were shifted about 7-10% towards dark. Fixing that cured the problem here. I'll take a look if we can do color balance corrections on a client side.
jarmonik is offline   Reply With Quote
Old 02-26-2016, 10:02 PM   #3514
martins
Orbiter Founder
Default

Quote:
Originally Posted by jarmonik View Post
 The blend equations is simply:

float3 cFnl = (cFar+0.5f) * (cMed+0.5f) * (cLow+0.5f);

So, the albedo from each texture is offset upwards by 0.5f resulting that each texture will range from 0.5f to 1.5f and then the results are multiplied.

If all channels of every texture is filled with 128 then the equation will become

1 * 1 * 1 = 1

Meaning that no change will occur to the color from a tile textures.

I noticed that some of the lowest mipmaps in _A texture were shifted about 7-10% towards dark. Fixing that cured the problem here. I'll take a look if we can do color balance corrections on a client side.
I must admit that I didn't follow the preceding microtexture discussion in enough detail, so I'm not entirely sure how to interpret the equation.

Do cFar, cMed and cLow refer to three levels of microtexture, or does one of these refer to the global surface texture?

If it's the first, then I am missing a step: how is the result of blending the microtextures together (cFnl) blended with the global texture?

If it's the second (let's say cLow refers to the global texture), shouldn't it be

float3 cFnl = (cFar+0.5f) * (cMed+0.5f) * cLow;

so that if both cFar and cMed are at 0.5, the global albedo (cLow) is maintained?
martins is offline   Reply With Quote
Old 02-26-2016, 10:15 PM   #3515
jarmonik
Beta Tester

Default

Quote:
Originally Posted by rstr View Post
 - I.e.: is (A) the tile size fixed, and an increased texture size just adds more crisp details to the tile, or does (B) the shader automatically increase the tile area size with a bigger texture size ?
A) Yes, right now it makes more crisp detail. B) No.

Quote:
Originally Posted by rstr View Post
 - If it is case(A), then: where is the tile size defined, and are there different sizes for _A, _B, and _C levels ?
These three lines in Surface.fx
PHP Code:
float3 cFar tex2D(MicroCSUVn*8.0f).rgb;            // High altitude micro texture C 
float3 cMed tex2D(MicroBSUVn*64.0f).rgb;        // Medimum altitude micro texture B 
float3 cLow tex2D(MicroASUVr*512.0f).rgb;        // Low altitude micro texture A 
Quote:
Originally Posted by rstr View Post
 - Are there currently fixed limits to the texture size, e.g. 2048x2048, or would 4096x4096 work as well without further modifications ?
No limits other than user hardware 16kx16k in my case. However, pushing resolution higher doesn't guarantee any better results. Random pattern of multiple smaller different textures might give better results that one big texture. I should run some test to see if it's applicable.

Quote:
Originally Posted by rstr View Post
 - And how does the tile size map to the rendered area (physical dimensions) ?
Depends about installed tile textures, tile latitude and possibly some other settings.

Important:
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. After that tile resolution is constant regardless installed tile textures, latitude and other settings. NOTE: that, this will also reverse the answer to the first question you made. With a specified pixels/meter setting increase in texture size will increase a surface area coverage. If all goes well should be ready in next 6h.

---------- Post added at 00:15 ---------- Previous post was at 00:04 ----------

Quote:
Originally Posted by martins View Post
 Do cFar, cMed and cLow refer to three levels of microtexture, or does one of these refer to the global surface texture?
It refers to three different levels of micro textures. The final step is:

// Apply luminance
cTex.rgb *= lerp(1.0f, cFnl.b, step1);

where "step1" is a sort of smooth on/off switch. So, depending the value of "step1" the eqation becomes.

cTex.rgb *= 1.0f or
cTex.rgb *= cFnl.b;

Luminance is stored in blue channel and per-pixel normal vector is stored in red and green channels. Normals are currently disabled.

Of course, the blend equation:
float3 cFnl = (cFar+0.5f) * (cMed+0.5f) * (cLow+0.5f);

is not ideal to process normals but works well enough.
jarmonik is offline   Reply With Quote
Thanked by:
Old 02-26-2016, 10:52 PM   #3516
martins
Orbiter Founder
Default

Quote:
Originally Posted by jarmonik View Post
 It refers to three different levels of micro textures. The final step is:

// Apply luminance
cTex.rgb *= lerp(1.0f, cFnl.b, step1);

where "step1" is a sort of smooth on/off switch. So, depending the value of "step1" the eqation becomes.

cTex.rgb *= 1.0f or
cTex.rgb *= cFnl.b;
That sounds ok to me. It certainly should maintain the global albedo if all three microtexture levels are at 0.5. So, rstr, are you really sure that the result of your 0.5-mean texture is too dark?

In fact, the one thing I am concerned about with the current blending equation is a possible bias towards high intensity:

Let's say you have two pixels next to each other, both of which have a value of 0.5 in all three microtextures. The mean result across both pixels is of course

cFnl = 1

Now assume that one pixel has a value of 0 in all microtextures, the other has a value of 1 in all microtextures. One would hope that their mean cFnl value is still 1, but it actually turns out as

cFnl = (0.5^3 + 1.5^3)/2 = 1.75

So a mean texture intensity of 0.5 will not guarantee an albedo-neutral microtexture blending.

What do you think about this alternative instead?

cFnl = 2/3 * (cFar + cMed + cLow)
martins is offline   Reply With Quote
Thanked by:
Old 02-26-2016, 11:02 PM   #3517
jarmonik
Beta Tester

Default

The lunar surface shading is a bit problematic. I have tried to apply Lommel-Seeliger style shading but I am not really sure if it works as it should. It looks good from a distance but when viewing Brighton-beach from a close range the surface illuminance depends heavily from a camera angle. Top-down view gives a darker surface and shallow camera angle brighter view. One possibility is to switch towards lambertian style shading at lower altitudes but then again the surface would become darker.

Of course, these issues are not related to the reported texture issue.

Here's the full code surface shader:
PHP Code:
float4 SurfaceTechPS(TileVS frg) : COLOR
{
    
float3 cNgt 0;
    
float3 cSpe 0;
    
float4 cTex tex2D(DiffTexSfrg.texUV.xy);
    
float4 cMsk tex2D(MaskTexSfrg.texUV.xy);

    
float3 nrmW frg.nrmW;                    // Per-vertex surface normal vector
    
float3 nvrW frg.nrmW;                    // Per-vertex surface normal vector
    
float3 camW normalize(frg.camW);        // Unit viewing ray
    
float3 vVrt vCameraPos frg.camW;    // Geo-centric vertex position
    
float3 vPlN normalize(vVrt);            // Planet mean normal    
    
float  fRad dot(vVrtvPlN);            // Pixel Geo-distance

    // Specular Water reflection
    //
    
if (bSpecular) {

        
#if defined(_SURFACERIPPLES)
            
float Fct min(2.0f10000.0f fCameraAlt);
            
float3 cNrm = (tex2D(OceaTexSfrg.texUV.zw).xyz 0.5f) * Fct;
            
cNrm.cos(cNrm.cNrm.1.570796); 
            
// Compute world space normal 
            
nrmW = (vTangent cNrm.r) + (vBiTangent cNrm.g) + (vPlN cNrm.b);
        
#endif

        
float f 1.0-saturate(dot(camWnrmW));
        
float s dot(reflect(-vSunDirnrmW), camW);
        
float m = (1.0 cMsk.a) * saturate(0.5f-frg.aux[AUX_NIGHT]*2.0f);

        
cSpe pow(saturate(s), 200.0f) * vWater.rgb 2.0f;

        
float3 cSky float3(1.21.43.5) * 0.7;
        
cTex.rgb lerp(cTex.rgbcSky* (f*f*f*f));
    }

    else {

        if (
bMicro) {

            
float dist frg.aux[AUX_DIST];

            
float2 UV  frg.texUV.xy;
        
            
float3 cFar tex2D(MicroCSUV*8.0f).rgb;            // High altitude micro texture C
            
float3 cMed tex2D(MicroBSUV*64.0f).rgb;            // Medimum altitude micro texture B
            
float3 cLow tex2D(MicroASUV*512.0f).rgb;        // Low altitude micro texture A
            
            
float step1 smoothstep(2500012000dist);
            
            
float3 cFnl = (cFar+0.5f) * (cMed+0.5f) * (cLow+0.5f);
            
            
// Create normals
            
float3 cNrm  float3((cFnl.xy 1.0f) * 2.0f0) * step1;
            
cNrm.cos(cNrm.cNrm.1.57); 

            
// Approximate world space normal
            //nrmW = normalize(-(vTangent * cNrm.x) + (vBiTangent * cNrm.y) + (nrmW * cNrm.z));
        
            // Apply luminance
            
cTex.rgb *= lerp(1.0fcFnl.bstep1);
        }
    }

    
// Do we have an atmosphere ?
    //
    
if (!bOnOff) { // No

        
float fDRP dot(vPlNvSunDir);

        
nrmW lerp(nrmWvPlNpow(0.05saturate(fDRP)));

        
float fDNS dot(nrmWvSunDir);
        
float fDNR dot(nrmWcamW);
        
float fDRS dot(camWvSunDir);

        
float fX saturate(fDNS);                        // Lambertian
        
float fY 0.05 saturate(fDNR)*0.4;            // Lommel-Seeliger compensation
        
float fZ pow(abs(fDRS),10.0f) * 0.3f;            // Shadow compensation
        
float fLvl fX * (fZ+rcp(fX+fY)) * fExposure;    // Bake all together

        
float3 color cTex.rgb max(fLvl0);            // Apply sunlight

        
return float4(pow(abs(color), fAux4), 1.0f);    // Gamma corrention
    
}

    else { 
// Yes, atmosphere is present

        
if (bLightsfrg.atten.rgb += 3.0f cMsk.rgb * (saturate(frg.aux[AUX_NIGHT]) * fNight);
        
float3 color cTex.rgb frg.atten.rgb cSpe frg.insca.rgb cNgt;
        
color = (1.0f exp2(-color*fExposure)) * vWhiteBalance;  
        return 
float4(pow(abs(color), fAux4), 1.0f);  
    }



---------- Post added at 01:02 ---------- Previous post was at 00:58 ----------

Quote:
Originally Posted by martins View Post
 What do you think about this alternative instead?
cFnl = 2/3 * (cFar + cMed + cLow)
Ok, I'll run some test with it.
jarmonik is offline   Reply With Quote
Old 02-26-2016, 11:21 PM   #3518
martins
Orbiter Founder
Default

Quote:
Originally Posted by martins View Post
 What do you think about this alternative instead?

cFnl = 2/3 * (cFar + cMed + cLow)
I suspect that this additive blending equation might result in low contrast of the microtexture features. A multiplicative blender could create higher contrast:

cFnl = 2 * (cFar*cMed*cLow)^1/3

but I guess that might be too computationally expensive.
martins is offline   Reply With Quote
Thanked by:
Old 02-26-2016, 11:36 PM   #3519
jarmonik
Beta Tester

Default

Quote:
Originally Posted by martins View Post
 What do you think about this alternative instead?

cFnl = 2/3 * (cFar + cMed + cLow)
Ok, here are some test results. Like you said below the contrast is reduced a bit but it's also a little brighter.

Darker stripes are from the original blend equation and lighter stripes are from the one in quote.

I'll make an other test run for this: cFnl = 2 * (cFar*cMed*cLow)^1/3

BTW, just noticed that base shadows go randomly on and off.
Attached Thumbnails
results.jpg  
jarmonik is offline   Reply With Quote
Old 02-26-2016, 11:39 PM   #3520
jarmonik
Beta Tester

Default

-double post forum making tricks-

Last edited by jarmonik; 02-26-2016 at 11:41 PM.
jarmonik is offline   Reply With Quote
Old 02-26-2016, 11:51 PM   #3521
martins
Orbiter Founder
Default

The reason the new version is brighter might be because the old algorithm actually biased towards lower intensities when averaging over the 3 microtextures:

cFar = cMed = cLow = 0.5 => cFnl = 1

but

cFar = 0, cMed = 0.5, cLow = 1 => cFnl = 0.75

Actually, this probably means that my second suggestion will turn out much too dark.
martins is offline   Reply With Quote
Thanked by:
Old 02-27-2016, 12:00 AM   #3522
jarmonik
Beta Tester

Default

Quote:
Originally Posted by martins View Post
 Actually, this probably means that my second suggestion will turn out much too dark.
Actually, No. Did I make mistake somewhere ??

Had to make some change to get it compile: float3 cFnl = pow(abs(cFar*cMed*cLow), 0.33333f) * 2.0f;

Original is the darker one.

EDIT: I would say that contrast is a little better in this one than cFnl = 2/3 * (cFar + cMed + cLow)
Attached Thumbnails
results2.jpg  

Last edited by jarmonik; 02-27-2016 at 12:05 AM.
jarmonik is offline   Reply With Quote
Old 02-27-2016, 12:09 AM   #3523
martins
Orbiter Founder
Default

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?
martins is offline   Reply With Quote
Thanked by:
Old 02-27-2016, 12:25 AM   #3524
jarmonik
Beta Tester

Default

Quote:
Originally Posted by martins View Post
 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 ----------

Quote:
Originally Posted by martins View Post
 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.

Quote:
Originally Posted by martins View Post
 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.

Last edited by jarmonik; 02-27-2016 at 12:30 AM.
jarmonik is offline   Reply With Quote
Thanked by:
Old 02-27-2016, 02:21 AM   #3525
rstr
Donator
 
rstr's Avatar
Default

Quote:
Originally Posted by martins View Post
 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 . 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:


19:


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

Quote:
Originally Posted by jarmonik View Post
 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 ) have invested.
Cheers - Rob
Attached Files
File Type: zip D3D9Moon_A_Hipass+ReestablContrast.zip (1.98 MB, 17 views)

Last edited by rstr; 02-27-2016 at 01:16 PM.
rstr is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project

Tags
d3d9client, graphicsclient


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 04:51 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.