AnKor's Shaders

[greycap.raf]

Where is this file available?

New Meshbuilder Budget.zip

This is an update of my previous offerings for a meshbuilderbudgets.xml file to be added to the Assets folder. This one requires a reasonably high end computer setup. Its origins in conception come from Charles Simpson's Meshbuilderbudgets_OUCH...

sim-outhouse.org

Having said that, I haven't checked yet if the new one in the package has the same benefits already.

 

[MajorMagee]

What if the issue is not the part that defines the color of the material, but the color of one of the reflective properties. F3 04 35 41 on line 640 and 66 DC 5E 41 on line 660. I always make these grayscale even when I'm using colored transparent materials. I'm not currently able to test, but maybe this accounts for the difference. I did a huge amount of testing with the weather, viewing things at all different angles over a two year development period. I'm sure I would have noticed if the color of the rain changed when flying my numerous aircraft with colored glass material.

I have an F-117 with gold tinted transparencies (00 9C BF 24) that makes the rain gold (kinda pretty actually). Variations in glossiness down to 00 00 00 00 had no effect. I tried adding colors to the ambient color and specular factor sections as well with no effect. Any changes in the diffuse color when transparency is turned on immediately changes the color of the rain (e.g. from gold to purple rain FF 9C BF 24). This particular install has 143 aircraft, and only three of them had this effect on the rain. The effect was different for each one, and was resolved with an edit of the diffuse color transparency. When I checked, the other 140 aircraft already had neutral shaded diffuse color transparencies.

Again, I almost missed that the F-117 had the issue because you only see it when looking from the port and starboard rear quarters. Rotate the view around a few degrees and the rain goes back to grey.

 

[mongoose]

Afraid that answer is beyond my limited knowledge, but I would hazard an educated guess that it's the fires on the ground in London in the early TOW He 111 mission I've been using for testing (as in the screen shots). Similarly, the effect in ETO, while not of the same order, was a function of the incendiaries I dropped. Thanks for looking into this.

I have had that issue b4 the new shaders, but have yet to try any mission with the new ones; I suppose that I better get to it! In any case I want to see hoe all Dan's Target Indicators react, more relevant to TOW II, but otherwise bombs and facilities representing fire and smoke would be the same.

 

[gecko]

Afraid that answer is beyond my limited knowledge, but I would hazard an educated guess that it's the fires on the ground in London in the early TOW He 111 mission I've been using for testing (as in the screen shots). Similarly, the effect in ETO, while not of the same order, was a function of the incendiaries I dropped. Thanks for looking into this.

Ok, if they are lighting effects, there is a limit to how many of these can be present at once. Beyond that, weird things can happen. CFS3 had this limitation originally I believe, but it was a little haphazard. IIRC Andrey tried to bring some order to the haphazard way CFS3 would cut out some of the lighting, and prioritized the lighting effects closest to the player. This has been the case since the 2019 release at least, if not before. The limit is 8 or 16 I think. I expect that it is likely that there are too many lighting effects in this scene by a wide margin, leading to some unexpected results. Alternate means of creating ground lighting should probably be explored, as these will not be subject to this limitation and will probably also be more framerate friendly.

New Meshbuilder Budget.zip

This is an update of my previous offerings for a meshbuilderbudgets.xml file to be added to the Assets folder. This one requires a reasonably high end computer setup. Its origins in conception come from Charles Simpson's Meshbuilderbudgets_OUCH...

sim-outhouse.org

Having said that, I haven't checked yet if the new one in the package has the same benefits already.

I quick look at the file (I'm on the road for a long time and can't test in game) shows a significantly different structure for the distance rings. If it doesn't define the budgets to a wide enough radius, I think that must be the issue, odd though it is.

I have an F-117 with gold tinted transparencies (00 9C BF 24) that makes the rain gold (kinda pretty actually). Variations in glossiness down to 00 00 00 00 had no effect. I tried adding colors to the ambient color and specular factor sections as well with no effect. Any changes in the diffuse color when transparency is turned on immediately changes the color of the rain (e.g. from gold to purple rain FF 9C BF 24). This particular install has 143 aircraft, and only three of them had this effect on the rain. The effect was different for each one, and was resolved with an edit of the diffuse color transparency. When I checked, the other 140 aircraft already had neutral shaded diffuse color transparencies.

Again, I almost missed that the F-117 had the issue because you only see it when looking from the port and starboard rear quarters. Rotate the view around a few degrees and the rain goes back to grey.

Can you test with the SJ Spitfire Mk.V? The clipped wing variants in particular have large transparent colored glass for the wingtip lights. I did 99% of the shaders testing in these aircraft and did not encounter it beyond what was related to the harbor model. This is both before and after discovering the issue originally and finding a solution, so I was specifically looking for it to crop up. I'd be curious if you encounter the issue on that aircraft as well. If not, we might be able to find a difference between models that do cause the issue and those that do not.

