PBR Texture issues
- Thread starter gds
- Start date
I think I went here...
https://forums.auran.com/trainz/entry.php?59-How-I-make-ground-textures
I used an on-line tool to make an image seamless in the event I couldn't find a seamless pic to work with.
Best,
smyers
https://forums.auran.com/trainz/entry.php?59-How-I-make-ground-textures
I used an on-line tool to make an image seamless in the event I couldn't find a seamless pic to work with.
Best,
smyers
Thanks, I have been using that method, however, the final texture always is lighter than the original texture.
Examples:
Original Diffuse
Resulting Texture in game TRS2019
Tony_Hilliam
Trainz Plus - enjoy Trainz from just 20 cents a da
What setting is your brightness slider on for the attached image? (in environment tools)
Does adjusting the slider make a difference?
Not saying this is the solution, but it is something to keep in mind.
A couple of the posts above (no names, no pack drill) question whether the new PBR textures are "better".
My own personal view -- damn right they are. No question about it. Much, much better.
Yes there are some downsides, like the lava flows on some terrain and the fact that they cannot be mixed and matched with non-PBR textures. However, the 3D effect adds considerably to the realism of the ground and terrain.
For me the classic example is the first scenes in this update of a T:ANE layout. The area around the turntable just springs to life with the 3D textures:
Phil
My own personal view -- damn right they are. No question about it. Much, much better.
Yes there are some downsides, like the lava flows on some terrain and the fact that they cannot be mixed and matched with non-PBR textures. However, the 3D effect adds considerably to the realism of the ground and terrain.
For me the classic example is the first scenes in this update of a T:ANE layout. The area around the turntable just springs to life with the 3D textures:
Phil
EverTrainz
Electric Blue
IMO there is absolutely no reason to create content with legacy materials (for Trainz 2019, at least).
If you know what you are doing there shouldn't be much of an issue, although learning how to do it can be a minor challenge.
.
Yes adjusting the slider will darken the texture, however, the other textures are adversely affected.
Thanks, John
BuilderBob
New member
The change appears to be to raise the ground, but it is not obvious if the default grid ground texture is a height-mapped texture. In that case it is the application of a non-height-mapped texture that changes the ground level. It appears that the default grid is height-mapped, probably with a map value of 255 (it's hard to tell, since it is built-in and not editable).
When the non-height-mapped texture is laid the apparent ground level is lowered, probably back to the original zero level (where objects are placed) as the road then appears to float slightly. The grid lines are now bent, so the height-mapped texture below the non-height-mapped texture is also lowered. In other words, this is a genuine change in ground level, not just a difference in the way that the two textures follow the ground level. The change in level also creates some overshoot, so the non-height-mapped texture overlays the road surface where it runs back into the default grid. This is the adjustment that makes converting older routes so difficult, and means it is nearly impossible to use a mixture of ground texture types in the vicinity of roads and tracks.
It seems a better solution is to leave the default ground height as it was, and set the height-mapped ground texture so that 127 corresponds to that height. A 'flat' height-mapped texture would then require a height-map of all 127, and would align properly with other textures and with the zero z point of objects. Content creators could decide whether their height-mapped ground textures would always underlay (<128) or overlay (>127) adjacent flat textures at the border, or they could use values higher and lower for textures that should be partially over and partially under adjacent flat textures.
Note also that the comment at http://online.ts2009.com/mediaWiki/index.php/Texture_file#Source_Image_Formats that "All images which comprise a given texture must have identical dimensions (width, height)" does not apply to height-mapped ground texture images.
Hi Paul, your method is good at first look but you then miss such great effects on track ballast for example.... I would just avoid using the bad looking ground tex and 3D objects.
Imagine this scenario: I have the same albedo tex for my track ballast and for ground tex. When I place my track and then I paint the ground texture underneath they look completly different not only in light but also colour. So there is something which makes both things look different even if they are just the same.
Another problem is that even if you try to darken the ground tex you will not achieve satysfing effect. It is practicaly not possible to achieve black or even something similar. There is no contrast. Ground tex look like they are semitransparent.
Yesterday I posted an "After Action Report" on my experience upgrading my Cattaraugus Creek & Lake Erie 1950s to fully TRS19 standards. As part of that experience report I discussed some issues I had with PBR textures when used with updating legacy structures. Here is an extract from that report:
Some lessons I learned with upgrading the old structures and bridges to PBR standards:
1. Parallax does not work well with structures. My recommendation is do not include the height map in the parameters file. It is the height map that provides the parallax effect.
2. Old texture atlases don't work all that well in a PBR environment. As an example I had an atlas image that had brick walls and windows on it, among other things. To make the window pane portion of the image transparent I could not use the m.glass or m.pbrmeteal materials. The m.glass material only works with glass and nothing else. If you have a texture that has anything other then glass on it then it will treat everything as if if were glass. In the end I had to use the legacy m.tbumptex for the walls since none of the new PBR materials allow for a portion of the image to be transparent. N3V really needs to implement a PBR material that handles texture that have areas that are transparent or semi-transparent in a manner similar to the old m.tbumptex. For best results with PBR structure textures consider having an individual texture for each element of the structure rather then one overall atlas texture. While not as efficient this will give you better control over how each element looks in PBR.
3. Night mode is more difficult to do in the PBR environment, mainly because of the transparency issues I noted above.
One important thing to note here is that these comments apply when upgrading a legacy (ie; pre-build 4.6) structure to build 4.6 standards. If you are creating a build 4.6 structure from scratch then you probably will not run into these problems as you can engineer to meet specific PBR requirements.
To see the full report go to this forum thread link:
https://forums.auran.com/trainz/sho...oute-to-TRS19-standards&p=1748155#post1748155
BTW the newly upgraded route is also available for download on the DLS if you want to see how everything worked out.
Bob
Some lessons I learned with upgrading the old structures and bridges to PBR standards:
1. Parallax does not work well with structures. My recommendation is do not include the height map in the parameters file. It is the height map that provides the parallax effect.
2. Old texture atlases don't work all that well in a PBR environment. As an example I had an atlas image that had brick walls and windows on it, among other things. To make the window pane portion of the image transparent I could not use the m.glass or m.pbrmeteal materials. The m.glass material only works with glass and nothing else. If you have a texture that has anything other then glass on it then it will treat everything as if if were glass. In the end I had to use the legacy m.tbumptex for the walls since none of the new PBR materials allow for a portion of the image to be transparent. N3V really needs to implement a PBR material that handles texture that have areas that are transparent or semi-transparent in a manner similar to the old m.tbumptex. For best results with PBR structure textures consider having an individual texture for each element of the structure rather then one overall atlas texture. While not as efficient this will give you better control over how each element looks in PBR.
3. Night mode is more difficult to do in the PBR environment, mainly because of the transparency issues I noted above.
One important thing to note here is that these comments apply when upgrading a legacy (ie; pre-build 4.6) structure to build 4.6 standards. If you are creating a build 4.6 structure from scratch then you probably will not run into these problems as you can engineer to meet specific PBR requirements.
To see the full report go to this forum thread link:
https://forums.auran.com/trainz/sho...oute-to-TRS19-standards&p=1748155#post1748155
BTW the newly upgraded route is also available for download on the DLS if you want to see how everything worked out.
Bob
ZecMurphy
Community Assistant
Hi BuilderBob
The terrain height is changed when using PBR ground textures to support Parallax. It is not the other way around. We add to the terrain height to account for the parallax textures. This is why, if you replace an older ground texture with a PBR one, it can 'bury' things with the PBR textures.
As the thread was specifically in relation to the distortion of the ground textures where the terrain angle changes sharply, the 255,255,255 value is the correct value to 'flatten' your texture to remove this effect.
If you use the 127/128 value to blend with older textures, then you will introduce the 'distortion' effect where ground textures change angle.
The distortion seems to be a bigger complaint than the overlap of different height textures, and my personal suggestion would be that any 'flat' textures be made 255,255,255...
As to the last link you provided, the dimensions of an image and it's 'alpha' channel must be identical; this is primarily relevant where a creator uses a separate image for the alpha rather than the actual alpha channel of the tga, and is very common in older content. It is not required for different textures in an asset or even in a single material to be the same dimensions (ie your albedo can be a different size to your parameters map and/or normals map).
Regards
The terrain height is changed when using PBR ground textures to support Parallax. It is not the other way around. We add to the terrain height to account for the parallax textures. This is why, if you replace an older ground texture with a PBR one, it can 'bury' things with the PBR textures.
As the thread was specifically in relation to the distortion of the ground textures where the terrain angle changes sharply, the 255,255,255 value is the correct value to 'flatten' your texture to remove this effect.
If you use the 127/128 value to blend with older textures, then you will introduce the 'distortion' effect where ground textures change angle.
The distortion seems to be a bigger complaint than the overlap of different height textures, and my personal suggestion would be that any 'flat' textures be made 255,255,255...
As to the last link you provided, the dimensions of an image and it's 'alpha' channel must be identical; this is primarily relevant where a creator uses a separate image for the alpha rather than the actual alpha channel of the tga, and is very common in older content. It is not required for different textures in an asset or even in a single material to be the same dimensions (ie your albedo can be a different size to your parameters map and/or normals map).
Regards
euromodeller
Imagineer
I hope that I don't give the impression that I am totaly anti-PBR groundtex, on the contrary, in the right location they are brilliant.
You do need to select carefully which groundtex to use and experiment with different scale settings in surveyor for each location.
One thing that I like is that they ovelap/blend perfectly and somewhat disquise the dreaded jagged edge.
If only they could work better on acute terrain hiight changes, like on the edges of cuttings......I am still experimenting with surveyor settings to lessen the effect.
You do need to select carefully which groundtex to use and experiment with different scale settings in surveyor for each location.
One thing that I like is that they ovelap/blend perfectly and somewhat disquise the dreaded jagged edge.
If only they could work better on acute terrain hiight changes, like on the edges of cuttings......I am still experimenting with surveyor settings to lessen the effect.
BuilderBob
New member
If it's not a change in ground height then something else is happening at change of scale (PBR Soil Texture 2).
EverTrainz
Electric Blue
For the color issues. Most of the HD photos used to make ground textures are taken in bright sunlight. What this does is make the colors brighter and more desaturated/pale yellowish. When you use that texture unmodified, Trainz’s default sunlight makes it appear brighter and desaturates it even more, making them look washed.
To combat this you should play around with the texture in an editor, and try to increase the saturation and lower brightness, to “normalize” the texture.
To combat this you should play around with the texture in an editor, and try to increase the saturation and lower brightness, to “normalize” the texture.
So far the PBR has been a blessing and a curse for me. I've had Ron's experience, trial and error with Photoshop to correct color. Usually up contrast and lower brightness. And the "semi-transparent" issue noted above, especially at brush edges which are too soft and can't be adjusted as far as I know. Had some better luck with terrain height lately.
Burying low maintenance yard track in dirt, ballast and so on has been nearly impossible...
...but using a fixed value in terrain height rather than the up and down arrows worked better. Set sensitivity to minimum for best control. The mud texture above the stack has a greater depth but still looks OK. The puddles are pretty convincing. Some textures are by your truly (not the mud) converted to PBR by ltated27.
Best,
smyers
Burying low maintenance yard track in dirt, ballast and so on has been nearly impossible...
...but using a fixed value in terrain height rather than the up and down arrows worked better. Set sensitivity to minimum for best control. The mud texture above the stack has a greater depth but still looks OK. The puddles are pretty convincing. Some textures are by your truly (not the mud) converted to PBR by ltated27.
Best,
smyers
Dinorius_Redundicus
kuid 68213
If it's not a change in ground height then something else is happening at change of scale (PBR Soil Texture 2).
Bob,
What are you trying to demonstrate in those pictures? It’s not obvious to me.
D
BuilderBob
New member
It appears from this example that changing the scale at which a PBR ground texture is painted changes the height variation that is applied to the ground.
It was stated that this doesn't happen. If that's so, then changing the scale at which a PBR ground texture is painted is introducing some other artefact that needs to be fixed.
If changing the scale at which a PBR ground texture is painted does change the height variation that is applied to the ground then this is one means by which the PBR height effect can be 'wound back' where needed. I believe this has previously been suggested as one way of minimising conflicts in the ground height - eg, to stop the texture showing through the bottom of other assets, such as roadways. It certainly emphasises the importance of careful adjustment of the range of values used for the height maps. For instance, will using height map values in the range 64 to 127 result in PBR ground textures that are always below the 'zero point' for the local ground level (ie, the position of the (0,0,0) point in a mesh placed at zero height in Surveyor)? Or will the expansion scale up from zero rather than the mid-point, so that a height map range of 64 to 127 becomes 64 to 159 (say) as scale increases, and a value range for the height map needs to be 0 to 64 to stop the texture ever appearing above the zero point?
Someone wrote the code to implement all this, so someone knows the answers to these questions, but it is not being made available for content creators to create content that addresses at least some of the concerns being raised by users.