SubwaySim Wiki

User Tools

Site Tools

Trace: • troubleshooting
manual:subwaysim:map_construction:importing_switches

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
manual:subwaysim:map_construction:importing_switches [2026/01/21 11:32] – dcsmanual:subwaysim:map_construction:importing_switches [2026/01/21 12:17] (current) – dcs
Line 1: Line 1:
 ====== Importing Switches ====== ====== Importing Switches ======
  
-In this section, we explain how to **place and use imported switches** in SubwaySim 2 and when they are required.+Imported switches are used when the Railtool cannot generate a special switch type reliably.
  
-Imported switches are used whenever the **Railtool does not support a specific track layout**. +Most standard switches can be created directly with the Railtool. 
-Typical examples include: +However, more complex constructions (for example **DW**, **EKW**, **DKW**, special double crossovers, or asymmetric real-world layouts) vary a lot between networks and often require manual modelling.
-  * 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.+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
  
 ---- ----
  
-===== When Are Imported Switches Required? =====+===== 1) When Do You Need Imported Switches? =====
  
-The Railtool supports: +Use imported switches when: 
-  * standard turnouts +  * the Railtool does not support the geometry (e.g. **DKW**, **EKW**, **DW**, special crossings, double crossovers) 
-  * simple crossovers +  * your switch has a non-standard shape/radius/angle that cannot be generated cleanly 
-  * regular procedural track geometry+  * you need an exact real-world design 
 +  * you need special frog/guard layouts or custom sleeper/gear parts
  
-However, some switch types are: +You do NOT need imported switches for: 
-  * too complex +  * normal crossings (they have no moving parts) 
-  * too custom +  * standard left/right turnouts supported by Railtool
-  * or too irregular+
  
-to be generated procedurally. +Crossings (no moving parts) are generated by Railtool and do not need custom building.
- +
-In these cases, **imported switches** are the intended and correct solution.+
  
 ---- ----
  
-===== Built-in Imported Switches =====+===== 2) Using Built-in Imported Switches (SDK / Base Game) =====
  
-SubwaySim 2 already includes a large collection of imported switches used by the base game.+The Modding SDK ships with a variety of imported switches that are used by the base game.
  
-They can be found inside the **SubwaySim2_Modding** plugin under:+You can find them here:
  
   SubwaySim2_Modding / RailwaySystem / ImportedSwitches   SubwaySim2_Modding / RailwaySystem / ImportedSwitches
  
-This folder contains many ready-made switches that can be used directly in custom maps.+Inside this folder, you will see many switch assets.
  
 Important: Important:
-  * Always use the **BP_...** variants +  * Only use the **BP_...** Blueprints for placement in levels. 
-  * Only these Blueprint actors contain the required logic for routing and Railtool integration+  * The Blueprints contain the configuration needed for Railtool and animations. 
 +  * StaticMeshes / SkeletalMeshes alone are NOT enough.
  
 {{:manual:subwaysim:importing_switches:switch1.png?direct&800|}} {{:manual:subwaysim:importing_switches:switch1.png?direct&800|}}
Line 49: Line 51:
 ---- ----
  
-===== Placing an Imported Switch =====+==== 2.1 Placing an Imported Switch in the Level ====
  
-To place an imported switch in your level:+1. Make sure you are in **Selection Mode** in the Unreal Editor   
 +   (important: not in Railtool mode while placing the BP)
  
-  * Make sure you are in **Selection Mode** in the Unreal Editor   +2. Drag the desired **BP_...** imported switch into your level.
-    (not Railtool mode)+
  
-  * Navigate to:   +3. You can freely move and rotate it like any normal actor.
-    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.+4. Align it to your intended layout. 
 +   (This is manual placement, so take your time.)
  
 {{:manual:subwaysim:importing_switches:switch2.png?direct&800|}} {{:manual:subwaysim:importing_switches:switch2.png?direct&800|}}
Line 72: Line 67:
 ---- ----
  
-===== Connecting Imported Switches to Tracks =====+==== 2.2 Connecting the Switch to Railtool Tracks ====
  
-Once the switch is placed:+Once the switch is placed, it needs to be connected to the Railtool track network:
  
-  * switch to the Railtool  +  * Switch to the Railtool workflow:
     → [[manual:subwaysim:map_construction:laying_tracks|Laying Tracks]]     → [[manual:subwaysim:map_construction:laying_tracks|Laying Tracks]]
  
-  * use the **Control Points** of the imported switch +  * Use the **Control Points** of the imported switch 
-  * connect Railtool track splines to the switch just like normal track elements+  * Connect your Railtool track splines to those Control Points (same idea as normal Railtool elements)
  
 After this step: After this step:
-  * the imported switch behaves like any other Railtool-connected track +  * the imported switch behaves like a normal track element 
-  * AI routing, signaling, and dispatching can work normally+  * AI routing and signaling can work, as long as the surrounding network is valid
  
 {{:manual:subwaysim:importing_switches:switch3.png?direct&800|}} {{:manual:subwaysim:importing_switches:switch3.png?direct&800|}}
Line 90: Line 85:
 ---- ----
  
-====== Creating Your Own Imported Switches ======+===== 3) Creating Your Own Imported Switches =====
  
 If none of the provided switches fit your needs, you can create your own imported switch. If none of the provided switches fit your needs, you can create your own imported switch.
Line 98: Line 93:
   * special crossover layouts   * special crossover layouts
   * prototype or fictional designs   * prototype or fictional designs
 +  * real-world designs that differ from the base assets
  
-Creating a custom imported switch involves: +The full workflow looks like this:
-  * 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. 
- 
----- 
- 
-====== Importing Switches ====== 
- 
-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 
- 
----- 
- 
-===== 1) When Do You Need Imported Switches? ===== 
- 
-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. 
- 
----- 
- 
-===== 2) Using SDK Imported Switches ===== 
- 
-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. 
- 
----- 
- 
-==== 2.1 Placing an Imported Switch in a Level ==== 
- 
-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. 
- 
----- 
- 
-===== 3) Building Your Own Imported Switch ===== 
- 
-This section explains the full workflow for building your own switch. 
- 
-Overview: 
   1) Planning & naming   1) Planning & naming
   2) Modelling rails + frogs + guards   2) Modelling rails + frogs + guards
-  3) Creating drivable paths (very important)+  3) Creating drivable paths (critical!)
   4) Sleepers, clamps, gravel   4) Sleepers, clamps, gravel
   5) UVs & materials   5) UVs & materials
Line 195: Line 110:
   12) Test in level + connect with Railtool   12) Test in level + connect with Railtool
  
-We follow the same principles used for base game switches.+This is the same concept used by base game imported switches.
  
 ---- ----
Line 201: Line 116:
 ===== 4) Terminology (German + English) ===== ===== 4) Terminology (German + English) =====
  
-This is a quick translation list used in references and modelling:+Quick translation list used in references and modelling:
  
 ^ English ^ German ^ ^ English ^ German ^
Line 222: Line 137:
  
 We generally build everything in the **60E1 rail profile**. We generally build everything in the **60E1 rail profile**.
-(That means your rail meshes, trims, and dimensions match the 60E1 standard assets.)+ 
 +That means: 
 +  * your rail meshes match the prepared 60E1 assets in the SDK 
 +  * your dimensions, trims, and clearances align with existing track content
  
 ---- ----
Line 239: Line 157:
   * visually (looks correct)   * visually (looks correct)
   * physically (wheels can pass)   * physically (wheels can pass)
-  * for flangeway clearance at the frog and guards+  * for flangeway clearance at frog and guards
  
 ---- ----
Line 250: Line 168:
   * rail geometry intersects   * rail geometry intersects
   * flangeway must remain correct   * flangeway must remain correct
-  * wings and guard guidance must prevent derailment+  * wings and guard guidance must prevent derailment / clipping
   * some switch types have double or triple frog variants   * some switch types have double or triple frog variants
  
Line 264: Line 182:
   * Some switches can also use manual levers instead of motors   * Some switches can also use manual levers instead of motors
  
-If you simulate the blade movement: +If you animate blade movement: 
-  * include this offset in the animation curves+  * include this offset in timing/curves
   * make sure throw bar geometry doesn’t clip   * make sure throw bar geometry doesn’t clip
  
Line 278: Line 196:
  
 When a guard rail does not fit cleanly: When a guard rail does not fit cleanly:
-  * add a small guide rail piece (look at existing switches for reference)+  * add a small guide rail piece 
 +  * look at previously made switches for style reference
  
 ---- ----
Line 295: Line 214:
 ---- ----
  
-===== 6) Switch Types (Crossing, Normal Switch, DW, EKW, DKW) =====+===== 6) Switch Types (Crossing, Switch, DW, EKW, DKW) =====
  
 ==== 6.1 Rail Crossing ==== ==== 6.1 Rail Crossing ====
Line 344: Line 263:
  
 Inside blades: Inside blades:
-  * easier geometry+  * simpler geometry
   * often tighter constraints   * often tighter constraints
  
Line 360: Line 279:
   DW-60E1-100-6:1LR   DW-60E1-100-6:1LR
  
-If your toolchain doesn’t like “:”:+Some softwares don’t like “:” so you may see:
   DW-60E1-100-1_6LR   DW-60E1-100-1_6LR
  
Line 373: Line 292:
 ===== 8) Modelling in Blender ===== ===== 8) Modelling in Blender =====
  
-This section describes the modelling workflow used for complex switches.+We assume you are working inside a prepared file like:
  
