• There seems to be an uptick in Political comments in recent months. Those of us who are long time members of the site know that Political and Religious content has been banned for years. Nothing has changed. Please leave all political and religious comments out of the forums.

    If you recently joined the forums you were not presented with this restriction in the terms of service. This was due to a conversion error when we went from vBulletin to Xenforo. We have updated our terms of service to reflect these corrections.

    Please note any post refering to a politician will be considered political even if it is intended to be humor. Our experience is these topics have a way of dividing the forums and causing deep resentment among members. It is a poison to the community. We appreciate compliance with the rules.

    The Staff of SOH

  • Server side Maintenance is done. We still have an update to the forum software to run but that one will have to wait for a better time.

Screenshots!

I've had them since we discovered the hidden ability of AnKor's shaders to limit effects to low latitudes the same way the high altitude contrails are done.

In the Shaders30 folder there the Texturemagic.ini file that has these entries:

[HighAltSprite]
tr_condenstrail_basis1.dds=7500|500
tr_condenstrail_basis2.dds=7500|500
tr_condenstrail_basis3.dds= 2500|-1500

The first two set the high contrails to start becoming visible at 23,000 ft and be fully on at 26,600 ft and above.
The third entry has the wing tip trails start showing up at 8,200 ft, and be fully on at 3,300 ft and below.

The xdp entries look like:
<Effect Type="Track" EffectName="fx_N_gtrail" AvH="emitter_damage_wing_tip_left" MinVel="45" MaxVel="250" PosX="-7.7" PosY="0.275" PosZ="-0.27432"/>
<Effect Type="Track" EffectName="fx_N_gtrail" AvH="emitter_damage_wing_tip_right" MinVel="45" MaxVel="250" PosX="7.7" PosY="0.275" PosZ="-0.27432"/>

<Effect Type="Track" EffectName="fx_high_contrail" Location="emitter_eng0_exh_r" />
<Effect Type="Track" EffectName="fx_high_contrail" Location="emitter_eng0_exh_l" />

The XYZ values for the gtrail will be different for each specific aircraft type.

The effects.xml needs to reference basis3.dds for the fx_N_gtrail entries.

<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"/>
 
I know the system, I was the one who originally made the lights and wingtip trails for the AvH aircraft... but those look different, twirling instead of the straight ones found on the Mk VII/VIII Spitfires and Fw 190As for example. I'll have to experiment with them a bit.

EDIT - well indeed. A great improvement over the normal G trails, they worked well in the pre-AnKor era but not so well nowadays.
 
The Mudpond site also has a P-51H that I'd missed seeing before. AI Gigapixel to increase the texture resolution and she looks pretty decent for something from 2004.

nw6JNdL.jpg
 
Nice.

Major using that AI Gigapixel to update to the 2048 textures do you take much of a frame rate hit?

Im only running cfs3 from a 5-6 year old ASUS ROG G75VW laptop which has a GTX670 graphics card so Ive so far resisted the temptation to run textures through that program in case I get a big hit on the frames.

For example I can pack the sky with planes (30+) and my frames drop to around 40 - 50fps with everything set to max for visuals typically with only the one plane it sits around 90-110fps depending on the aircraft both without stutter.
 
No, on my system even 4096 can be used without any negative effects.

I'm running a 4.6 GHz 8 core I7,with 16 Gb memory, at 3440 x 1440 with a 4Gb GTX 980 at 75-100 fps (Gsync) using 4X Multisampling for AA, and 4X SGSSAA for Transparency (eliminates shimmering). Increasing to 8X and 8X cuts my framerate to 40-60 fps. If I check the GPU memory usage it never goes above about 1GB when the game is running, so texture size is not really an issue. The system is now all on SSD versus the Hard drives I was running until last fall, but other than the initial game loading times, I haven't noticed any improvements in performance from that.

