Jump to content
COMBATSIM Forum
Krycztij

TFXplorer

Recommended Posts

This is just an idea, but as the .3 format is such a pain to work with, I was wondering whether we could mix in another format in TFXplorer? For instance, there is already a brilliant VRML renderer out there which I'm sure could be grafted in.
f16vrml.png.72d02ae5b3a1167cf41bfd7b0a8fd67b.png

These started out as .osg files, then converted to .wrl via .3ds.

Share this post


Link to post
Share on other sites

I’m absolutely already working on this, but VRML import will start with terrain.

 

Reason: We need to consider …

  • animations/bone structure – for control surfaces or if you want to animate landing gear extension
  • sensors/hotspots – you probably want to mark missile spawn positions and button positions right in the plane/cockpit mesh instead of entering the coordinates into the program code

… and I have not investigated how good or bad VRML is with that. Terrain is much easier, so we’ll start there.

 

Short roadmap:

  1. finish the contrail/weather system
  2. finish the LOD system
  3. properly disable the autopilot I had started working on
  4. fix the torque computation (it’s fundamentally flawed, but I don’t know where, and that’s a very bad thing to build a game upon) 
  5. implement heightmap in VRML loader
  6. implement VRML loader into TFXplorer terrain handling

I haven’t done much in the last months, so it’s a long way. At least I had half an hour of spare time yesterday and I added impulse to bullets. I.e. the Shilka shakes when firing and the bullets shake the plane upon impact (albeit very very little).

 

Share this post


Link to post
Share on other sites

Ah, you've already noticed the synergy between Lean Viewer and TFXplorer. :)

 

From what I have seen of the rather crap official VRML documentation, you can do 'anything' with it, and extend it if 'anything' isn't enough.

A good idea to start with the terrain though...

 

I'll try some experiments as time permits.

 

Share this post


Link to post
Share on other sites

Mike,

 

last thing I remember about your VRML terrain experiments is that ElevationGrid was the perfect node for our purpose, but ironically it was one of the few node types Lean Viewer couldn’t understand yet.

 

Are you still working with the terrain? I’ve got a new Lean Viewer version which displays ElevationGrid just fine; if it’s of any use to you, I’ll upload it …

Share this post


Link to post
Share on other sites

Not that I've looked at it too much, but if we just wanted to convert TFX data then the 'IndexFaceSet' would be the way to go. The 'ElevationGrid' is a subset of that but assumes a regular xz grid. The 'ElevationGrid' is much better suited to high resolution terrains, and there's more chance of reusing raster heightmap data that might be in the public domain.

We're looking at a monster amount of data if we want to recreate a TFX sized world with unique tiles though.

 

tl;dr Yes, please upload it!

 

 

 

Share this post


Link to post
Share on other sites

Here it is: https://app.box.com/s/u1usy05kkraremqvo8lo5ru58r89jfyz

 

Many, many unfinished things in this version, so please don’t complain if lighting/texture things don’t work well. At least it shouldn’t crash.

 

Changes since last version:

  • now supporting VRML 2 “ElevationGrid”
  • now supporting BMP/GIF/JPEG/PNG/TIF textures; removed support for other texture formats
  • now supporting STLs exported from “3D-Coat”, “3Shape”, “Adobe Photoshop”, “Anarkik3D Design”, “BRL-CAD”, “CATIA” (German), “Cheetah3D”, “3D Systems Cube”, “3D Systems Cubify”, “AutoDesSys form·Z”, “SpaceClaim”
  • changed error screen to error icon
  • scene graph root now always starts expanded
  • fixed crash with VRML 2 “Extrusion” with more than 2³² vertices
  • fixed memory leak with damaged VRML files
  • fixed errors if VRML geometry has more than 65,535 vertices
  • fixed memory leak resizing the viewer with no file loaded
  • fixed ASCII STLs with “end solid” oddity
  • fixed names in multi-object STLs
  • fixed flipped STL colors with “Meshmixer”
  • fixed multi-object ASCII STLs without proper “endsolid” markers
  • fixed duplicate error messages on rare occasions
  • fixed detection of short STLs
  • fixed a rare crash during error handling
  • fixed a crash with very long filenames
  • fixed warning “missing object name after 'endsolid'”
  • fixed crash with infinite coordinates
  • fixed crash with extremely large files
  • fixed display of 2D STLs
  • fixed high-DPI display
  • fixed “DesignSpark” detection
  • fixed object names in ASCII STLs
  • fixed flipped STL colors with “VisCAM”
  • fixed possible crash with very small ASCII STLs
  • fixed “Textures” and “Lighting” menu items
  • fixed “Exit” hotkey
  • fixed tab order
  • fixed ellipses in menus
  • fixed ellipsis in title with long names
  • fixed centimeter scaling in ArchiCAD STLs
  • fixed black Autodesk Inventor STLs
  • fixed Art Of Illusion STL metadata
  • fixed STL materials
  • minor performance improvements

