Use of Transfers for Terrain painting roadbed

[bcrailfan]

The following may qualify for "work in progress" . I still am attempting all possible avenues to represent the "roadbed" underneath tracks, that is sorely missing but on a handful of MSTS Route . Being relentless about this, I believe I may be "on to something" , which has a wider range of application, for a greater number of train simmers . Have a look !



First screenshot : the conventional track laid directly on top of the terrain . We all seen Routes where tracks are laid directly over top of golf course-flat "lawns" ...
http://i271.photobucket.com/albums/jj143/c37dash7/grab_006-2.jpg


Second screenshot shows a "transition" pont . "What's that" ? ... :?


http://i271.photobucket.com/albums/jj143/c37dash7/grab_011-5.jpg


Rotating the camera 180 degerees, we can see this same (temporary ) transition spot


http://i271.photobucket.com/albums/jj143/c37dash7/grab_016-1.jpg


So ? What d'you guys think ? If anyone ever applied 'waterslide decals" on a plastic model,
this is something you could do ... If you ever thought all this "terrain painting" using Mosaic
was pure aggravations , then , you may consider this way of doing things . Enjoy !


http://i271.photobucket.com/albums/jj143/c37dash7/grab_027-2.jpg


http://i271.photobucket.com/albums/jj143/c37dash7/grab_028-2.jpg


I will revisit this thread on Monday , not having enough time to post comments for the following .

But this would illustrate the process oh how I , say “ arrived”, at the results in the previous
Screenshots . When you are relentless about something , as they , one thing leas to
Another …

Jean Brisson BCLW Route Building Team

[bcrailfan]

Here are the screenshots illustrating the process .

Process

http://i271.photobucket.com/albums/jj143/c37dash7/1terrainspraypainting3.jpg


http://i271.photobucket.com/albums/jj143/c37dash7/2lowerby1meter.jpg


http://i271.photobucket.com/albums/jj143/c37dash7/3transferpainting.jpg


http://i271.photobucket.com/albums/jj143/c37dash7/4transfertest.jpg


I will revisit this thread on Monday .

Jean brisson Victoria, B.C.

[qballbandit]

Jean,
Though I have no idea how you are doing it, if there is an easier way to create a roadbed, i would love to learn the technique.
Being pretty unskilled at Mozaic, the most I have done thus far was go through the tutorial on how to create a roadbed, and I got a headache. :p

I would love to hear more about your discovery. I am fascinated with your intense study of terrain/terrtex development. We had chatted offline a few times about it in the past, and you were very helpful and insightful.

Good luck, and anxious to see more. :)

Neil :)

[MasterChief]

Jean,

That's an intriguing idea... how did you get the transfer to curve? This might be a far better idea, as far as route download size goes, than creating a million terrtex files with Mosaic to create a roadbed with a different texture than the surrounding landscape.

I have quite a lot of track that goes through plowed fields - farmland, and this might just do the trick.

[snootnose]

I actually thought to do that a few years back. I just never figured out how to make it curve. I am impressed that you did.

[jovet]

I'm guessing the curve was built into the texture. Each radius of curve will need its own tweaked texture?

I'm skeptical about this idea...namely because Transfers are abhorrent on frame rates, especially large-area ones. There's also the flickering problem when they ultimately overlap.

[mdeming]

I did just that, used transfers, on an early version of my route. I am not sure about how framerates were affected but didnt like the visual effect. The flicker was annoying and the texture was stretched and didnt look right. I wound up removing them. I love how mosaic looks but it is extreemly time consuming. I have made generic ones that looked ok, but were not flexible enough. The only thigs I use transfers for are tunnel entrances and distant, more than 1000 m from track, roads.

[Swissie]

Hi guys,

transfers under the tracks have their pros and cons, over some of which the route builder has an influence.

Pro:
1) Better and more realistic looks.
2) Friendly on download size and route installation size
3) Easy to use in summer and snow environments (I've seen routes with over 6000 individual terrtex files, 1000s of which lack their matching counterpart in snow, so running the route in winter is years away!)

Cons:
1) FPS: Any transfer texture eats away a bit at the fps.
2) Flickering issue where ever two transfers overlap. The flickering is not only annoying, but further eats away at the fps as well.
3) Requires accurate placement and is thus also very time consuming.
4) Transfers often dissapear over tile boundaries, so extra care must be used to place them at, but not over the tile boundary.
5) For good lucks, many relatively short sections must be used, instead of a long, but distorted single one. That, again, slows down their placement

Some comments to the cons:

