Project: Revising my TRS19 PBR Parallax SAP Track U.S. 132LB SG, FB, TP track series

MSGSapper

Trainz route developer
I have decided to bite the bullet, stop everything else I am doing for TRS19 right now, and revise my PBR with parallax TRS19 SAP Track U.S. 132LB SG, FB, TP track series. This comes about due to the below forum post and the problems it brought out with the existing track:

https://forums.auran.com/trainz/sho...to-point-produces-abbreviated-ballast-contour

At the time I did the original project (Jan-Mar 2019) my intent was to create a build 4.6 PBR with parallax fairly modern U.S. standard gauge track with 132 LB rail and a realistic looking ballast bed and ties. At the time there was no such track included with TRS19, and not much has changed since then. I succeeded more or less, although as the forum post above, and several other comments I have have received over the last year has shown, there are a number of problems with the track which need to be resolved.

I am not thrilled at all to be going back to the track project as it was a real nightmare for me to do in the first place. Frankly, my experience level with procedural track, PBR or Non-PBR, is not all that great to begin with, but I have learned a few things since I did this track project about a year ago and I hope some of you out there with better experience will help me to make this track the best modern PBR parallax U.S. standard gauge track that it can be by participating in this project.

When I released the track last year I provided all my Blender 2.79 project code for the track as part of the track mesh library which can be downloaded from the DLS. Here are the details:

kuid_439337_103187.jpg

TRS19 SAP Track U.S. 132LB SG Mesh Library
KUID:439337:103187
Description: TRS19 SAP Track Mesh & Texture Library for U.S. 132LB Standard Gauge flat bottom railroad track with tie plates and spikes. I have also included all my Blender 2.79 project files for this mesh library in a sub-folder called 'blender_files'. Before trying to access them be sure to first read the 'instructions_read_first.txt' file in that folder.

What I need from you in the way of help for this project:

I would ask that those of you who are willing to do so please download that mesh library, look at the Blender project files you will find there, and help me to resolve the issues that exist in the track by posting suggested detailed revision information for specific Blender project files in that mesh library to fix the reported problems. BTW my direct email address is included in the config.txt file if you want to revised the Blender project file and send it to me. Credit of course will be be provided in the description for those who make significant contributions for fixing this track,

As of the time I am writing this today I am in the process of migrating the Blender project files to Blender 2.80 and the texture files from .tga format to .png format. I will of course make those available to everyone once the project is completed as I did before. As always I want to help others and to encourage variants or even new track of different types

Here are all the content files which are for the track series:

<kuid:439337:103193> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Rail-Shiny-Right
<kuid:439337:103409> TRS19 SAP Track U.S. 132LB SG, FB, Shiny, Track only
<kuid:439337:103417> TRS19 SAP Track U.S. 132LB SG, FB, Rusty, Track only
<kuid:439337:103416> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Rusty, No Ballast
<kuid:439337:103414> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Rusty
<kuid:439337:103413> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Rail-Rusty-Right
<kuid:439337:103196> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Shiny
<kuid:439337:103412> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Rail-Rusty-Left
<kuid:439337:103407> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Shiny, No Ballast
<kuid:439337:103192> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Rail-Shiny-Left
<kuid:439337:103191> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes-Right
<kuid:439337:103190> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes-Left
<kuid:439337:103189> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Timber Ties

Bob

Note: The track I originally built was based on this online tutorial on creating procedural track which included downloadable source assets:

http://online.ts2009.com/mediaWiki/index.php/HowTo/Build_Procedural_Track_for_T:ANE
 
Last edited:
Challenge #1 to solve: This missing right side chairs.

Here is a screenshot of a reported problem with the track showing that the right side chairs are missing where the turnout branches off as shown in the screenshot below.

PBR-Track-Junction-SS1.jpg


I am baffled by this problem as I really don't understand what is causing it as I believe have done everything according to the N3V tutorial as stated at:

http://online.ts2009.com/mediaWiki/index.php/HowTo/Build_Procedural_Track_for_T:ANE

ZecMurphy indicated in the following reply that he believed it was a problem with the single chair mesh. See his reply at:

https://forums.auran.com/trainz/sho...eviated-ballast-contour&p=1794942#post1794942

I do not really understand the mechanics of how TRS19 forms the procedural junction and how it assigns the chairs and why they disappear from the right side of the tracks as shown in the screenshot above.

Here is a screenshot of the relevant Blender file I am using for the single right side chair:

Right-Chair-SS-1.jpg


Any insights on this anyone?

Bob
 
Last edited:
I was just looking at this one of yours and i'm not seeing the same problem.

Thanks but that is my <kuid2:439337:102745:1> SAP Protrack U.S. 132LB SG, FB, TP with Spikes, Rusty is not my PBR Parallax track. The one in your screenshot is a build 4.2 track.

Bob
 
Last edited:
I tried a little experimentation with the track. Angle seems to make a difference in what is displayed. If the angle is not great enough my right chairs are not displayed. If I make the angle greater they are displayed as shown in this screenshot:

Track-Chairs-SS1.jpg


Why would this be and what settings in the config.txt file would control that behavior?

Bob
 
Last edited:
In the screen shot above you can see that no procedural turnout was created. The only time I've seen the missing chairs in your track is when a procedural turnout is formed. I've checked several other pro tracks in TRS19 and not seen the same behavior.

As to why no turnout was formed it's because the geometry you presented the game is outside the norm for procedural turnouts that is programmed into Trainz. You'd have to get the exact specs from N3V but some content creators have complained that for small gauges like 24" ng some "real" turnout geometry doesn't seem to be included in this norm. For sg though I'd say the turnout in the above pic is outside any realistic norm.

Bob Pearson
 
I original looked at this track because of a post in the forums pointing out some ballast problems in turnouts in TRS19. I had just made a set of sample turnouts and checked a few out with a new turnout tool that had just been uploaded to the DLS. The turnouts are my own design but the geometry is very close to real SG turnouts. The main difference is that I carry the circular arc of the divergent track from point of frog to point of switch blade where in real turnouts the curve stops short and is finished with a fixed length straight blade. Because of this the lead (distance from frog point to point of the switch blade) in my turnout is slightly longer than in the real turnout by typically a couple of feet. The frog angles are however very exact.

The series [edit] covers turnouts with standard frog numbers (FN) ranging from #4 to #9 by half frog number, #9 to #12 by whole frog number and #12 to #20 by two frog numbers. The tool works with #5, #6, #7, #8 and #9 turnouts so I increased the track beyond the frog to accommodate the tool on those turnouts. Not relevant here but you'll see it in the pics.

I made additional sets with procedural track made with PBR materials especially for TRS19. These were made by coping the original set made for the test and using a bulk replacement to change the track to the new TRS19 PBR procedural track. If you can't tell which track is the old spline version - the basic mesh and textures are at least 15 years old - I suspect you'll be visiting the optometrist soon.

The #4 Frog Turnouts from all 4 series. This is probably the minimum SG FN I expect to see in Trainz. IIRC the procedural turnout code fails with a #3.5 Turnout in previous tests.
My-Trainz-Screenshot-Image.jpg



#4 Frog N3V's TRS19 protrack - PBR
My-Trainz-Screenshot-Image.jpg



#4 Frog Elstoko's NSWGR TRS19 protrack - PBR
My-Trainz-Screenshot-Image.jpg



#4 Frog TRS19 SAP protrack - PBR
My-Trainz-Screenshot-Image.jpg



#4 Frog TRS19 SAP protrack - PBR Close up
My-Trainz-Screenshot-Image.jpg



#9 Frog TRS19 SAP protrack - PBR. #8.5 and #10 Frog Turnouts shown in the pic exhibit the same behavior.
The chairs under the rails on the right side of this track are missing for the entire length of the procedural turnout as indicated below - but only iwo the procedural turnout.
My-Trainz-Screenshot-Image.jpg




#9 Frog TRS19 SAP protrack - PBR Blowup 1
My-Trainz-Screenshot-Image.jpg




#9 Frog TRS19 SAP protrack - PBR Blowup 2
My-Trainz-Screenshot-Image.jpg



Bob Pearson
 
