ELRail Smooth Curves

[ohdude 2,353]

Hi there!

While playing in SimCity 4 Tram there is a detail that is not very good looking and not very good experience for Tram users. I'm talking about sharp curves.

As a special petition to NAM developers, it would be nice to have the possibility to play the game with smoother curves for ElRail-Tram transition but not conditioned by an avenue or road below it, just as a single curve . I've seen that there are smoother curves made for Monorail as a NAM addition but no for Elrail. It would be fantastic to have that option.

I'm open to help with it if is not necesary to model anythin, just isolating the already designed rails from the roads, avenues, etc.

Look the image please.

Thanks to @NAM Team for your time and amazing work.

[Tarkus 6,933]

Smoother and Wide-Radius/Multi-Radius Curves for the Elevated (Light) Rail (ELR) network are on our wishlist, too, and have been for a long time.  The sticking point, however, as always, is models--and in the case of default/Maxis networks, the models are more complicated, making things that much harder.  The alignment of the ELR-over-Avenue curves is offset compared to what it would need to be for the base ELR network, since the ELR is split between two tiles when it's over the Avenue. 

The people who made the models for the ELR-over-Avenue stuff are long gone, too, unfortunately, and the process for doing this sort of thing is different than normal BATing--it's more similar to automata modeling, but with the added caveat of slicing.  The slicing process (carving the model up into single-tile chunks) is by far the most trouble-laden part of the entire process, and getting the slicing done without texture mapping/geometry glitches when converting over to the SC4-readable S3D model format can be tricky stuff.  We have exactly one person on the team who is good at slicing, and he's often super busy. 

ELR curves are also likely a prerequisite for GLR curves, as the ideal implementation (in line with all the other modern curve setups in the NAM) would entail ELR-based FLEX Pieces that get overridden down to GLR.

-Tarkus

[matias93 7,535]

Just to know. Isn't there a possibility to redo the el-rail network with the same tools you use for the elevated RHW, which seems to be easier to model?

[Tarkus 6,933]

3 hours ago, matias93 said:

Just to know. Isn't there a possibility to redo the el-rail network with the same tools you use for the elevated RHW, which seems to be easier to model?

That's an intriguing idea, and one I had put some thought to recently, in light of some images that @Lucario Boricua showed in our private NAM dev Discord channel of Light Rail in Puerto Rico.  If we were, in fact, reusing the elevated RHW models (or some substantial part of them) for new ELR models, it would be quite easy to port many things over. 

Keep in mind that the end result of such an effort is going to be very similar to how RealRailway supplanted Maxis Rail--the new specification would very likely become the standard and only option in the installer.  The existing Maxis ELR would effectively not be getting any of the new developments, though that's somewhat of a moot point, given that Maxis ELR's specifications are the bottleneck preventing new ELR features, so I don't expect there to be any real loss there.

-Tarkus

[Lucario Boricua 7,052]

To provide more context, the idea is that modern metro rail systems, including both light and heavy rail systems, have moved away from using steel frame viaducts (like the New York Subway and the Chicago L, or many of the older European systems) towards using pre-cast concrete segment structures or using simply supported concrete beams. These structures tend to have lower maintenance requirements, lower construction costs, and have the benefit of being far less noisy when trains pass over them.

 

Here's the examples from Puerto Rico I was citing in that discussion. This is the Tren Urbano, a metro system serving the cities of San Juan, Guaynabo and Bayamón, and consisting mainly of viaduct segments (photograph by me):

 

 

Other examples I'm aware of include similar systems in the western United States, like the Seattle WA Link Light Rail system (image source):

 

The Honolulu Area Rapid Rail Transit in Honolulu, Hawaii (image source):

 

 

Or if looking to other parts of the world, we see other similar structure types in other metro and light metro systems. I honestly feel that using concrete viaduct structures would result in a more neutral look which can look more at home in cities of different architectural styles.

I didn't consider @matias93 and @Tarkus' idea to repurpose the RHW viaduct models, but if done, it would save an immense amount of model work, focusing more on texture replacements and programming.

 

Dubai Metro, Dubai, United Arab Emirates (image source):

 

Mass Rapid Transit of Kuala Lumpur, Malaysia (image source):

 

Metro de Santiago, Santiago, Chile (image source):

 

 

[matias93 7,535]

Given the chance, this new implementation could be based on L1 height viaducts? L2 feels really unnatural, and in most of the real life examples I've seen, the height is around 8 metres, or even less

[Lucario Boricua 7,052]

I wonder if doing both L1 and L2 would be doable. I can see many situations in which an L2 base network would be desirable, rather than limiting it to a few select overpassing sites (ex. where the Tren Urbano goes over the PR-2 viaduct in my example photograph). The availability of viaduct models from the RHW would make it far more feasible.

[BartonThinks 3,416]

Personally, I'd be very disappointed to see the el-rail system switched over to concrete viaducts, without some way to reskin them as metal frames. Not sure if that's exactly what's under discussion. I'm sure other players are just as disappointed to be stuck with metal viaducts right now, but as someone who's quite fond of the Chicago and New York-style el-rail systems, it would be a shame to see metal frames essentially become unsupported.

[Lucario Boricua 7,052]

The challenge we confront with much of the recent NAM development is the lack of full-time 3D model makers specialized in transportation features. If we do get more model makers as team members, there's a lot more we could do, and hopefully also keeping the option to preserve the steel frame viaducts as an override while adding the concrete viaducts as the new base option. What ends up happening, unfortunately, doesn't depend on me. We do appreciate the feedback, especially since we're on time to make a decision on what we'll do about the future of El-Rail.

[Propfam 2,307]

17 hours ago, Lucario Boricua said:

the lack of full-time 3D model makers

That's why NAM seems like stagnating in terms of new 3D models. I hope that someone with 3D modelling skill can be a part of the team so we can progress the NAM further.

[rsc204 21,866]

On 10/06/2021 at 10:19 AM, Lucario Boricua said:

If we do get more model makers as team members, there's a lot more we could do, and hopefully also keeping the option to preserve the steel frame viaducts as an override while adding the concrete viaducts as the new base option. What ends up happening, unfortunately, doesn't depend on me.

At issue here is essentially cross linking, where multiple variants of network skins/texture sets have to interoperate. As soon as you require such options, it vastly complicates the installer and hierarchy of the mod. Put simply, everything like this was stripped to the bear minimum as part of the new installer for NAM 37, so there is little appetite to allow such things to creep into future releases. Given that adding new features using the original models is undesirable, that would likely end up like RRW/Rail in that a legacy El-Rail plugin could be offered, but it wouldn't support the newer features that only worked with the re-skin.

On 10/06/2021 at 8:10 AM, matias93 said:

Given the chance, this new implementation could be based on L1 height viaducts?

I'm inclined to agree if we're going to the effort of completely altering the existing El-Rail networks, we should be switching it from L2 to L1 for the base mod. I personally think this would be the right way to go for MHY and Monorail too. Sure, all those networks require some L0/L2 support to allow for flexible crossing options. The problem as always is the workload of seemingly reasonable tasks, they are often far more involved than it first seems. For example with El-Rail, you have to cover the El-Rail over Road/Street and Ave/Rd-4 networks, Stations were all designed around L2 standards and plenty of other puzzle pieces exist for interacting with other networks. It's hard to see a scenario where re-making all of that would be quicker than making the original styled WRCs IMHO.

Just a thought, but the track bed of both the Maxis El-Rail and Moonlights Alt version can both be easily separated from the pillars. Having done that you could make some simple concrete pillars and T21 them into place, seems much less work to me. Not to mention, it'd then be super easy to alter the heights of the models if desired and just use smaller pillar props where necessary.

[ohdude 2,353]

@Lucario Boricua your forgot the Springfield monorail elevated rail... (image source: https://i.gifer.com/7RTO.mp4)

 

[ohdude 2,353]

As a approach to improve the Elrail curves, and considering the difficult it has on the developmnet of the 3D models, maybe it would be a good idea to start or keep developing first TRAM smooth curves, and modular FAR diagonal rails for TRAM, like in the Real Railway mod (RRW). That would involve the development of FAR stations for TRAM as well ( @mattb325 developed some FAR stations that can be useful for TRAM, see image below). Maybe is not a difficult work as it is in ElRail development considering that we already have part of the work done as you can see in the image below. At the end (before having ElRail smooth curves) we could have the option to choose between Elevated Rail straight lines or ground (tram) FAR diagonals and smooth curves. I'm just giving some ideas of development that, in my opinion, are necessary to improve the SC4 transport to be more realistic-enjoyable.

 

[Tarkus 6,933]

On 6/10/2021 at 6:34 PM, chfzdn said:

That's why NAM seems like stagnating in terms of new 3D models. I hope that someone with 3D modelling skill can be a part of the team so we can progress the NAM further.

I don't know that we've really "stagnated", because it's hard to stagnate from a near-zero point.  Models have been a sticking point for pretty much the entire time the NAM has been around, and at least for the 14 years I've been on the team.  There are some areas (things like bridges and the FLUPs portals) where things work more similar to standard BAT models, and we've managed to get some outstanding contributions there over the years.

But things like El-Rail models, viaducts, etc., are a different animal, and the process is a very different one that not a lot of people have experience handling. In the form the game is reading them, they're actually true-3D models, instead of renderings that are designed to merely look good at the camera angles the game supports (which is what the BAT export process actually does to 3D models normally).

For those who are curious, we have, at various points over the years, had established BATers try to make true-3D elevated network models.  A lot of them try to do some sort of massive revamp/re-spec, and produce a snazzy orthogonal prototype, because they want to do something more than our usually fairly utilitarian models . . . but that's usually as far as they get.  Often, that prototype hasn't even gotten integrated properly into the game, as there's some weird quirk with their setup that leads to a mess once it's in the game-readable S3D format (often with the UV mapping or scaling, or various bizarre things, sometimes to the point of causing CTDs when it's loaded in game), or prevents them from even being able to get it to the point of becoming an S3D. And even if we do get to the point of that ortho prototype successfully making it into the game, while it might make a big splash . . . but there's a lot more to a network than an ortho prototype.  The hard work is only beginning at that point.

I've also remarked many times in regards to how I designed the RHW's interchange functionality, that a large part of it had to do with the absolute dismal failure of the integration of the pre-fab interchanges for the stock Maxis Highways.  There were tons of people trying their hand at making Maxis Highway interchanges when I arrived in the SC4 community in 2006.  Of those early attempts in the first couple years of the NAM's existence, I think maybe two actually made it into the game (the stack and that diagonal thing that I'm not sure how to describe), leaving behind an "interchange graveyard", and a ridiculously long list of effectively unfulfillable requests (the old NAM: Requests thread was largely requests for Maxis Highway interchanges).  Eventually, @andreharv somehow managed to make 3-4 more circa 2009-2010, though each took anywhere several months to a full year (in the case of his first one) to make.  The amount of dedication required there is not for the faint of heart.

The one person presently active on the team who is really good at true-3D transit network modeling is @Eggman121.  I can sometimes piece things together if I can modify the existing geometry easily (which is how I managed to add a few elevated ramp interfaces over the years), or if I'm incredibly patient, but I'm nowhere near his league there.  There's a few other people in the past who were effective at actually doing things mathematically (actually modifying existing models, sometimes quite substantially, using spreadsheets and ilive's Reader).  @Swamper77 was the absolute master--they made the original ERHW models, which, due to their design, have been able to be extended many, many times over the years.  @ArkenbergeJoe--same deal with his Rail Viaducts.  And all of them are great team players, too.  We've had a few others around--but they've usually been involved in so many other things, or were only around for a short time. 

On 6/11/2021 at 4:06 AM, rsc204 said:

Just a thought, but the track bed of both the Maxis El-Rail and Moonlights Alt version can both be easily separated from the pillars.

Curiously enough, moonlinght-san was the one responsible for Monorail getting Wide-Radius Curves, and of course, he created Shinkansen/Bullet Train Mod reskins of them.  If I'm not mistaken, his Shinkansen/Bullet Train Mod is based on ELR specifications.  It may be worth investigating that as a potential avenue () for a solution.

Regarding the whole height-level debate . . . the Maxis Highway Override (MHO) came out during the NAM 31 cycle, which was the first NAM to have any content at L1.  I'd note that while the MHO included some components designed to hook into the L1 RHW networks, the actual (Elevated) Highway network remained at L2, in spite of the fact that the MHO was intentionally designed not to play nice with "legacy" Maxis Highway setups.  The L1 specification is, without a doubt, more realistic for most elevated usage, but no major re-spec/reskin of a base network has made a dramatic height-level change like that.  RRW compatibility with most of the stations and Rail-related Lots out there was possible just by making some new textures (save for extreme "baked-in" cases), but dropping ELR is a whole other level (), and a massive can of worms. 

I'll note, though, the fact that we're discussing a total ELR re-spec just in order to get smoother curve options really demonstrates how much of a role the model situation plays in terms of the NAM development process. 

20 hours ago, ohdude said:

As a approach to improve the Elrail curves, and considering the difficult it has on the developmnet of the 3D models, maybe it would be a good idea to start or keep developing first TRAM smooth curves, and modular FAR diagonal rails for TRAM, like in the Real Railway mod (RRW).

Tram curves and the like is a much easier thing to pull off, for sure.  The ideal implementation for those, though, at least for GLR/L0 Tram would be to have the base network (ELR) be the basis of the FLEX pieces (standard puzzle pieces have been a no-go in NAM development for several years now), and that's one of the hangups here.

-Tarkus

[ohdude 2,353]

But anybody knows how is this posible? I'm trying using bullet train mod but it doesn't appear the the smooth curve

@philforhockey51 where did you found this?

 

image from https://community.simtropolis.com/forums/topic/13543-show-us-your-railroads/?do=findComment&comment=1613888

 

[Haljackey 17,398]

3 minutes ago, ohdude said:

But anybody knows how is this posible?

@philforhockey51 where did you found this?

 

image from https://community.simtropolis.com/forums/topic/13543-show-us-your-railroads/?do=findComment&comment=1613888

 

That's BTM version 2.

https://community.simtropolis.com/files/file/21544-bullet-train-mod-btm-version-2/

[ohdude 2,353]

@Haljackey

I've just installed BTM version 2 with its patch but i see many issues and no smooth curves with at least the textures indicated on the image before. Is possible that there is any incompatibility with NAM 41 that i have installed?

 

[Tarkus 6,933]

That version of BTM doesn't support the Monorail Wide-Radius Curves (which didn't exist when it was made).  It's the moonlinght (ML JPN) version that used to be bundled with the NAM that specifically that supports the curves.  We're going to be re-releasing it as a separate download soon.

-Tarkus

[kschmidt 6,223]

On 9-6-2021 at 5:27 AM, Tarkus said:

Smoother and Wide-Radius/Multi-Radius Curves for the Elevated (Light) Rail (ELR) network are on our wishlist, too, and have been for a long time.  The sticking point, however, as always, is models--and in the case of default/Maxis networks, the models are more complicated, making things that much harder.  The alignment of the ELR-over-Avenue curves is offset compared to what it would need to be for the base ELR network, since the ELR is split between two tiles when it's over the Avenue. 

The people who made the models for the ELR-over-Avenue stuff are long gone, too, unfortunately, and the process for doing this sort of thing is different than normal BATing--it's more similar to automata modeling, but with the added caveat of slicing.  The slicing process (carving the model up into single-tile chunks) is by far the most trouble-laden part of the entire process, and getting the slicing done without texture mapping/geometry glitches when converting over to the SC4-readable S3D model format can be tricky stuff.  We have exactly one person on the team who is good at slicing, and he's often super busy. 

ELR curves are also likely a prerequisite for GLR curves, as the ideal implementation (in line with all the other modern curve setups in the NAM) would entail ELR-based FLEX Pieces that get overridden down to GLR.

-Tarkus

ELR might be complicated, how is this for monorial ? RRW curves and switches !HSR. Shikansen  would look more awesome with these added ! Second 7.5m ELR how that development at the moment ?  GLR avenue bridges might be imposible, non dragable short bridges with a candy like idea but still funtional at both sides be posible. Let´s have a set of river wides of 10 or 20 squarres.as long there´s a land squarre at both sides as a bat ? Bridge height feature  should be disgarded in this instance, it´s a physical non changable bridge design without supports.  Would be a real addition to the game making seperate GLR.Avenue bridges obsolete !

Sincerely yours,

Kschmidt

[Ulisse Wolf 4,461]

41 minutes ago, kschmidt said:

ELR might be complicated, how is this for monorial ? RRW curves and switches !HSR. Shikansen  would look more awesome with these added ! Second 7.5m ELR how that development at the moment ?  GLR avenue bridges might be imposible, non dragable short bridges with a candy like idea but still funtional at both sides be posible. Let´s have a set of river wides of 10 or 20 squarres.as long there´s a land squarre at both sides as a bat ? Bridge height feature  should be disgarded in this instance, it´s a physical non changable bridge design without supports.  Would be a real addition to the game making seperate GLR.Avenue bridges obsolete !

Sincerely yours,

Kschmidt

The main problem is the models.  As Tarkus wrote the NAM Team has a shortcoming on this front but we are catching up on this front albeit slowly as people are learning advanced techniques and the full aspect of modding.

I know there is a lot of interest in GLR and EL Rail but the effort is very big and there are priority projects such as Real High Speed Rail (RHSR) that will allow you to discontinue HSRP and all legacy mods like BTM. Patience must be because NAM members devote their free time to making NAM content and from the first internal tests NAM 46 continues with the translation to radically change the concept of dragging networks.

For the question of the bridge you have to answer an expert in modding bridges @McDuell and @redfox85

 

[kschmidt 6,223]

On 10-10-2022 at 10:37 PM, ulisse said:

The main problem is the models.  As Tarkus wrote the NAM Team has a shortcoming on this front but we are catching up on this front albeit slowly as people are learning advanced techniques and the full aspect of modding.

I know there is a lot of interest in GLR and EL Rail but the effort is very big and there are priority projects such as Real High Speed Rail (RHSR) that will allow you to discontinue HSRP and all legacy mods like BTM. Patience must be because NAM members devote their free time to making NAM content and from the first internal tests NAM 46 continues with the translation to radically change the concept of dragging networks.

For the question of the bridge you have to answer an expert in modding bridges @McDuell and @redfox85

 

Thank you, Realize this a project of effort, love and time ! Conscideration what feauture of NAM  to develope. RHW, RRW,NWM,CAM; last maybe the most shelfd one. El rail more usefull with the onslope transition. Inflexible non dragable networks replaced by dragable there might still be some place for certain prefab sollutions, like the RhW flyover models, multitrack diagonal railstations non dragable bridges for GLR connections. Why there+s a dragable glr road bridege and not a modded avenue one ? Avenue might not be adjustable, road bridge appearance another model !

Sincerely yours,

Kschmidt

[simmering 2,743]

I was about to add smooth ELR and GLR curves to the NAM wish list when I found this thread. Is there an update?

[Tarkus 6,933]

6 hours ago, simmering said:

I was about to add smooth ELR and GLR curves to the NAM wish list when I found this thread. Is there an update?

Unfortunately, not really.  We played around with actually repurposing the MIS models for an ELR revamp after this question got asked, which almost kind of worked, but not well enough that it progressed much beyond that, and while there's been occasional passing discussion of ELR, nothing new has happened beyond that.  Re-reading this did remind me of the commonalities between moonlinght-san's BTM and Maxis ELR, and I'm kind of curious to see if that provides any viable avenue (metaphorically), but it's probably still going to be some time before anything concrete happens.

Also, re-reading the thread also led me to find this question from earlier that wasn't answered (and I would suppose is a somewhat common one amongst those familiar with the GLR Dual-Networking options):

On 10/15/2022 at 12:23 PM, kschmidt said:

Why there+s a dragable glr road bridege and not a modded avenue one ? Avenue might not be adjustable, road bridge appearance another model !

