• Guest Please check out the Help Wanted thread in Ickie's NewsHawks.
    The future of the Outhouse depends on you!
    Help Wanted

This Could Be Very Interesting - AnKor's Shaders

OK, that sounds too cool. Is that mapping texture somehow enabled by the shader mod just through association with the parent t.dds, or is there some hacking into an M3D involved? Does the mapping texture function like an s.dds/r.dds in that the brighter it is the greater the effect? Also, is the alpha texture issue being addressed on some level?
 
OK, that sounds too cool. Is that mapping texture somehow enabled by the shader mod just through association with the parent t.dds, or is there some hacking into an M3D involved? Does the mapping texture function like an s.dds/r.dds in that the brighter it is the greater the effect? Also, is the alpha texture issue being addressed on some level?
Normal map textures (as well as self illumination ones) are loaded by my shaders automatically if their name matches the main texture (with a suffix like +nm) - no changes in M3D are needed.
These textures use special format - first you create a grayscale map with bumps in brighter color and dents in darker and then convert it to normal map and save in one of suitable dds formats.
Perhaps gecko can explain it better :)

By the way, what is the alpha texture issue I keep reading about?Maybe it is something I can fix, but I don't know what the problem is.

Ankor, your laptop must be smokin' hot
Well, I don't really play on laptop, I just use it for programming :)
It has built-in Intel HD GPU (don't remember which one) which is too slow to enjoy all visual effects, but just enough to test all features.
 
AnKor,

There has been an occasional issue for a long time now that if the shadow layer dds was saved with an alpha layer it would turn the aircraft black or grey depending on the shade of the alpha. Once I figured out the cause it was easy enough to fix for the few files that had it so I didn't bring it up.
 
I figured out the bump map process. However, it is overriding the r.dds texture and presenting the aircraft with an s.dds effect and no reflection. Is this something that should be for non-r.dds models only? I also have what appears to be a scale issue as the wing parts are displayed on the fuselage. Using the Nvidia plug-in for Photoshop. Any suggestions?

In regards to the alpha texture issue: I have alpha'd out a certain part of a t.dds texture so that it does not appear in sim. With the shader mod active the part shows up black or casts a shadow on the aircraft. Without the shader mod it is invisible as intended. Also, I have custom loadouts that display a ground texture (with the use of an alpha) upon impact and those flash/flicker like crazy. It is entirely possible that I may have done something wrong but this problem has been consistent.

Side Note: These new shaders are outta sight! I saw my first squall w/rain effect! I mean it looked real, complete with water reflection! Even the tracers cast light on aircraft!:jump:
 
Just for a quick test and for a point of reference I used the panel line layer for the nm.dds. Looks promising once I have more practice but obviously I have a scale issue. The accompanying r.dds also doesn't seem to be used when the nm.dds is used.

On the B-25J, the nose guns and turret have been alpha'd out in the textures but their model shadows remain.
 
Just for a quick test and for a point of reference I used the panel line layer for the nm.dds. Looks promising once I have more practice but obviously I have a scale issue. The accompanying r.dds also doesn't seem to be used when the nm.dds is used.

I believe if you make it the same size as the _t.dds file it will map correctly. (I just tried it at 2048 x 2048)
 
A useful explanation from AnKor.

I've been trying to get a surface with high specular and low reflective values, and I can't seem to figure out how. I can't seem to manipulate them separately anymore. What do I need to do to make it work?
Specular – strength of environment reflections (I suspect in GMAX it is set as Specular Color * Specular Level).
Glossiness – sharpness of sun and environment reflections.
To make existing models look better if Specular > Glossiness then glossiness is increased to match specular to avoid having very strong but blurred reflections (real material don’t usually work this way).

However, it still works vice versa - to get materials with sharp sun highlights, but not reflecting the environment you should set high glossiness, but low specular.

If you are doing HEX editing of existing m3d files, I have a correction for the info “Projected Knowledge Base” thread on SOH.
Here what it says now:
- ff ff ff ff specular factor (RGB components plus intensity)
- 00 00 00 43 glossiness, usually goes from 00 00 00 40 to 00 00 00 44

I doubt the last FF in specular has any use, but more importantly my shaders actually ignore the tint of specular and just average its RGB components to get single specular value.
So FF FF FF FF is the highest specular value (= 255) and thus the strongest environment reflection.
While 00 00 00 FF is the lowest specular value and minimum env reflection (my code will add a bit of reflectivity anyway).
Does it work for you?
If not I will need to check my code – I never actually tried high gloss/low specular combination so maybe it doesn’t work as expected. Just note that our eyes will always see sharp detailed reflection as stronger than a blurred one.

Glossiness is more complex.
That 00 00 00 43 is actually floating point number 128.0 which is high glossiness (my code also multiplies it x1.5 by default).
Note that in this example a special rule I mentioned above will kick in and the glossiness will become = 255 to match specular.
Now, to convert between floating point number and hex bytes you can use this simple site: http://gregstoll.dyndns.org/~gregstoll/floattohex/
The only inconvenience is that you need to reverse the order of bytes, while keeping the order inside pairs.
Simply speaking 00 00 00 43 becomes 43000000, and 12 34 56 78 becomes 78563412 – you also have to remove whitespace.

Some simple values that mentioned in the thread are:
00 00 00 40 = 2.0 – very low, basically absolutely dull surface – my shaders will almost certainly override it to make shinier.
00 00 00 41 = 8.0 – rough surface
00 00 00 42 = 32.0 – normal shine
00 00 00 43 = 128.0 – highly shiny
00 00 00 44 = 512.0 – very shiny, this will be reduced by my shaders which don’t allow glossiness above 250 (it doesn’t make much sense for normal materials)
For convenience 64.0 will look like 00 00 80 42 in hex, and 16 will be 00 00 80 41.

Finally, my shaders use _s textures (standard or DX9 specific +sr) to adjust glossiness instead of specular. This is more correct approach used in most modern rendering engines.
 
What role do stock CFS3 _r.dds textures play now? Are they treated the same as _s.dds textures?

If object uses “_r” texture my code uses special rendering settings to simulate metallic surface:

  • Base glossiness is increased by +200. In stock renderer the reflection was always sharp, but in this new one it will look blurred for low glossiness material.
  • First of all, the texture works exactly as “_s” in a sense that it adjusts glossiness - 200% for white, 0% for black pixels.
  • Additionally the texture affects initial reflectivity – white pixels mean that reflectivity is at maximum at any viewing angle (like a mirror), for black pixels the reflectivity relies on Fresnel effect with 0 reflectivity when looking at 90 degrees.
  • There is also some tint applied to specular reflections (both env and sun) – that’s generally how metals behave: gold has yellow tinted reflections, etc. It is implemented in a simplistic way by tinting reflections with main texture color. The amount of tint also depends on “_r” texture (none for black pixels, and the most for white).

WOFF doesn’t use “_r” textures – so if you need any changes (for example that +200 glossiness hack is undesirable) I can change the way metallic reflectivity works. After all it will give more control – like having unpolished metal which still has metallic properties (high reflectivity at 90* and tinting) but blurry reflections.
This +200 boost is hardcoded in dll for performance, but you can adjust Models.fx to see the original look.
Find this part (line 538 and below) and add the line marked in yellow:
/////// Specular map ///////
float specMap;
if(bSpecularMap)
{
if(bExtTexture)
{
specMap = dot(extMap * vSpecMask, 1);
}
else
{
specMap = tex2D(Tex1, In.TexCoord.xy).r;
if(bReflective) Material.fPower -= 200;
}
specMap *= 2;
}
 
Thanx Major. I've added those to my notes and they will come in handy.

The r.dds alone is OK. It is when the +nm.dds is used in conjunction with the t.dds/r.dds (all .dds textures involved are in 2048) that the problem occurs. I'm using the Nvidia plug-in for Photoshop and I'm assuming that is where the scaling problem is. If anyone is successfully using this plug-in, I would be interested in their filter settings.
 
I will check if _r and +nm work together properly. I believe they are supposed to work, but maybe there's a bug as I don't remember if I ever tested it.
 
Hmmm...

I recall abandoning the nvidia plugin whilst doing textures in photoshop as it seemed to foul things when saving.
...also saving required extra care as too many saves degraded the final product(?) Of course that wuz awhile back
w/ version 6 and/or 6.1... Just me two cents worth :mixed-smiley-010:
 
I recently noticed an airplane that was overly shiny and seemed immune to the hex editing that I normally use to tone this down. After a good deal of trial and error I rediscovered that AnKor has built in a fix for aircraft that do no have a *_s.dds or *_r.dds file included in the m3d texture references. Adding a 33% gray *_t.+sr.dds file to the texture folder worked to correct the problem.

I just ran into a model (F6 Mustang from Korea) that the *_t.+sr.dds didn't seem to work with. In trying different things with editing the m3d to get it to work I found that the drawing type needed to be 00 00 FF 00 versus the more typical 00 00 00 00. Normally the m3d only has this factor set to 00 00 FF 00 if it already references a _r or _s file. This limits the utility of using *_t.+sr.dds to add reflective textures because you may still need to edit the m3d file.
 
Adding a 33% gray *_t.+sr.dds file to the texture folder worked to correct the problem.

Major, can you give a brief explanation on how this +sr.dds is created. I have tried this on several different aircraft without success. I'm begining to think maybe my rig/driver is fouled up.
 
I would start with the *_t.dds, make a copy, rename it, and then repaint it.

The repainting is typically done in shades of grey, but leave it in the rgb file format (not greyscale). Black areas will have no environmental reflectance, and white areas would look like a perfect mirror. You’ll need to experiment a bit based on how a particular m3d might be set up, but generally you want most surfaces to be fairly dark, as too much reflectance looks unnatural on military aircraft. You don’t have to be too fussy about the fine details of the original texture as small errors will not be noticed, but areas like anti-glare panels, and insignia on polished metal backgrounds should have pretty sharply defined black / grey edges.

The pattern of light and dark reflectance information is applied to the same areas that the *_t.dds textures is mapped to like the _s or _r would be. These should be in the DXT1, no alpha layer format.

The new discovery this morning with the F6 Mustang was that the m3d file still needs to contain the right drawing mode hex information or the *_t.+sr.dds file will be ignored.

This is still a useful capability since a relatively simple edit of an m3d file that does not have any *_r.dds reference listed can still be made to read the reflectance data. Be careful to make a copy of your original files because if you turn AnKor's shaders off after you make this edit the plane will turn into an all over perfect mirror like the silver surfer.
 
So, it functions like a normal r.dds then? That's what I assumed but did not have any success. I reviewed my GPU settings just in case and then . . .

I stepped into an even bigger pile when I updated my GPU driver (Nvidia GTX 750Ti with the 365.19 update). Rising Sun wanted to reconfigure the graphics before starting and once in, I set all sliders to max. I now have no water, less than detailed ground textures and a big horizontal band that overlays the horizon across everything. I've reconfigured the overrides twice, deleted the uisel/unlimitedpilots/view xml's, removed and replaced the current Ankor Shaders.

This is over Haliewa facing the ocean. Shorelines appear but no water.

I grow weary of this never ending fixing.:monkey:
 
So, it functions like a normal r.dds then? That's what I assumed but did not have any success. I reviewed my GPU settings just in case and then . . .

I stepped into an even bigger pile when I updated my GPU driver (Nvidia GTX 750Ti with the 365.19 update). Rising Sun wanted to reconfigure the graphics before starting and once in, I set all sliders to max. I now have no water, less than detailed ground textures and a big horizontal band that overlays the horizon across everything. I've reconfigured the overrides twice, deleted the uisel/unlimitedpilots/view xml's, removed and replaced the current Ankor Shaders.

This is over Haliewa facing the ocean. Shorelines appear but no water.

I grow weary of this never ending fixing.:monkey:
Hi Foofighter,
check that dual pass render is turned off in your configoverrides file, it has a sneaky habit of turning itself on. That should get rid of horizon effects.
 
...and its another nice mess we've gotten yourself into :engel016:

If you're able to make the repairs w/o reinstalling, please post your magic...
...oh and best of luck!

(...reminds of the way things look when the actors have left the theater!)
 
Back
Top