mue

Thanks for the bug report. I investigated the issues and that are my findings: SH-3D issue: The lodviewer scales and positions the 3D view depending on the bounding box of the lod object so that the entire area of the bounding box (and therefore the entire lod object) is displayed. In the SH-3D lod there are two nodes whose z coordinates are "out-of-the-way": RescuedGuy with z coordinates around -44000 and FoldingRotor with -100000 (maybe a fault in the lod model?). Thus the resulting bounding box has an extent of over 100000 meters and the resulting view is extremely scaled down (zoomed out). A possible solution could be to add a view option that excludes hidden nodes from the (view scaling) bounding box calculation and let the user select and hide the problematic nodes. What do you think? Sea Stallion issue: These lods contain an animation type I haven't seen before. I will try to reverse engineer that animation type format too. I can not promise to understand and display that animation correctly but at least it should be possible to prevent the lodviewer from crashing.

Yes: http://combatace.com/topic/86103-fading-tod-objects/

And don't forget to set ObjectsFade=false in options.ini. For this mod to work the stock built-in fading function must be disabled.

It seems, my todo list is getting longer and longer... Currently I don't plan to implement joystick input. But I'm curious: What should the joystick input do exactly? What are your system specs? Does it happen with all lod files? Is your graphic card driver up to date?

Sorry, a new version is not ready yet. The last weeks nice weather kept me away from (non-work-related) programming activities. But I'll continue to work on the target area editor soon.

It's an RGBA color code. The 4th value is the alpha channel. The value ranges from 0.0 (full transparency) to 1.0 (full opacity).

The tod objects are defined in the *.tod files. I reverse engineered (most of) the tod file format: http://combatace.com/topic/84706-tod-file-format/ In theory the tod file format allows arbitrary object meshes (not only rectangular blocks). Unfortunately TWs terrain editor only creates rectangular blocks. Therefore, to create other tod objects than the rectangular blocks one has to write his own tod file generator/editor for creating the tod files. It's on my long-term todo list...

Have you in Extras->Settings set the correct path to the SF2 install directory?Do you run the latest SF2 patch level? Do you have an ATI graphic card? Some users with ATI cards have problems with my programs. I still try to figure out where the bug is.

Strange... Only recently I noticed that SF2/FE2 support 4 (or 5 if one counts the zoom axis) DOF with TrackIR. I always thought that SF2/FE2 support only 2 DOF (pitch and yaw), therefore I had only pitch and yaw enabled in my TrackIR profile. By accident, I watched a SF2 video on youtube and I was quite suprised to see the cockpit view shifting left and right. So I googled "6DOF trackir sf2" and the first hit was a link to a combatace.com thread that mentions to add/configure the following entries in the [CockpitSeat001] section in the <aircraft>_cockpit.ini to allow larger lateral head movements: MinMovementX=-0.1 MaxMovementX=0.1 MinMovementZ=-0.1 MaxMovementZ=0.1 It seems that SF2 didn't have those entries per default, but FE2 did. Anyway, now with 4DOF enabled I can see the runway better while landing. The lack of visibility ahead while landing has always bothered me.

Yes, maybe it's worthwhile to have a closer look at the FE2 inis. I'm curious...could it be that the 4DOF support came with FE2 into the thirdwire game engine? BTW, the info I mentioned in my post is from your post: http://combatace.com/topic/83894-trackir-6dof/?p=674605

I see you have an ati graphic card. I know of (a few) other people who have graphic problems with my programs (lodviewer / target area editor) and ALL have ati graphic cards. Unfortunately I haven't found the cause of the graphic problems yet.

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..."

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.

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/