In this section, we explain how to place and use imported switches in SubwaySim 2 and when they are required.

Imported switches are used whenever the Railtool does not support a specific track layout. Typical examples include:

• double crossovers
• double slip switches
• special or asymmetric switch constructions

Because these layouts can be very complex and highly individual, they are created manually in a 3D application (such as Blender) and then imported into SubwaySim 2 as finished switch assets.

The Railtool supports:

• standard turnouts
• simple crossovers
• regular procedural track geometry

However, some switch types are:

• too complex
• too custom
• or too irregular

to be generated procedurally.

In these cases, imported switches are the intended and correct solution.

SubwaySim 2 already includes a large collection of imported switches used by the base game.

They can be found inside the SubwaySim2_Modding plugin under:

SubwaySim2_Modding / RailwaySystem / ImportedSwitches

This folder contains many ready-made switches that can be used directly in custom maps.

Important:

• Always use the BP_… variants
• Only these Blueprint actors contain the required logic for routing and Railtool integration

To place an imported switch in your level:

• Make sure you are in Selection Mode in the Unreal Editor

(not Railtool mode)

• Navigate to:

SubwaySim2_Modding / RailwaySystem / ImportedSwitches

• Drag the desired BP_ImportedSwitch Blueprint into the level

After placing the switch:

• it can be freely moved
• it can be rotated as needed
• positioning is done manually

Take your time to align the switch correctly with your intended track layout.

Once the switch is placed:

• switch to the Railtool

→ Laying Tracks

• use the Control Points of the imported switch
• connect Railtool track splines to the switch just like normal track elements

After this step:

• the imported switch behaves like any other Railtool-connected track
• AI routing, signaling, and dispatching can work normally

If none of the provided switches fit your needs, you can create your own imported switch.

Typical reasons include:

• unique geometry
• special crossover layouts
• prototype or fictional designs

Creating a custom imported switch involves:

• modeling the switch in a 3D tool (e.g. Blender)
• preparing meshes and pivots correctly
• importing the assets into the SDK
• creating the required Blueprint setup

This process will be explained in the next section.

Imported switches are used when the Railtool cannot generate a special switch type reliably.

Most standard switches can be created directly with the Railtool. However, more complex constructions (for example double crossovers / DKW, EKW, DW, or special custom geometry) vary a lot between networks and often require manual modelling.

In those cases, the switch is built in a 3D program (usually Blender), exported as FBX, imported into SubwaySim 2, and finally wrapped into a Blueprint so the Railtool can use it like any other switch.

This page covers:

• when imported switches are needed
• using already included imported switches from the SDK
• the full pipeline for creating your own imported switch:

modelling → paths → export → import → animations → Blueprint → Railtool connection

Use imported switches when:

• the Railtool does not support the geometry (e.g. DKW, EKW, DW, special crossovers)
• your switch has a non-standard shape/radius/angle that cannot be generated cleanly
• you need an exact real-world design
• you need special frog/guard layouts or unique sleeper/gear parts

You do NOT need imported switches for:

• normal crossings (they have no moving parts)
• standard left/right switches supported by Railtool

Crossings (no moving parts) are generated by Railtool and do not need custom building.

The Modding SDK already ships with a variety of imported switches used by the base game.

You can find them here:

SubwaySim2_Modding / RailwaySystem / ImportedSwitches

Inside this folder, you will see many switch assets.

Important:

• Only use the BP_… Blueprints for placement in levels.
• The Blueprints contain the configuration needed for Railtool and animations.

1. Make sure you are in Selection Mode in the Unreal Editor

 (important: not in Railtool mode while placing the BP)

2. Drag a BP_… imported switch into your level.

3. You can freely move and rotate it like any normal actor.

4. Once positioned:

 go to the Railtool track workflow:
 [[manual:subwaysim:map_construction:laying_tracks|Laying Tracks]]

5. Connect the switch using ControlPoints exactly like a normal Railtool switch.

The imported switch behaves like a normal switch after it is connected.

This section explains the full workflow for building your own switch.

Overview:

1) Planning & naming
2) Modelling rails + frogs + guards
3) Creating drivable paths (very important)
4) Sleepers, clamps, gravel
5) UVs & materials
6) Rigging blades + throw bars
7) Animations (NLA)
8) Export FBX
9) Import into Unreal (SkeletalMesh, StaticMeshes, paths, animations)
10) Animation Blueprint (ABP)
11) Switch Blueprint (RTImportedSwitchActor)
12) Test in level + connect with Railtool

We follow the same principles used for base game switches.

This is a quick translation list used in references and modelling:

We generally build everything in the 60E1 rail profile. (That means your rail meshes, trims, and dimensions match the 60E1 standard assets.)

The blade rail is the moving part of the switch. The stock rail is the fixed rail the blade presses against.

Key details:

• The blade starts thin and gradually becomes thicker until it transitions into a near-normal rail profile.
• The stock rail also changes shape around the blade area.
• The blade sits slightly higher than the standard rail but must keep the correct track gauge.

This transition is critical:

• visually (looks correct)
• physically (wheels can pass)
• for flangeway clearance at the frog and guards

The frog is where rails intersect and split.

It is usually the most complex part because:

• rail geometry intersects
• flangeway must remain correct
• wings and guard guidance must prevent derailment
• some switch types have double or triple frog variants

The throw bar and motor move the blades.

Important behavior:

• Blades do NOT start moving at exactly the same time
• One blade starts slightly earlier than the other (realistic behavior)
• Some switches can also use manual levers instead of motors

If you simulate the blade movement:

• include this offset in the animation curves
• make sure throw bar geometry doesn’t clip

Guard rails and guide rails keep wheels aligned over frogs.

• Guard rails prevent the wheelset from drifting sideways at the frog.
• Guide rails are used when geometry is tight or guard rails don’t fit.

When a guard rail does not fit cleanly:

• add a small guide rail piece (look at existing switches for reference)

Switches use several clamp types:

• normal rail clamps
• blade clamps
• guard clamps
• special clamps where space is too tight

Clamps often become the biggest performance cost if modelled fully. (We cover optimization later.)

Crossings are NOT switches. They have no moving parts. Railtool can generate them → no custom build required.

A standard switch (single turnout) can be generated by Railtool. No custom build needed in most cases.

DW is basically two switches extremely close together that intersect. These currently must be custom built because Railtool cannot reliably generate them.

EKW is a crossing with a switch integrated. Custom build required.

DKW is like EKW but allows switching between tracks in multiple directions. Even more complex → custom build required.

DKW has two typical constructions:

• blades outside the two frogs
• blades inside the frogs

Outside blades:

• more complex to build
• often allow higher speeds

Inside blades:

• easier geometry
• often tighter constraints

Before modelling, decide:

• rail profile (we assume 60E1)
• radius (e.g. 100 m)
• angle ratio (e.g. 1:6)
• direction pattern (left/right sequence)

Example naming:

DW-60E1-100-6:1LR

If your toolchain doesn’t like “:”:

DW-60E1-100-1_6LR

Keep the naming consistent across:

• Blender file collection names
• exported FBX names
• Unreal folders
• Blueprint names

This section describes the modelling workflow used for complex switches.

We assume you are working inside a prepared file like:

60E1-Rail.blend

which already contains prepared meshes.

Follow the existing folder/collection structure:

• create a new Collection for your switch
• keep rails, sleepers, clamps, paths separated

We start by defining the geometry using curves.

Example: angle 1:6

1) Place a vertex at world origin. 2) Extrude 6 m on X 3) Extrude 1 m on Y 4) Fill the triangle

The triangle edge length “c” (approx 6.08 m) will be used for alignment.

Next:

• Create a 100° circle
• Align the bottom vertex of the circle to the world origin
• Use a high vertex count divisible by 4

(example: 1024 verts) with ~0.6 m edge length

Then:

• delete unnecessary verts
• extrude the triangle edge “c”
• move the circle along X until it is tangent to “c”

How to align precisely:

• use snapping (active element)
• pick a vert, select all, edge snap to “c”
• if still crossing, pick another vert

Now you have the left curve.

For the right curve:

• duplicate the first
• move so its start sits at the origin
• rotate 180° or mirror along X

Add a straight section, convert everything to curves.

You now have the main curve layout.

Paths define where trains can drive. They must match exactly wherever paths intersect.

Workflow:

• duplicate the curves
• convert to meshes
• shorten ends slightly
• ensure all paths start at the same point if required
• extrude edges 0.1 m upwards for better visibility

Naming recommendation:

• PathLeft
• PathRight
• PathStraight
• (and any additional needed)

Critical rule:

• Wherever paths intersect, they must share identical vertex positions.
• If the vertices don’t match, routing can break or trains can “jump”.

These path meshes are exported and later referenced inside the Switch Blueprint configurations.

Rails:

• Take 60E1Double mesh
• duplicate it
• add Array modifier (enable Merge)
• add Curve modifier using one of your curves
• repeat for all rail segments

Flangeway:

• do the same with the “Abstand” mesh (wheel space indicator)

Now you should see rails and flangeway along curves.

Take an existing sleeper mesh:

• usually WoodenSleeper2.6

Add:

• constant offset array: 0.6 m (distance)
• curve modifier on each curve

After merging / lengthening / stitching, you should see sleepers aligned under the rails.

At first it will look wrong because rails overlap.

Step 1: Cut out the intersection areas

• remove mesh parts where flangeway and rail intersect

Step 2: Model the frog geometry

• extend rails to intersection points
• use references
• add wings
• ensure flangeway stays correct

Frogs can look weird in Blender:

• that’s normal
• focus on real clearances and reference alignment

Blades:

• start from BladeRailDouble mesh
• curve it along blade curves
• rotate if needed so thick part is near center
• duplicate segments (thin end, mid, thick)
• move segments where blade starts intersecting
• delete the “wrong” blade side faces

Then:

• bridge edges between segments (linear)
• add enough cuts so each segment is about 0.6 m long
• sharpen thin end edges
• apply curve modifier

Stock rails:

• duplicate StockRailDouble
• curve it along the corresponding rail
• repeat same for every blade area

Goal:

• the blade sits correctly against stock rail
• no gauge errors
• no wheel clearance issues

Guard rail:

• duplicate GuardRailDouble
• curve it along needed areas
• trim if needed

If guard does not fit:

• add a guide rail piece (small metal guide)
• use existing switches as style reference

Hollow sleeper (tub):

• use existing HollowSleeper mesh
• place at blade ends between two sleepers
• ensure steel doesn’t intersect anything

Throw bar:

• place ThrowBar + ThrowBarNuts at same location
• align to blade ends

Make sure:

• throw bar doesn’t clip
• blades have enough clearance for motion

Clamps are placed individually because:

• arrays do not allow unique pivots for rotation
• clamps must match rail curvature and sleeper placement

Workflow:

1) add a longitudinal edge loop through sleepers (helper)
2) add a longitudinal edge loop through rails (except blades)
3) take RailClamp mesh
4) edge snap to middle of sleeper and middle of rail
5) duplicate along X by 0.6 m (sleeper spacing)
6) Shift+R to repeat until full length
7) rotate each clamp individually to match rail direction
8) special cases: if clamps clip, separate and make a “special clamp”

Blade clamps:

• use ClampK_BladeBUILD on stock rail near blades

Guard clamps:

• use ClampK_GuardBUILD on guard rails

Performance note:

• clamps can become huge triangle counts
• see Optimization section

Correct way (more work, best performance):

• separate clamps into types
• add sockets to clamp positions
• record single/double clamp type
• place clamps as instanced meshes in Unreal
• most efficient for symmetrical switches (DKW quarters)

Lazy way (often acceptable):

• export clamps as a separate StaticMesh
• add aggressive LODs to reduce cost

For most mod projects:

• start with the lazy way
• optimize later if needed

Pick gravel mesh:

• GravelOEBB or GravelSubway depending on context

Then:

• curve modifier on gravel (often multiple passes)
• apply modifiers
• merge parts to avoid overlaps / Z-fighting
• ensure ends connect cleanly to regular track gravel

UV note:

• gravel must match texel density of base gravel mesh
• project from view (top-down) and apply same tx density

We use a tileable trimsheet (RailTileSet).

Workflow:

• select shiny metal parts → cube project → tx density 5.12 px/cm at 1k
• move those UVs to shiny section (upper part)
• rust parts → second section
• repeat for wood/concrete sections

Tip:

• keeping consistent texel density avoids mismatched appearance next to base assets

Imported switches need blade animations.

We use an Armature.

1) Create root bone:

 Name: Rail

2) Assign Rail vertex group to all non-moving meshes:

 (rails, frogs, guards, sleepers, gravel, clamps etc. depending on your setup)

Quick workflow:

• merge those meshes temporarily
• select all faces
• CTRL+G → assign to group “Rail”

3) For each blade:

• create a bone at the thick end
• move end to thin end
• subdivide twice → 4 bones per blade
• align bones to curved blade centerline

Naming convention:

Blade(FromTo)_(L/R)(Index)

Examples:

• BladeLR_L1
• BladeLR_L2
• BladeRL_R3

Throw bars:

• vertex group named after attached blade bone group, with final number

Skinning:

• parent blades to armature with automatic weights
• verify in pose mode that skinning is correct

A DW example usually has 2 animations:

• BladeSwitch1 (SW1) → first blade pair
• BladeSwitch2 (SW2) → second blade pair

Workflow (example timing):

• frame 1: one blade side closed
• frame 20: other side begins
• frame 80: return to neutral for one side
• frame 100: other side reaches switched end

Example rotation:

• R1: 1°
• R2: 0.5°
• (values depend on geometry, adjust for clearance)

Important:

• ensure flangeways pass without clipping
• throw bar doesn’t intersect hollow sleeper
• set graph curves to linear
• export animations as NLA strips

Make sure:

• both animations exist as NLA strips
• naming matches what you will reference in Unreal

Export settings:

• Use the same settings as vehicle exports for meshes
• Use animation export settings for animations

Export groups:

• SkeletalMesh FBX (with armature + blades)
• Animations FBX (or together depending on workflow)
• StaticMeshes FBX (sleepers/clamps/gravel if separate)
• Paths FBX (all path meshes can be in one FBX)

For paths:

• Turn off Combine Meshes on import later
• Ensure path names are clean and unique

Folder structure:

• follow the SDK naming/folder conventions consistently

Import categories:

Import the SkeletalMesh like a vehicle asset:

• place it into your ImportedSwitch folder structure
• then import animations into an Animations subfolder

Verify:

• skeleton is correct
• animations play in animation preview

StaticMeshes:

• import normally

Paths:

• can be imported from one FBX
• IMPORTANT: disable Combine Meshes so each path becomes its own StaticMesh
• verify each path mesh exists:

PathLeft / PathRight / PathStraight / …

Create an Animation Blueprint for the switch.

Rules:

• place it near other imported switch ABPs
• follow naming conventions
• Parent Class must be: Lua Anim Instance

Workflow:

• copy an existing imported switch ABP
• create variables for SW1 / SW2 (or your needed blade groups)
• assign your Anim Sequences to those variables
• update Layered Blend per Bone with your bone names

(triple-check typos and correct order)

If blades don’t move:

• bone names wrong
• wrong skeleton
• animations not assigned
• not exported as NLA

In this step we create the Blueprint Actor that RailTool uses.

The Blueprint combines:

• SkeletalMesh component
• StaticMeshes (optional)
• Animation Blueprint
• RailTool2 SwitchConfigurations (critical)

1) Create Blueprint Class 2) Parent Class:

 RTImportedSwitchActor

3) Name it coherently:

 BP_IS_DW_60E1_100_1_6LR

SkeletalMesh component:

• assign your SkeletalMesh
• assign Animation Blueprint

Optional:

• add StaticMesh components for clamps/gravel/sleepers if separate

Open Details:

RailTool2 → SwitchConfigurations

Add entries for each valid route through the switch.

Each configuration links:

• a Path mesh
• blade state values (SW1 / SW2 / …)

State values are usually discrete (0 / 1 / 2) depending on ABP logic.

Example logic:

• Left route:

Path = PathLeft

    SW1 = 1
    SW2 = 0
* Right route:
    Path = PathRight
    SW1 = 0
    SW2 = 2

Use configuration index cycling for debugging:

• 0 first config, 1 second, etc.

If you see no changes:

• ABP variables wrong
• animations not assigned
• bone names mismatch

Common toggles:

• Gravel visibility (bridge/slab track use)
• sleeper variant selection (wood vs concrete)

Implement by:

• exposed variables
• Set Visibility in Construction Script

Add switch motor meshes if needed.

Workflow:

• determine motor transform in Blender
• copy relative location/rotation into Blueprint
• optionally use an enum (MotorPosition) like base switches

1) Ensure you are in Selection Mode 2) Drag the BP_… imported switch into the level 3) Move/rotate it into position 4) Connect with Railtool ControlPoints:

 [[manual:subwaysim:map_construction:laying_tracks|Laying Tracks]]

Important:

• after connection, validate routes by driving AI/player across each path
• check for clipping at frogs and blade ends
• verify blade animations match selected route

Example 1:6

1/6 = 0.1666...
atan(0.1666...) = 9.462322208...

Rounded to 4 decimals:

9.4623°

You can keep a list of known angles to avoid repeating the math.

• Paths do not share identical vertices at intersections
• Wrong pivot/orientation → switch doesn’t align with tracks
• ABP bone names mismatch → blades never move
• SwitchConfigurations missing/incorrect → trains take wrong routes
• Frog flangeway clearance wrong → derail-looking behavior / clipping
• Clamp geo too heavy → performance issues (use LODs or instancing later)
• Gravel overlaps existing ground → add toggle visibility

After your imported switch works in-game:

• place more of them as needed
• connect them with Railtool
• continue with the rest of the map workflow

Back to:

• Laying Tracks