[ErickC]

OKAY!

So building switches is actually not that hard, it's just time-consuming. I have completed a prototype:



This shot gives an idea of how I built the ballast:



The steps are as follows:

• Create a cylinder with a height of zero, two cap sections, a radius set to match the curve, as many sides as it takes to match the number of curve sections you want (in this case, the cylinder has 180 sides, meaning there is a segment for every 2 degrees of arc) and placed a full radius to the side of the track center.
  
• Copy the straight section. Detach the ballast. Slice it along the centerline. Make sure you are in E-Poly as E-mesh will slice along face edges and create unnecessary vertices.
  
• In this new ballast section, use vertex snap to create several vertices at the points on the cylinder. Go one point past the desired end of the track. Move them to the centerline.
  
• Slice the ballast at the position of each vertex. You can delete those vertices now.
  
• Make sure the cylinder is at the same height as the top of the ballast. Grab the center vertex for each cross section and snap it to the edges of the circle. DO NOT ROTATE. Again, remember to go one point past the desired endpoint of the track.
  
• Position a slice plane at the centerline vertex that defines the desired endpoint of the track. Rotate it the correct number of degrees - in this case, 10.
  
• Slice the ballast layer. Delete anything past the endpoint. There will be a triangular segment from the original perpendicular edge on the inside of the curve, so snap those verts to the end, weld the UV coordinates with target weld in Unwrap UVW, and then weld the vertices in the mesh.
  
• Select the vertices defining the cross-section at the start of the track. Hold shift and drag to clone them. Rotate them the appropriate number of degrees for the end (in this case, 10 degrees).
  
• Grab the center vertex and snap it to the center of the end. You'll notice the ballast is a bit narrower at the end than it should be. Snap the edges of the mesh to these vertices. Remove isolated vertices.
  
• The curve is now correct and the ties will remain straight, ensuring overall alignment with the straight section.
  
• Detach the ballast from the straight section. Hide everything but the two ballast sections.
  
• On the ballast section, use edge cut to slice in the area where the two ballast sections will meet. It doesn't have to be perfect, just make sure it's between the rail and the end of the ties. Do this all the way down the section. At the start point of the curve, the last cut should be close to the center. Delete anything inside this new series of edges.
  
• Select the straight ballast layer. Use vertex snap and create vertices at those same new edge points. Slice plane across the ballast at those points.
  
• Use edge cut and vertex snap to cut the same edges. Delete everything on the curved side of those edges.
  
• Attach the curved section to the straight section. Weld the vertices where they meet.

The prototype piece is a little messier than I would do a final piece because I had sliced down the center, thinking it would make life easier (it did not, because I ended up edge cutting anyway):



Ideally, future sections would look more like this:



I constructed the rails the same way, but this leads to a sight narrowing of the gauge from simply shifting left/right, so I would create them the same way I would build curves for the final version:

• Calculate the total length of the arc in meters. Divide by 24 to figure out the number of times the texture should repeat, round to the nearest half.
  
• Add a UVW XForm modifier. Enter this number in the V Tile field.
  
• Decide how many segments this curve needs. One segment per degree is probably best, so a curve that has 20 degrees of arc should have 20 segments.
  
• Position the end of the track at whatever that number is in meters, so for a 20 degree arc, place it 20 meters out.
  
• Slice every meter.
  
• Create the reference cylinder as with the ballast, make sure it has a number of sides that matches the number of segments - if there's to be a segment for every degree, there should be 360 sides. Make sure the cylinder has a height of 0 meters and is placed 0 meters above the origin.
  
• Select all vertices along one side of the ballast. Shift and drag to clone. Position them at the centerline.
  
• Snap each sequential segment to the points on the reference cylinder.
  
• Select each cross section and type in the number of degrees it should be rotated. In this example, there would be a segment for every degree of arc, so each segment should be rotated one more degree than the last.

For switches, the very last step would be to add an Unwap UVW modifier and move the coordinates for each cross-section vertically along the texture to get the tie plates lines up with the ties. This is a pretty simple matter.

What isn't so simple is getting the placement and radius of the curves right. Here is my 10 degree test switch with the switch it was intended to match:



You can see that the curve is not positioned correctly. If I move it 1.5 meters down the track, it lines up well:



The inner rail matches fine when you consider the accidental narrowing of the gauge from the technique that was used. The outer rail, however, is nowhere close:



I used the numbers from the XTracks site for the radius, so that I'm sure of. Was the outer rail on the default shape just wrong? The slight (3 cm or so) narrowing of the gauge doesn't account for this huge difference on the position of the point of the curved moving segment.

Route developers: Do any of you have any input on the correct positioning of the start of the curve of the default switches? I suspect it's primarily a function of an opposing curve of the same radius and arc that meets a parallel track section, which would make calculations a simple matter of the radius, arc, and distance between tracks. That doesn't solve the outside rail misalignment problem, though. Whose outside rail is correct, theirs or mine?

[Genma Saotome]

All of the dimensional information you need is recorded in the Tsection.dat file. It looks complex (sometimes it is complex) but once you know how it works you can decode anything you find there.

First, the Tsection file has two sections -- the first is dimensional information and the second is all about the shapes themselves. The later will hold a collection of pointers to the data in the dimensional area and so the shape data will define what dimensions to use to make up the path for every track or road shape.

For example, the shape A1tPnt5dLftMnl.s has these two dimensions defined:

• SectionIdx ( 2 0 0 0 0 182 173 )
  
• SectionIdx ( 1 0 0 0 0 180 )

The first number you see is a count of how many track definitions to find. One line one, this value is 2 and both index numbers are found at the end -- 182 and 173. Line two has only 1 and its value is 180.

You take those values and go to the top of the file and search down from there. You will find:

• TrackSection ( 173 SectionSize ( 1.5 0 ) SectionCurve ( 655.007 -5 ) )
  
• TrackSection ( 180 SectionSize ( 1.5 80 ) )
  
• TrackSection ( 182 SectionSize ( 1.5 17.912364 ) )

Let's take them in order: Line one is the only entry that has the phrase SectionCurve so that tells us it is the diverging path; It has a radius of 655.007m and is 5 degrees in length. Do note that the length of degrees is -5. The minus sign tells you the path will curve to the left. (+)5 will curve to the right.

Lines two and three are tangents... line two is 80m long, line three is 17.912364m long.

A glance back at the SectionIdx lines from the shapefile entry shows that TrackSections 182 and then 173 form one path -- this is the diverging path so the remaining one has to be the full tangent (and at 80m it should).

That leaves the question of where do these things start and end. The answer to that are the three digits following the count of track sections. In this example, all three are zeros. These are the xyz coordinates relative to the shapes origin point. Taking everything into account we the placement of the begins at the far end of tracksection 182 -- exactly 17.912364m due north of the origin point. This means when there are multiple indicies to the tracksection data within a single SectionIdx the first one listed is always placed where ever the xyz data says it should go and all the following entries are sequenced in a line where each begins at the end of the previous segment. Be aware that not all tangents leading into the diverging curve start at 0,0,0.

Perfectly obvious, right?

To wrap up this example, there are two other data to take note of: Numpaths() and MainRoute(). Numpaths() gives you the number of discrete paths found in a shape. MainRoute() tells you which of those paths is the default path. AFAIK this applies only to track switches. I think zero is left and one is right. In most cases MainRoute() will be the tangent but do note there are track switches where the diverging path is the default.



Looking at another example, A1t250r10d.s; It's a single track curve, 250m radius, 10 degrees in length, right? WRONG!. You must assume any number in the name is a nominal dimension and that the real dimension may be something else. In this case it is not a radius of 250m, instead it is an actual radius of 247.5075m. ALWAYS check, never assume. There are not many like this but it's no fun to make several models on the assumption and then have to throw them away on the facts.

Elsewhere you may come across something like this: SectionIdx ( 5 -4.985 0 0 0 29804 29804 29804 29804 29804 ). It's telling you there are 5 occurrences of dimensional data -- all the same and that the origin point of this path is -4.985m to the left of the shapes origin path. This being a three track curve this particular SectionIdx defines the leftmost track. The 5 occurrences on the track index means whatever the dimension is will be repeated five times. As it happens, this is for a 5d curve so you can safely assume the index value of 29804 points to a dimensional definition of 1d.

Now, having seen an example where the start of the path is not at 0,0,0, you will understand what you are looking at when you see the specifications for a road intersection. There will be n paths all starting at the zero line and then m paths starting on the left. You always do these left to right, finishing each axis before moving on (the default here is always moving clockwise so knowing thateven 3 street intersections can be deciphered. To ensure understanding I'll rephrase: Do all the paths that start at the om line going leftmost to the right. When done with those paths then rotate your attention to the left side of the shape and do all of those paths. The tricky part here is you have rotated the shape to align these paths on a horizontal line, you will again go in order from leftmost to right. OTOH if you have not rotated the shape the correct order is to go top to bottom. If this is confusing it might help to gin up a square in your modeling tool, mark off a couple lines on the left side. It's top to bottom when the square is not rotated but obviously left to right when it is rotated and the dashes are on now the bottom. My point is don't get confused when you do the work... take your time and get it right.

Questions?

[ebnertra000]

Useful trick for switches...and you're right about them - not difficult, but time-consuming.

The numbers I used when I did my track and berm work a few years back came from the tsection file. There's a way to read it that I'd have to re-learn. The radius (164 and some change) is right, but the 10d switch's curve starts 1.5m in from the origin of the shape, so I think that's what got you. The 5d starts...15m in? I'd have to check. They're all different

[Genma Saotome]

FWIW I routinely convert the tsection file from many rows per entry to a single row per. I find it far easier to read.

The 250r curve looks like this in my tsection file:

TrackShape ( 254 FileName ( A1t250r10dTun.s ) NumPaths ( 1 ) SectionIdx ( 1 0 0 0 0 198 ) TunnelShape ( ) )

and the SectionIdx entry looks like this:

TrackSection ( 198 SectionSize ( 1.5 0 ) SectionCurve ( 247.5075 -10 ) )

Having converted everything to one line per, there are still over 26,000 lines. I do the same for the routes .ref file and I often do the same for world files. If you have an editor that can search and replace with escape characters you can do the same.

[ErickC]

That's pretty easy to decipher. Now that I understand the parameters in the tsection.dat file, it's only a matter of coming up with the final texture mapping and images, working out the rest of the processes, and building the rest of the basic profiles. Then I can upload the source files for anyone else who might want to work on track shapes. I'll only really be able to work on the weekends between other projects for the time being, but building most of the non-switch pieces shouldn't take long for the basic track set. Replacing XTracks, on the other hand, may take some time...

Anyway, now that I've worked out the process for switches, I won't need that second ballast center section after all. I think I'm going to reduce that portion of the map down to just the space between tracks. I could use the extra space for other things.

Further questions for all of you:

• Should the manual switches come with stands like they originally did? Or should they just be copies of the automatic switches?
  
• If it's best to have the stands built in, what style seems best?
  
• LODs? No LODs?

[ebnertra000]

I recommend no stands, but also making some documentation, so that a model builder could make a switchstand that accurately matches the profile of the track shape, especially tie spacing, which is the hard part. That, and there's so bloody much variety in designs and especially targets/lanterns. Maybe extend a couple ties out on one side or the other? If that's the case, you'd probably need two versions, with ties on the inside or outside

[steved]

The JJHSwStands that come with the Monon are animated with the handle lifting up and swinging around with the lantern.
You might look at how these are set up. The textures are easy to modify for just about anything.

Steve

[Genma Saotome]

WRT stands... IO think the answer has to go with the purpose of this project: Is it to create a better looking alternative to KUJU/XTrks? If the former, do whatever you want whereas if it is the later I think it best to do exactly what the original shape has & does.



FWIW I have become quite partial to defining generic shapes in the tsection file and loading up the route's \shape folder with the actual shapes to use. For example, I now have a very generic road shape -- textures are NOTHING like any road -- and then a corresponding library of static shapes of identical dimensions skinned for concrete, asphalt, cobblestone, and streetcar (11ft centerline spacing) and I might do shapes for Kuju's double track spacing, single track streetcar/rail, gravel , and dirt. I'm using a limited number of tangent dimensions and counting on OR's instancing to provide better performance that a huge library of every possible length. I expect to do curves in only 5d and less. This saves a very large number of tsection entries which I just hate creating or editing. Had KUJU done this from teh start I expect the number of Tsection shape definitions would be under 1000.

[eric from trainsim]

Switchstand targets are something I'd miss. That was my entire reason for migrating to Scalerail over ten years ago. I don't think moveable handles are essential, but for branch line/non-signaled operations, having the visual indicator of the switch being aligned for the main or diverging route is pretty critical. And I won't lie -- I'd prefer to avoid going back to the "create a semaphore that looks like a switchstand" days...

Would it be practical to have another way to "child" an object and share the parent's animation triggers?

 Genma Saotome, on 25 January 2021 - 08:59 PM, said:

FWIW I have become quite partial to defining generic shapes in the tsection file and loading up the route's \shape folder with the actual shapes to use. For example, I now have a very generic road shape -- textures are NOTHING like any road -- and then a corresponding library of static shapes of identical dimensions skinned for concrete, asphalt, cobblestone, and streetcar (11ft centerline spacing) and I might do shapes for Kuju's double track spacing, single track streetcar/rail, gravel , and dirt. I'm using a limited number of tangent dimensions and counting on OR's instancing to provide better performance that a huge library of every possible length. I expect to do curves in only 5d and less. This saves a very large number of tsection entries which I just hate creating or editing. Had KUJU done this from teh start I expect the number of Tsection shape definitions would be under 1000.

Sounds like you're doing for roads what I've been doing with tracks via WFH... Ties, rails and TDB lines are the only things I place manually, and all I expect from my track shape.

Everything else is decor sharing the same axis point.

[Genma Saotome]

 eolesen, on 26 January 2021 - 12:36 AM, said:

Sounds like you're doing for roads what I've been doing with tracks via WFH... Ties, rails and TDB lines are the only things I place manually, and all I expect from my track shape.

Everything else is decor sharing the same axis point.

Yup. I first realized the utility of generic road and track while editing copies of Scalerail track ti substitute Pink Lady ballast. I didn't have enough alternative track to warrant going down that path but I did find myself in need a completely new road system for Chicago's loop and so implemented the idea there.





note arch.


The gap in the center allows me to plug in whatever center line is correct; In 1947 Illinois was using a single 8 inch continuous black line on concrete (my Goose Island rte) whereas California was (IIRC) using a double 4 inch white line (Cal-P rte.) Other states were using yellow... Texas had stone rubble embedded in their centerlines. IIRC State rules continued until things were set nationally when the 1961 proposals were distributed, giving us yellow lines and yet there was another fuss about colors in the early 70's where white was again promoted but sensibility finally ruled enough is enough.

As these specific shapes were intended for the late 40's the lane width is reduced to 10ft, fairly typical for slow speed streets. Curbs and parkway/sidewalks are separate shapes so they too can be swapped in and out for different widths.


An interesting contrast is curb colors have been a national standard since 1924 with additions as necessary.

Oh, and stop signs color was also a state by state affair but most were yellow w/ black letters and borders until (IIRC) 1956.

All of which to say any steam era route we use has wrongly skinned roads and signs.