Share this post


Link to post
Share on other sites

Thanks! As usual, the first example I tried might not have been a good one...
VRML 2 error: missing floating-point literal; aborting

 

#VRML V2.0 utf8
Transform { children [
  Shape {
    geometry DEF EG ElevationGrid { 
      xDimension 5
      xSpacing 1
      zDimension 4
      zSpacing 1
      height [          # 5x4 array of heights
        0 .707 1 .707 0
        0 .47 .667 .47 0
        0 .236 .33 .236 0
        0 0 0 0 0
      creaseAngle 0.8
    }
    appearance Appearance { 
      material DEF M Material { diffuseColor 1 1 1 }
      texture DEF IT ImageTexture { url "marble2.gif" }
    }
  }
  Transform {
    translation 4.3 0 0
    children Shape {
      geometry ElevationGrid {
        xDimension 5
        xSpacing 1
        zDimension 4
        zSpacing 1
        height [          # 5x4 array of heights
          0 .707 1 .707 0
          0 .47 .667 .47 0
          0 .236 .33 .236 0
          0 0 0 0 0
        ]
        creaseAngle 0.8
      }
      appearance Appearance {
        material USE M
        texture USE IT
        textureTransform TextureTransform { scale 1 -1 }
      }
    }
  }
  DirectionalLight { direction -0.80 -0.6 0 }
  Viewpoint { position 3 2 8 }
  Background { skyColor 1 1 1 }
]}

 

Share this post


Link to post
Share on other sites

Line 14, just before creaseAngle, you’re missing a closing square bracket.

 

I will add line numbers to errors (and probably opening a text editor when double-clicking the error). It has been annoying me for so long. It just requires lots of testing (all errors and warnings need to be re-tested), that’s why I procrastinated it.

Share this post


Link to post
Share on other sites

That was pasted from a VRML reference book, so doesn't bode well for the rest of the information it contains...

Apologies for assuming that your viewer hadn't implemented something in that file.

 

A lot of STL stuff in that change list. Are we planning on fabricating a real F22? :D

Share this post


Link to post
Share on other sites

Lean Viewer is currently unfinished and its code base too fragile to use in mission-critical environments, so I moved the STL code into a separate project.

 

This has reached production quality and everything I fixed along the way was also fixed in Lean Viewer, since they share their STL code.

 

The next step is bringing Lean Viewer to production quality, but boy this will take time. (Not just of VRML, there’s major UI decisions unsolved.) I’ll probably bring VRML to production quality, release STL+VRML as a separate project, and later merge in the image file formats and other stuff from Lean Viewer.

Share this post


Link to post
Share on other sites

That STL viewer looks great!...and a bit familiar.

 

STL is still used a lot in the 3D printing world, so is still very relevant. VRML not so much.

I'd imagine that VRML is more 'complicated' than STL, and getting 100% compliance might not be worth the effort. It's not my effort though. :)

 

By the way, in the brave new 'App' world of Google, etc. the concept of 'production quality' doesn't exist in any meaningful way.

So it's nice to see there's a  bit of integrity left in the SW development world. :thumbsup:

Share this post


Link to post
Share on other sites

STL is still the primary 3D printing format, yes.

 

VRML is very rarely used, that’s also true. It was once planned for the WWW, then some printer manufacturers recycled it as 3D printing exchange format because it supports colors better than STL. (I don’t know why they chose VRML specifically – it’s the worst choice in every possible aspect. Probably the same conspiracy that made my phone run on Java?)

 

One of my clients explicitly needed VRML import, and the code is 95 % done. Now I can just as well finish it and distribute it – it can’t become less useful than it is now, sitting on my hard drive for nothing but TFXplorer :) Along the way, I noticed that there is not a single decent VRML import (even the reference implementation has horrible security flaws), so I might as well do better.

 

Luckily, VRML is slowly being replaced by OBJ. That’s even older, but at least it doesn’t have this nightmarish omnipotent scripting/interaction bloat. It’s also very common in games and animation, so this will be my next implementation, hopefully this summer …

 

17 minutes ago, mikew said:

By the way, in the brave new 'App' world of Google, etc. the concept of 'production quality' doesn't exist in any meaningful way.

So it's nice to see there's a  bit of integrity left in the SW development world. :thumbsup:

 

I’m running my STL viewer through more than a hundred thousand random STLs from thingiverse and get more than 99.9 % compatibility, that’s a level of quality assurance I haven’t seen with any CAD software (why not, by the way?).

Share this post


Link to post
Share on other sites
On 1/26/2018 at 5:10 PM, Krycztij said:

I’m running my STL viewer through more than a hundred thousand random STLs from thingiverse and get more than 99.9 % compatibility, that’s a level of quality assurance I haven’t seen with any CAD software (why not, by the way?).

Everybody storing their work on the internet, and thus making it available to everyone else (including CAD SW developers) is a relatively recent phenomenon. While I don't see it happening anytime soon, there may be a backlash against being online. Since nobody else makes standalone programs anymore, you'll be pole position for all the work if that happens. :)

 

From my point of view, I can only hope that the code for your viewers can be reused in TFXplorer. From what I can see, VRML could be used to define the entire map but I see it as a means to store equivalent information to the .ssd and .3 files in a non-XML text form. Since you're already working on a viewer, this puts it ahead of similar formats like .ac, .obj, .osg etc.

 

Anyway, back to TFXplorer. Is there any quick way to disable the sim part so we just have a terrain viewer? Specifically, I'd like it to not try and load the F22 model data when it is not needed.
I'm sure I've asked this before, but don't remember why not.
 

Share this post


Link to post
Share on other sites
33 minutes ago, mikew said:

From my point of view, I can only hope that the code for your viewers can be reused in TFXplorer.

 

Yes, TFXplorer already uses Lean Viewer interfaces for loading the moving map ILBM.

 

32 minutes ago, mikew said:

Anyway, back to TFXplorer. Is there any quick way to disable the sim part so we just have a terrain viewer? Specifically, I'd like it to not try and load the F22 model data when it is not needed.
I'm sure I've asked this before, but don't remember why not.

 

The only way to disable the F-22 model (i.e. its .3 shape and .ssd supershape) is to replace its entry in the shape lists (ssinfo.fn etc.) with something different.

 

Currenlty, TFXplorer loads all data upfront at startup, no exceptions. This avoids problems we had with ADF/TAW where you’d run the game for some minutes and suddenly a specific model entering sight would break the game and we had no clue which exact model was the cause. It also simplifies engine architecture because nothing can fail in the rendering loop (there is just no need to check for failure when you did that during loading).

 

I see that this is a problem because it doesn’t scale well. When I designed it, it seemed that TAW’s terrains were all we ever needed. Then came large terrain, now comes Earth-sized terrain with HD graphics. Obviously we can’t have it all in RAM at the same time, but boy will it be an effort to get the on-demand loading right …

Share this post


Link to post
Share on other sites

Ah yes, I think we're stuck with the ssinfo.fn shape list. Now I remember making a combined TF1/2/3 ssinfo.fn for that 'TFX1 in TFX3 format' exercise I did a year or so ago.

While TFXplorer notes in the console that a shape is missing (and there are a lot missing in that combined list), it doesn't crash at startup. The sim part needs f22.ssd, c747.ssd etc, and it will complain if they are not there.

 

The plan was to look at world development again. If I had a world with just sea. I should only need sea.ssd, sea.3 and a texture together with the level files.

Since I don't know exactly which TFX3 ssd files are needed for the sim, it's easier to copy over the entire TFX3 ssd/3 directories every time.

 

Not a big deal, but backing up my memory stick with lots of directories with thousands of small files in each takes a long time.

It's my fault we don't have a flexible way to pack a file set though...

 

Share this post


Link to post
Share on other sites

Mike, could you test this?

  1. SHIFT+Q, X for explorer mode
  2. go to such a plane
  3. reduce your viewing range to minimum (repeated S/X)
  4. use the numpad to move far away from the plane, until it is far out of sight
  5. use the numpad to move closer again
  6. there should now be two planes in its place
  7. repeat as often as you like, always adding another plane
  8. switch to game via F5, all planes but one should disappear

If it reproduces, then it’s a problem I have already fixed for the upcoming version.

 

It’s because the simulation adds random planes when a traffic route comes into sight, and it should remove planes when the traffic route leaves sight. But I can’t remove the planes directly, because some events (e.g. collisions) depend on them. So I wait until all events are processed (when the current simulation step is complete). But the simulation is stopped (you’re in explorer mode after all) and so nothing is processed and the planes are not deleted at all.

 

Until the simulations proceeds via F5.

 

Simulating a vivid world is a complicated mess :)

Share this post


Link to post
Share on other sites

Yes, that's pretty much what happens. The extra planes disappear on F5.

If I enter the sim, then immediately go to explorer mode, then find some planes, there are sometimes already 5 in a row.

Strange that I haven't seen this before, but good that it's already fixed. :thumbsup:

Share this post


Link to post
Share on other sites

I keep seeing these purple balls around the TFX1 terrain

purple_ball.png.0af51fcaee312cd43f7962ebb2cd7259.png
...then noticed they were associated with white dots.

purple_ball2.png.287c719a583cc8ceb8f8a8d43a8055b7.png

So, I assume that's heavenly.3

What it's doing in my terrain, I have no idea. :)

Share this post


Link to post
Share on other sites

Your diagnosis is correct :) From a quick search, it doesn’t seem that heavenly.3 is hard-coded in TFXplorer, so it seems to be sneaking in some way else. I removed all occurances of it when I replaced TAW’s stars with my own stars, but the code is such a mess that errors on my side are likely.

 

Do you see them as well if you open the SSD in 3View?

Share this post


Link to post
Share on other sites

Ah, it was a long shot thinking TFXplorer may be to blame. :)

 

So, for those tiles, one of the called shapes must be using heavenly.3's index number.

This goes back to what I did a year ago, which was to identify all the used shapes in TFX1 and TFX2's terrain ssd files. Then I joined together the ssinfo.fn files for the three games.

Finally, I offset all the indices in the TFX1 and TFX2 ssd files to match the new positions in ssinfo,fn and changed the texture indices in  the TFX2 and TFX1 .3 files.

 

After copying the TFX1/2 supeshapes, shapes and textures into the TFX3 directories, I have one big file set which I this week packed into a single did.dat (except for the lev/ folders).

Somewhere in this process, it seems that at least one number is wrong. :(

Share this post


Link to post
Share on other sites

TFXplorer should just see this as a TFX3 level unless there's some flag I'm missing. All the lev/files have 'redsea' names.

It's just strange as it's the only obvious shape mapping problem that I'm seeing. It could do with being fixed as it's really distracting in Yugoslavia which has the highest building density I've seen in any of the maps. All the stars produce a nice snow effect though. :)

Share this post


Link to post
Share on other sites

Interesting. I have hard-coded explosion animations and craters, but these shouldn’t normally appear in levels.

 

Heavenly.3 is at index 2. 2 is a common value; could be uninitialized data.

 

Can you reproduce it by opening the according supershape in 3View?

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×