Due to the game's various quirks, it was determined that in order to properly function and not have the "congestion bug" (i.e., a bridge that immediately turns blood red on the congestion view, as soon as a single vehicle uses it), the GLR-in/on-Road bridges needed to be ELR-based instead of Road-based.  Since bridges cannot be built directly adjacent to one another (there must be a one-tile gap at minimum), and having the bridge be Avenue-based would induce the congestion bug, this effectively precludes creation of proper GLR-in-Avenue bridges.

-Tarkus

[simmering 2,743]

Thank you for explaining that, much appreciated.

[memo 1,473]

Creating models for smooth curves is not actually that difficult and can be fun. In contrast, I think creating the SC4Paths for the curves is harder, or at least more tedious. For the modeling, there exists good documentation.

For anyone interested in giving this a try, here are some of the steps one could take:

1. Decide on the exact geometry of the curve. Experiment with Bender (part of GoFSH) and an image editing program. You'll want to figure out the exact radius of the curve, using some trigonometry. Things to consider:
   • How much straight track leads up to the curve at the orthogonal and diagonal end?
   • There can be small overhangs to keep the footprint small.
   • It's useful to choose a geometry such that two 45 degree curves can overlap to form a 90 degree curve. Natural choices would be R1.5 mini-curves as used by RRW (two of them form a 3×3 90° curve) or a 2×4 curve as used by FLEX-Fly (two of them form a 5×5 90° curve).
2. Export the S3D models of orthogonal (0x08031504) and diagonal (0x08001a04) Lightrail as 3DS, as well as their textures. Import them in Blender.
3. Experiment with exporting in the opposite direction, from Blender to 3DS, and import the 3DS into an S3D in Reader. Alternatively, there's a way to export an OBJ file and use fshgen to convert to DAT, but it's not currently optimized for true 3D models. Things to figure out:
   • Some conversion steps might permute the coordinate axes.
   • Some conversions might scale the model by a factor of 10.
   • Make sure that info about materials is preserved as much as possible.
4. Familiarize yourself with basic Blender concepts, such as:
   • Camera movement
   • Selecting and moving objects
   • Object Mode vs Edit Mode
   • Global vs local coordinates
5. Start off of the orthogonal Lightrail model and convert all triangles to quads. This is important to avoid unnecessary polygons in the final model. If the curve is going to have significant overhangs, also add a semi-transparent plane at ground level for use as shadows.
6. Scale the model in longitudinal direction to make it long enough to fill the entire curve. Rescale the UV-mapping in longitudinal direction accordingly. Subdivide the polygons, e.g. by adding Loop Cuts every 4 meters. Ideally, there will be a polygon edge exactly at the 45 degree point of the curve – similarly, the tiling of the textures (perhaps with an offset) at the orthogonal and diagonal ends should be considered. For small-radius curves, it makes sense to scale the left and right railing separately.
7. Bend the model along a circle. There are different ways to do this, for example using the Warp tool or the Curve modifier. For the latter, create a Circle Mesh with the correct radius and with sufficiently many vertices to make it smooth. Offset it in local coordinates so that it touches the origin. Convert the Circle Mesh to a Curve. Then select the straight model and apply the Curve modifier using the Circle curve. (Technically, the curve does not need to be perfectly circular, but this helps in case you want to combine the model with textures created with Bender or want to compute SC4Paths programmatically.) 
8. Make a test export to ensure that everything looks right in the game.
9. Connect both ends of the curve to orthogonal and diagonal track models to ensure the ends line up with the 16m×16m cell grid. This could also be accomplished by cutting the circle apart and extending it as necessary.
10. Export the full curve model for use as a Preview model.
11. Slice up the model into 16m×16m pieces. Again, there are different ways to do this, e.g. using the Bisect tool (used by BAT4Blender) or a Boolean modifier applied to a 16m×16m box. For tiles with overhangs, the box needs to be larger than 16m×16m. If the overhangs are big, it can make sense to cut them in half along a 45 degree diagonal in order to allocate them to two different tiles (this is for slope-tolerance – the effect depends a bit on the eventual RUL flags used, though). 
12. Move each slice to the cell at the origin and export each of them separately.
13. Expect to do the whole process at least three times because you overlooked some detail.
14. Later on, consider creating a 90 degree curve model (this should only be one additional 16m×16m tile) as well as models for switches.