I have had that issue b4 the new shaders, but have yet to try any mission with the new ones; I suppose that I better get to it! In any case I want to see hoe all Dan's Target Indicators react, more relevant to TOW II, but otherwise bombs and facilities representing fire and smoke would be the same.

It's been so long, I don't recall if those TIs I did use a lighting effect (as opposed to a glowing ground decal). If they did, they might suffer from the issue explained above if used in large quantities or alongside other lighting effects. There should be nothing new in this round of shaders that should affect them.

 

[mongoose]

Quote:
Ok, if they are lighting effects, there is a limit to how many of these can be present at once. Beyond that, weird things can happen. CFS3 had this limitation originally I believe, but it was a little haphazard. IIRC Andrey tried to bring some order to the haphazard way CFS3 would cut out some of the lighting, and prioritized the lighting effects closest to the player. This has been the case since the 2019 release at least, if not before. The limit is 8 or 16 I think. I expect that it is likely that there are too many lighting effects in this scene by a wide margin, leading to some unexpected results. Alternate means of creating ground lighting should probably be explored, as these will not be subject to this limitation and will probably also be more framerate friendly." which probably applies to TIs
END

If that's the case, that will be an issue for TOWII Are you saying this is a shaders issue, in which case IO would have to revert to earlier or no shaders30?

 

[gecko]

The advantages for the shaders at night I believe outweigh the cons, with things like landing lights, cockpit lights, smoke that doesn't glow at night etc. A lot of the features of the shaders were created specifically to improve the experience at night, and that continues in the latest version. It might be helpful to see screenshots of the same missions flown with the 2019 shaders to compare differences. It might help narrow down the problem areas.

Light effects (that is, specifically those with ClassName="Lighting") are the ones that need to be used very strategically, and this is true no matter which version of the shaders is used, or even if just the stock shaders are used. Where possible, other options, such as shockwave class effects can be used in place of them.

 

[MajorMagee]

I couldn't get the SJ Spit to run in the install where I'm easily seeing this issue, so I flew around for an hour and couldn't find any rain showers in the install where it does run... Frustrating!

 

[Threedp]

Regarding the night/lighting limit issue, is that new in these shaders? The older ones I was using (2019 I think) are fine in the same mission. I could swear I had this problem with TOW initially but it was somehow solved. I'll dig deeper into my documentation when I get the chance.

 

[gecko]

The limits are not new, but that's not to say a new issue isn't also at play here. I just don't think any of that was changed.

 

[gecko]

I couldn't get the SJ Spit to run in the install where I'm easily seeing this issue, so I flew around for an hour and couldn't find any rain showers in the install where it does run... Frustrating!

Not sure what you mean? There are quite a few rain options in the weather files I included that can be selected in QC.

 

[MajorMagee]

New mystery I have to solve. The rain animation is no longer working in my ETO install where the SJ Spit is installed. It's still on the 2019 shaders and default weather files. Rain is not disabled in the ConfigOverrides file.

p.s. I found that I had a mod installed called Small Rain. It was so small I couldn't see it!

 

[mongoose]

The advantages for the shaders at night I believe outweigh the cons, with things like landing lights, cockpit lights, smoke that doesn't glow at night etc. A lot of the features of the shaders were created specifically to improve the experience at night, and that continues in the latest version. It might be helpful to see screenshots of the same missions flown with the 2019 shaders to compare differences. It might help narrow down the problem areas.

Light effects (that is, specifically those with ClassName="Lighting") are the ones that need to be used very strategically, and this is true no matter which version of the shaders is used, or even if just the stock shaders are used. Where possible, other options, such as shockwave class effects can be used in place of them.

I'll get back to you later as plenty on your plate and I'm away fro 3 weeks on Monday.

 

[MajorMagee]

Can you test with the SJ Spitfire Mk.V? The clipped wing variants in particular have large transparent colored glass for the wingtip lights. I did 99% of the shaders testing in these aircraft and did not encounter it beyond what was related to the harbor model. This is both before and after discovering the issue originally and finding a solution, so I was specifically looking for it to crop up. I'd be curious if you encounter the issue on that aircraft as well. If not, we might be able to find a difference between models that do cause the issue and those that do not.

Okay, figured out what's different. The SJ Spitfire Mk.V doesn't trigger the tinted rain because it uses the texture "spit5_navlights_t.dds" to define the color on the transparent surface rather than setting it directly in the diffuse color section of the m3d.

 

[MajorMagee]

New mystery I have to solve. The rain animation is no longer working in my ETO install where the SJ Spit is installed. It's still on the 2019 shaders and default weather files. Rain is not disabled in the ConfigOverrides file.

p.s. I found that I had a mod installed called Small Rain. It was so small I couldn't see it!

I redid the small rain mod so now it's much less rain in the animation rather than invisibly small.

 

[Threedp]

Curiouser and Curiouser . . .

I spent a while today spit balling anything I could think of, with little success. The last thing I did was to search for and delete all the BDP files in my TOW install, delete them, restart my PC, any mysteriously, the problem is gone. Literally scratching my head, but at least I'm finally OK, at least for now.

