mue

I have no plans to write a converter. The LODViewer is in fact a first step to a bigger project. For me it helped me to get familiar with the Qt-Toolkit and to see if I can display LOD objects with textures via OpenGL. The bigger project will be a target area editor. With this program it should be possible to place target objects interactive into the 3D scenery (inclusive displaying of TODs and tiles). But before I start with the target area editor I work on an update of the LODViewer. Unfortunately my free time is limited, so please be patient!

Ok, I need your help. To get the texture file handling in the next version of the LODViewer right I need information about how and in which order the game engine is looking up texture files. This is what I think to know: First the game searches in the texture directory specified by "Directory" under [TextureSetXXX] in <LOD>.ini. It searches for the texture file specified in the lod file (eg. fuselage.bmp). If it's not there then its looking for texture files with the same name but different extensions/types (eg. fuselage.jpg, fuselage.tga, ...). Does anybody knows which file formats the engine supports? If a matching file is still not found then the game searches the directory in which the *.lod and *.ini files reside. If there is also no matching file then the game is searching in the *.cat files. Can someone please confirm this or correct me otherwise? Thanks!

I don't know the rotation behaviour of 3dmax but I can descibe what my program does: In the default position the rotation center is the center of the objects bounding box. But this rotation/view center is changed by view translation (right click + move) along the current view axes. The rotation is always around the current view center either around the current horizontal view axis (left click + moving up down) or the vertical view axis (left click + moving left right). I don't know exactly what an UV viewer is. Is it drawing of the mesh on the bitmap like this: Then the answer is yes, it can be done. A texture reload button is on my todo list. As a workaround you can reselect the texture directory in the combo box (if the directory is shown there) for reloading the textures. I don't know yet. I will try to make the next version XP-compatible. Theoretically it should be possible. But I don't know if it's beneficial to the community. Not everybody wants that his 3D work is converted and used/altered by others. But I don't know how the community thinks about it. I'm only guessing here. I think more beneficial would be exporter for free/cheaper 3d designer applications like blender. But for writing an exporter one has to know the complete lod format. And I still don't understand parts of the header and the material description :-(

First, Sorry for the inconvenience regarding the file hoster. Because of the upload limit (1 MB) on combatace.com I couldn't upload the 7 MB zip file. So I used a random file hoster. Of course I tested the download link. And this is what I get: One simple button for download. No ads. I found that ok. So I couldn't believe that you guys get popups, malware warning and the likes..... Eventually I figured it out: I have an adblocker browser addon installed and you probably not. So I tested it with the adblocker disabled: Two more download buttons, that are actually ads and link to malware crap. Once again, sorry!! Regarding your problems: If texture folders are not selectable, that probably means the ini file couldn't be read. The program assumes the ini file of the same name as the lod file. But it seems thats not always the case. The feature "File->Open the ini file and then the program opens the referenced lod file" is on my todo list for the next version. Regarding problems with textures are not shown: Either... the program couldn't find the files: the programm is file extension/type sensitive. E.g. if the lod file references "texture.bmp" the file has to be "texture.bmp" and not "texture.jpg" or "texture.tga". Probably the game engine is file type insensitive, right? So its on my todo list. Or... the format couldn't be read. I know of problems with some tga files. How is the additional lod referenced? In the ini file? Can you give me more details, please.

I wrote a tool that someone may find useful: a LOD viewer. I tested it on Windows 7 and 8. Unfortunately it doesn't run on Windows XP. From the readme.txt: LODViewer Version 0.1 Author: mue Use at your own risk. The program is free for personal, non-commercial use. Usage: LOD files are loaded with File->Open... The program also tries to read the ini file with the same basename (eg. tank.lod -> tank.ini) for textureset information. The texture directory can then be selected via the texture directory combo box. If no ini file is found or it does not contain textureset information then the texture files are assumed in the lod file directory. The left upper window shows the node structure: node names and material ids. Nodes can be selected with left click and deselected with ctrl+left click. The lower left window shows the texture file names of the materials. The right graphic window displays the 3D view of the lod object. The view can be manipulated with the mouse: rotation: left click + move translation: right click + move zoom: mouse wheel reset view: middle click Nodes can be selected with ctrl+left click, and deselected with ctrl+left click on a blank area. Selected nodes are highlighted in red. Nodes whose texture couldn't be read are displayed in green. Known issues, missing features, bugs: -simplistic lighting (no specular, glossiness, reflection, bump mapping,...) -no transparency -no decals -problems with reading some tga files Screenshot: (Download link temporarily redacted)

For aircraft objects the maximum drawing distance is limited to 6.7 nm. See here: http://combatace.com/topic/82507-some-tests-regarding-aircraft-drawing-distances/ I don't know if ships fall into this category. But for target objects the maximum drawing distance can be increased. You have to change "MaxVisibleDist" in <terrain>_types.ini and (LOD) "Distance" in <targetobject>.ini . See here: http://combatace.com/topic/81464-increasing-the-view-distance-of-target-objects/

The only missing/unknown parts are the exact format of the shadow data and the 8 bytes after the object center position (These 8 bytes were alway zero btw.). I think with the current info it should be possible to write a tod editor (at least for non shadow casting objects). While I played with the terrain editor I found the following: If I placed y-trees on a tile the terrain editor created a tod file, whose format didn't matched my findings. So my question is: Has anyone created a tod file with y-trees? And does this tod file work in the game engine?

Some updated information about the tod file format: number variable type description of bytes 4 integer number of solid objects 4 integer number of alpha objects n objects data (see below) for each object: 4 integer chance in % (probability of appearance) 4 integer number of vertices 4 integer number of triangle vertices = 3 * number of triangles 4 integer number of triangles 32 * number of vertices vertex data (see below) 2 * number of triangle vertices triangle data (see below) 4 integer 0 = don't cast shadow and no shadow data follows, 1 = cast shadow and 292 bytes shadow data follows 0 or 292 73 floats ? shadow data (8 vertices + additional information) ? 4 float object width / 2 4 float object length / 2 4 float object height 4 float rotation angle around z axis (in radians) 4 float max. horizontal extension / 2 4 float object center position x 4 float object center position y 4 float/integer 0 ? 4 float/integer 0 ? for each vertex 4 float position x 4 float position y 4 float position z 4 float normal x 4 float normal y 4 float normal z 4 float texture coordinate u 4 float texture coordinate v for each triangle 2 short integer vertex index 2 short integer vertex index 2 short integer vertex index

Is the 100% probability always used for tod objects or are there also tod objects with a probability other than 100%? I ask because a for me unknown data in the tod files always has the value 100, so maybe this data is this "chance" value.

By the way, what das "ObjectXXX.Chance=100" in the tod.ini mean? Back to the tod format: I wonder why the object dimension, angle and position are in the tod file. For display purposes the vertex and triangle data should be sufficient. Probably for height adjustment in the terrain or for collision detection? Are tod object collidable or destroyable?

Sorry, I don't understand what you want to say? There is no difference between stock and modded TODs. Both have the same format. Both are created by the Terrain Editor and can be read by the game engine. The object coordinates can be read from the TODs. In the format description above I named them "object center position x" and "object center position y".

You may find this helpful. I opened a new topic: http://combatace.com/topic/84706-tod-file-format/

For those who may be interested... this is what I found out about the tod file format. Maybe someone can help me to fill the gaps. number variable type description of bytes 4 integer number of solid objects 4 integer number of alpha objects n objects data (see below) for each object: 4 integer ? 4 integer number of vertices 4 integer number of triangle vertices = 3 * number of triangles 4 integer texture id ? 32 * number of vertices vertex data (see below) 2 * number of triangle vertices triangle data (see below) 4 float ? 4 float object width ? 4 float object length ? 4 float object height ? 4 float rotation angle around z axis (in radians) ? 4 float ? 4 float object center position x ? 4 float object center position y ? 4 float ? 4 float ? for each vertex 4 float position x 4 float position y 4 float position z 4 float normal x 4 float normal y 4 float normal z 4 float texture coordinate u ? 4 float texture coordinate v ? for each triangle 2 short integer vertex index 2 short integer vertex index 2 short integer vertex index For testing purposes I extracted and displayed the object meshes from the vietnamC1.tod and vietnamG1.tod files (I think from the vietnam expansion pack). See the pictures below.

I tested the patch level Jul 2013 and I definitely notice the limit at 6.7 nm. Probably you remember older patch levels without this limit?

Lately I read in the forums some complaints about the too short drawing distance of aircraft in sf2 and how it is not moddable. So I decided to make some tests. My test setup: Screen resolution: 1920 x 1080 Game graphic settings: unlimited (horizon setting: very far) Strike Fighters 2: Vietnam (Jul 2013) I used two different aircraft: B-52D and MiG-17. I made the tests with three different zoom levels: gunsight view (fov = 30°), normal cockpit view (fov = 60°) and wide cockpit view (fov = 90°). Further, I varied the LOD005 Distance settings in the <aircraft>.ini . In the following tables you can see the distances at which I could spot the aircraft: aircraft: B-52D fov: 30° 60° 90° LOD005 Distance: 24000 (stock) 6.7nm 6.7nm 5.3nm 30000 6.7nm 6.7nm 6.7nm aircraft: MiG-17 fov: 30° 60° 90° LOD005 Distance: 10000 (stock) 6.7nm 3.8nm 2.2nm 20000 6.7nm 6.7nm 4.4nm 30000 6.7nm 6.7nm 5.1nm I came to the following conclusions: 1.) The maximum drawing distance is locked at 6.7 nm. And this can't be exceeded by increasing the LOD Distance settings. (Ok, that's nothing new. It was already described here: http://bbs.thirdwire.com/phpBB3w/viewtopic.php?f=5&t=8850 ) 2.) With stock LOD Distance settings the drawing distances for fighter aircraft in normal and wide cockpit views are very short. But you can increase the drawing distances in normal and wide cockpit views up to the 6.7 nm limit by increasing the LOD Distance settings. Of course, you will not see the aircraft unless it has the projected size of at least one pixel. Because of that I saw the MiG-17 (with fov = 90°) at 5.1nm and not 6.7nm. (Mathematical backing: An object that appears on the screen as a single pixel has the distance = (object size * (screen resolution width / 2.0)) / tan(fov / 2.0) With object size = 10 meter (MiG-17 wing span and length), fov = 90°, resolution width = 1920, the distance is 9600 meter = 5.2nm. That matches my observation.) Overall, apart from the 6.7nm limit, it seems the rendering is not that unrealistic.