-We assume you are working inside a prepared file like: 
   60E1-Rail.blend   60E1-Rail.blend
-which already contains prepared meshes. 
  
-Follow the existing folder/collection structure:+This file already contains prepared meshes and references. 
 +Follow its folder / collection structure:
   * create a new Collection for your switch   * create a new Collection for your switch
   * keep rails, sleepers, clamps, paths separated   * keep rails, sleepers, clamps, paths separated
Line 385: Line 303:
 ---- ----
  
-==== 8.1 Curves and Paths (The Foundation) ====+==== 8.1 Curves and Paths (Foundation) ====
  
-We start by defining the geometry using curves.+First we set up our angle, example **1:6**:
  
-Example: angle 1:6+  1) Place a single vertex in world origin 
 +  2) Extrude it 6 m along X-Axis 
 +  3) Extrude it 1 m along Y-Axis 
 +  4) Fill the 2 lonely verts → you now have a triangle
  
-1) Place a vertex at world origin. +The edge that is ~6.08 m long will be called **“c”**.
-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 we make a 100° circle and align it so that the bottom vertex sits in the origin. 
 +Recommended: 
 +  * a vertex count divisible by 4 
 +  * individual edge length ~0.6 m (as close as possible) 
 +Example: 1024 verts.
  
-Next: +Delete unnecessary verts (keep only the range you need).
-  * 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: +Now:
-  * delete unnecessary verts+
   * extrude the triangle edge “c”   * extrude the triangle edge “c”
-  * move the circle along X until it is tangent to “c”+  * move the circle along X until the circle is tangent to “c”
  
-How to align precisely: +How to align precisely (recommended): 
-  * use snapping (active element) +  * enable snapping (active element) 
-  * pick a vert, select all, edge snap to “c” +  * select a vertex, then select all verts 
-  * if still crossing, pick another vert+  * edge snap it to “c” 
 +  * if still crossing the edge, select another vertex 
 +This is faster and more precise than eyeballing.
  
-Now you have the left curve.+Now you have the left curve more or less done.
  
-For the right curve: +You still need a right curve: 
-  * duplicate the first +  * duplicate the first curve 
-  * move so its start sits at the origin +  * move it so that the very start sits in world origin 
-  * rotate 180° or mirror along X+  * rotate by 180° / mirror along X
  
-Add a straight section, convert everything to curves. +Now add a straight edge, convert them to curves. 
- +At this point your switch layout curves should look correct.
-You now have the main curve layout.+
  
 ---- ----
  
-==== 8.2 Creating Drivable Paths (Export-Ready) ====+==== 8.2 Creating Drivable Paths (Export-Ready / Critical!) ====
  
 Paths define where trains can drive. Paths define where trains can drive.
-They must match exactly wherever paths intersect.+They MUST be correct, otherwise routing will fail.
  
 Workflow: Workflow:
-  * duplicate the curves+  * duplicate your curves
   * convert to meshes   * convert to meshes
-  * shorten ends slightly +  * cut them short a bit 
-  * ensure all paths start at the same point if required +  * make sure they all start at the same point (if your layout requires it) 
-  * extrude edges 0.1 m upwards for better visibility+  * extrude the edges 0.1 m up so they are easier visible 
 + 
 +Important rule: 
 +  * Wherever paths intersect, they must share IDENTICAL vertex positions. 
 +  * The paths need the exact same verts wherever they intersect.
  
 Naming recommendation: Naming recommendation:
Line 443: Line 365:
   * PathRight   * PathRight
   * PathStraight   * PathStraight
-  * (and any additional needed)+(and more if needed)
  
-Critical rule: +These paths will later be referenced inside the Switch Blueprint SwitchConfigurations.
-  * 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.+
  
 ---- ----
Line 456: Line 374:
  
 Rails: Rails:
-  * Take 60E1Double mesh+  * take the 60E1Double mesh
   * duplicate it   * duplicate it
-  * add Array modifier (enable Merge) +  * add an Array modifier (enable “Merge”) 
-  * add Curve modifier using one of your curves +  * add a Curve modifier and select one of your curves 
-  * repeat for all rail segments+  * repeat for all required rail segments
  
-Flangeway: +Flangeway / wheel space: 
-  * do the same with the “Abstand” mesh (wheel space indicator)+  * do the same with the “Abstand” mesh (shows the wheel clearance / flangeway)
  
-Now you should see rails and flangeway along curves.+After that you should have rails + clearance along the curves.
  
 ---- ----
Line 471: Line 389:
 ==== 8.4 Sleepers (Array on Curves) ==== ==== 8.4 Sleepers (Array on Curves) ====
  
-Take an existing sleeper mesh: +Next, sleepers: 
-  * usually WoodenSleeper2.6+  * take an existing sleeper mesh (often WoodenSleeper2.6) 
 +  * add a constant offset array of 0.6 m (if not already existing) 
 +  * add a curve modifier and put it onto the curves
  
-Add: +After lengthening and vertex merging you should have sleepers aligned.
-  * constant offset array: 0.6 m (distance) +
-  * curve modifier on each curve +
- +
-After merging / lengthening / stitching, you should see sleepers aligned under the rails.+
  
 ---- ----
  
-==== 8.5 Frogs: Cut, Stitch, Model =====+==== 8.5 Frogs: Cut-Out + Stitching the Heart ====
  
-At first it will look wrong because rails overlap.+At first the frog area will look wrong because rails intersect.
  
-Step 1: Cut out the intersection areas +Step 1: Cut out the parts where the flangeway and rail intersect.
-  * remove mesh parts where flangeway and rail intersect+
  
-Step 2: Model the frog geometry +Step 2: Model the frog: 
-  * extend rails to intersection points +  * lengthen rails to the intersecting points 
-  * use references +  * use references (real photos or existing switches) 
-  * add wings +  * don’t forget the wings 
-  * ensure flangeway stays correct+  * keep flangeway clearance correct
  
-Frogs can look weird in Blender: +Frogs will always look a bit weird in Blender – don’t worry. 
-  * that’s normal +Focus on clearance and correct geometry.
-  * focus on real clearances and reference alignment+
  
 ---- ----
  
-==== 8.6 Blades + Stock Rails =====+==== 8.6 Blades + Stock Rails ====
  
 Blades: Blades:
-  * start from BladeRailDouble mesh +  * take BladeRailDouble mesh 
-  * curve it along blade curves +  * put it on the curves you need 
-  * rotate if needed so thick part is near center +  * rotate if needed (thick part should be as close to center as possible) 
-  * duplicate segments (thin end, mid, thick) +  * duplicate the middle piece and move both the second middle and thin end piece to where the blade starts intersecting with the rail 
-  * move segments where blade starts intersecting +  * move the thin end to where the blade ends 
-  * delete the “wrong” blade side faces+  * delete the face from the “wrong” blade
  
-Then: +Now: 
-  * bridge edges between segments (linear) +  * select each segment and bridge edges (linear) 
-  * add enough cuts so each segment is about 0.6 m long +  * add as many cuts as needed so each segment is about 0.6 m long 
-  * sharpen thin end edges +  * delete unneeded faces 
-  * apply curve modifier+  * sharpen the thin end edges 
 +  * apply the curve modifier
  
-Stock rails:+Stock rail:
   * duplicate StockRailDouble   * duplicate StockRailDouble
-  * curve it along the corresponding rail +  * add curve modifier 
-  * repeat same for every blade area+  * align it to the corresponding rail 
 +Repeat for all blade/stock sections.
  
 Goal: Goal:
-  * the blade sits correctly against stock rail +  * blade sits correctly against stock rail 
-  * no gauge errors +  * gauge stays correct 
-  * no wheel clearance issues+  * no clearance issues
  
 ---- ----
  
-==== 8.7 Guards and Guides =====+==== 8.7 Guards and Guides ====
  
 Guard rail: Guard rail:
-  * duplicate GuardRailDouble +  * duplicate GuardRailDouble mesh 
-  * curve it along needed areas +  * put it on the required curve segments 
-  * trim if needed+  * trim it if needed
  
-If guard does not fit: +If a guard does not fit: 
-  * add a guide rail piece (small metal guide) +  * add a small metal piece called guide rail (“Leitschiene”) 
-  * use existing switches as style reference+  * look at previously made switches for reference
  
 ---- ----
  
-==== 8.8 Hollow Sleepers + Throw Bar =====+==== 8.8 Hollow Sleepers + Throw Bar ====
  
-Hollow sleeper (tub): +Hollow sleepers: 
-  * use existing HollowSleeper mesh +  * take HollowSleeper mesh 
-  * place at blade ends between two sleepers +  * move it to the end of your blades in between two sleepers 
-  * ensure steel doesn’t intersect anything+  * make sure the steel part doesn’t intersect → adjust position if needed
  
 Throw bar: Throw bar:
-  * place ThrowBar + ThrowBarNuts at same location +  * take ThrowBar and ThrowBarNuts meshes 
-  * align to blade ends+  * move them to the same point and align them with the blade ends
  
 Make sure: Make sure:
-  * throw bar doesn’t clip +  * flangeway clearance is OK in both blade positions 
-  * blades have enough clearance for motion+  * throw bar doesn’t clip the hollow sleeper
  
 ---- ----
  
-==== 8.9 Clamps (Tedious but Required) =====+==== 8.9 Clamps (Tedious but Required) ====
  
-Clamps are placed individually because: +Clamps are the most tedious part.
-  * arrays do not allow unique pivots for rotation +
-  * clamps must match rail curvature and sleeper placement+
  