However, as I had been noticing some visual oddities in other installs, I thought I'd repeat the process. I tried PTO and afterwards, when I dropped a Little Boy, the area of the devastation was flickering in a similar way. Maybe my PC/video card just can't handle the new stuff properly? I only installed parts 1 and 2 so i thought I'd be OK. Oh well. Thanks for trying to help.

 

[MajorMagee]

I just installed it in DPC Korea. The biggest edit required was to reset the time in the frontend.xml files because of the offset for being on the other side of the planet. Without that the UI was always displayed as the middle of the night. Rising Sun and PTO will most likely need similar edits.

 

[MajorMagee]

This is my version of the Water Animation files to minimize repeating patterns in the seafoam.

Alternative Water Animation Files

 

[Threedp]

I just installed it in DPC Korea. The biggest edit required was to reset the time in the frontend.xml files because of the offset for being on the other side of the planet. Without that the UI was always displayed as the middle of the night. Rising Sun and PTO will most likely need similar edits.

I've often wondered about this. How exactly does one modify the frontend.xml file for the Pacific installs? Does it fix the in-game times as well or does that require another fix? I've never actually had an issue in the UI, but in game, the times of day are a crapshoot.

 

[Frosty]

Amidst all these questions and problems regarding weather and coloured rain, I wonder whether someone has read point 6 of the Developer's notes and knows how to implement this channel packing and suffix business? I can't seem to get it to work and it might save some serious disk space as the P-47 has a lot of textures (which I am trying to reduce in number anyway).
As I feel this part of Readme is rather concise and I am not more than an well-meaning amateur, there's a lot that requires some clarification, such as:

• Are the textures applied with their suffixes in gmax or just like any other texture without these suffixes and are they automatically recognized in game like the .+nm.dds?
• The +.nm.dds needs to be a standalone texture so in what texture's channels can we pack the other ones? Not in the ._t.dds, can we? I thought all the colour information of the diffuse (skin) texture is stored there, or I am mistaken?
• In what format should these individual 'to-be-suffixed' textures be saved before they are compressed and converted to .dds? Just bmp or .tga, like I found on the web?
• Does 'one' channel ATI1N and 'two' channel ATI2N refer to the number of textures packed in the channels of the file? Eg. if one should pack two textures in the channels of a single file, should ATI2N be used?
• Some explanation of how to pack a texture in another file's channel would be appreciated. I can seem to paste a texture into a channel in Photoshop but should there be anything else in the other channels or in the background/layers? I pasted a _r texture in one of the channels of an otherwise empty file, applied the correct suffix but it doesn't seem to do anything in game.
• What's the difference between the .+clight and the .+lrgb files?
• If I understand the Readme correctly, it should be possible to use both _s and _r files, where _s controls the strength of the reflections and _r the sharpness of the reflections. However, the _s value should preferably not exceed the _r value, otherwise the _r value is increased to match the _s value (and this does not happen the other way around).
• Should the _r and _s textures be in grayscale for the channel packing?

I am sure there's a lot I have left out, but this seems to sum up some basic things I need to know to use these features of the 2025 shaders...

 

[MajorMagee]

This may answer some of your questions.

For some odd reason my (AnKor) current implementation of self-illumination textures (+lrgb) worked as if the original texture was lit by external light source instead of actually emitting the light.

This means that if you have absolutely black original texture, then no matter how bright the lightmap is you will still get the black color as a result.

To fix it I have introduced a new suffix for textures: +light

These will actually add the lightmap on top of original texture, so even black surfaces will appear "emitting" the light.

In addition to these there are two new suffixes for such emitting textures:

+nlight -- these are only active at night

+clight -- these are for cockpit use and only active when cockpit light is switched on

Keep in mind that only ONE additional texture of this kind can be used, i.e. you can't specify +light and +nlight for the same original texture. If you try to use these and they dont' seem to work check for a file with the same name but with the +lrgb.dds ending.

You can use self-illumination for scenery (autogen) buildings.

So you can do either to add some light to windows ignoring the black-out:

ScenerySheet01.+light.DDS -- always-on

ScenerySheet01.+nlight.DDS -- night-only

Again, it is either first or second, can't use both.

ScenerySheet01 is default name for scenery sheet texture, but if your install uses different name the lightmap has to match it (i.e. WOFF uses WW1ScenerySheet.dds).

The lightmap doesn t have to match the resolution of the original texture, it can be smaller.

You can even use specular map for scenery sheet: +sr for standalone (without lightmap) or +sa for alpha channel, but it is an overkill.


Besides normal map, there can be only one additional texture (unfortunately standard "_s" texture also counts).

However, you can combine specular and light map in a single texture, using this naming scheme: xxx.+lrgb+sa.dds

This would mean that RGB channels are used for lighting and ALPHA channel is used for specular (note that it is "sa" not "sr").