Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Krycztij last won the day on February 5

Krycztij had the most liked content!

Community Reputation

3 Neutral

About Krycztij

  • Rank
    Brig. General
  • Birthday 09/05/1981

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Krycztij

    Stealth: A retro-style F117A simulator

    So I guess it didn’t work out with PPJohn from SimHQ?
  2. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    Let’s not care about the practical part – the VRML will be preprocessed and cached as a binary file. Let’s just make the most out of it, and your work is just stunning!
  3. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    The current look of EF2000/ADF/TAW in TFXplorer will be preserved 99 % after the transition. I try to not break anything. I had to remove the canopy reflections, but that’s it. I would love to make a big leap straight away. Consider that terrain is logically separate from vehicles (planes, ships and tanks) – we can proceed with TAW’s F-22 cockpit chasing TAW enemies in a VRML-powered terrain of our choice. Make it a point list with emissive material. Lean Viewer doesn’t support points yet, but it will. Consider streets preliminary. I’d love to have OpenStreet import and fill the streets with a million cars (that’s four million lights, isn’t it?) and this requires special case handling for streets, probably procedural generation of streets, street lights and bridges along predetermined paths. Until we get there, just place some bright points for street lights. Still better than TAW’s
  4. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    I misunderstood, sorry! If you want to preserve as much data as possible, how do you want to add dynamic lighting? Imagine: A building has a bright texture at day … and a dark texture at night At night, something explodes right next to it and casts orange light on the building … but the building’s texture is dark, so there is no effect. It’s just dark under all circumstances. I would just always use the bright day texture and let the engine darken the lighting at night, not the actual texture. (Lights are a different beast. If it’s a lit area, put that into the material’s emissive component. If it’s building lights etc, we make a separate texture, e.g. with _EMISSIVE prefix and the engine will treat it automatically. I did that here, for example.)
  5. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    Windsocks and parachutes are a very difficult corner case, and I don’t know yet how to handle them properly. Please just skip them for now. Some of TAW’s other models have moving/rotating parts: The turret of the Shilka, or some antennas on ships, and so on. If you find any way to do it, please … isolate the moving parts into a separate object do not store the entire rotation animation; just store the first frame if you have any hint at the axis or origin of the rotation, move the coordinate origin of the sub-object to this point To be honest, I’m not quite sure how to accomplish all that, but that’s what we need … The slowdown is due to the CPU making decisions during drawing: Are we on side XY of the model? Then draw this polygon first then that and skip the other one. After five or six polygons, a similar decision, and so on. The GPU expects a contiguous stream of polygons, but if we skip a polygon, then the stream is not contiguous any more. So all later polygons must be moved to an earlier position and close the gap. This can only be solved with at least one copy per polygon, and this takes ~200 cycles (not counting the overhead for decisions like “what time of day is it”, “how far away is the shape”, and – worst – “on which side of a plane defined by three points are we” (for Painter’s algorithm). At 200 cycles per polygon, you can quickly estimate an upper limit for smooth rendering: 3.2 GHz CPU @ 60 fps makes 53.3 million cycles per frame, so we can’t ever surpass 266 thousand polygons/frame. Assuming 100 % CPU for rendering and 0 % for gameplay here. On modern systems, it’s best to not invoke the CPU at all. Rule of thumb is, if the model has less than thousand polygons, don’t even try to check visibility on the CPU because this visibility computation will likely eat more time than the GPU needs for rendering. Just render it. (Exceptional is excessive material/shader use, e.g. each of the 1000 polygons using a unique material, but that’s rare.) That’s why we need one complete set of polygons per object and per LOD. Just let the GPU handle it. (Lean viewer renders everything blindly and without CPU interference, and it gets ~1000× TFXplorer’s polygon count.) Same for moving/rotating parts: Let the CPU only change the rotation matrix (16 values) and let the GPU rotate thousands of vertices to the new position (because GPUs are pretty good at that). That’s why I only want one indexed triangle set per moving part, and not TAW’s stuttering animation: We’ll just change the matrix and the part will move smoothly and with high efficiency. And as soon as that works, we’ll add Skeletal animation.
  6. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    No, don’t use ROUTE. Apart from not being supported by Lean Viewer, that’s exactly what made TAW so slow and it would make your new terrain just as slow! The Python VRML library is interesting. I will take a look in the future …
  7. Krycztij

    I see we got a new paint job and all new emojis

    See https://stackoverflow.com/questions/9626115/color-in-the-unicode-standard . Win 10’s font rendering is more sophisticated and focused on hip mobile chat apps, so its emojis are more colorful. (You should try with a Mac.)
  8. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    I don’t have an alternative to Visual Studio either. Eclipse is very clunky and buggy IMHO. I’m forced to use Qt Creator at work, and it has some advantages over Visual Studio (source code browsing/refactoring is easier) but you have to configure a lot regarding makefiles and stuff. (Thumbs up for Dev-C++, if I hadn’t found it in 1999 or so, I would probably never have started programming.) Please keep the LODs; there is an LOD node in VRML. Samples here, but remember that I don’t support “inline” so you’d place (or USE) your IndexedFaceSet there. Lean Viewer does not automatically support LoD, but you can select individual levels to display by double-clicking them in the scene graph. (If I’ve done it right, it should only ever display one of them at a time.)
  9. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    Yes, it’s very user-offensive. My „trial“ license runs out tomorrow so I’ll have to enter an email address 😞
  10. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    From my memory, it should map to meters. But also from my memory, it should have been 1024×1024 units in the VRML file. I’m confused and I don’t find my notes on the experimental checks, so I’d like to withdraw my statement …
  11. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    I always try to be as compatible as it comes with the vanilla data. There’s always the uncertainty of whether our project will be banned somewhere *cough SimHQ cough* if we deliver our own TAW-based content instead. Yes I recognized it ❤️ Regarding scale, because this will certainly be a problem: When I last checked, the tiles were ca. 1024 m wide (should be 420 TFX units). This must be a giant building.
  12. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    Yes, absolutely. This dependency on Painter’s Algorithm is the main performance bottleneck because it can’t be done in hardware and doesn’t scale with cores. Lean viewer’s thing is called depth buffering and TFXplorer uses it as well, but in a very limited scope to avoid problems with TAW’s geometry. The future VRML-based terrain will use depth buffering exclusively.
  13. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    I love it, no matter what the texture 👍
  14. Krycztij

    TAW 3View — A Renderer for TAW's .3 Files

    Linux is actually a common request for my software, from something like 5 % of users. So I seek to enhance compatibility wherever I can, and I welcome and value your information FYI: You can set render states in D3D 11 to NULL to trigger default behavior. E.g. set depth-stencil to NULL and you get default Z buffering with "pass if closer" Z test. This saves me a dozen function calls where others pass explicit parameters. It’s easy to overlook in the documentation and I’ve never seen anyone else do it, so I suspect early Wine missed out on it and this resulted in a mis-configured render pipeline. Anyway, I hope to improve the lighting situation soon. There will be no hard-coded shadows in TFXplorer’s custom terrain. It will be computed from directional light, just the way it’s meant to be. Don’t waste your time on shadows. Still very slow progress and short on time, though.