The only unresolved issue I have is micro-stuttering caused by a high density of ground objects when viewed perpendicular to the direction of aircraft movement (view from the side when flying low and fast). As far as I can tell this is related to how they blit the memory in the code for scrolling the image left and right across the screen space. It seems that they don't use the graphics memory for that, and the cpu regularly skips a beat when the memory blocks that are changing reach some limit in the code. Looking straight ahead, flying slower, or higher up, or reducing the number of ground objects being displayed all seem to reduce or eliminate the hitching problem
 
MajorMagee said:
No, on my system even 4096 can be used without any negative effects.

I'm running a 4.6 GHz 8 core I7,with 16 Gb memory, at 3440 x 1440 with a 4Gb GTX 980 at 75-100 fps (Gsync) using 4X Multisampling for AA, and 4X SGSSAA for Transparency (eliminates shimmering). Increasing to 8X and 8X cuts my framerate to 40-60 fps. If I check the GPU memory usage it never goes above about 1GB when the game is running, so texture size is not really an issue. The system is now all on SSD versus the Hard drives I was running until last fall, but other than the initial game loading times, I haven't noticed any improvements in performance from that.

The only unresolved issue I have is micro-stuttering caused by a high density of ground objects when viewed perpendicular to the direction of aircraft movement (view from the side when flying low and fast). As far as I can tell this is related to how they blit the memory in the code for scrolling the image left and right across the screen space. It seems that they don't use the graphics memory for that, and the cpu regularly skips a beat when the memory blocks that are changing reach some limit in the code. Looking straight ahead, flying slower, or higher up, or reducing the number of ground objects being displayed all seem to reduce or eliminate the hitching problem
Click to expand...

Thanks for the info mate, to be honest some of the things you added about gsync and multisampling are way above my head, I get my son to see what he thinks for my setup but again cheers for the info.
 
MajorMagee said:
I'm still trying to repopulate my PTO install that was lost in the big computer crash I had last year. This was a quick transfer of the stock MkIb Typhoon to Australian service using AI Gigapixel to increase the resolution of the skin texture, and a hex edit of the m3d to add AnKor's reflectivity.

S10ZHDE.jpg
Click to expand...
Hi Major,

nice skin, but RAAF never had the light blue inner roundel, we had white inner and dark blue outer. what you have there is the RAF version of the roundel in use in the far east.

regards Rob.
 
Was playing around with replacing the original searchlights in the 'Chastise' mission with the new ones and caught this nifty shot . . .
 
For anyone interested:

I did not modify the mission file. I modified the Mohne dam facility to replace the searchlights in it. Next, I'm going to dup the mission, change it to day, and see what it looks like. This is part of my effort to try and get searchlights into Quick Combat. My thought is that if searchlights don't show during the day, there'd be no harm in replacing a flak gun or two in each facility with searchlights. It's a thought if nothing else!
 
There's a function in the TextureMagic.ini file you might be able to take advantage of to do this.

[NightSprite] ; Sprites which are drawn (fullbright) only when the world light is below the certain threshold set in d3d8.ini
piston_exhaust_n.dds

Just add the associated texture file name from your searchlight.

The other option would be to use the .+nlight function.
 
MajorMagee said:
There's a function in the TextureMagic.ini file you might be able to take advantage of to do this.

[NightSprite] ; Sprites which are drawn (fullbright) only when the world light is below the certain threshold set in d3d8.ini
piston_exhaust_n.dds

Just add the associated texture file name from your searchlight.

The other option would be to use the .+nlight function.
Click to expand...

I suggest put all light.dds files that only should be illuminated at night under [NightSprite] . Since I have different TextureMagic.ini files for ETO(day) and TOW(night) eras, I was reminded of this when the ETO era3 did not have all my airfield lights.dds files under [NightSprite], so they were illuminated in the daytime. ( The reason I have different TextureMagic.ini files is that I wanted a darker night. It does however make grass purple in the daytime!)

If in doubt you will have to check what dds files are called for by various objects through their m3d files.
 
You must log in or register to reply here.
Back
Top