.
Page 2 of 4 FirstFirst 1234 LastLast
Results 16 to 30 of 57

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

  1. #16
    Join Date
    Nov 2006
    Location
    United States of America, Colorado, Colorado Springs
    Posts
    787
     

    Default

    Sounds like you have been busy. I will look forward to trying them, especially with reduced moire. Thanks
    I7-8700K
    1070Ti
    PCIe SSD operation (program and build)

  2. #17
    Join Date
    Nov 2006
    Location
    Canberra, Australia
    Posts
    8,479
    Blog Entries
    30
     

    Default

    Quote Originally Posted by MSGSapper View Post
    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/i...Part_Container

    and

    http://online.ts2009.com/mediaWiki/i...e%22_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.

    Paul


  3. #18
    Join Date
    Mar 2009
    Location
    Australia
    Posts
    3,457
    Blog Entries
    1
     

    Default

    Quote Originally Posted by MSGSapper View Post
    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
    Zec Murphy

    Customer Support Rep
    N3V Games (Auran)

    *Please do not use Private Messages for support. Support can only be provided via the helpdesk, or via the forums.

  4. #19
    Join Date
    Nov 2006
    Location
    United States of America, California, Del Mar
    Posts
    466
     

    Default



    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.
    Creator of TRS19 QR PB15, TRS19 Class 37 Cab, TRS19 Class 47 Cab
    Admin of: https://www.sodorworkshops.com/

  5. #20
    Join Date
    Feb 2009
    Location
    United States of America, Arkansas, Harrison
    Posts
    2,574
     

    Default

    Quote Originally Posted by pcas1986 View Post
    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/i...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/i...e%22_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 by MSGSapper; February 19th, 2020 at 03:58 PM.
    Master Sergeant/E8, U.S. Army, Retired (1972-1993)

  6. #21
    Join Date
    Feb 2009
    Location
    United States of America, Arkansas, Harrison
    Posts
    2,574
     

    Default

    Quote Originally Posted by ZecMurphy View Post
    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
    Zec:

    While I appreciate the reply and information, I am even more confused now with this explanation. Where is an article published by you all about all this and giving texture examples?

    If I read you correctly, you are telling me that only dark ballast will work here, which explains why the ballast for all the built in TRS19 Jarrah track is dark, and sometimes too much so. That means my light ballast will not work in this situation?

    I wish I had known all of this before! Now I have to go back, re-do everything, to make my track work for both PBR parallax and non-PBR parallax use. That means re-doing 90 meshes, which is what it takes to make a TRS19 procedural track with three LOD levels. In my opinion you all are just making things more and more complex for all of us content developers out here, especially when you throw in LOD requirements on top of everything else (ie; PBR, Non-PBR, Snow mode, shiny track, rusty track, track with ballast, track without ballast, track only, etc).

    Anyone else confused by all of this?

    BTW it would be really helpful if you would make all of the source code and textures for the <kuid2:661281:44274:1> TRS19 Trk Jarrah 6 - Library available as part of that procedural track creation tutorial at:

    http://online.ts2009.com/mediaWiki/i...rack_for_T:ANE

    Bob
    Last edited by MSGSapper; February 19th, 2020 at 11:21 AM.
    Master Sergeant/E8, U.S. Army, Retired (1972-1993)

  7. #22
    Join Date
    Mar 2009
    Location
    Australia
    Posts
    3,457
    Blog Entries
    1
     

    Default

    Hi Bob
    It's not the colour of the ballast itself that is the issue, but rather the brightness of the parallax (aka height) map.

    In this case, simply lowering your ballast meshes and lightening the ballast heightmap (but only the ballast) should be able to resolve this issue.

    Regards
    Zec Murphy

    Customer Support Rep
    N3V Games (Auran)

    *Please do not use Private Messages for support. Support can only be provided via the helpdesk, or via the forums.

  8. #23
    Join Date
    Nov 2006
    Location
    Canberra, Australia
    Posts
    8,479
    Blog Entries
    30
     

    Default

    I recreated one of my ballast meshes with a PBR material and then tested it in TRS19 SP1 in both standard and ultra shaders. I added a graduated pole to see the effect. One of Bob's tracks is in the foreground.





    I didn't really need the pole to measure the effect.

    This was my height map as produced by one of the Substance products. I didn't attempt to adjust the default height values and it turned out rather dark and also blurry.




    I think this one of those cases where you need to do some experimentation to find a combination that works for the various shader nodes.

    Paul


  9. #24
    Join Date
    Feb 2009
    Location
    United States of America, Arkansas, Harrison
    Posts
    2,574
     

    Default

    OK I think I have finally found the solution which is the good news. The bad news, is that it required replacing the ballast I was using with a different one. Here are the results:

    Screenshot of revised track with Shader set to Ultra:



    Screenshot of revised track with Shader set to Standard:



    What this means is that everyone regardless of Shader setting will now be able to use my highly prototypical TRS19 SAP Track U.S. Standard Gauge procedural-track assets. These tracks use flat-bottomed 132LB rail with tie plates secured by spikes into timber ties over ballast. The ties are a prototypical 7 inches x 9 inches x 8.5 feet in size and spaced 19.5 inches center-to-center.

    This now solves the last of the problems that have been reported. I still have some testing and cleanup to do today but everything seems to now look pretty good I think.

    Bob
    Master Sergeant/E8, U.S. Army, Retired (1972-1993)

  10. #25
    Join Date
    Apr 2015
    Location
    United States of America, Pennsylvania, Beaver
    Posts
    578
     

    Default

    Yes they look very good!
    TRS19 106618 - T:ANE 105957
    i7 6700K @ 4.0 ghrtz, nVidia 970
    I don't have a PhD, I have a DD214 - Freedom carries sacrifice

  11. #26

    Thumbs up

    Good Day Sir,

    Those new Tracks, look really good..........Thank you for the extended effort.........

  12. #27
    Join Date
    Feb 2009
    Location
    United States of America, Arkansas, Harrison
    Posts
    2,574
     

    Default

    I have completed the track revision project and uploaded all the files to the DLS. For full details see my announcement at the following forum link:

    https://forums.auran.com/trainz/show...47#post1796147

    BTW all my Blender 2.80 project files which cover all 88 meshes are included with the <kuid2:439337:103187:1> TRS19 SAP Track U.S. 132LB SG Mesh Library-Revised content item.

    My thanks to those who participated in this forum thread!

    Bob
    Master Sergeant/E8, U.S. Army, Retired (1972-1993)

  13. #28
    Join Date
    Feb 2009
    Location
    United States of America, Arkansas, Harrison
    Posts
    2,574
     

    Default

    Quote Originally Posted by RPearson View Post
    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.

    Bob Pearson
    Bob:

    Can you provide me with specifications in meters for the various turnouts you show? I am considering a new project to see if it is possible to design build 4.6 "snap track" type turnouts. Basically this would like an industry track similar to my SAP BI3 industry tracks and would become whatever track you is connect to it. I need:

    1. Total length in meters of straight portion.
    2. Starting point location in the straight portion of the track in meters where the track diverges to the left or right.
    3. Distance in meters between center points of both straight and diverging track at the point where diverging track is as long as the straight track.

    Hopefully you can understand what I am asking for here as I may not be using the right turnout terms for what I need.

    Bob
    Master Sergeant/E8, U.S. Army, Retired (1972-1993)

  14. #29
    Join Date
    Feb 2009
    Location
    United States of America, Arkansas, Harrison
    Posts
    2,574
     

    Default

    Bob Pearson:

    Never mind. I have found a line of turnouts from GAWPO50 on the DLS which seems to have all the information I need, so cancel that request from me, unless you have something to add. Thanks anyway.

    Bob
    Master Sergeant/E8, U.S. Army, Retired (1972-1993)

  15. #30
    Join Date
    Nov 2006
    Location
    Australia, Queensland, petrie Queensland
    Posts
    76
     

    Default

    I quickly scanned through the thread but could not see any mention of the issues I have found while trying your track in my current route development.

    I am trying to use TRS19 SAP Track U.S. 132LB SG,FB, TP with Spikes, Shiny to replace TRS19 Track 1 Procedural - Seasonal. Apart from Moire it is superior in appearance to most tracks I have tested.

    I have shader set to ultra even though I usually have STD set while building a route.

    1. While trying to lay track if I go away to set a switch type or something it defaults back to rail only version. This tends to cause errors when I go back and assume I can continue. I have not seen this with other track types, is this normal or is there a way to set the default. I do have it set in Picklist but don't need to go back there with other track usually.

    2. Sometimes it needs to set matching height on switch lever position to fully form frog

    3. Also in other cases I need to use straighten tool to get the frog to form correctly, mainly in longer switches

    4. I have to replace the PBR texture PBR Gravel 2 - Seasonal with PBR Gravel 5 - Seasonal to get a smooth joint on the ballast to ground position.

    I have not seen this reported before so wonder if I am doing something wrong.

    I have a 1080 TI Graphics card standard settings i7-9700K with 64GB memory and use TRS2019 version 106136.

    Hope someone can suggest solution.

    Colin Rayner
    render2017
    Colin's Trains AKA render2017
    email: render2017 at yahoo.com.au
    Youtube Channel https://goo.gl/Mg3k2m

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •