mue

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. sf2_extfadingdistance_shaders_v1.1.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 = 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: fe2_zbufferoffset_shaders.zip 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: sf2_zbufferoffset_shaders.zip

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.

2) The coordinate system axis tripod (View->Show Coordinate System) can act as a compass rose. The green axis points north, the red axis points east. 1) With shift + mouse move you can "slide" around. The moving direction depends on the current view azimuth: e.g. rotate the view, so that the green tripod axis points up and the red tripod axis points right. If you now hold shift and moves the mouse up/down you slide north/south (moving the mouse left/right you slide west/east)

In Extras->Settings point to the SF2 install directory. NOT to the terrain subfolder. With File->Open select the terrain.ini file within your mod terrain folder. For viewing stock terrain you have to extract at least the terrain.ini file into your mod terrain folder and open it from there.

If we could get the source code, I would help with programming.

Although the target area editor in its current state only has viewing (and no editing) capabilities I decided to release a first version. Maybe someone find it already useful. For usage instructions read the readme.txt. I tested it with stock terrains, Rends germany terrain and the range terrain. Feel free to report bugs, feature wishes etc. TargetAreaEditorV0.1.zip Screenshot: Rends germany terrain, (now ex-) airbase near my hometown.

Ok, after the change of the thirdwire homepage I was afraid that the pc games may disappear. So I purchased First Eagles 2 and some DLCs as long as they are still available. And that gave me the opportunity to add FE2 and DLC support to the LODViewer. Version 0.5 changelog: -reads SF1 and FE2 cat files -reads DLC files -copy 3D coordinates to clipboard (press key 'c' while the 3D view window has the focus) -case insensitive hitbox node names LODViewerUpdateV0.5.zip

Screenshots of my new project: Target Area Editor. Currently it only has viewing (and no editing) capabilities.

You can try to change the video card settings (especially the texture filtering settings). Is the game engine case sensitive? And if not, should I change it in LODViewer?

Directx version doesn't matter. LODViewer don't depend on Directx it uses OpenGL. Regarding your test results: I can not understand why this happens. I changed the texture generation routine in version 0.2. But some users (e.g. Raven) got black textures with the 0.2 version. So with version 0.2.1 I changed the texture routines back to version 0.1. But for you version 0.1 and 0.2 work and 0.2.1 and later not. But I see no difference regarding texture handling between version 0.1 and 0.2.1. From version 0.2 and later I compiled the lodviewer with xp support. Maybe thats the reason. Although verson 0.2 works for you. Anyway, I don't believe the xp support is the cause but here is version 0.4 without xp support: LODViewerUpdateV0.4_noXP.zip