I have the following problem: Target objects are shown only if I'm very close to the objects. Moreover the distance where the objects appear depends on the field of view (fov). The most time I use a fov of 90 degrees. With a smaller fov (= zoom in) the maximum view distance of the objects is greater. Take, for example, the (stock) warehouse in the range terrain: With fov = 90 deg the warehouse appears at ~3 nm, with fov = 60 deg it appears at ~5 nm and with fov = 30 deg it appears at ~12 nm. At fov = 90 and 60 deg I think the maximum view distances are way too small. The only solution I found to increase the maximum view distance is changing "MaxVisibleDist" in <terrain>_types.ini and (LOD) "Distance" in <targetobject>.ini. But it's a little bit tedious to change every single object. For the warehouse I set in range_types.ini "MaxVisibleDist" and in warehouse1.ini "Distance" both to 60000.0 Now the warehouse appears with fov = 90 at ~9 nm. Thats ok for me. Does anyone know how "MaxVisibleDist" and "Distance" result in actual maximum view distance at a given fov? Is there an easier way to increase the view distances, without changing every single object?

Thank you! It works. No tree-sized buffalos in south vietnam anymore :-)

I've got the same error (tree-sized water buffalos) but only in the South Vietnam terrain. The SF2V Expansion pack has two terrains: North Vietnam (VietnamSEA folder) and South Vietnam (SouthVietnam folder). I just copied the GH3.5 files into both terrain folders. With the North Vietnam terrain it seams to work but with the South Vietnam terrain it does not. Does anyone know what I've done wrong? Or is GH3.5 not compatible with the South Vietnam terrain?