[captain_bazza]

Quote

"Will all great Neptune's ocean wash this blood clean from my hand? No, this my hand will rather the multitudinous seas incarnadine, making the green one red"

Macbeth

The only historical advice I could find, keeping in mind that anything to do with train sims is, "blood, sweat & swears".

Cheers
Bazza :aggressive:

[Genma Saotome]

rdamurphy, on 11 January 2014 - 07:46 PM, said:

Shaders are already included in the .env file, read by OR, and used...

Of course, they're global, as well as the corner heights being attached to the corner heights of the tile, a HUGE limitation since all of the water on one tile must be at exactly the same height.

Robert

The offsets can be handled:

ByPatch (			# (Exclusive with AllPatches)
			NumPatchesDefined ( int )				# (not sure this is needed )
			Patch (
				PatchX ( int )					# (values of -8 to -1, 1 to 8 inclusive )
				PatchY ( int )					# (values of -8 to -1, 1 to 8 inclusive )
				Layers (
					Layer (
						LayerNbr ( int )
						WatertexFile ( 
							WatertexPath (full path )		# (Optional; defaults to current routes path to terrtex folder.)
							WatertexFilename ( name.ace )
						# ( any other data useful to defining the layer goes here.)
						)
					# all other layer definitions for all layers for this patch goes here.)
					)
				)
				PatchOffsets (					# (either relative to the heights defined in RE or absolute. )
					NWCorner ( real )
					NECorner ( real )
					SWCorner ( real )
					SECorner ( real )
			# ( any other data useful to defining the water across the whole patch goes here.)
			)

Where it all gets tricky -- and makes my rough examples quite rough -- is the awkward nature of mixing new and old: A completely new design would, IMO, would trash all of KUJU's physical design while retaining and extending what it seems to have originally intended: multiple layers of water textures applied route-wide, varying by seasons and weather conditions... with the new of having the flexibility of over-rides for individual tiles and even individual patches. As we maintain backwards compatibility the team cannot entirely let go of KUJU's .env file, nor the texture metadata contained within the terrain mesh, and so it seems moving forward with any improvement creates a requirement for a sticky solution.

<sigh> Well, I do hope my sketchy ideas here can inspire someone to design a useful solution... there are many MSTS routes that could be improved with varied water textures in different areas.

[rdamurphy]

Dave, actually, you can use varied water textures by season, realistically, the only reason that it hasn't been done is because no one has tried it yet.

For example, say you wanted a frozen solid layer of ice on your lake in the winter, and nice pleasant clear blue water in the summer.

No need for fancy, tricks, simply designate your 3 (or more) summer water layers in the sun.env file, and you get your summer thing.

Then, in your snow.env file, simply designate your single layer of solid ice (TexDiff, and no alpha layer), in a single layer rather than multiple ones and name it "ice.ace."

Simple, really, although it doesn't work in OR - yet.

But it actually looks pretty good in MSTS. In the default files, they simply left everything like it was and changed BlendATexDiff to TexDiff to hide the alpha channel and everything below it. On, and disabled the animation.



Dave, you do know that I NEVER play my train sims in the snow, though, ever... I get enough of that IRL.

LOL.

Robert

[James Ross]

rdamurphy, on 11 January 2014 - 04:36 PM, said:

The water tiles are another thing Kuju seemed to have put an awful lot of effort into and then implemented very poorly. I'm beginning to believe the programmers and the guys who made the routes never had a conversation about what could be done.

I'd very much agree; there's a huge load of flexibility and ability in MSTS that's never used, sometimes because it's global when it should be per-route or per-season, but sometimes for no apparent reason at all. I am repeatedly impressed with what they could do, even though they usually didn't bother. (Latest example: the unit parsing in MSTS... appears to be a full-on stack-based expression engine with a generic system of unit conversion. I mean, wow.)

[rdamurphy]

The further I dig into the .env files, the more obvious it is how many things they just missed out on. I had no idea that MSTS actually simulated wind!

So, after some effort, I came to the conclusion that reading everything out of the water files is really a waste of time. The information really makes no sense. It tiles the under layers 8X, and the top layer 4X for default. Not much point really, I just tiled them all 4 times to match the default.

I did figure out how to exactly reproduce the "wave" effect, really just the top layer moving in an odd pattern, basically from the start, makes three moves in a somewhat square pattern, then back to original. It sucked so bad that they disabled it by default in all of the default routes - except the one that they use when you create a new route. It seems that you could add parameters and move it in a much more subtle pattern, slower, with smaller steps, and even in a circular pattern if you were willing to do the work in the .env files. Bizarre. And yet they just did a four point movement and called it "good." I might try experimenting with it in MSTS to see if we could possible translate it to OR.

James, I found a code example of making "waves" by moving a bump map around, that might actually work, although I don't think using the original MSTS parameters would be at all helpful, but if we could make it look good by having it move slowly between the points, then people could experiment with the parameters to get the effect they want. What do you think?

Robert

[James Ross]

rdamurphy, on 14 January 2014 - 03:21 AM, said:

The further I dig into the .env files, the more obvious it is how many things they just missed out on. I had no idea that MSTS actually simulated wind!

These are the kinds of weird discoveries that make me want to disassemble the game files for nearly everything. I usually resist, except for MSTS, though. :sign_thanks:

rdamurphy, on 14 January 2014 - 03:21 AM, said:

James, I found a code example of making "waves" by moving a bump map around, that might actually work, although I don't think using the original MSTS parameters would be at all helpful, but if we could make it look good by having it move slowly between the points, then people could experiment with the parameters to get the effect they want. What do you think?

I would suggest taking the following approach, as long as it doesn't make things too complex:

• Anything MSTS does that you can do reasonably/easily, do it.
  
• Anything MSTS might do or is harder to replicate, it's up to you. But, if you know it exists and choose not to add it to Open Rails just now, please leave at least one // TODO about it and document everything you have found in a source code comment next to the TODO. That way, someone else can pick up without having to rediscover everything.
  
• Anything MSTS doesn't do but which would be a nice improvement, start off by having an experimental menu option for it.

So, in this specific case, I think you've done most of the first point already by the sounds of it; I think the moving water should be skipped for now, but documented with a TODO, and the bump mapping 'waves' should be an experimental option. I doubt it makes sense to use the MSTS moving-water data for the bump map.

Does that make sense to you?

[Genma Saotome]

rdamurphy, on 14 January 2014 - 03:21 AM, said:

The further I dig into the .env files, the more obvious it is how many things they just missed out on. I had no idea that MSTS actually simulated wind!

I knew that. You use it to control the direction that clouds move.

WRT water, having 4 seasonal .env files to work with I set different values in each for the offset-from-water-height-on-each-tile and that got me a tidal effect that works reasonably well across the mud flats and shoreline marshes of the Cal-P route. Low tide in summer, high tide in winter with the later really flooding large areas.

Summer:


Winter:

[roeter]

Genma Saotome, on 14 January 2014 - 09:12 AM, said:

WRT water, having 4 seasonal .env files to work with I set different values in each for the offset-from-water-height-on-each-tile and that got me a tidal effect that works reasonably well across the mud flats and shoreline marshes of the Cal-P route. Low tide in summer, high tide in winter with the later really flooding large areas.

Clearly that method only works if you have just coastal waters.
If you have a route with both coastal and inland waters it's going to flood all your valleys and lakeside areas as well.

If possible, a distinction between tidal and non-tidal water areas would be usefull (in the VERY long term).
That would also be more realistic regarding water textures as sea looks quite different from lakes or rivers.
And - seas rarely freeze over (apart from Polar regions, ofcourse).

Regards,
Rob Roeterdink

[That Genset Foamer]

The other thing that would help is a shoreline hit detection for a larger body of water, and user-defined wave heights. How a more substantial wave (such as the 10-foot breakers we get in San Clemente every so often) would be simulated, I don't know, but it could be done through a translucent shape with 2-faced polys and a "cresting" / "breaking" animation as it gets closer to shore. Maybe when ORTS implements texture animations this might be feasible...

With regards to non-tidal water bodies - couldn't a set of static shapes be installed with a distinct flow to them via an animation (i.e. moving polygons spawning "in and out of existence") to avoid using the MSTS watertable? Of course, now that I suggested that I'm gonna have to give it a try in TSM, and test-fit it on the CFNR or Salinas Valley.

[Genma Saotome]

roeter, on 14 January 2014 - 09:52 AM, said:

Clearly that method only works if you have just coastal waters.
If you have a route with both coastal and inland waters it's going to flood all your valleys and lakeside areas as well.

In my case that's exactly what I wanted as the inland rivers are flooded in winter from all of the rain (California has a Mediterranean climate so think of Italy in winter)... and so it all worked out very well.

Quote

If possible, a distinction between tidal and non-tidal water areas would be usefull (in the VERY long term).
That would also be more realistic regarding water textures as sea looks quite different from lakes or rivers.
And - seas rarely freeze over (apart from Polar regions, ofcourse).

No need to wait so long... if you would review the data in the file suggestion I made above you'd see it would be possible to insert either absolute or relative offset height values on a patch by patch basis which, along with patch specific water textures, would do everything you just mentioned. Near term it still depends on RE to set the base water level on a tile by tile basis as well as the route default water textures with the new file doing only the exceptions. And editing the new file is done w/ an ordinary text editor. I don't think it would be all that hard to do.