1) How much a transfer affects performance depends on three factors:
a) Resolution of the .ace file (don't use 512x512 for a transfer, or your fps counter will literally grind to a stop once you've placed a few dozens of them). Make them as small as possible, e.g. 128x128 or even 64x64, and avoid excessive detail on the transfer itself.
b) The use of an alpha channel vs a "solid" transfer
c) The area actually covered by the transfer. The bigger you set its dimensions in the RE, the more flickering occurs.

On a side note: Using several dozens of individual terrtex files on the same tile isn't really improving your performance either, their loading may also cause stuttering whenever you approach the next tile, and if each one has lots of detail painted on it, the fps gets down as well...

2) Flickering / overlapping issue: A transfer is always "glued" to the ground, i.e. the texture always sits at ground level. If two neighbouring transfers overlap, then both their textures are in the very same spot. The sim tries to display them both, causing the flicker.

It seems that the effect is not that bad if alphaed-out sections of two transfers overlap. Thus. to avoid the issue, use a number of alternate alpha channels to "shape" the transfer, e.g. have U-shaped end sections, V-shaped sections that go under switches and turnouts, straight / parallel sections that go under straights etc.

3) Not much to do about accurate placement. When using them, I consider myself lucky if I manage to put down transfers under a five mile stretch of track in one evening, usually using 50m "sections" of transfers to avoid the distortion. Using longer sections would make my progress faster, but they definitely don't look as good as the shorter ones. And if it doesn't look good, what's the use of still placing it?

4) I usually go to the next tile boundary first (blue line in RE), place a transfer either side of the blue line (often a V-shaped one so that the gravel under the roadbed narrows a bit near the blue line, minimising the effect of any overlaps or dissapearing transfers) and adjust it so that both transfers just meet on the blue tile boundary. Then, I work my way back to the tile boundary behind me, filling up the area inbetween with transfers.

5) See above, nbr. 3. On single straight track, I usually use a transfer that is 8-10 metres wide (depending on the alpha channel) and 50 metres long. In curves, I reduce the lenght accordingly so that the string of transfers roughly followes the curve (that's of course not giving you a 100% accurate gravel bed under the curve, but it isn't 100% accurate in real life, either). If there's more tracks, so that the transfers get wider, I can also up the length a bit without distoring the effect.

In yards however, I'd never use transfers under the tracks, but cusomised terrtex files. Mainly because it's flicker free, while large areas covered by transfers will always be "flickery"...

[jovet]

3) Easy to use in summer and snow environments (I've seen routes with over 6000 individual terrtex files, 1000s of which lack their matching counterpart in snow, so running the route in winter is years away!)

That depends. For a while now I've wanted to experiment with creating a single "snow blanket" texture....and then making and using a utility to copy that single file to match all of the Mosaic filenames in the Snow folder. It would make them all look the same, but if the ground is covered in snow, it looks about all the same anyway. If there are roads or such painted onto the terrain one could try to manually manipulate the files containing those.

[bcrailfan]

if there is an easier way to create a roadbed, i would love to learn the technique. Neil :)

Feedback : Neil, I just prepared what amounts to a "mini-turorial" on this topic , just last night . Only problem is that it just won' t 'fit" , within a post / reply on the Forum . Send me a PM or email , and I will send this tutorial as an attachment .

I will see what I can do as far as making the basic transfer I have shown here, available for the File Library ( packaged with the tutorial ), so anyone could make their own 'version" of it .

Jean Brisson BCLW Route Building Team

[bcrailfan]

I'm guessing the curve was built into the texture. Each radius of curve will need its own tweaked texture?.

Feedback : I will post a screenshot showing underneath the terrain surface, and you will see those really are fairly short ( 12 meters by 12 meters, once fully "deployed") .

Because of the manageable size / spacing of each texture , those in fact "articulate" from one to another . I guess I thought about this "articulation" concept from working with my very short ( 5 meters long ) berm segments, which did 'telescope" one into another , seamlessly . Same concept / idea , here .

http://i271.photobucket.com/albums/jj143/c37dash7/6grab_002.jpg


The following screenshot should give a better understanding of the 'articulation" taking place ( as this is all that is ) .

The transfer is first 'deployed" to 12 meters by 12 meters ( fairly small , that is true, but TOTALLY square , to match very close to a 1:1 ratio, with a 512 ace texture image with alpha channel "spillover" pattern on 2 opposite edges ) .

The transfer's center point is always 'slid" into place, to match the track center line , and in wireframe mode, the texture is simply rotated aroung its center pivot point ( it behaves like a 'waterslide decal", and will not "fly all over the place" like world objects ) .