Last edited:
I original looked at this track because of a post in the forums pointing out some ballast problems in turnouts in TRS19. I had just made a set of sample turnouts and checked a few out with a new turnout tool that had just been uploaded to the DLS. The turnouts are my own design but the geometry is very close to real SG turnouts. The main difference is that I carry the circular arc of the divergent track from point of frog to point of switch blade where in real turnouts the curve stops short and is finished with a fixed length straight blade. Because of this the lead (distance from frog point to point of the switch blade) in my turnout is slightly longer than in the real turnout by typically a couple of feet. The frog angles are however very exact.

The series [edit] covers turnouts with standard frog numbers (FN) ranging from #4 to #9 by half frog number, #9 to #12 by whole frog number and #12 to #20 by two frog numbers. The tool works with #5, #6, #7, #8 and #9 turnouts so I increased the track beyond the frog to accommodate the tool on those turnouts. Not relevant here but you'll see it in the pics.

I made additional sets with procedural track made with PBR materials especially for TRS19. These were made by coping the original set made for the test and using a bulk replacement to change the track to the new TRS19 PBR procedural track. If you can't tell which track is the old spline version - the basic mesh and textures are at least 15 years old - I suspect you'll be visiting the optometrist soon.

The #4 Frog Turnouts from all 4 series. This is probably the minimum SG FN I expect to see in Trainz. IIRC the procedural turnout code fails with a #3.5 Turnout in previous tests.

#4 Frog N3V's TRS19 protrack - PBR

#4 Frog Elstoko's NSWGR TRS19 protrack - PBR

#4 Frog TRS19 SAP protrack - PBR

#4 Frog TRS19 SAP protrack - PBR Close up

#9 Frog TRS19 SAP protrack - PBR. #8.5 and #10 Frog Turnouts shown in the pic exhibit the same behavior.
The chairs under the rails on the right side of this track are missing for the entire length of the procedural turnout as indicated below - but only iwo the procedural turnout.

#9 Frog TRS19 SAP protrack - PBR Blowup 1


#9 Frog TRS19 SAP protrack - PBR Blowup 2

Bob Pearson

Bob:

Thanks for the information and screenshots which were interesting. I am very much aware of the problems here, but trying to track down the cause of them is not proving to be easy at all, and where I need help. One thing I discovered was that the chairs are actually there if you zoom in as close as possible. You only see the very tops of the spikes portion o the chair, but they are there, at least they are for me.

Bob
 
Yes I show them in one of the pics above. If they are part of the chairs then maybe the PBR ties are expanding enough to hide them - but why only the one side?

Since procedural turnouts are coded into the game engine, from the start I figured N3V should be involved particularly since it seems this happens only with some PBR materials.

Bob Pearson
 
Yes I show them in one of the pics above. If they are part of the chairs then maybe the PBR ties are expanding enough to hide them - but why only the one side?

Since procedural turnouts are coded into the game engine, from the start I figured N3V should be involved particularly since it seems this happens only with some PBR materials.

Bob Pearson

I finally solved the problem with the chairs. I did two things at the same time so I am not sure which it was. I copied the single left chair Blender file over the right chair Blender file to ensure absolute positioning and also I fixed a problem with both left and right slide chairs being out position. Which ever it was the problem with the chairs was solved.

Bob
 
Question. I have seen several track examples where the mesh-length parameter seems to reflect the LOD2 mesh length, or greater, and not the LOD0 mesh length. The NV3 procedural track creation tutorial is not very clear about that and seems to show something else. See at:

http://online.ts2009.com/mediaWiki/index.php/HowTo/Build_Procedural_Track_for_T:ANE

Here is the config.txt for my <kuid:439337:103196> TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Shiny file:

Code:
kind                                    "procedural-track"
username                                "TRS19 SAP Track U.S. 132LB SG, FB, TP with Spikes, Shiny"
trainz-build                            4.6
category-class                          "TR"
category-region                         "US"
istrack                                 1
enable-pfx-collisions                   0
track-type                              "ballast"
track-gauge                             1.436
check-gauge                             1.395
sleepers-orientation                    "average"

mesh-table
{
  track-lod0
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "tracklod0n.trainzmesh"
    mesh-season                         0
  }
  
  track-lod0-snow
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "tracklod0ns.trainzmesh"
    mesh-season                         2
  }
  
  track-lod1
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "tracklod1n.trainzmesh"
    mesh-season                         0
  }
  
  track-lod1-snow
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "tracklod1ns.trainzmesh"
    mesh-season                         2
  }
  
  track-lod2
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "tracklod2n.trainzmesh"
    mesh-season                         0
  }
  
  track-lod2-snow
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "tracklod2ns.trainzmesh"
    mesh-season                         2
  }
  
  endcap_prev
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "endcapalod0n.trainzmesh"
    mesh-season                         0
  }
  
  endcap_prev-snow
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "endcapalod0ns.trainzmesh"
    mesh-season                         2
  }
  
  endcap_next
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "endcapblod0n.trainzmesh"
    mesh-season                         0
  }
  
  endcap_next-snow
  {
    mesh-asset                          <kuid:439337:103187>
    mesh                                "endcapblod0ns.trainzmesh"
    mesh-season                         2
  }
}

track
{
  mesh-length                           2.959
  adjust-cross-section-to-ground        0
  
  track-lod-tree
  {
    lod-distance                        500
    
    high-detail
    {
      subdivisions                      2
      lod-distance                      350
      
      high-detail
      {
        subdivisions                    2
        lod-season-index                2
        
        high-detail
        {
          mesh                          "track-lod0-snow"
        }
        
        low-detail
        {
          mesh                          "track-lod0"
        }
      }
      
      low-detail
      {
        lod-season-index                2
        
        high-detail
        {
          mesh                          "track-lod1-snow"
        }
        
        low-detail
        {
          mesh                          "track-lod1"
        }
      }
    }
    
    low-detail
    {
      lod-season-index                  2
      
      high-detail
      {
        mesh                            "track-lod2-snow"
      }
      
      low-detail
      {
        mesh                            "track-lod2"
      }
    }
  }
}

endcap-prev
{
  mesh-length                           1
  adjust-cross-section-to-ground        0
  
  track-lod-tree
  {
    lod-distance                        400
    
    high-detail
    {
      lod-season-index                  2
      
      high-detail
      {
        mesh                            "endcap_prev-snow"
      }
      
      low-detail
      {
        mesh                            "endcap_prev"
      }
    }
    
    low-detail
    {
    }
  }
}

endcap-next
{
  mesh-length                           1
  adjust-cross-section-to-ground        0
  
  track-lod-tree
  {
    lod-distance                        400
    
    high-detail
    {
      lod-season-index                  2
      
      high-detail
      {
        mesh                            "endcap_next-snow"
      }
      
      low-detail
      {
        mesh                            "endcap_next"
      }
    }
    
    low-detail
    {
    }
  }
}

thumbnails
{
  default
  {
    width                               240
    height                              180
    image                               "thumbnail.jpg"
  }
}

attached-splines
{
  rail_left
  {
    lateral-offset                      -0.751
    use-same-direction                  1
    spline-kuid                         <kuid:439337:103192>
    visual-only                         1
  }
  
  rail_right
  {
    lateral-offset                      0.751
    use-same-direction                  1
    spline-kuid                         <kuid:439337:103193>
    visual-only                         1
  }
  
  sleepers
  {
    lateral-offset                      0
    use-same-direction                  1
    spline-kuid                         <kuid:439337:103189>
    visual-only                         1
  }
  
  chairs_left
  {
    lateral-offset                      -0.751
    use-same-direction                  1
    spline-kuid                         <kuid:439337:103190>
    visual-only                         1
  }
  
  chairs_right
  {
    lateral-offset                      0.751
    use-same-direction                  1
    spline-kuid                         <kuid:439337:103191>
    visual-only                         1
  }
}

season-selector
{
  above-snow-line                       1
  
  branch-true
  {
    output-season                       2
  }
  
  branch-false
  {
    output-season                       0
  }
}
kuid                                    <kuid:439337:103196>

kuid-table
{
  1                                     <kuid:439337:103187>
  2                                     <kuid:439337:103193>
  3                                     <kuid:439337:103192>
  4                                     <kuid:439337:103191>
  5                                     <kuid:439337:103190>
  6                                     <kuid:439337:103189>
}

I believe the track mesh-length parameters should reflect the LOD0 mesh length which is 2.959 for my LOD0 ballast bed (ie; Tracklod0n.fbx) . Its that correct?

Bob
 
Good news! After a lot of very hard work I have been able to resolve all but one of the issues reported to date with my track. Here are some screenshots:

My track with Shader set to standard:

My-Trainz-Screenshot-Image.jpg


My track with Shader set to Ultra:

My-Trainz-Screenshot-Image.jpg


The problem is that the tracks, chairs, sleepers, etc sink below the ballast bed when the Shader is set to Standard but are perfectly fine with the Shader set to Ultra.

Any ideas why this is the case, or is this a PBR things as I mentioned in earlier? I don't see this issue with the TRS19 Jarrah PBR tracks so I am thinking it must be something else, unless Jarrah track textures don't have a height map in them?

Bob
 
Code:
track
{
  mesh-length                           2.959
  adjust-cross-section-to-ground        0

Bob, are you sure that's correct for the latest version, <kuid:439337:103196> that's on the DLS?

Here's what I see and I have the lastest version that I downloaded recently [edit] (just re-dl'd and this is correct):
Code:
track
{
  mesh-length                           17.754601
  adjust-cross-section-to-ground        0
I checked them all a few days ago and Elstoko's has:
Code:
track
{
  mesh-length                           16
  adjust-cross-section-to-ground        0
about the same as yours.

The N3V track I used has:
Code:
track
{
  mesh-length                           20
  adjust-cross-section-to-ground        0
  padding-length                        5

So N3V is using the mesh length of the LOD2 for the ballast spline. As for the padding-length I found this suggestion as a possible fix for problems with the ballast stretching (others were adding or moving spline points which are on the users end):

- add the tag padding-length to your kind "procedural-track", track-type "ballast" in the track-lod-tree container.
You might want to set padding-length to the length of your highest ballast LOD (i.e your shortest ballast mesh).

In the other thread on this problem (my last post in that thread) I noted that your track anywhere has problems displaying properly if the length between spline points is under about 14 m. That in fact was the original problem observed - a short length of track between 2 junction points.

Bob Pearson
 
Last edited:
Bob, are you sure that's correct for the latest version, <kuid:439337:103196> that's on the DLS?

Here's what I see and I have the lastest version that I downloaded recently [edit] (just re-dl'd and this is correct):
Code:
track
{
  mesh-length                           17.754601
  adjust-cross-section-to-ground        0
I checked them all a few days ago and Elstoko's has:
Code:
track
{
  mesh-length                           16
  adjust-cross-section-to-ground        0
about the same as yours.

The N3V track I used has:
Code:
track
{
  mesh-length                           20
  adjust-cross-section-to-ground        0
  padding-length                        5

So N3V is using the mesh length of the LOD2 for the ballast spline. As for the padding-length I found this suggestion as a possible fix for problems with the ballast stretching (others were adding or moving spline points which are on the users end):



In the other thread on this problem (my last post in that thread) I noted that your track anywhere has problems displaying properly if the length between spline points is under about 14 m. That in fact was the original problem observed - a short length of track between 2 junction points.

Bob Pearson

I found the answer by a lot of trial and error.

The mesh-length is whatever you want it to be. In my case the LOD0 mesh for the ballast bed which is 2.959 meters in length. The problem turned out to be in the subdivision parameter which should have been 1 instead of 2. For more on this see the two links below:

http://online.ts2009.com/mediaWiki/index.php/Track_Part_Container

and

http://online.ts2009.com/mediaWiki/index.php/"track-lod-tree"_container

Since the basic mesh was fairly small I didn't want to sub-divide it, as was shown in the tutorial on procedural track creation. The tutorial is helpful in many regards, but it doesn't break down the config.txt examples and explain what each line is for and why it is being used, which is something that newbies to build 4.6 track creation, as I was at the time, would find helpful in understanding.

As always things are not always clear when it comes to Trainz track creation. This was one of those cases, at least for me.

Once I changed the subdivisions parameter to 1 the problem, or at least that problem, was solved for me.

Bob
 
Last edited:
Here is where I stand now with revising the track:

1. All .tga texture files have been converted to .png format.
2. All Blender files have been converted to 2.80.
3. The position problem with the slide chairs has been fixed.
4. Visual anomalies, distortions of all types, and kinking has been corrected.
5. The Moire effect has been reduced a fair bit. The only way I could do this was to darken the ballast albedo file by 85% in GIMP.
6. The missing right chair problem has been fixed.
7. The checkrail-body-length has been adjusted to the correct body length.

Here are some screenshots of the fixed track as it is now:

Fixed-track-SS1.jpg


Fixed-track-SS2.jpg


Fixed-Track-SS3.jpg


I have not however been able to correct the problem when the track is used with the Shader set to standard because I simply do not know what is causing it, or how to fix it. Please keep in mind that I designed this PBR Parallax track primarily for a TRS19 environment where the Shader is set to Ultra in order for the ballast to look real and have depth. For what I designed it for it does that perfectly now with all the other fixes I have done above. If you have not set the Shader to Ultra for your TRS19, for whatever reason, I would advise you to consider using instead the following in its place or some other track of your choice:

<kuid2:439337:102789:1> SAP Protrack U.S. 132LB SG, FB, Shiny, Track Only
<kuid2:439337:102787:1> SAP Protrack U.S. 132LB SG, FB, Rusty, Track Only
<kuid2:439337:102786:1> SAP Protrack U.S. 132LB SG, FB, TP with Spikes, Shiny, No Ballast
<kuid2:439337:102784:1> SAP Protrack U.S. 132LB SG, FB, TP with Spikes, Rusty, No Ballast
<kuid2:439337:102745:1> SAP Protrack U.S. 132LB SG, FB, TP with Spikes, Rusty
<kuid2:439337:102580:1> SAP Protrack U.S. 132LB SG, FB, TP with Spikes, Shiny

Bob
 
Sounds like you have been busy. I will look forward to trying them, especially with reduced moire. Thanks
 
I found the answer by a lot of trial and error.

The mesh-length is whatever you want it to be. In my case the LOD0 mesh for the ballast bed which is 2.959 meters in length. The problem turned out to be in the subdivision parameter which should have been 1 instead of 2. For more on this see the two links below:

http://online.ts2009.com/mediaWiki/index.php/Track_Part_Container

and

http://online.ts2009.com/mediaWiki/index.php/"track-lod-tree"_container

Since the basic mesh was fairly small I didn't want to sub-divide it, as was shown in the tutorial on procedural track creation. The tutorial is helpful in many regards, but it doesn't break down the config.txt examples and explain what each line is for and why it is being used, which is something that newbies to build 4.6 track creation, as I was at the time, would find helpful in understanding.

As always things are not always clear when it comes to Trainz track creation. This was one of those cases, at least for me.

Once I changed the subdivisions parameter to 1 the problem, or at least that problem, was solved for me.

Bob

I recall I never really understood how the subdivisions worked. i.e. are the parts compressed or expanded to fit? Are the meshes simply sliced by the number of divisions, or are you expected to "pre slice" the meshes? On resurrecting my old test track I found that I had deliberately put edge loops at the point where I expected the slice to occur. However, I cannot recall if that was the answer or a waste of time.
 
I have not however been able to correct the problem when the track is used with the Shader set to standard because I simply do not know what is causing it, or how to fix it. Please keep in mind that I designed this PBR Parallax track primarily for a TRS19 environment where the Shader is set to Ultra in order for the ballast to look real and have depth. For what I designed it for it does that perfectly now with all the other fixes I have done above. If you have not set the Shader to Ultra for your TRS19, for whatever reason, I would advise you to consider using instead the following in its place or some other track of your choice:

Bob

Hi Bob
In this case it appears you might be using the heightmap to push the details too far in, so that when you have heightmaps turned off (shader set to 'standard'), the ballast ends up covering everything.

A way to think of this is that when you have shader set to 'standard', the visuals will be the equivalent of the heightmap set to RGB=255,255,255 over the entire texture. 255,255,255 is the 'top' of the surface, and 0,0,0 is the 'bottom', with the greys between being heights between.

From this, I'd suggest that you check how 'light' your heightmap is. To give the best chance of the ballast not covering the entirety of everything with shader set to standard, you'll want the light bits as close to RGB=255,255,255 as possible.

To put it another way, the top of the highest point/rock in your texture should be around RGB=250,250,250 (giving you a little leeway above just in case). The difference between the lightest and darkest part of the texture should remain the same, you just need to make it 'lighter', just not so light as to start clipping the ends (that'll give you flat bits).

Regards
 
yz6pvfU.png
CKCvoOf.png


When I made my ballast for some new dusty track, I originally started with the height map on the left but had to increase it to the one on the right to get a good effect. I've noticed that most height maps should look something like this anyway, as it will cause the least amount of trouble when mixing other textures.
 
I recall I never really understood how the subdivisions worked. i.e. are the parts compressed or expanded to fit? Are the meshes simply sliced by the number of divisions, or are you expected to "pre slice" the meshes? On resurrecting my old test track I found that I had deliberately put edge loops at the point where I expected the slice to occur. However, I cannot recall if that was the answer or a waste of time.

Paul:

That is both of us in not understanding how that works.

In the N3V procedural track creation tutorial he shows his ballast mesh length as follows:

LOD0 = 5 meters
LOD1 = 10 meters
LOD2 = 20 meters

In the config.txt file example for <kuid2:30501:1001:10> TANE Trk Oak ballast he shows the mesh-length as 18 meters which doesn't match any of the above. He then proceeds to show subdivisions = 3 in the first part of the LOD tree and subdivisions = 2 in the other subdivision parameter part of the tree. None of this is explained in the procedural track creation tutorial or elsewhere in the various N3V tutorials or wiki pages on the subject. The basic question here in the mesh-length parameter for the sleepers, is which LOD mesh length do you use? What he put in his tutorial seems at odds with common sense in that it would be LOD0 or LOD1 or LOD2, but his length his entirely different.

Here is what it says from the N3V wiki page on the Track Part Container for the mesh-length parameter:

"The mesh-length value is a track distance in meters which defines the basic unit length of track that the track-lod-tree describes. The track-lod-tree may supply a single mesh of this length, or may subdivide the unit mesh-length into a number of smaller mesh pieces."

You can see this at:

http://online.ts2009.com/mediaWiki/index.php/Track_Part_Container

Here is what it says from the N3V wiki page on the track-lod-tree container for the subdivisions parameter:

"The subdivisions tag causes the current track part to be subdivided into multiple parts, each of which is then passed through the track-lod-tree. Each part may take a separate path through the tree, however they all start at the current tree node and move downward (ie. the parsing does not re-start from the root of the tree.)"

You can see this at:

http://online.ts2009.com/mediaWiki/index.php/"track-lod-tree"_container

Now to add even more confusion he shows the mesh lengths parameters a follows:

1. <kuid2:523:19723344:6> TANE Trk Oak Sleepers mesh-length = 4. Subdivisions are 4, 1, and 1 respectively.

2. <kuid2:523:19723342:8> TANE Trk Oak Rail-Left mesh-length = 6. Subdivisions are 2, and 2 respectively.

Confused yet?

LOD has made things extremely complicated here, and I have begun to wonder if all the trouble it creates for us content developers is really worth the large amount of effort it takes to make it work.

I was only able to resolve the visual distortions and kinking by showing the LOD0 mesh-length as it really was (2.959) and subdivisions as 1. I used trial and error, one test at a time, to see what would happen by altering various parameters in the various config.txt files. To say this was tedious is a massive understatement. Once I did this everything cleared up immediately. Of course I am not at all sure what will happen with LOD1 or LOD2 with the settings I have used, as I am still testing things out.

The people who know about this don't seem to be too willing to clear it all up as there have been few authoritative replies to my questions on these matters.

In my opinion some real clarification on how all this inter-relates is sorely needed here.....

Bob
 
Last edited:
Back
Top