AnKor's Shaders

[MajorMagee]

Reticle effect information for P-40B/C Tomahawk
<Effect Type="Track" EffectName="US_AAF_N6a_gunsight" PosX="-0.005" PosZ="-0.80" PosY="0.7525" Pitch="90.5" MinVel="-999999" MaxVel="999999"/>

 

[AnKor]

As you may know, I'm working on new shaders for WOTR and since some will likely want to use them for CFS3 I wanted to mention one "breaking" change in new shaders.

When CFS3 renders Virtual Cockpit view it removes a part of external model related to cockpit and inserts more detailed VC model instead. Additionally VC model is rendered in a way that it is overlaid on top of anything external, regardless of actual Z values.
The latter was required because Z buffer at the time was unable to precisely represent a range of distances from millimeters in cockpit to a more than a hundred of kms outside. Putting everything into a single "scene" would cause bad z-fighting (flickering of closely placed objects). That's why CFS3 first rendered external scene first and then cleared Z buffer and adjusted Z range to render the cockpit. This worked, but caused visual issues even in stock DX8 mode, but was especially bad for my DX9 shaders where I had to invent a tricky rendering sequence to reduce overdraw (so that I was able to render cockpit first and only render those external parts or terrain which are not obscured). It was really painful to handle and still had issues. For example, [CockpitSprite] section in TextureMagic was required to let certain sprites be rendered inside the cockpit instead of being obscured.

Current hardware (or rather a simple and smart trick invented some years ago) allow using a very precise Z buffer practically at the same cost as a conventional one. It allows discerning Z values at precision no worse than 0.005 m (half a millimeter!) within 150 km visibility range! Basically you can put everything into one scene and don't worry about z-fighting. Well, not that simple - at those ranges other issues tend to appear, but you see the point

So, new shaders will use this new Z buffer and will render everything together.
But what is the downside?
Well, it is not actually a downside, it can be used to advantage, but it breaks that part of old renderer where "cockpit is overlaid on top of everything else". CFS3 will still remove the cockpit part of external model, but if something is not removed it may stick through VC model into the cockpit.
Good news is that it doesn't affect any stock CFS3 aircrafts, and recently released FW 190 and Me 163 are unaffected too (but these are only recently released models I have to test). I understand there are hundreds of 3rd party models, but if a modeller was careful enough to mark all required external parts to be removed from cockpit and didn't leave any "shared" surfaces everything should be ok.
One 3rd party model that works badly is Mig 15 (don't remember which one) because for some reason VC model is a bit wider than the aircraft itself and I can see fuselage sides inside the cockpit.
Certain WOFF aircrafts tend to have issues. Some has low-res external view gauges, headrests or other nearby parts not removed in VC view. Sometimes it is an oversight, sometimes they had to do this to make WWI biplane open cockpits work correctly. Most of them are ok though.

The point of this post is to let you know that some old aircrafts may have issues with new shaders, and if you are making new aircrafts try not to rely on "cockpit hides everything" behavior and properly mark external surfaces to be removed in VC view.

 

[MajorMagee]

The Mig-15bis was an example where a cockpit was borrowed from another model to shorten the development cycle. Something similar was done for a number of ai only models that we've made flyable as beta versions.

Will the new rendering approach bring any particular performance benefits or new capabilities to the game?

 

[AnKor]

New approach should not be slower than the original one, I doubt it is faster, but it is well supported by modern hardware.

It makes code simpler.
It will allow me to add some new effects which weren't previously possible because Z buffer values were inconsistent.
It removes Z-fighting - i.e. in WOFF it is sometimes visible how distant facility buildings flicker if you look from high altitude, shouldn't be the case anymore.
It could make modelling easier if you intentionally want to have external parts visible in VC. For example some WW1 aircrafts have that small propeller attached to a strut which pressurizes the fuel tank, but CFS3 doesn't allow blurred prop in VC model and OBD guys had to go through hoops to make external model propeller visible in VC mode.

Here is how it looks in Mig 15.

Oh, and I've just figured out that my Mig 15 is not "Mig15 bis" you are referring to, somehow I missed that there's a new model you made with BorekS. My one is an ancient model from 2003 and I don't even remember where I got it. Need to try the new one

 

[gecko]

Ah, I see some new possibilities with cockpit animations with this, since animations that are only available in the external model can now be used inside the cockpit.

I'm curious if there is a way ensure that models being worked on currently don't have conflicts between the external and VC?

 

[AnKor]

I plan to make a preview build sometime soon, but only for development use, not for public.

PS: 0.005 m is actually 5mm, not 0.5mm as I said before, but that's the worst case which happens at distances above 50km
The best case is much more precise. And cockpit distance is the best case.

 

[sdsbolt]

Ankor,

Thank you for the advance notice on the new shaders. Sounds like it will allow us to add a few new animations at the very least.

Will fog and smoke effects look the same in front of external parts as they do vc parts?

Steve

 

[AnKor]

Fog, smoke and rain is a problem I'm still thinking about.
There are some models which have VC parts placed as if they were external. For example Ground Crew's BF110 has gauges on engines.

Currently these outside parts appear through fog. My new code will allow to fog them properly.
However there's a reverse side of this: you wouldn't want to see smoke or rain inside closed cockpits, this could be especially bad for large bombers.

I think I will make cockpit obscure rain effect as it always did because there's nothing else I can do.
In-cloud fog overlay will likely go away and will be completely reworked.
However I haven't decided yet what to do with smoke from gunfire. My current idea is to do additional rendering pass for cockpit to get Z values of its opaque parts and cockpit glass (normally semi-transparent objects don't write Z values) and then use these values to block sprites. This adds some overhead, but it should be relatively small.

 