Using a smaller / "mandatory" ... square size ... for the deployed transfers, this can be applied to ANY existing curved track radius , as well as dynamic tracks. Anything goes .... just about "one filename fits all" .

And as Lukas pointed out, a cetain degree of "randomness" and slight "sloppiness" in their placement , can certainly be desirable , and you can very quickly 'eyeball" their placement , in wireframe mode .

http://i271.photobucket.com/albums/jj143/c37dash7/4transfertest.jpg

I also prepared a mini-tutorial that won't fit as a post / reply, which shows how you can use the Gantry,dat auto-placement , to ( temporarily ) drop , say , "markers" , following the track's centerline , spaced apart every 11.5 meters ( to allow for some overlap and articulation ) , "marker" entries that you would simply "overwrite" in the world file, replacing their filenames, with the ones for the transfers .

You would then have a tile's worth of tranfer's "green cubes" , where nothing needs to be done at all, as far as their X axis, and Z axis world placement ( you would only need to go back and 'deploy" each one , and rotate them as needed ) .

Here the Gantry.dat "script" I am using :

GantrySet(
Name ( "MGS_sub_Roadbed_trans " )
Style ( 00000002 )
Separation ( 11.5)
GantryTable ( 1
GantryTableEntry (
Filename ( "MGS_DBB_sub_rdbed_transfer.s" )
Distance ( 5 )
)
)
)


I still obviously need to do some more testing to fully ensure there are no issues related to transfer's 'flickering" and so forth . At this point in time , it's all good, as they say ...

Jean Brisson BCLW Route Building team

[bcrailfan]

Since I cannot post my mini-tutotial here, here is yet another screenshot to illustrate the edges of the (roadbed ) transfer :


http://i271.photobucket.com/albums/jj143/c37dash7/4grab_005.jpg



Highlighted in red, you can clearly see the "ballast spillover" pattern , on the acleantrack1.ace texture, exact same "pattern" , which I applied to 2 of the outer edges of the transfer's alpha channel .

Compression was using a lower compression rate , namely , the straight "Alpha" checkbox selection in TGATools 2 .

I had MAJOR terrain texture challenges not too long ago ( those Terrtex "Mirage" issues ), by using DXT1 compression . DXT1 compression would also leave the equivalent of "burnt" or "charred' black marks, on the outer edges of the "spillover" pattern, once those are in place , in RE , and in the InGame mode .

For my own "Frame Rates Budget" / for my specific application , I can certainly afford to spend a more generous allocation of my FPS "budget", on things like higher resolution roadbed replication . Each situation varies.

Jean Brisson Victoria, B.C.

[emacom]

And what about the number of objects per tile? There is a certain limit, as we all know, depending on how many polys are on a tile or, in your case, on how big the .w file will grow.

[bcrailfan]

And what about the number of objects per tile? There is a certain limit, as we all know, depending on how many polys are on a tile or, in your case, on how big the .w file will grow.

Feedback : This is up to the individual to make an assessment ( before launching the auto-placement ).

Each project is different , and as I mentioned, one should consider both the "Frame rates Budget", and the maximum number of world objects that can be entered, before you actually "blow up" your Tile .

That is, if using "world objects" elements such as short 3 dimensional berm segments, or the 'flat plate" berms I will revisit tomorrow .

So far, on a single track mainline with a few sidings, I usually have gotten from 200 to 400 something individual "gantry" defined entries per world file .

When we hear of folks "blowing up"their tiles, they usually are installing far too many 'details" which are not always entirely "relevant" to the Train Simulation part of the SIM . Too easy to let ourselves get carried away , and indulge into "super-detailing" .

I cannot tell as far as maximum number of transfers per tile . But since they are entered in world files, if I have this right , the "maximum" limit per tile, for world file entries, is less than 1,300 or so . I hope I have this right ...

But Yes, you are absolutely correct that there is a risk, and that you are indeed 'rolling the dice" , when launching the auto-placement function on a Tile . You can always "bail out" of Route Editor without saving ( at all ), and making multiple backups of your Route , still the best advice to this day .

Jean Brisson Victoria, B.C.

[jovet]

I cannot tell as far as maximum number of transfers per tile . But since they are entered in world files, if I have this right , the "maximum" limit per tile, for world file entries, is less than 1,300 or so . I hope I have this right ...

There is no known actual limit to the number of objects that can be placed on a single world tile or the allowed size of a .w file.

Think of the perceived limits like body weight. "Thin" world tiles are like bodies and are perceived to be healthier and more active. As a world tile gets fatter and fatter, like a body, it causes more sluggishness, more resistance to movement (frame rates) and more risk of disease (crashes).

It's possible to have a 1800 object world tile just as it's possible to have 900 pound person... but you should strive to have neither. Fewer is always better.

Interactive objects and forest/yard regions always expand file size and consume memory more than other objects .

[bcrailfan]

I had a bit of a 'breakthrough" using Google Sketchup and finally ... being able to use an ace texture WITH an alpha channel, and make it work on a basic Google Sketchup-designed model .

This may be nothing new to some ( Google Sketchup models with alpha-channel equipped textures ) , but for me, this did change my outlook as to why I would not want to use dedicated world object "flat berms", as I call them . I' ll explain as I go.

Let's revisit this option , as some other arrow in your quiver . This still remains "on track" with the roadbed replication purpose of this thread .

To set the context properly, the first screenshot shows this world object "flat berm" on location .

Those "flat berms" already had been "test-placed" on location, using the Gandtry-dat auto-placement / I simply upgraded just the texture itself, and voila ! ... Google Sketchup-created flat plate with alpha channel texture "terrain spillover" effect .

Note the overall resolution and sharpness of the texture, is now higher than using transfers ( deployed to the exact / same 12 meters by 12 meters size ) , and the rendering , very much a 1:1 ratio replication of a 512 X 512 texture image .

http://i271.photobucket.com/albums/jj143/c37dash7/grab_016-2.jpg



http://i271.photobucket.com/albums/jj143/c37dash7/10.jpg


For anyone curious about how I actually created the flat berm world object texture ( with alpha channel ), I just posted a 2 part mini-tutorial on this very topic, in the Scenery Object design section of this Forum .

http://www.trainsim.com/vbts/showthread.php?t=291089



What was truly holding me back, from using world object "flat berms", were 2 things : One , I had no success in getting Google Sketchup created shapes, to display conventional (MSTS) Ace textures , having their own Alpha Channel .

Now that this setback out of the way , only remained some rendering "flicker" happening on occasion . By the looks of it, I also overcame that , and some tips related to that , would also apply to other situation one may experience .

The screenshot below illustrates a rendering "glitch" , that happens occasionally and erratically , mostly depending on the camera angle . Only a few , somewhat precise "spots' or areas, seem to have this issue .

http://i271.photobucket.com/albums/jj143/c37dash7/flatbermrenderingproblem.jpg


From previous experiences, this indicated same kind of conflict between the height of the Terrain , and the Y axis parameters of the flat berm world object .

First step, was to highlight the next closest section of track, activate it, and then press "Y", to perhaps "tamp" the ground underneath the track, a bit tighter against its bottom surface .

This, actually did not change anything .

I also have to add a reminder , here, that all those berm shapes had their Terrain Object properties activated , already ( prior to any re-adjustments ) .

Just that ( setting the world object , as a Terrain Object ), eliminates a good 90% and more of those 'rendering" abnormalities , when such as a world object comes into contact with the tracks / terrain immediately underneath the tracks.


http://i271.photobucket.com/albums/jj143/c37dash7/flatbermrenderingproblem2.jpg


What was left, is perhaps some imprecise auto-placement positioning of the shape , initially . The Gantry.dat auto-placement is never perfect , and anyone having made use of this function, does know its limitations, as well as its "DUH moments" ...

Previous experience at working with berm shapes placed with the auto-placement , and I quickly then did the following .

Being "dead certain" that the surrounding terrrain was 'flat like a pancake" for a good 6 meters either side of the track centerline , I then activated the berm plate , and pressed "N" ,to perhaps "re-align it" a bit better ( as far as 3 dimensional "rotation" ) .

Nothing happend as the result of pressing "N".

What was left, was to raise the berm plate , a mere One Tenth of One meter ( 0.1 meters ), by activating it, left-clicking to open the properties box, and adding .1 , to the "Y" paramters .

Done . For this one . There were not that many "deficient" ones at all, per Tile ( less than 12 to 24 , per 400 or more such shapes "zapped" instantly into place , by launching the auto-placement function, in Route Editor )

On the screenshot below, showing this plate , after it had been completely fixed ( less than 4-5 seconds, really, to get to this ).

You may still note, in the top left corner of the RE window, one small horizontal line still showing ( this would be a different plate than the one we fixed ) .

That one is not a rendering glitch , but a slightly misaligned "plate" , as the track line itself, is on a slight grade , and the auto-placment does create some minimal 'staircase" effect here and there ( minimzed to next-to-nothing , by using very short sections, such as those 12 meters by 12 meters flat plates )

And so, lots of options for "roadbed replication", now, and you can certainly "pick and choose" , and / or, "mix & match" , as fits the specific Tiles / Route , you' re working on !

http://i271.photobucket.com/albums/jj143/c37dash7/raisedbyonetenthofameter.jpg


Jeab Brisson BCLW Route Building Team

[jovet]

Now that this setback out of the way , only remained some rendering "flicker" happening on occasion . By the looks of it, I also overcame that , and some tips related to that , would also apply to other situation one may experience .

It has already been mentioned in this thread that two or more Transfers that overlap will cause this phenomenon and that the reason for it is the two Transfers try to render in the exact same place causing random results.

That is true for any two faces (polygons) in the exact same position. They will complete with each other and produce random results...which looks like flickering. This phenomenon is also observed with light "planes", particularly on locomotives, where two lights are too close together to get along. Same cause and reason.

Unlike the Transfers, the problem can be fixed for your static shapes. Adjust one of the shape's Y coordinates up by a millimeter (0.001m) and the flicker should disappear. It should be a much better effect than 0.1m. You will then need to adjust every other overlapping shape's Y coordinate in the same manner to avoid two shapes with identical Y coordinates being adjacent.

With multiple shapes that share the same Y coordinate, you can select them all, and set their Y coordinate manually all at once. If a coordinate box is blank when multiple objects are selected, then they have disparate coordinates, and entering a value into the box will change their relative positions to identical (which you don't want to do in this case).

I'd also like to point out that flickering should never be accepted by any route builder. What looks like minor flickering on your computer can be major flickering on another user's computer.

[bcrailfan]

After trying many different options for replications of track roadbeds / berms, etc ... , and having taken the time to test those in the InGame mode, I came up with a few solutions which are worth pursuing ( for my specific applications / hopefully that of other Route Builder as well... ) .

Here's a few of those " I think I got it , this time", type of screenshots . All 3 screenshots were taken while in Route Editor .


http://i271.photobucket.com/albums/jj143/c37dash7/IthinkIgotit2.jpg


This first screenshot, shows the 3 dimensional berm shapes I had created earlier .

I did 'revisit" the specific texture assigned to this part of the berm, where there is ballast "spillover" . This "spillover" transition is much rougher and 'randomized" than previously done , and for the lower "terrain" part, I used the exact same ace texture as the surrounding "terrtex" .

In addition ... to the 3D roadbed , I added some 'flat" roadbed plates ( e.g. "world object" shapes ), further below ( about a meter or so, lower than the top of the rails ) , and this came out like that .


http://i271.photobucket.com/albums/jj143/c37dash7/IthinkIgotit3.jpg


This is the exact / same / square "flat" 12 meters by 12 meters shape, with a different ace texture ( this time a darker grey and slightly coarser grain , crushed rock texture ) . Yet another "keeper" ... Perfect for making at ransition when the mainline reaches switches , grade crossings, etc ...

Not to forget that all textures created while doing all this, can also... be used to create dedicated 'transfers" .

http://i271.photobucket.com/albums/jj143/c37dash7/IthinkIgotit.jpg




Jean Brisson BCLW Route Building Team

[Richard]

That depends. For a while now I've wanted to experiment with creating a single "snow blanket" texture....and then making and using a utility to copy that single file to match all of the Mosaic filenames in the Snow folder. It would make them all look the same, but if the ground is covered in snow, it looks about all the same anyway. If there are roads or such painted onto the terrain one could try to manually manipulate the files containing those.


Create your snow blanket texture then copy it to the EUROPE2\TerrTex\Snow folder. Make a backup of OEGrass2.ace in the Snow folder then rename your blanket texture to OEGrass2.ace. Now make sure there are no other routes in your Train Simulator folder that have snow textures with the same filenames as in your route. If there are other routes that have the same mosaic.ace filenames that appear in your route, move those other routes to another temp folder so they are no longer in your Train Simulator\Routes folder. Now run Route-Riter and have it check your route. When Route-Riter does not find a snow texture for your summer terrtex texture, tell Route-Riter to use the default texture. Route-Riter will then use the texture you copied into the EUROPE2\TerrTex\Snow folder. This method at first sounds more complicated that it really is and it will allow you to create blank snow textures for all of your mosaic textures ;)

[jovet]

Route-Riter will then use the texture you copied into the EUROPE2\TerrTex\Snow folder.

Yep, that definitely sounds like a solution!

[qballbandit]

Richard, thanks for that info - VERY usefull!! :)

And Jean, those last picks look unbelievable. I commend your patience and determination. I wish my routes looked that nice along the tracks.

Neil :)

[Simon12345]

Thanks Jean,

A very convenient and fast method to do the same task I used to do previously, which took me ages. Thanks again!