mue

Do I see it right: the terrain tile is shown ok, only the target objects are fading in? This is really strange and I can't reproduce the error on my systems. Does anyone else have this problem? Please, can you save your graphic system information to a file and send it to me. You can do this either by using msinfo32: -click start -in the search field type "msinfo32" and press enter -select "component->display" -save the info to a file with file->export or you can use dxdiag: -click start -in the search field type "dxdiag" and press enter -click "save all information..."

As most of you know spotting other aircraft in SF2 is quite difficult. I think most are using the red targeting box to engage enemy aircraft. But only the currently targeted aircraft is marked with the red box and not the other aircrafts. Another option would be to turn labels on (HUD Display option set to "Easy"). Unfortunately the label text is too verbose and is also shown at too long distances. Some people already had the idea to change the label text into a single dot but AFAIK nobody has accomplished it yet...until now... I proudly present the "dot label mod": dot_label_mod.zip With this mod labels are shown as a dot and only within a distance of 10 nm. This mod uses a modified text drawing shader that hides all characters and digits of the label text and only draws the "dot" character. Unfortunately there is a negative side effect: the text in the target info box is also "filtered" by this shader and therefore not correctly displayed. So I disabled the target info box. Furthermore to get rid of the way point label text (which shows up if the HUD Display option is set to "Easy") the shader also completely hides all text that is drawn with NormalColor. This means that also the text in the top info box and in the bottom left info box is hidden. But the afterburner message is still shown. To install this mod just put the contents of the zip file (huddata.ini and twfont.fx) into your Flight folder and set the HUD Display option to "Easy". The enemies are shown with red dots, and friendlies are shown with blue dots. But you can change the colors to your liking by changing the values of EnemyTargetColor and/or FriendlyTargetColor in the huddata.ini AND setting exactly the same values (without the alpha compononent) in the twfont.fx files: e.g: if you set in huddata.ini EnemyTargetColor=0.1,0.2,0.3,0.4 you must set in twfont.fx float3 EnemyTargetColor = float3(0.1,0.2,0.3);

I noticed another positive effect of this mod (in particular the ObjectsFade=false and the increasing DetailMeshSize settings): The 6.7 nm aircraft drawing distance limit (http://combatace.com/topic/82507-some-tests-regarding-aircraft-drawing-distances/) is gone. Now I can see a B-52 fully zoomed in at distances of 15nm (with DetailMeshSize=10) or 19nm (with DetailMeshSize=12).

No, the shader (*.fx) files must be put into the individual Terrains\<terrain> folder. By setting ObjectsFade=false (in options.ini) and increasing DetailMeshSize (in flightengine.ini) you increase the drawing distance of tod objects. But the tods will still popping up. Only if you put the shader files into the individual terrain folder, the fading is enabled for this greater drawing distance.

I haven't had much time lately to work on the target area editor. So progress is rather slow at the moment .

I ported the fading tod objects functionality from the sf2 shaders to the fe2 shaders. fe2_fading_tods_shader.zip -Copy the shader files (*.fx) into the Terrains\<terrain> folder. -Adjust the variables fadeStartDistance and fadeLength to your likings in the follwing code section of both shader files: float fade_with_distance(float FadeDist) { float fade_alpha = 1.0; //mue: distance at which the object still has alpha = 1.0 (full opaque) const float fadeStartDistance = 3000.0; //in meters //mue: fadeStartDistance + fadeLength = distance at which the object has alpha = 0.0 (full transparent) const float fadeLength = 1000.0; //in meters const float fd = FadeDist - fadeStartDistance; if (fd > 0.0) { fade_alpha = clamp(0.0, 1.0, 1.0 - (fd / fadeLength)); } return (fade_alpha); } -Set in flightengine.ini DetailMeshSize to the rounded up value of (fadeStartDistance + fadeLength) / terrain_tile_size. E.g. fadeStartDistance = 3000.0, fadeLength = 1000.0 and terrain_tile_size = 500 (stock fe2 terrain_tile_size is 500): (3000.0 + 1000.0) / 500 = 8.0, rounding up = 8 => DetailMeshSize=8 -Set in <terrain>_data.ini [solidObjectTextureMaterial] BlendOp=BLEND_SRC_ALPHA (or BLEND_DST_ALPHA) This makes sure that the tod objects are drawn after the terrain tiles (It's a requirement for the fading to work correctly). Unfortunately this has the negative side effects that the tods don't cast shadows anymore and the shadows cast by target objects are visible through the tods.

Minor bugfix update version 0.5.1: -bugfix: crashes while reading 24 bit tga files. LODViewerUpdateV0.5.1.zip

It's in the <aircraft>_cockpit.ini. Try to increase it as much as possible as long as you don't get any clipping issues. E.g. in FE2 for an aircraft I could increase that value only from 0.05 to 0.08 without clipping issues.

Have you really set ZBufferOffset of [solidObjectTextureMaterial]? Disappearing runways seems to indicate that you changed [NormalTextureMaterial] or [backgroundMaterial].

As I wrote in the first post: In options.ini (in your mod root folder) set ObjectsFade=FALSE. For this mod to work the stock fading function must be DISABLED.

I updated the shaders in my first post. I found and fixed a bug in the original part of the shader code (so don't blame me). The distances of objects that are not in the view center were miscalculated. That can result in objects still popping up (instead of fading) outside of the view center especially near the screen border. With the fixed shaders (and if DetailMeshSize is correctly set) TODs should no longer pop up.

Yes. But that was a bit more tricky. The computation of the alpha value is the same as in teralphaobject.fx. The problem is, that the actual blending is done outside the vertex/pixel shaders. And with ObjectesFade = FALSE the blending is switched off for solid objects. Fortunately I found that the blending can be switched on in the shader file with SetBlendState(...) (It's near the end of the tersolidobject.fx file). If I have time I will have a look.

Yes and yes if your rig can handle that number of tods. Its the size of the terrain tiles. I think all stock terrains have a tile size of 2000 meters. If you don't know the tile size of the terrain, assume 2000 meters and set DetailMeshSize according to the given formula: E.g. fadeStartDistance = 16000.0, fadeLength = 3000.0 and terrain_tile_size = 2000 (16000.0 + 3000.0) / 2000 = 9.5 Rounding 9.5 up to the next integer gives 10 => set DetailMeshSize=10 If you see that the tods pop up in roughly at the half distance (~10000 meters) then the tile size is probably 1000 meters and you have to set (16000.0 + 3000.0) / 1000 = 19, rounding up gives still 19 => DetailMeshSize=19 Of course you can set a higher DetailMeshSize but it will only decrease your frame rate.

Since I had a look into the shaders I also extended the drawing distance for fading objects. The modified object shaders: Update V1.1: fixed incorrect calculation of object distances outside the view center. external link: https://www.dropbox.com/scl/fi/8ga2kdz23ymnlnpof1bkw/sf2_extfadingdistance_shaders_v1.1.zip?rlkey=wwomjcwrz0g05ccdt0iqm1v0b&st=3t8k6ohe&dl=0 -Copy the shader files (*.fx) into the Terrains\<terrain> folder. -Adjust the variables fadeStartDistance and fadeLength to your likings in the follwing code section of both shader files: float fade_with_distance(float FadeDist) { float fade_alpha = 1.0; //mue: distance at which the object still has alpha = 1.0 (full opaque) const float fadeStartDistance = 16000.0; //in meters //mue: fadeStartDistance + fadeLength = distance at which the object has alpha = 0.0 (full transparent) const float fadeLength = 3000.0; //in meters const float fd = FadeDist - fadeStartDistance; if (fd > 0.0) { fade_alpha = clamp(0.0, 1.0, 1.0 - (fd / fadeLength)); } return (fade_alpha); } -Set in flightengine.ini DetailMeshSize so that (fadeStartDistance + fadeLength) / terrain_tile_size < DetailMeshSize -Set in options.ini ObjectsFade=false -Enjoy your flight!

I added the modified terrain shaders for SF2 to the first post.

Since I'm playing FE2 recently, there the problem with shimmering TODs and target objects is more intense, I had a closer look at this issue. I posted my findings/solutions in the SF2 forum, since it also apply to the SF2 games: http://combatace.com/topic/85970-shimmering-tods-and-target-objects/

The shimmering of TODs and target objects and the flickering of shadows in the thirdwire game engine always anoyed me. And since I'm playing FE2 recently, there this problems are more intense,I decided to have a closer look at this issue and possible solutions. This is what I came up with: As many of you already know, the shimmering of the objects and flickering of shadows is caused by the limited precision of the z-buffer. The precision of the z-buffer depends (besides the buffers bit depth) on two values: the near clipping plane distance (znear) and the far clipping plane distance (zfar). To increase the z-buffer precision you have to shorten the interval[znear,zfar], either by decreasing zfar or by increasing znear. Whereby increasing znear is FAR more effective for increasing z-buffer precision. Changing zfar: I'm not quite sure what *.ini setting defines zfar. But I think that decreasing the horizon distance in the game options menu decreases zfar. But I found to see any (minor) effect (regarding reducing shimmering/flickering) I had to change the horizon setting to Near. But I like the horizon setting at Very Far and I will let it at Very Far. Changing znear: znear is defined in the flightengine.ini by FE2: [NearSceneClip] NearClipDistance= SF2 with object fading disabled (fading enabled I haven't investigated yet): [ForegroundSceneClip] NearClipDistance= But there is an exception: If in the <aircraft>_cockpit.ini OpenCockpit= is set to TRUE, then znear is defined by (the usually smaller value) ExternalClipDistMin=. Thats the reason why in some aircraft the shimmering happens, while in the external view it does not. The external view uses the flightengine.ini setting. The znear value has to be increased as much as possible. Unfortunately this value can not be increased arbitrary without side effects: e.g. clipping issues. You have to experiment until you find a maximum znear value without side effects. If you are lucky then the znear increase was sufficient to stop the shimmering/flickering. If not, then you have to tweak further. Tweaks against flickering shadows: Against the flickering shadows I don't know any tweaks. The only solution is to switch them off: Shadow option = High switches TOD shadows off, = Medium also switches target object shadows off. The following tweaks are meant to reduce the shimmering caused by z-fighting between the terrain and the TODs / target objects. What the tweaks do is to increase the z value distances between the terrain and the TODs / target objects. Tweak against shimmering TODs: In the <terrain>_data.ini set [solidObjectTextureMaterial] ZBufferOffset=2.0 or higher (in FE2 I set it to 5.0 to stop the shimmering) That modifies the z value by an offset so that the TODs are put a bit "forward" in the z-buffer. But this doesn't affect target objects shimmering. Tweak against shimmering target objects (and TODs). The solution I found is to modify the terrain shaders: TERTERRAINEFFECT.FX (near terrain) TERFARTERRAINEFFECT.FX (far terrain) TERWATEREFFECT0.FX (terrain with water, Water Detail = Low) TERWATEREFFECT1.FX (terrain with water, Water Detail = Medium) TERWATEREFFECT2.FX (terrain with water, Water Detail = High) In each shader I added the following lines in the vertex shader code const float zOffset = 3.0e-7; output.pos.z += zOffset * output.pos.w; That adds an offset to the z value so that the terrain is put a bit "back" in the z-buffer. This tweak ALSO affects TOD shimmering. But it has a side effect: The TOD / target object shadows are a bit shifted if viewed from greater distances. It's a tradeoff: choosing a greater zOffset value lessens the shimmering but shifts the shadows more and vice versa. You can try to decrease/increase zOffset in small steps (e.g. 1.0e-7) to see which offset fits best. The terrain shaders for FE2: external link: https://www.dropbox.com/scl/fi/m6dd3pigm1lr2f49y3rhu/fe2_zbufferoffset_shaders.zip?rlkey=gvrl7bm12vcrzmmjsq8xvsq5f&st=jize30og&dl=0 Put the shader files (*.fx) into the Terrains\<terrain> directory. @admins/moderators: I also have modified SF2 shaders. But I don't know if the combatace policy allows to upload modified LOCKED shaders. Update: The terrain shaders for SF2: external link: https://www.dropbox.com/scl/fi/jcrile91muzwlqvxzp1ra/sf2_zbufferoffset_shaders.zip?rlkey=v16n56tjvbp2i1cbp8xdyexp7&st=cr3bbbvx&dl=0

No. Just open the *.ini file.

For me, it works. Have you set the pointer to "C:\Program Files (x86)\ThirdWire\Strike Fighters 2" ? Can you post the exaxt size of ObjectData009.CAT. That's there the A-1H.LOD is. I will check if we have identical cat files. Do have others also problems with loading/displaying stock lods?

The program reads all (unlocked and locked) *.cat files from your <installdir>/objects/ and <installdir>/terrains/ folder and all *.dlc files from your <installdir>/DLC/ folder. Dlc files are just cat files with the *.dlc extension. You open the lods by opening the respecitive *.ini files from your mod folder. Not all lods are in objectdata002.cat. DLC lods are in the *.dlc files. Game specific (eg. Europe, Israel, NA, Expansion Packs,...) lods are in the respective cat files. Terrain object lods are in the terrain.cat files.

Regarding ground objects / textures not showing: To debug this issues I need the following information: -which terrain is affected (+ download link) -which target area -which object Furthermore I have some questions regarding the target.ini file: What does the following entries mean? [TargetAreaXXX] Radius= Location= Is the entry [TargetXXX].Heading an integer or can it also be a floating point number? Questions regarding targettypes.ini: If the type has the following entries: UseGroundObject=TRUE and TargetType=AAA (or SAM_RADAR, EW_RADAR, SAM_LAUNCHER) how does the game engine decides which object to put into the target area? Currently the target area editor always displays the objects ks-19, fansong, barlock and sa-2l. Is that ok, or is there a better solution? It's only for display purposes anyway.

Have you tried "shift + left mouse button + mouse moving" ?

Change the color depth to 32 bit.

I think, as a community project without financial backing it will only work if we could get the source code for free. I know of at least one game where this happened: "Enemy Engaged Comanche vs. Hokum". Empire Interactive released the source code under the eech license: http://eechcentral.simhq.com/index.php?title=EECH_License . The community could do what they want with the source code, but the source code and the modifications were still owned by Empire Interactive. But as others already wrote, the possibility that Thirdwire will release the source code is near (equal) zero.

Maybe it didn't find the desert.tfd file. Do you have correctly set the sf2 install directory in Extras->Settings? (Do not select the Terrains folder) Do you have in your install directory the /terrains/desert.cat file? You can also try to extract the desert.tfd file and put it next to the desert.ini file.