[MajorMagee]

Here's an exciting new effect I sort of backed into this evening.

I always noticed that the fx_N_gtrail wing tip vortex effect looked okay from the outside, but from inside the cockpit, the alpha transparency wasn't working and you saw a solid stripe instead of a vapor trail.

After trying a number of fixes I discovered that referencing a different texture file resolved the issue. tr_condenstrail_basis2.dds that I provided with AnKor's Shaders was a perfect looking candidate, but when I tried it there seemed to be a new problem with it not always appearing when it should have. These effects have traditionally been implemented as speed dependent, but even expanding the speed range didn't fix the problem.

This evening it dawned on me that tr_condenstrail_basis2.dds was being suppressed because it was listed in texturemagic.ini as [HighAltSprite] and would only appear at high altitude like all good contrails should. So I created a copy of the file with a different name called tr_condenstrail_basis3.dds and then it would show up properly whenever the speed range requirement was being met.

That got me to thinking, that like contrails the wing tip vortex effect should really have been altitude dependent with it being limited to the thick humid air near the ground. AnKor's effect is set up so that the contrail effect becomes progressively more visible as you go above the threshold altitude, and then is 100% for everything above that. What I discovered just now was that you could trick it into doing the same thing to limit it to lower altitudes, getting progressively more visible as you descended, by adding this line to the [HighAltSprite] section of texturemagic.ini

tr_condenstrail_basis3.dds= 2500|-1500

This barely starts the effect at 8,200 ft, and it gets progressively more dense until it has 100% visibility below 3,300 ft.

I've seen exactly this effect on commercial airliners during the summer as we've made our landing approach. It's barely visible as you initially break below the cloud base, and gets brighter as you continue to descend, disappearing as the speed drops after touchdown.

With this ability you no longer have to restrict the gtrail effect to a narrow band of speeds to make it seem realistic. You could edit the aircraft xdp files to widen the speed range to cover more of the typical approach and landing speeds, and let the altitude control prevent it from showing up at combat altitudes.

Editing the altitude value ranges in the texturemagic.ini would be needed to adjust for winter versus summer humidity levels to be completely accurate, but that's not an absolute requirement to use this.

The entry in the effects.xml now looks like

<fx_N_gtrail ClassName="GroupEffect" Effect0="N_track_contrail_s"/>
<N_track_contrail_s ClassName="TrackEffect" FlatTrack="0" Lifetime="0" InitialDelay="0" ParticleLifetime="0.15" FadeInTime="0.02" FadeOutTime="0.12" PosX="0" PosY="0" PosZ="0" CountSegments="5" SegmentLength="2" Width="0.25" WidthGrow="1.2" InitialAlpha="0.00" InitialColor="250 250 255" Alpha="0.55" Color="250 250 255" FinalAlpha="0.00" FinalColor="250 250 255" BlendMode="QuadSprite" Texture="tr_condenstrail_basis3.dds" ZBias=".03"/>

versus the original

<fx_N_gtrail ClassName="GroupEffect" Effect0="N_track_contrail_s"/>
<N_track_contrail_s ClassName="TrackEffect" FlatTrack="0" Lifetime="0" InitialDelay="0" ParticleLifetime="0.15" FadeInTime="0.02" FadeOutTime="0.12" PosX="0" PosY="0" PosZ="0" CountSegments="5" SegmentLength="2" Width="0.1" WidthGrow="1.2" InitialAlpha=".00" InitialColor="250 250 255" Alpha=".55" Color="250 250 255" FinalAlpha=".00" FinalColor="250 250 255" BlendMode="QuadSprite" Texture="tr_smoke_6.dds" ZBias=".03"/>

*** Be careful not to end up with multiple copies of fx_N_gtrail as you edit effects.xml ***

 

[AnKor]

Nice find! It is always interesting to see how people find unintended features in my code

Meanwhile I did some background work for DX11 shaders and found how cfs3 checks velocity limits for track effects. This allowed me to plug additional conditions into that code. So far this just means that I can define contrails by effect's name instead of texture name and can avoid emitting them at all instead of just hiding them at rendering level.
This could potentially allow more complex conditions for enabling/disabling effects, but I haven't thought about it much and not sure what is possible and what is not. Are there any interesting effects which require additional conditions?

Unfortunately keeping contrails when aircraft is out of view is still impossible.

 

[FOO FIGHTER]

Here's an exciting new effect I sort of backed into this evening.

You're a certifiable genius!

I've been going mad trying to figure out how to get my helo dust effect appear at the right altitude and speed. This solves it perfectly!

One minor thing: It is ineffective on airbases/land a couple hundred feet above sea level.

 

[gecko]

Great idea Andy, I'll have to add that to my next round of effects for the Spitfire project.

This could potentially allow more complex conditions for enabling/disabling effects, but I haven't thought about it much and not sure what is possible and what is not. Are there any interesting effects which require additional conditions?

Well that's got the wheels turning. Give me long enough and I could think up a whole bunch of things. Here's a few off the top of my head.

Horsepower - useful for engine exhaust effects. Manifold pressure could work too, but horsepower would be ideal. Would be good if it could be used in conjunction with the high altitude sprites so contrails can be shut off when the engine is shut down or destroyed.