-Workflow: +Helper setup: 
-  1) add a longitudinal edge loop through sleepers (helper) +  * add an edge loop lengthwise through every sleeper (can be removed later) 
-  2) add a longitudinal edge loop through rails (except blades) +  * add an edge loop lengthwise through all rails (except blades) 
-  3) take RailClamp mesh + 
-  4) edge snap to middle of sleeper and middle of rail +Placement workflow: 
-  5) duplicate along X by 0.6 m (sleeper spacing) +  1) take RailClamp mesh 
-  6) Shift+R to repeat until full length +  2) edge snap it to the middle of the first sleeper and middle of the rail 
-  7) rotate each clamp individually to match rail direction +  3) duplicate it along X by 0.6 m (sleeper spacing) 
-  8) special cases: if clamps clip, separate and make a “special clamp”+  4) press Shift+R to repeat until you cover the full length 
 +  5) move clamps to align with the curve of the rail 
 +  6) rotate all clamps individually to match the rail direction 
 + 
 +Why not instances/arrays: 
 +  * you may need to adjust clamps individually 
 +  * pivots must rotate properly per clamp
  
 Blade clamps: Blade clamps:
-  * use ClampK_BladeBUILD on stock rail near blades+  * use ClampK_BladeBUILD on the corresponding stock rail
  
 Guard clamps: Guard clamps:
-  * use ClampK_GuardBUILD on guard rails+  * use ClampK_GuardBUILD on the corresponding guard rail
  
-Performance note: +Special clamps: 
-  * clamps can become huge triangle counts +  * when clamps clip, separate them and build a “special clamp”
-  * see Optimization section+
  
 ---- ----
  
-==== 8.10 Optimization Choices for Clamps =====+==== 8.10 Clamp Optimization Choices ==== 
 + 
 +Clamps are a lot of geometry. You have two approaches:
  
-Correct way (more work, best performance): +Correct way (best performance, more work): 
-  * separate clamps into types +  * separate special clamps, blade clamps and guard clamps from the rest 
-  * add sockets to clamp positions +  * add sockets for clamp positions 
-  * record single/double clamp type +  * write down single/double clamp info 
-  * place clamps as instanced meshes in Unreal +  * place clamps via Instanced Meshes in Engine 
-  * most efficient for symmetrical switches (DKW quarters)+This is easier for symmetrical switches (especially DKW quarters).
  
-Lazy way (often acceptable):+Lazy way (often good enough to start):
   * export clamps as a separate StaticMesh   * export clamps as a separate StaticMesh
-  * add aggressive LODs to reduce cost+  * apply strong LODs to reduce performance impact
  
-For most mod projects:+Recommendation:
   * start with the lazy way   * start with the lazy way
-  * optimize later if needed+  * optimize later if performance becomes a problem
  
 ---- ----
  
-==== 8.11 Gravel =====+==== 8.11 Gravel ====
  
-Pick gravel mesh: +Take a gravel mesh (GravelOEBB or GravelSubway depending on usage) 
-  * GravelOEBB or GravelSubway depending on context+and apply curve modifiers (often multiple curve passes).
  
 Then: Then:
-  * curve modifier on gravel (often multiple passes) 
   * apply modifiers   * apply modifiers
-  * merge parts to avoid overlaps / Z-fighting +  * merge parts together (avoid overlaps / Z-fighting) 
-  * ensure ends connect cleanly to regular track gravel+  * make sure ends connect correctly to adjacent gravel
  
-UV note: +UV important: 
-  * gravel must match texel density of base gravel mesh +  * gravel must match texel density of normal gravel mesh 
-  * project from view (top-down) and apply same tx density+  * project from view (top-down) and apply same texel density
  
 ---- ----
Line 625: Line 545:
 ===== 9) UVs and Textures ===== ===== 9) UVs and Textures =====
  
-We use a tileable trimsheet (RailTileSet).+UVs are quite simple because we use a tileable trimsheet: **RailTileSet**.
  
 Workflow: Workflow:
-  * select shiny metal parts → cube project → tx density 5.12 px/cm at 1k +  * select shiny metal parts → cube project → texel density 5.12 px/cm on a 1k texture 
-  * move those UVs to shiny section (upper part)+  * move those UVs into the shiny section of the trimsheet (upper part)
   * rust parts → second section   * rust parts → second section
-  * repeat for wood/concrete sections+  * repeat for wood/concrete parts
  
-Tip: +Consistency matters: 
-  * keeping consistent texel density avoids mismatched appearance next to base assets+  * same texel density as base assets avoids “patchy” look in-game
  
 ---- ----
  
-===== 10) Rigging and Animating (Blades) =====+===== 10) Rigging and Animating =====
  
-Imported switches need blade animations.+Imported switches need blade movement.
  
 We use an Armature. We use an Armature.
Line 646: Line 566:
 ---- ----
  
-==== 10.1 Rigging =====+==== 10.1 Rigging ====
  
-1) Create root bone: +1) Create your root bone: 
-   Name: Rail+   Name: **Rail**
  
-2) Assign Rail vertex group to all non-moving meshes: +2) Assign a vertex group called “Rail” to everything that is static (non-moving): 
-   (rails, frogs, guards, sleepers, gravel, clamps etc. depending on your setup)+   * rails (excluding blades) 
 +   * frogs 
 +   * guards 
 +   * sleepers 
 +   * gravel 
 +   * clamps (if included here)
  
-Quick workflow: +Fast workflow: 
-  * merge those meshes temporarily+  * merge the static meshes temporarily
   * select all faces   * select all faces
-  * CTRL+G → assign to group "Rail"+  * CTRL+G → assign to vertex group “Rail”
  
 3) For each blade: 3) For each blade:
-  * create a bone at the thick end +  * place your first bone at the start of the blade (thick end) 
-  * move end to thin end +  * move its end to the thin end 
-  * subdivide twice → 4 bones per blade +  * subdivide the bone twice → 4 bones per blade 
-  * align bones to curved blade centerline+  * align the bones to the curved blade centerline 
 +  * bones should sit in the middle of the blade
  
 Naming convention: Naming convention:
-  Blade(FromTo)_(L/R)(Index)+  Blade(direction from → direction to)_(left/right blade)(bone index starting at thick end)
  
 Examples: Examples:
Line 674: Line 600:
  
 Throw bars: Throw bars:
-  * vertex group named after attached blade bone group, with final number+  * vertex groups named after their attached blade 
 +  * include the final number accordingly
  
 Skinning: Skinning:
-  * parent blades to armature with automatic weights +  * parent blades to the armature with Automatic Weights 
-  * verify in pose mode that skinning is correct+  * then verify each bone in Pose Mode (fix if something didn’t skin correctly)
  
 ---- ----
  
-==== 10.2 Animating =====+==== 10.2 Animating ====
  
-A DW example usually has 2 animations:+Example: A DW usually has 2 animations: 
 +  * BladeSwitch1 (SW1) 
 +  * BladeSwitch2 (SW2)
  
-  * BladeSwitch1 (SW1) → first blade pair +Typical timing example: 
-  * BladeSwitch2 (SW2) → second blade pair+  * frame 1: one blade side is “closed” 
 +  * frame 20: opposite blade starts moving (slightly later) 
 +  * frame 80: one side returns to neutral 
 +  * frame 100: the other side reaches the final switched position
  
-Workflow (example timing): +Example rotation values (will vary):
-  * 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°   * R1: 1°
   * R2: 0.5°   * R2: 0.5°
-  * (values depend on geometry, adjust for clearance) 
  
 Important: Important:
-  * ensure flangeways pass without clipping +  * blades don’t move at the same time (offset timing) 
-  * throw bar doesn’t intersect hollow sleeper +  * ensure flangeways can pass without clipping 
-  * set graph curves to linear +  * ensure throw bars do not intersect hollow sleepers
-  * export animations as NLA strips+
  
-Make sure: +Graph Editor: 
-  * both animations exist as NLA strips +  * set curves to linear 
-  * naming matches what you will reference in Unreal+ 
 +Output requirement: 
 +  * both animations must be NLA strips 
 +  * naming must match what you will reference in Unreal (BladeSwitch1 / BladeSwitch2)
  
 ---- ----
  
-===== 11) Exporting from Blender =====+===== 11) Exporting (FBX) =====
  
-Export settings: +Export groups (recommended): 
-  * Use the same settings as vehicle exports for meshes +  * SkeletalMesh FBX (armature + blades + any skinned parts) 
-  * Use animation export settings for animations +  * Animations FBX (or included depending on your workflow) 
- +  * StaticMeshes FBX (sleepers, gravel, clamps if separate) 
-Export groups: +  * Paths FBX (all paths can be in one FBX)
-  * 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: Folder structure:
-  * follow the SDK naming/folder conventions consistently+  * follow the SDK conventions (keep it clean and consistent) 
 + 
 +Paths requirement: 
 +  * names must be clean and unique (PathLeft, PathRight, etc.) 
 +  * paths must share vertices at intersections
  
 ---- ----
  
-===== 12) Importing into Unreal Engine (SubwaySim 2 SDK) =====+===== 12) Importing Into Unreal (SubwaySim 2 SDK) =====
  
 Import categories: Import categories:
  
-==== 12.1 SkeletalMesh + Animations =====+---- 
 + 
 +==== 12.1 SkeletalMesh and Animations ====
  
-Import the SkeletalMesh like a vehicle asset: +Import the SkeletalMesh like a vehicle: 
-  * place it into your ImportedSwitch folder structure +  * place it into your plugin folder structure (ImportedSwitches / YourSwitchName / ...) 
-  * then import animations into an Animations subfolder+  * import animations into an Animations subfolder
  
 Verify: Verify:
   * skeleton is correct   * skeleton is correct
-  * animations play in animation preview+  * animations play correctly on preview
  
 ---- ----
  
-==== 12.2 StaticMeshes and Paths =====+==== 12.2 StaticMeshes and Paths ====
  
 StaticMeshes: StaticMeshes:
Line 756: Line 681:
 Paths: Paths:
   * can be imported from one FBX   * can be imported from one FBX
-  * IMPORTANT: disable Combine Meshes so each path becomes its own StaticMesh +  * IMPORTANT: disable “Combine Meshes” 
-  * verify each path mesh exists: +  * each path must become its own StaticMesh asset 
-    PathLeft / PathRight / PathStraight / ...+  * verify that PathLeft/PathRight/PathStraight exist as separate meshes
  
 ---- ----
Line 767: Line 692:
  
 Rules: Rules:
-  * place it near other imported switch ABPs+  * place it with other imported switch ABPs (same structure) 
 +  * Parent Class must be: **Lua Anim Instance**
   * follow naming conventions   * follow naming conventions
-  * Parent Class must be: Lua Anim Instance 
  
-Workflow: +Workflow (recommended): 
-  * copy an existing imported switch ABP +  * copy/paste an existing imported switch ABP as a base 
-  * create variables for SW1 / SW2 (or your needed blade groups)+  * make SW1 / SW2 (or your blade groups) variables in the ABP
   * assign your Anim Sequences to those variables   * assign your Anim Sequences to those variables
-  * update Layered Blend per Bone with your bone names +  * update “Layered Blend per Bone” to your blade bone names 
-    (triple-check typos and correct order)+    (triple check for typos and correct order)
  
 If blades don’t move: If blades don’t move:
-  * bone names wrong+  * wrong bone names
   * wrong skeleton   * wrong skeleton
   * animations not assigned   * animations not assigned
-  * not exported as NLA+  * NLA strips not exported correctly
  
 ---- ----
Line 788: Line 713:
 ===== 14) Switch Blueprint Setup (RTImportedSwitchActor) ===== ===== 14) Switch Blueprint Setup (RTImportedSwitchActor) =====
  
-In this step we create the Blueprint Actor that RailTool uses.+This Blueprint is what you actually place in the world and what Railtool integrates with.
  
-The Blueprint combines:+It combines:
   * SkeletalMesh component   * SkeletalMesh component
-  * StaticMeshes (optional)+  * StaticMesh components (optional: gravel/clamps/sleepers if separate)
   * Animation Blueprint   * Animation Blueprint
   * RailTool2 SwitchConfigurations (critical)   * RailTool2 SwitchConfigurations (critical)
Line 798: Line 723:
 ---- ----
  
-==== 14.1 Create the Blueprint =====+==== 14.1 Create the Blueprint ====
  
 1) Create Blueprint Class 1) Create Blueprint Class
-2) Parent Class: +2) Parent Class: **RTImportedSwitchActor** 
-   RTImportedSwitchActor +3) Name it coherently, e.g.:
-3) Name it coherently:+
    BP_IS_DW_60E1_100_1_6LR    BP_IS_DW_60E1_100_1_6LR
  
 ---- ----
  
-==== 14.2 Assign Meshes and ABP =====+==== 14.2 Assign Meshes and ABP ====
  
-SkeletalMesh component:+In the Blueprint:
   * assign your SkeletalMesh   * assign your SkeletalMesh
-  * assign Animation Blueprint+  * set Animation Mode to use your Animation Blueprint 
 +  * assign your ABP
  
 Optional: Optional:
-  * add StaticMesh components for clamps/gravel/sleepers if separate+  * add StaticMesh components for clamps/gravel/sleepers if those were exported separately
  
 ---- ----
  
-==== 14.3 RailTool2 SwitchConfigurations =====+==== 14.3 RailTool2 SwitchConfigurations ==== 
 + 
 +Open the Blueprint Details and locate:
  
-Open Details: 
   RailTool2 → SwitchConfigurations   RailTool2 → SwitchConfigurations
  
-Add entries for each valid route through the switch.+Each SwitchConfiguration defines one valid route through the switch.
  
 Each configuration links: Each configuration links:
-  * a Path mesh +  * a Path mesh (PathLeft / PathRight / PathStraight / ...) 
-  * blade state values (SW1 / SW2 / ...)+  * animation state values for SW1 / SW2 / ...
  
-State values are usually discrete (0 / 1 / 2) depending on ABP logic. +Example idea: 
- +  * Route “Left”:
-Example logic: +
-  * Left route:+
       Path = PathLeft       Path = PathLeft
