TSRE GenX - MAX OVERHAUL

[Brot]

hello developers pls add wiggly tracks as in trainz if possible ☺

just a feature request
no expectations attached ☺

[derekmorton]

Hi Brot,

The developers do not add tracks, route builders do to suit the route that they are building.

[Brot]

i mean tracks that u can add by click and drag that can go any long u want
instead of block pieces like 10m, 40m, 80m like we have now

[scottb613]

Scott, GitHub was updated to the last changes I made in 8.006m

Hi Eric,

Thanks much - I'll take a gander and see where we can go from here.


Regards,
Scott

[cnwfan]

Scott Thank you for the work your doing, one thing I miss is Stick to target, makes snapping easier ! I enjoy the elevation data. Sure makes it easier following along with the profiles

[CSRX]

So, I have booted this up to try out, but it seems very stick (low FPS) for me for some reason. Which is odd, as my computer can handle games like Halo Campaign Evolved, Train Sim World 6, The Elder Scrolls V: Skyrim, Cities Skylines 2, all maxed out on graphics and what not just fine, with very minimal fps lag.

I noticed with Eric's latest version, when I goofed around with some settings, it started doing the same, until I completely deleted and reinstalled. So, I am unsure with this fresh out of the box.

My computer info:

Processor: AMD Ryzen 5 4600H with Radeon Graphics (3.00 GHz)
Installed RAM: 32GB (31.4GB Usable)
Graphics Card: NVIDIA GeForce GTX 1650 Ti (4GB)

[scottb613]

Scott Thank you for the work your doing, one thing I miss is Stick to target, makes snapping easier ! I enjoy the elevation data. Sure makes it easier following along with the profiles

Hi Todd,

Yep - it's in there - I think - just toggle this button so it turns yellow.

Thanks for the comments - appreciated.


I don't know why the image is so poor - 2K image - full size selected.

Image1.jpg

Regards,
Scott

[scottb613]

So, I have booted this up to try out, but it seems very stick (low FPS) for me for some reason. Which is odd, as my computer can handle games like Halo Campaign Evolved, Train Sim World 6, The Elder Scrolls V: Skyrim, Cities Skylines 2, all maxed out on graphics and what not just fine, with very minimal fps lag.

I noticed with Eric's latest version, when I goofed around with some settings, it started doing the same, until I completely deleted and reinstalled. So, I am unsure with this fresh out of the box.

My computer info:

Processor: AMD Ryzen 5 4600H with Radeon Graphics (3.00 GHz)
Installed RAM: 32GB (31.4GB Usable)
Graphics Card: NVIDIA GeForce GTX 1650 Ti (4GB)

Hi Shawn

I would guess your LOD range - I typically run where only the camera tile is drawn and (1) surrounding tile.

To boost performance - while not needed or in the way - under top drop-down view menu - I added an option to hide ALL forest regions.

The "settings.txt" file is going away in my next update - all changes made via F12 panels and stored as JSON in appData. F12 panels will be the user interface to settings.

Regards,
Scott

[CSRX]

Scott,
I dropped the ObjectLOD range to 1500 from 3000 and that seemed to have resolved the issue. Thanks!

[scottb613]

Scott,
I dropped the ObjectLOD range to 1500 from 3000 and that seemed to have resolved the issue. Thanks!

Hi Shawn,

If this image comes out the Tile LOD also may help...

Image1.jpg

Regards,
Scott

[GokuMK]

Hi Eric,

I just happened upon it.

It’s a modernized, still‑incomplete port of the TSRE5 route and asset editor, rebuilt around Qt6, CMake, and VSCode to bring the aging MSTS/Open Rails toolchain into a current, maintainable environment. The project has its core framework, rendering backend, file loaders, and UI scaffolding in place, along with early support for GLTF models, DDS textures, and a new math‑driven flex‑track system that replaces the old spline logic with more precise geometric calculations. While these foundations work, many of the original TSRE5 editing tools—terrain manipulation, full world editing, object dialogs, pathing, and advanced consist/route utilities—are still missing or only partially implemented. Overall, it’s a functional but far‑from‑complete modernization effort, offering updated architecture and several new features while still requiring substantial development to reach full TSRE5 parity.

GokuMK/TSRE5vc

Regards,
Scott

This description is probably made by a free AI model and completely false.

TSRE 0.7.6 version is feature complete QT6 version of original TSRE 0.7 version.

Main changes:
+ Visual Studio Code support as modern IDE instead of outdated Netbeans, allowing to use Codex and all vs code forks like Claude Code, opencode etc.
+ Modern, platform independent cmake build. Works well on Windows, Linux both x64 and ARM.
+ Modern project directory and code structure, making some order with the previous mess.
+ Some introduction to new rendering pipeline.
+ GLB/GLTF support.
+ New native DXT support and native compression support.
+ Some new feature examples

Anyway, back then I gave some very heavy tasks to AI agent to implement and it failed, so the project sits in "limbo" now.

Why I did not port 0.8x:
- I found most of the Eric implemented features valuable, but requiring better code solutions. Because most of those features were kind of basic, the goal was to use an AI agent to review them and propose more elegant and feature complete solution.
- One example what was implemented is Ref Template. Instead just blindly list directory shape files. the process is now controllable using template files : https://github.com/GokuMK/TSRE5vc/bl...plate-items.md

