zlacker

Bumped into your project a while back - pretty impressive. I was a little disappointed it seemed to just convert the resources rather than use the original runtime formats (since there are a features that don't directly translate to gltf), but for a viewer it's perfectly reasonable. Are you planning on supporting tribes 1 maps at all? Theres still quite a surprising interest in reverse engineering and extending the life of torque games. I'm hoping on publicly releasing a refresh of the original torque codebase this year which improves support for modern platforms including wasm. It's amazingly easy these days to reverse engineer stuff and revive old codebases!

>>jamesu+(OP)
It would be possible to have it decode the .dts and .dif formats on demand - that was my original plan - just much less efficient, as the .glb files are about 1/5 of the file size on average. (I also assume glTF loading/rendering has had a lot more optimization work put into it than what I'd be able to accomplish.) For these reasons it seemed more productive to have it work on the Blender addons as a starting point rather than JavaScript/TypeScript parsers for the original formats. I still ship the original assets alongside the .glb files (meaning they have URLs just aren't loaded) in case I want to switch it someday.

Some of the custom features you may be referring to I implemented as custom properties in the glTF output - like surface flags. "Outside Visible" is one example, it's a flag baked into each .dif surface that determines whether rays can reach it from the outside, so the engine knows whether to apply the map's directional sunlight, or just ambient and light map lighting. So, even though it technically could try to render with modern PBR, dynamic lighting/shadows and all that, it instead renders as close to the original as possible using the same (or similar) techniques. Comparing screenshots with actual Tribes 2 renders is often indistinguishable unless you really know what to look for!