-      SW1 = 1+      SW1 = 1 (end)
       SW2 = 0       SW2 = 0
-  * Right route:+  * Route “Right”:
       Path = PathRight       Path = PathRight
       SW1 = 0       SW1 = 0
       SW2 = 2       SW2 = 2
  
-Use configuration index cycling for debugging: +Notes: 
-  * 0 first config, 1 second, etc. +  * You can cycle through SwitchConfigurations (index 0, 1, 2, …) for debugging. 
- +  * If you can’t see changes, check the ABP (bone names, variables, animation assignment).
-If you see no changes: +
-  * ABP variables wrong +
-  * animations not assigned +
-  * bone names mismatch+
  
 ---- ----
  
-==== 14.4 Optional Construction Script Toggles =====+==== 14.4 Optional Construction Script Toggles ====
  
-Common toggles: +Some imported switches need optional toggles: 
-  * Gravel visibility (bridge/slab track use) +  * hide gravel (bridge / slab track scenarios) 
-  * sleeper variant selection (wood vs concrete)+  * swap sleepers (wood vs concrete)
  
-Implement by:+Typical setup:
   * exposed variables   * exposed variables
-  * Set Visibility in Construction Script+  * Set Visibility calls in Construction Script
  
 ---- ----
  
-==== 14.5 Switch Motors =====+==== 14.5 Switch Motors ====
  
-Add switch motor meshes if needed. +If your switch uses motor meshes: 
- +  * determine motor placement in Blender 
-Workflow: +  * copy relative location/rotation into the Blueprint 
-  * determine motor transform in Blender +  * optionally use an enum for motor positions (like base switches)
-  * copy relative location/rotation into Blueprint +
-  * optionally use an enum (MotorPosition) like base switches+
  
 ---- ----
  
-===== 15) Testing the Switch in a Level =====+===== 15) Testing the Switch in the Level =====
  
-1) Ensure you are in Selection Mode +1) Make sure you are in **Selection Mode** 
-2) Drag the BP_... imported switch into the level+2) Drag your BP_... imported switch into the level
 3) Move/rotate it into position 3) Move/rotate it into position
-4) Connect with Railtool ControlPoints: +4) Connect it with Railtool ControlPoints: 
-   [[manual:subwaysim:map_construction:laying_tracks|Laying Tracks]]+   → [[manual:subwaysim:map_construction:laying_tracks|Laying Tracks]]
  
-Important: +Validate: 
-  * after connection, validate routes by driving AI/player across each path+  * drive each route (player and/or AI) over all paths
   * check for clipping at frogs and blade ends   * check for clipping at frogs and blade ends
   * verify blade animations match selected route   * verify blade animations match selected route
 +  * verify signals / route setting behave as expected on connected tracks
  
 ---- ----
Line 892: Line 811:
 ===== 16) Extra Info: Calculating the Angle ===== ===== 16) Extra Info: Calculating the Angle =====
  
-Example 1:6+Example 1:6:
  
   1/6 = 0.1666...   1/6 = 0.1666...
Line 900: Line 819:
   9.4623°   9.4623°
  
-You can keep a list of known angles to avoid repeating the math.+It can be useful to maintain a list of known angles to avoid repeating the math.
  
 ---- ----
Line 907: Line 826:
  
   * Paths do not share identical vertices at intersections   * Paths do not share identical vertices at intersections
-  * Wrong pivot/orientation → switch doesn’t align with tracks+  * Wrong pivot/orientation → switch doesn’t align with adjacent tracks
   * ABP bone names mismatch → blades never move   * ABP bone names mismatch → blades never move
   * SwitchConfigurations missing/incorrect → trains take wrong routes   * SwitchConfigurations missing/incorrect → trains take wrong routes
-  * Frog flangeway clearance wrong → derail-looking behavior / clipping +  * Frog flangeway clearance wrong → clipping / derail-looking behavior 
-  * Clamp geo too heavy → performance issues (use LODs or instancing later) +  * Clamp geometry too heavy → performance issues (use LODs or instancing) 
-  * Gravel overlaps existing ground → add toggle visibility+  * Gravel overlaps adjacent ground → add a toggle (visibility) or adjust mesh
  
 ---- ----
Line 918: Line 837:
 ===== Next Step ===== ===== Next Step =====
  
-After your imported switch works in-game: +Once your imported switch is placed and connected successfully, continue building your track network as usual:
-  * place more of them as needed +
-  * connect them with Railtool +
-  * continue with the rest of the map workflow+
  
-Back to: 
   * [[manual:subwaysim:map_construction:laying_tracks|Laying Tracks]]   * [[manual:subwaysim:map_construction:laying_tracks|Laying Tracks]]
  
 {{page>manual:footer}} {{page>manual:footer}}
  
manual/subwaysim/map_construction/importing_switches.txt · Last modified: by dcs
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki