Orbiter-Forum [New Release] D3D9Client Development
 Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

 Orbiter Visualization Project Orbiter external graphics development.

 02-26-2016, 08:52 PM #3511 jedidia shoemaker without legs 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
 Thanked by:
 02-26-2016, 08:52 PM #3512 martins Orbiter Founder Quote: Originally Posted by rstr  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.
 02-26-2016, 09:44 PM #3513 jarmonik Beta Tester 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.
 02-26-2016, 10:02 PM #3514 martins Orbiter Founder Quote: Originally Posted by jarmonik  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?
 02-26-2016, 10:15 PM #3515 jarmonik Beta Tester Quote: Originally Posted by rstr  - 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  - 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(MicroCS, UVn*8.0f).rgb;            // High altitude micro texture C  float3 cMed = tex2D(MicroBS, UVn*64.0f).rgb;        // Medimum altitude micro texture B  float3 cLow = tex2D(MicroAS, UVr*512.0f).rgb;        // Low altitude micro texture A  ``` Quote: Originally Posted by rstr  - 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  - 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  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.
 Thanked by:
 02-26-2016, 10:52 PM #3516 martins Orbiter Founder Quote: Originally Posted by jarmonik  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)
 Thanked by:
 02-26-2016, 11:02 PM #3517 jarmonik Beta Tester 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(DiffTexS, frg.texUV.xy);     float4 cMsk = tex2D(MaskTexS, frg.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(vVrt, vPlN);            // Pixel Geo-distance     // Specular Water reflection     //     if (bSpecular) {         #if defined(_SURFACERIPPLES)             float Fct = min(2.0f, 10000.0f / fCameraAlt);             float3 cNrm = (tex2D(OceaTexS, frg.texUV.zw).xyz - 0.5f) * Fct;             cNrm.z = cos(cNrm.x * cNrm.y * 1.570796);              // Compute world space normal              nrmW = (vTangent * cNrm.r) + (vBiTangent * cNrm.g) + (vPlN * cNrm.b);         #endif         float f = 1.0-saturate(dot(camW, nrmW));         float s = dot(reflect(-vSunDir, nrmW), camW);         float m = (1.0 - cMsk.a) * saturate(0.5f-frg.aux[AUX_NIGHT]*2.0f);         cSpe = m * pow(saturate(s), 200.0f) * vWater.rgb * 2.0f;         float3 cSky = float3(1.2, 1.4, 3.5) * 0.7;         cTex.rgb = lerp(cTex.rgb, cSky, m * (f*f*f*f));     }     else {         if (bMicro) {             float dist = frg.aux[AUX_DIST];             float2 UV  = frg.texUV.xy;                      float3 cFar = tex2D(MicroCS, UV*8.0f).rgb;            // High altitude micro texture C             float3 cMed = tex2D(MicroBS, UV*64.0f).rgb;            // Medimum altitude micro texture B             float3 cLow = tex2D(MicroAS, UV*512.0f).rgb;        // Low altitude micro texture A                          float step1 = smoothstep(25000, 12000, dist);                          float3 cFnl = (cFar+0.5f) * (cMed+0.5f) * (cLow+0.5f);                          // Create normals             float3 cNrm  = float3((cFnl.xy - 1.0f) * 2.0f, 0) * step1;             cNrm.z = cos(cNrm.x * cNrm.y * 1.57);              // Approximate world space normal             //nrmW = normalize(-(vTangent * cNrm.x) + (vBiTangent * cNrm.y) + (nrmW * cNrm.z));                      // Apply luminance             cTex.rgb *= lerp(1.0f, cFnl.b, step1);         }     }     // Do we have an atmosphere ?     //     if (!bOnOff) { // No         float fDRP = dot(vPlN, vSunDir);         nrmW = lerp(nrmW, vPlN, pow(0.05, saturate(fDRP)));         float fDNS = dot(nrmW, vSunDir);         float fDNR = dot(nrmW, camW);         float fDRS = dot(camW, vSunDir);         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(fLvl, 0);            // Apply sunlight         return float4(pow(abs(color), fAux4), 1.0f);    // Gamma corrention     }     else { // Yes, atmosphere is present         if (bLights) frg.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  What do you think about this alternative instead? cFnl = 2/3 * (cFar + cMed + cLow) Ok, I'll run some test with it.
 02-26-2016, 11:21 PM #3518 martins Orbiter Founder Quote: Originally Posted by martins  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.
 Thanked by:
 02-26-2016, 11:36 PM #3519 jarmonik Beta Tester Quote: Originally Posted by martins  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
 02-26-2016, 11:39 PM #3520 jarmonik Beta Tester -double post forum making tricks- Last edited by jarmonik; 02-26-2016 at 11:41 PM.
 02-26-2016, 11:51 PM #3521 martins Orbiter Founder 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.
 Thanked by:
 02-27-2016, 12:00 AM #3522 jarmonik Beta Tester Quote: Originally Posted by martins  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   Last edited by jarmonik; 02-27-2016 at 12:05 AM.
 02-27-2016, 12:09 AM #3523 martins Orbiter Founder 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?
 Thanked by:
 02-27-2016, 12:25 AM #3524 jarmonik Beta Tester Quote: Originally Posted by martins  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  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  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.
 Thanked by:
02-27-2016, 02:21 AM   #3525
rstr
Donator

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

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
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
 D3D9Moon_A_Hipass+ReestablContrast.zip (1.98 MB, 17 views)

Last edited by rstr; 02-27-2016 at 01:16 PM.

 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 User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Orbiter-Forum.com     Announcements     Meets & Greets Orbiter Space Flight Simulator     Orbiter Web Forum         OFMM         Orbiter Forum Space Station         Simpit Forum     General Questions & Help     MFD Questions & Help     Hardware & Software Help     Tutorials & Challenges     Orbiter SDK     Orbiter Visualization Project     Orbiter Beta » Orbiter Project Orbiter Addons     OrbitHangar Addons & Comments     Addons     Addon Development     Addon Requests     Addon Support & Bugs         Addon Developer Forums             Project Apollo - NASSP     Orbiter Lua Scripting Far Side of the Moon     Spaceflight News     Math & Physics     Astronomy & the Night Sky     Backyard Rocketry     Brighton Lounge     International Forum

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