For the love of Alcos (RS-3)

[pwillard]

It's OK Fred, Thanks. It's nice to know people understand what I'm dealing with. BTW: Mine was a triple.

PS: Getting old is not for sissies.

[pnrailway]

Pete,

I know exactly what you are going through, my wife had a quadruple bypass. Please get well and out thoughts are with you.

[superheatedsteam]

You have any images of that Alco of yours - be nice to see. If you haven't played around with HDRI renders and interested - I could send you an example blend of how I make all the - in my humble opinion - beautiful renders of my models.

Hi Scott,

I haven’t worked on the M636 for a while but still gathering reference material for it any time I find it. I made it a bit more presentable and here are some snaps of the M636. This model has not been completely UV mapped yet so no complete texture sheets. To avoid the current dazzle ship effect, I have applied an AO shader for the screen captures.

M636_Clipboard_10-05-2026_01.jpg

M636_Clipboard_10-05-2026_02.jpg

M636_Clipboard_10-05-2026_03.jpg

These locomotives differ from US / Canadian models primarily by using double stack radiators, heat shield over the cab roof, bolt on air conditioning units and metric gauges in the cab.

From the ALCO stable, I also have a C636R and C636 but these are still at MSTS quality level and were to shy to make an appearance.

Your renders are beautiful. Whereas I do render my gauges, I do not use HDRI for these. These speedometers are my first serious attempt at using PBR materials in Blender and I’m reasonably happy with the result, factory finish aside. I use the free blenderkit add on as it has over 10,000 materials, 7,700 of which are procedural, and most of them are royalty free. You just select the object you want the material applied to, search for the material type you want applied to that object and it downloads the shader (and texture files if not procedural) for real time inspection. You can swipe left or right till you get the effect you are looking for, and modify the material in the node editor as desired, often to just change the colour, if required.

BlenderSpeedo_10-05-2026_01.jpg

Texture creation has always been and still is my Achilles heel with respect to model making. I’m still mulling over if I’m going to stick with Blender or move to Substance Painter for texture creation. I used Subsance Painter for a few days when I first purchased it a couple of years ago and found it easier to use the layer system to create edge wear and distressed paint than trying to do it in Blender using shader nodes. However I also found that you need to have a completely mapped model and modified workflow and that requires that I invest more time to learn new skills and yet another tool.

Thank you for all your hard work and contribution to the community.

Cheers,

Marek.

[scottb613]

Hi Scott,

I haven’t worked on the M636 for a while but still gathering reference material for it any time I find it. I made it a bit more presentable and here are some snaps of the M636. This model has not been completely UV mapped yet so no complete texture sheets. To avoid the current dazzle ship effect, I have applied an AO shader for the screen captures.

These locomotives differ from US / Canadian models primarily by using double stack radiators, heat shield over the cab roof, bolt on air conditioning units and metric gauges in the cab.

From the ALCO stable, I also have a C636R and C636 but these are still at MSTS quality level and were to shy to make an appearance.

Your renders are beautiful. Whereas I do render my gauges, I do not use HDRI for these. These speedometers are my first serious attempt at using PBR materials in Blender and I’m reasonably happy with the result, factory finish aside. I use the free blenderkit add on as it has over 10,000 materials, 7,700 of which are procedural, and most of them are royalty free. You just select the object you want the material applied to, search for the material type you want applied to that object and it downloads the shader (and texture files if not procedural) for real time inspection. You can swipe left or right till you get the effect you are looking for, and modify the material in the node editor as desired, often to just change the colour, if required.

Texture creation has always been and still is my Achilles heel with respect to model making. I’m still mulling over if I’m going to stick with Blender or move to Substance Painter for texture creation. I used Subsance Painter for a few days when I first purchased it a couple of years ago and found it easier to use the layer system to create edge wear and distressed paint than trying to do it in Blender using shader nodes. However I also found that you need to have a completely mapped model and modified workflow and that requires that I invest more time to learn new skills and yet another tool.

Thank you for all your hard work and contribution to the community.

Cheers,

Marek.

Hi Marek,

WOW - what a beast compared to my little RS3. Absolutely gorgeous - sir.

I forgot the meticulous detail to which you model - OMG - it makes my work look like a child playing with plastic blocks.

I'm at 45K polys on the locomotive and 21K polys on the cab - I honestly don't know where I should draw the line for polys vs. performance. I know the DTG and Trainz guys far surpass my meager allotments with their models. Every shape I throw down - I'm always considering how I can shave a few more polys from the shape. Maybe I'm not even close to the performance thresholds I need to worry about? I pull 60 car trains with four of my locomotives - through heavy scenery - and they seem to work fine. I started modeling when - if you went over 10k polys - there was a good chance your model would EXPLODE in MSTS.

I'm also very conscious of draw calls - animations such as trucks/bogies, wheels, cab levers, needles, all get their own smaller texture sheets because they inherently spawn a new draw call. The cab is mostly a 4k texture sheet - with gauge faces and animated parts on separate sheets.

I've looked at Substance Painter - it seemed pretty complicated. I never use the paint features in Blender - I just do all my work in PSP. I typically just find detailed textures I like - make them seamless - and leave the scratches and chips to the base texture.

Incredible work you've done there.

For those unfamiliar - Marek has his SD40-2 on Git - which I relied on heavily to figure out 3D Cabs.

https://github.com/superheatedsteam/generic_SD40-2

Regards,
Scott

[superheatedsteam]

Thanks for the kind words Scott. Flattery will get you everywhere.

I honestly don't know where I should draw the line for polys vs. performance.

I would suggest doing your own tests using your trains, on the types of routes that your models are expected to run on to find what the limits are.

What I did was get a MSTS model that exports to .S OK and then applied a sub division surface modifier to the body, as many time as required to get the triangle count I wanted to test. As you can see from the wireframe, this mangles the body but I was just testing for performance.

AC6000_subDiv_Clipboard_10-05-2026_01.jpg
I exported the model as .S and ran in OR and made a note of the FPS when viewing the entire length of the train when stationary and when moving. I tested with varying triangle counts and different numbers of textures applied to the model, that did and didn’t have an alpha channel.

My tests confirm everything that I have read about minimising draw calls. Have as few objects/nodes in a model as possible. That means an optimised ore car will have 4 wheels, 2 bogies and 1 body object. That is 7 draw calls for the objects and 1 draw call for the single texture file with no alpha for the complete ore car. Each animated part of the motion in a steam locomotive, or animated control / gauge in a 3D cab view adds an additional draw call but that is unavoidable.

That being said, one of my currently un-optimised 3D cab views generates 77 draw calls because of all the animations in the multi function display screen. To offset this the cab only uses 4 x 4K textures (2 for external body and 2 for cab internal) and only one of those textures has an alpha channel. This cab view still gives me 120 FPS on my 2^nd Gen 3.6HHz i7 and RTX2070.

I'm also very conscious of draw calls - animations such as trucks/bogies, wheels, cab levers, needles, all get their own smaller texture sheets because they inherently spawn a new draw call. The cab is mostly a 4k texture sheet - with gauge faces and animated parts on separate sheets.

I suspect that having an individual texture per animation part is going to increase the draw calls and if that texture is using the alpha channel then that adds yet another draw call.

Unfortunately, as far as I can tell all the current .S viewers do not display the number of draw calls. I'm moving to glTF so what I do is export the model as a .glb file and then open it with the Windows default 3D viewer, or drag the .glb file to one of the online glTF/glb viewers like https://github.khronos.org/glTF-Sample-Viewer-Release

In the Windows default 3D viewer the draw calls are shown in the Performance data section. At the Kronos web site, in the Advanced Controls > Statistics section, the ‘Mesh Count’ is the equivalent to draw calls.

In summary, triangle count has less impact than number of nodes, number of textures and number of textures that have an alpha channel.

Hope this helps.

Also, do you have or want photo images for your wiper motors? Unsurprisingly, it appears ALCO used the same wiper motors in the M636.

Cheers,

Marek.

[scottb613]

Thanks for the kind words Scott. Flattery will get you everywhere.



I would suggest doing your own tests using your trains, on the types of routes that your models are expected to run on to find what the limits are.

What I did was get a MSTS model that exports to .S OK and then applied a sub division surface modifier to the body, as many time as required to get the triangle count I wanted to test. As you can see from the wireframe, this mangles the body but I was just testing for performance.

I exported the model as .S and ran in OR and made a note of the FPS when viewing the entire length of the train when stationary and when moving. I tested with varying triangle counts and different numbers of textures applied to the model, that did and didn’t have an alpha channel.

My tests confirm everything that I have read about minimising draw calls. Have as few objects/nodes in a model as possible. That means an optimised ore car will have 4 wheels, 2 bogies and 1 body object. That is 7 draw calls for the objects and 1 draw call for the single texture file with no alpha for the complete ore car. Each animated part of the motion in a steam locomotive, or animated control / gauge in a 3D cab view adds an additional draw call but that is unavoidable.

That being said, one of my currently un-optimised 3D cab views generates 77 draw calls because of all the animations in the multi function display screen. To offset this the cab only uses 4 x 4K textures (2 for external body and 2 for cab internal) and only one of those textures has an alpha channel. This cab view still gives me 120 FPS on my 2^nd Gen 3.6HHz i7 and RTX2070.



I suspect that having an individual texture per animation part is going to increase the draw calls and if that texture is using the alpha channel then that adds yet another draw call.

Unfortunately, as far as I can tell all the current .S viewers do not display the number of draw calls. I'm moving to glTF so what I do is export the model as a .glb file and then open it with the Windows default 3D viewer, or drag the .glb file to one of the online glTF/glb viewers like https://github.khronos.org/glTF-Sample-Viewer-Release

In the Windows default 3D viewer the draw calls are shown in the Performance data section. At the Kronos web site, in the Advanced Controls > Statistics section, the ‘Mesh Count’ is the equivalent to draw calls.

In summary, triangle count has less impact than number of nodes, number of textures and number of textures that have an alpha channel.

Hope this helps.

Also, do you have or want photo images for your wiper motors? Unsurprisingly, it appears ALCO used the same wiper motors in the M636.

Cheers,

Marek.

Hi Marek,

What a good idea on testing poly count - subdividing the surface. I'll have to give that a try.

My understanding of Draw Calls and performance comes from conversations with Wayne.

Yep - 7 draw call is the absolute minimum for a standard 2 truck 4 axle freight car. Hierarchy view in Paul's Shape Viewer would show you the draw calls on a model - no?

Every animated object spawns a new draw call. That's why I break out gauge needles and such to tiny textures as they will be called repeatedly.

Yep - changing the material type is a new draw call - in the old days - I used to alpha the entire body texture atlas - so i didn't need to spawn a new call just for the few parts that needed alpha. Alpha itself is cheap when transparent - translucent is more expensive for performance. All my glass faces share a smaller glass texture.

The first thing I do when Pete issues a new exporter - is change these two values in the beginning. The initial values were intended to support MSTS - and are impractical for ORTS. By default, sub objects spawn a whole new set of draw calls every 2666 polys. Steve clued me in to these settings. The following seem to work well for me.

MaxVerticesPerPrimitive = 24000 # Triangle index entries per draw call (8,000 triangles).
MaxVerticesPerSubObject = 60000 # Unique exported vertices; below the 65,536 index range.

I'm at like 24 draw call on my Alco. I used several repeating textures where I am not worried about baking in detail or AO.

It's always good to compare notes.

Thanks for writing this all up. I have some new things to try.


Regards,
Scott

[pwillard]

Each time Pete issues a new exporter... Pete has a little nervous breakdown worrying if they just made things worse instead of better.

[scottb613]

Each time Pete issues a new exporter... Pete has a little nervous breakdown worrying if they just made things worse instead of better.

Hi Pete,

Hah - don't sweat it - we break it - we fix it.


I just got my full Alco pack ported to GLB/PBR format - using the new REAL LIGHTS.

Regards,
Scott

[UP6706]

It won't be usable until ORTS adds support for PBR graphics in the stable version, I mean GITF.

[scottb613]

It won't be usable until ORTS adds support for PBR graphics in the stable version, I mean GITF.

Hi.

Understood - personally - I haven't run STABLE in many years.

Regards,
Scott

[pwillard]

I really do need to see this new method actually work for me personally. It would also reduce developers' dependence on the legacy S file and ACE/DDS files.

A side note, though: Currently, we can make the Blender S file exporter do more than just export the shape. For glTF, we are stuck with someone else's idea of a generic export tool... so no special features (though I'll agree with the sentiment that "export" is all that is really needed)

[scottb613]

I really do need to see this new method actually work for me personally. It would also reduce developers' dependence on the legacy S file and ACE/DDS files.

A side note, though: Currently, we can make the Blender S file exporter do more than just export the shape. For glTF, we are stuck with someone else's idea of a generic export tool... so no special features (though I'll agree with the sentiment that "export" is all that is really needed)

Hi Pete,

Yeah - it's worth the effort - I can send you my blend or runtime - if desired.

Regards,
Scott

[superheatedsteam]

A side note, though: Currently, we can make the Blender S file exporter do more than just export the shape. For glTF, we are stuck with someone else's idea of a generic export tool... so no special features (though I'll agree with the sentiment that "export" is all that is really needed)

The github page indicates that extensions can be added to the exporter.

https://github.com/KhronosGroup/glTF-Blender-IO

Cheers,

Marek.

[UP6706]

Do you only run unstable for the GITF format support?

[superheatedsteam]

Do you only run unstable for the GITF format support?

Yes.