Hi...
Thanks - that is pretty much where my head is at too.
From what I have seen so far, ORTS is very tile-size aware, but the terrain file format itself does appear to carry information about the terrain sample structure. So in theory, yes, there may be room to experiment with higher-density terrain than the traditional MSTS-style 8m grid.
That said, I have been trying to keep SCO LIDEX conservative for the first release. Right now it writes terrain in the format ORTS, MSTS tooling, and TSRE are already known to tolerate: normal route terrain at the standard 256 x 256 raw height grid, which works out to 8m post spacing. The 1m LIDAR is used as the source data, but it is resampled down into the normal ORTS terrain structure.
The reason I have been cautious is compatibility. It is one thing to prove that Open Rails might accept a denser tile. It is another thing to prove that TSRE, existing route tools, tile compression, patch metadata, water/texture data, and long routes all remain stable. I would rather have a boring 8m output that works everywhere than a brilliant 1m experiment that eats someone's route.
I do think higher-density local terrain is worth investigating, especially for special areas like tunnel portals, cliffs, rock cuts, yards, and riverbanks. But my gut says it may be better handled as a separate "detail terrain" or scenery-object workflow rather than changing the whole route terrain grid globally.
The near/distant mountain point is a good one too. The current normal tile / distant mountain split is pretty coarse. SCO LIDEX currently builds TSRE-style DM tiles from lower-resolution data, mainly to give route builders a complete one-pass terrain workflow. Using nearby terrain tiles, or a reduced version of them, as a substitute for distant mountains is an interesting idea. It would probably need careful LOD handling so we do not just move the performance problem farther from the camera.
So short answer: yes, I think there is room to experiment. For v1.000, SCO LIDEX stays intentionally compatible and predictable. Once that baseline is solid, higher-density or "super near" terrain experiments become a lot safer to explore.
I also wanted to say I agree strongly with your comments elsewhere about teamwork, and that nobody should have to go it alone.
That has been one of the harder parts of this hobby, at least from my seat. I know the Open Rails development team is small, and they are trying to do a huge amount of work with limited hands. I have a lot of respect for that. But at the same time, it has often felt almost impossible to get real cooperation between the ORTS and TSRE sides of the house.
For the changes that would make the biggest difference to route builders, I do not think cooperation is just helpful. I think it is essential.
One example is Forest Regions. Eric and I have both wanted to see Forest Regions improved so a single forest region could contain multiple tree types instead of being locked to one tree type. I would think, a pretty easy task. I have also wanted to see the return of the "cruciform tree" as they are far superior to moving "billboard trees" especially in near-to-track applications. Eric has asked for help. I have asked for help. But no champion ever really stepped forward to carry that across the line. This is just a single example off the top of my head, but clearly illustrates the world in which we live.
LOL - I have given this some thought...
Route building is an enormous job, and very few people are willing to take it on. My feeling is simple: the easier we make the process, the more routes will get built. Better tools, better workflows, and better cooperation all feed directly into more content for the community.
I have also seen several times where Goku expressed frustration because he wanted to improve TSRE, but could not really move forward because corresponding code changes were not being adopted in Open Rails. That is a tough spot for everyone.
So yes, I agree completely. More teamwork is needed, and I would love to see it. Not as a criticism of anyone's effort, but because the whole community benefits when the simulator and the tools can move forward together.
Regards,
Scott
Thanks - that is pretty much where my head is at too.
From what I have seen so far, ORTS is very tile-size aware, but the terrain file format itself does appear to carry information about the terrain sample structure. So in theory, yes, there may be room to experiment with higher-density terrain than the traditional MSTS-style 8m grid.
That said, I have been trying to keep SCO LIDEX conservative for the first release. Right now it writes terrain in the format ORTS, MSTS tooling, and TSRE are already known to tolerate: normal route terrain at the standard 256 x 256 raw height grid, which works out to 8m post spacing. The 1m LIDAR is used as the source data, but it is resampled down into the normal ORTS terrain structure.
The reason I have been cautious is compatibility. It is one thing to prove that Open Rails might accept a denser tile. It is another thing to prove that TSRE, existing route tools, tile compression, patch metadata, water/texture data, and long routes all remain stable. I would rather have a boring 8m output that works everywhere than a brilliant 1m experiment that eats someone's route.
I do think higher-density local terrain is worth investigating, especially for special areas like tunnel portals, cliffs, rock cuts, yards, and riverbanks. But my gut says it may be better handled as a separate "detail terrain" or scenery-object workflow rather than changing the whole route terrain grid globally.
The near/distant mountain point is a good one too. The current normal tile / distant mountain split is pretty coarse. SCO LIDEX currently builds TSRE-style DM tiles from lower-resolution data, mainly to give route builders a complete one-pass terrain workflow. Using nearby terrain tiles, or a reduced version of them, as a substitute for distant mountains is an interesting idea. It would probably need careful LOD handling so we do not just move the performance problem farther from the camera.
So short answer: yes, I think there is room to experiment. For v1.000, SCO LIDEX stays intentionally compatible and predictable. Once that baseline is solid, higher-density or "super near" terrain experiments become a lot safer to explore.
I also wanted to say I agree strongly with your comments elsewhere about teamwork, and that nobody should have to go it alone.
That has been one of the harder parts of this hobby, at least from my seat. I know the Open Rails development team is small, and they are trying to do a huge amount of work with limited hands. I have a lot of respect for that. But at the same time, it has often felt almost impossible to get real cooperation between the ORTS and TSRE sides of the house.
For the changes that would make the biggest difference to route builders, I do not think cooperation is just helpful. I think it is essential.
One example is Forest Regions. Eric and I have both wanted to see Forest Regions improved so a single forest region could contain multiple tree types instead of being locked to one tree type. I would think, a pretty easy task. I have also wanted to see the return of the "cruciform tree" as they are far superior to moving "billboard trees" especially in near-to-track applications. Eric has asked for help. I have asked for help. But no champion ever really stepped forward to carry that across the line. This is just a single example off the top of my head, but clearly illustrates the world in which we live.
LOL - I have given this some thought...
Code:
//forests.json
{
"ORTSForestRegions": [
{
"Name": "Mixed Deciduous Woodland",
"Trees": [
{
"Texture": "MSMajesticOak36A.ace",
"RenderMode": "Billboard",
"Width": 15.0,
"Height": 20.0,
"MinScale": 0.8,
"MaxScale": 1.2,
"PopulationWeight": 70
},
{
"Texture": "Generic_Birch.ace",
"RenderMode": "Cruciform",
"Width": 10.0,
"Height": 18.0,
"MinScale": 0.9,
"MaxScale": 1.1,
"PopulationWeight": 25
},
{
"Texture": "Dead_Elm_Snag.ace",
"RenderMode": "Cruciform",
"Width": 8.0,
"Height": 15.0,
"MinScale": 0.7,
"MaxScale": 1.0,
"PopulationWeight": 5
}
]
}
]
}
Route building is an enormous job, and very few people are willing to take it on. My feeling is simple: the easier we make the process, the more routes will get built. Better tools, better workflows, and better cooperation all feed directly into more content for the community.
I have also seen several times where Goku expressed frustration because he wanted to improve TSRE, but could not really move forward because corresponding code changes were not being adopted in Open Rails. That is a tough spot for everyone.
So yes, I agree completely. More teamwork is needed, and I would love to see it. Not as a criticism of anyone's effort, but because the whole community benefits when the simulator and the tools can move forward together.
Regards,
Scott
Comment