Your changes are very substantial and this approach is no longer possible. Your version is full blown fork.

But, I encourage you to do this QT6 migration yourself. You should first agree with Eric about development freeze, migrate, and continue working.

When migrating from QT5 to QT6, some functions become obsolete, but it is not much.
- The biggest obstacle was lack of DXT support in QT6. But with help of Codex, I made much better native DXT support than QT5 even had. It properly uses texture compression, both for ACE and DXT, substantially reducing memory usage. Be cautious in copying code from my version, because it will collide with your terrain painting modifications.
- Be cautious when migrating old QRegexp to new.
- Some other minor things, but nothing much.

Peter Groenbaek contacted me some time back about how he got the 8.005 codebase moved over to use CMAKE and QT6 as well as VSCode.

With help of AI it is no big deal, so it won't surprise me if someone came up with a similar solution. But I doubt that DXT loading was solved by him.

[eric]

- I found most of the Eric implemented features valuable, but requiring better code solutions. Because most of those features were kind of basic, the goal was to use an AI agent to review them and propose more elegant and feature complete solution.

I'm fine with that approach. The end goal should be something that can be supported long-term.

[scottb613]

This description is probably made by a free AI model and completely false.

TSRE 0.7.6 version is feature complete QT6 version of original TSRE 0.7 version.

Main changes:
+ Visual Studio Code support as modern IDE instead of outdated Netbeans, allowing to use Codex and all vs code forks like Claude Code, opencode etc.
+ Modern, platform independent cmake build. Works well on Windows, Linux both x64 and ARM.
+ Modern project directory and code structure, making some order with the previous mess.
+ Some introduction to new rendering pipeline.
+ GLB/GLTF support.
+ New native DXT support and native compression support.
+ Some new feature examples

Anyway, back then I gave some very heavy tasks to AI agent to implement and it failed, so the project sits in "limbo" now.

Why I did not port 0.8x:
- I found most of the Eric implemented features valuable, but requiring better code solutions. Because most of those features were kind of basic, the goal was to use an AI agent to review them and propose more elegant and feature complete solution.
- One example what was implemented is Ref Template. Instead just blindly list directory shape files. the process is now controllable using template files : https://github.com/GokuMK/TSRE5vc/bl...plate-items.md

Your changes are very substantial and this approach is no longer possible. Your version is full blown fork.

But, I encourage you to do this QT6 migration yourself. You should first agree with Eric about development freeze, migrate, and continue working.

When migrating from QT5 to QT6, some functions become obsolete, but it is not much.
- The biggest obstacle was lack of DXT support in QT6. But with help of Codex, I made much better native DXT support than QT5 even had. It properly uses texture compression, both for ACE and DXT, substantially reducing memory usage. Be cautious in copying code from my version, because it will collide with your terrain painting modifications.
- Be cautious when migrating old QRegexp to new.
- Some other minor things, but nothing much.


With help of AI it is no big deal, so it won't surprise me if someone came up with a similar solution. But I doubt that DXT loading was solved by him.

Hi Piotr,

Thanks for clearing this up - you're right - the description came from an AI review and it got the wrong end of the stick. It saw the unfinished rendering work and assumed the whole application was unfinished. I should have looked into it more closely before sending that description.

By the time I found TSRE5vc - I was already well down the road with Eric's 8.006 code. What started as a few changes has grown far beyond anything I originally intended - so I agree - it is now a full-blown fork. There is no practical way to move everything over to your version without doing a large part of the work again.

I think the sensible path now is to finish what I have open - get to a stable state - and freeze development there. I'll speak with Eric before going further - then make the QT6 and CMAKE conversion as its own project. At least that way I'm migrating a known working version instead of chasing code which is still changing.

Your QT6 work will be extremely helpful as a reference - especially the DXT changes. I won't just copy that section blindly - I've done a lot with terrain painting - seasonal textures and texture refreshing - so I understand why those areas may collide. I'll work through it carefully when I get there.

I appreciate you taking the time to explain it - and I'm glad you happened upon the project. I never set out to create a competing version - I started changing the editor I was already using and apparently didn't know when to stop.

Thanks again for everything - especially for sharing the code and pointing me in the right direction.

TSRE is the way forward.

Regards,
Scott

[eric]

What I've found in 30 years of programming.... it's always better the second or third time around...

Merging things into the VC version won't be nearly as hard with the pre-VC source from the forks to look at.

[GokuMK]

Hi Folks,
My Vendetta - LOL - wires - splines, lofts, procedural objects are high on my list - but - to truly implement them would require code changes to ORTS - and cooperation between ORTS and TSRE is not one of our forte's. I'm hopeful we'll be able to do something.

For procedural objects, tracks, fences etc, you have two options to go:

A. implement TSRE procedural generator in ORTS. The code is so basic and library/code independent that good AI agent should have no issue in making this feature. The downside is that TSRE procedural objects file specification is a draft, not a finished product.

B. commit TSRE procedural objects into .S files. This would require making next gen Shape File format support in TSRE that is able to write full S files, and in best case read too. Rather big task, but may be fully automated if you have enough S files for testing. Or go with "compromised" solution - write these objects as GLTF files, ORTS should read today.

Solution A is superior, but that requires you touching ORTS project. Solution B is inferior because it makes procedural object uneditable after conversion.