G forces - G-force induced contrails (combined with Andy's low altitude sprite trick if possible), smoke from negative-g carburetor flooding that certain aircraft experienced (best if paired with horsepower for the same reason as the high altitude sprites).

Mach (as opposed to airspeed) - sonic booms, etc.

Altitude above ground - would be useful for dust effects as pictured above, would be good if it could differentiate between land and water to allow different effects. Think of flying at wave top height and kicking up a spray!

Rain - wet cockpit windows (that might be a long shot)

Rounds remaining in a given gun - could turn on tracers the last few rounds as was often done to let the pilot know he was almost out of ammo.

No idea how feasible any of that is, but a lot of those have been things we've beat our heads against for years.

 

[MajorMagee]

You're a certifiable genius!

I've been going mad trying to figure out how to get my helo dust effect appear at the right altitude and speed. This solves it perfectly!

One minor thing: It is ineffective on airbases/land a couple hundred feet above sea level.

Now this is getting really cool!

 

[mongoose]

................

Unfortunately keeping contrails when aircraft is out of view is still impossible.

Since after aircraft leave the scene, contrails tens to break up a bit and widen, could narrow bands of clouds be made to simulate that effect?

 

[MajorMagee]

SweetFX versus Reshade

A couple of years ago I discovered that I needed to run SweetFX with AnKor's shaders for G-Sync to work in CFS3. I had tried to install the more up to date version called Reshade back then, but it wouldn't run at all so I reverted back to SweetFX for my 16 different installs. In most cases I didn't want/need any special effects so I created a null SweetFX profile that had everything turned off, and G-Sync would still be working fine.

When I recently installed MAW-43 I found that even before I got around to adding SweetFX to that install that G-Sync was working just fine. I'm not sure if it was an Nividia Driver Update, Windows 10 Update, or the newer d3d8.dll from AnKor that did the trick, but it was nice to know that I didn't need SweetFX any longer.

That prompted me to try the latest version of Reshade again, and sure enough, it was now mostly working okay (no DOF functions) with CFS3 (MAW-43 install). It warns you when you do the install that you will need an open source d3d8.dll that Reshade has as an optional add-on, but I just used the one already provided by AnKor and it ran fine. (I didn't want to risk losing all of our wonderful new functionality in CFS3 by using the generic file)

When I do have special effects turned on in-game I typically want to produce the same look that I get by post-processing a saved image in PhotoShop. My method is to do an Image-Adjustments-Auto Contrast, followed by an Unsharp Mask with settings of 20% strength, 30 pixel radius, Threshold 0 (High Local Contrast Enhancement). After trying a variety of shader filter and function combinations I finally hit on one that very closely matches what I get in Photoshop.

In SweetFX it's:
#define USE_LIFTGAMMAGAIN 1
#define RGB_Lift float3(0.82,0.82,0.82)
#define RGB_Gamma float3(1.075,1.075,1.125)
#define RGB_Gain float3(1.085,1.085,1.085)

In Reshade it's:
Effects=LiftGammaGain.fx
Techniques=LiftGammaGain
TechniqueSorting=LeiFx_Tech,AdaptiveFog,AdaptiveSharpen,AmbientLight,ASCII,BloomAndLensFlares,Border,Cartoon,Chromakey,CA,Clarity,ColorMatrix,Colourfulness,AdvancedCRT,Curves,Daltonize,Deband,KNearestNeighbors,NonLocalMeans,DepthHaze,DisplayDepth,RingDOF,MagicDOF,GP65CJ042DOF,MatsoDOF,MartyMcFlyDOF,DPX,EGAfilter,Emphasize,HDR,MotionBlur,FilmGrain,FilmGrain2,FilmicAnamorphSharpen,FilmicPass,Mode1,Mode2,Mode3,FXAA,GaussianBlur,GlitchB,HighPassSharp,HQ4X,Levels,LiftGammaGain,LightDoF_AutoFocus,LightDoF_Far,LightDoF_Near,LumaSharpen,LUT,MagicBloom,Monochrome,MultiLUT,MXAO,Nightvision,Nostalgia,PerfectPerspective,ChromaticAberration,ReflectiveBumpmapping,Tint,SMAA,SurfaceBlur,Technicolor,Technicolor2,TiltShift,Tonemap,UIMask_Top,UIMask_Bottom,Vibrance,Vignette


[LiftGammaGain.fx]
RGB_Lift=0.820000,0.820000,0.820000
RGB_Gamma=1.075000,1.075000,1.125000
RGB_Gain=1.085000,1.0850000,1.085000

The result is that the real time image gains clarity (a hint cooler, brighter and more contrast).

The only difference I see between SweetFX and Reshade using this profile so far is that Reshade drops about 3 FPS, while SweetFX has no slow down at all.

Reshade does provide more filters than SweetFX did, and is the basis for Nvidia's new FreeStyle Ansel features. However, some of the filters available in Reshade run quite a bit slower (-25FPS) on my system than the equivalent ones in SweetFX did, and combinations of even the ones that don't have much impact on FPS can quickly kill the performance. Having said that, the results can be amazing if you have the time to play with all the settings and options to create the look you want.

 

[MajorMagee]

For bright and sunnier climates like MAW I find that in addition to the added clarity of LiftGammaGain I need to also brighten things up a bit, so I add in DPX as well.

The SweetFX DPX values I'm using are:
#define USE_DPX 1
#define Red 8.00
#define Green 8.00
#define Blue 8.00
#define ColorGamma 2.00
#define DPXSaturation 2.00
#define RedC 0.36
#define GreenC 0.36
#define BlueC 0.34
#define Blend 0.20

and in Reshade it's:
[DPX.fx]
Strength=0.200000
RGB_Curve=8.000000,8.000000,8.000000
RGB_C=0.360000,0.360000,0.340000
Contrast=0.010000
Saturation=2.000000
Colorfulness=2.000000

Top = Null, Middle = SweetFX Lift Gamma Gain, Bottom = SweetFX Lift Gamma Gain + DPX

Again with SweetFX there is no FPS loss, but with Reshade LGG drops about 3 FPS and LGG+DPX drops about 9 FPS

 

[MajorMagee]

Here are the AnKor compatible xpd effects entries for the ETO He219 aircraft:

<Effect Type="Track" EffectName="fx_high_contrail" Location="emitter_engine_0_exh_r" />
<Effect Type="Track" EffectName="fx_high_contrail" Location="emitter_engine_1_exh_l" />
<Effect Type="Track" EffectName="cockpit_light_uv" PosX="-0.475" PosZ="4.00" PosY="0.85" Pitch="110" Heading="20" MinVel="-999999" MaxVel="999999"/>
<Effect Type="Track" EffectName="cockpit_light_uv" PosX="0.475" PosZ="4.00" PosY="0.85" Pitch="110" Heading="-20" MinVel="-999999" MaxVel="999999"/>

 

[MajorMagee]

One of the things I discovered about the SweetFX settings I posted above, that nicely enhance the daytime clarity, is that they make flying at night almost impossible. They push the darker shades all down toward black, and there are essentially no lighter tones to brighten, so there's nothing to see on the screen. At least it's easy to switch between presets.

 

[BorekS]

You're a certifiable genius!

I've been going mad trying to figure out how to get my helo dust effect appear at the right altitude and speed. This solves it perfectly!

One minor thing: It is ineffective on airbases/land a couple hundred feet above sea level.

yum! would be great to see this applied on the BMW Flugelrad!

 

[mongoose]

Here are the AnKor compatible xpd effects entries for the ETO Halifax aircraft

<Effect Type="Track" EffectName="cockpit_light_uv" PosX="-0.575" PosZ="4.25" PosY="1.05" Pitch="100" Heading="20" MinVel="-999999" MaxVel="999999"/>
<Effect Type="Track" EffectName="cockpit_light_uv" PosX="0.475" PosZ="6.25" PosY="0.75" Pitch="100" Heading="-20" MinVel="-999999" MaxVel="999999"/>

<Effect Type="Track" EffectName="fx_high_contrail" Location="emitter_engine_0_exh_l" />
<Effect Type="Track" EffectName="fx_high_contrail" Location="emitter_engine_1_exh_r" />
<Effect Type="Track" EffectName="fx_high_contrail" Location="emitter_engine_2_exh_l" />
<Effect Type="Track" EffectName="fx_high_contrail" Location="emitter_engine_3_exh_r" />