[rdamurphy]

So, finally, took me a week, but I cracked a tough nut! Only two lines of code, and two slight changes to two others, and we have: Walaaa!

Tiled water textures!

Problem is, I don't know how many times to tile them per patch? This screenshot is tiled 2 x 2, but basically, it can be easily changed, and I did in fact look at MSTS, and um, yeah...

Does anyone know how many times MSTS tiled the water texture per terrain square?

I know the banks look funny, this is just a test route to try out different things, and I didn't take the time to actually make a lake or anything... Also, no water animation yet.

Robert

[Stephen Hjellum]

I believe MSTS tiles were 4x per square. I'm currently building a route in MSTS, but if this is possible through changing lines of code, we're one step closer to some form of editing before Version 1.0. This is amazing!

[eric from trainsim]

I have always assumed that tiling factor for water follows the same 16x16 matrix used for Terrtex.

That works out to 128m x 128m for every sub-tile and terrtex image.

[Genma Saotome]

Robert, any chance of stepping beyond a MSTS-like solution and going big? You know how the tile patches can have unique microtex (it's stored inside the tile file) but only if you have Mosaic as an editor? We can't really change the tile file itself to do something like that for water so how about creating a new file type that holds up to 64 "Watertex" files (per layer as defined by the *.env file) per tile? Use a text editor to maintain. I shouldn't be too difficult to figure out which patch in the 64 gets which watertex and and in many cases it will be just one watertex.ace file per layer anyway, but for those situations where there are multiple bodies of water, such as lake vs river, it could be a real godsend to getting the world looking as it should.

If the watertex files go into the existing tertex directory then we could also have \snow watertex... ponds and small lakes could be all frozen but larger bodies of moving water could show both water and ice.

FWI, IMO all the terrtex assignments should be outside of the tile data -- it's metedata after all -- so when we get our own editor the file that drives terrain could be just data, with the hope it can be pulled into other tools for viewing and/or CAD-GIS like editing.

[nicober]

In each Tiles for Terrtex or Water you have 16 X 16 sub-divisions for textures.
The water textures are defined in each ENV files and you have only 3 possibilities Water-top - Water-mid and Water-bot
You need also to activate the water textures in a sub-screen if you want to see it in each sub-division.

The water textures can be displayed in many ways - You have to change this line in your ENV. File.

For each textures - watertop - watermid and waterbot you have this line:
world_anim_shader_frame_uvtiles 8 8 )
These two numbers 8 in red are for the numbers of times the textures is displayed in each sub-division

Like this for the 8 X 8
http://imageshack.com/a/img842/9378/hqgp.jpg

If you change these numbers for 1
world_anim_shader_frame_uvtiles 1 1 )
You will have the texture displayed only one time in each sub-division

Like this for the 1 X 1
http://imageshack.com/a/img707/5042/doxc.jpg

You need to change these lines for every ENV files in MSTS and for Itinary Editor.
if you use a fraction like 0.5, only the half of the texture will be displayed in each sub-division.

In Open Rails the water top texture is displayed like this and I think OR doesn't use the ENV files options.:

http://imageshack.com/a/img18/1162/kbq7.jpg

I used a Checkermap texture to well see the difference and the effect in each situation in remplacement of a water texture.

Hope these informations can help.

[Genma Saotome]

nicober, on 11 January 2014 - 11:13 AM, said:

The water textures are defined in each ENV files and you have only 3 possibilities Water-top - Water-mid and Water-bot

Not correct. You can have as many layers as you want (using any file name you want)... all you have to do is edit the .env file and add or take away the water file sections, being sure to change any number up at the top to equal the number of layers you are using.

[nicober]

Hi Dave,

I forgot this possibility to change the number of layers for the water textures. I never see a route with more than 3 layers and don't understand if more than 3 layers would be very useful. But in theory you can have as many layers as you want.

Cheer!

[rdamurphy]

On the microtex, since we already have it in the ground tiles, it shouldn't be hard to implement it in the water tiles, however, MSTS is set up to use the same water texture(s) for the entire route, so, we could start there. Dave, do you have a water microtex we could use?

I think using different textures for different patches would be a great idea, but definitely a post-1.0 OR RE type of addition.

Nicober, your information on the water tiling for MSTS is invaluable! We actually do read the water texture files out of the .env files now, so all I'll need to do is read the tile information as well, and simply add it to the code. Apparently, the default is 8x8 for each 1024 meter water tile, which makes sense, since the .ace file is 256 pixels. I'm not sure why it would be tiled differently, such as 2x8, but no matter, there's no reason not to do it the same way...

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.

Having said that, if you build a terrain lake, and say make the water layers very light at the top, and then the second one darker, and move the terrain below it, and then one even darker, and move the terrain below that layer, you'd be able to see the depth of the water at the slope of the lake bottom moving away from the shore. Here's a rather crude example that accidentally happened... Think about using, say 10 layers, what a subtle effect could be accomplished! The lighter color has terrain above the .05 meter level, and the darker is below the 1 meter level. Adding a few more layers would give you more of the color changes related to depth.



So, also, we're creating a completely flat plane using 256 vertices for absolutely no reason whatsoever, and then stretching a perfectly flat water texture across it. I want to change that to creating a 4 vertices rectangle, so we can use the CPU cycles for something else, perhaps an animation, or a really cool looking wave effect I found using a bumpmap. Of course, like MSTS, it would be one directional. For now. Of course, if we implemented Dave's idea of storing the data in a file for the textures in the future, it wouldn't be difficult to specify the direction of the water flow in the same files...

Robert

[Genma Saotome]

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

Dave, do you have a water microtex we could use?

Noooooo and if you want me to make one I'll offer all my fingernails to be let off the rack I'm mean hook. :thumbup3:

WRT the Watertex idea... a very rough example as food for thought:

Watertex (
	Tile ( 
		TileId (value )								# (only those tiles so affected by tile-specifc watertex; default remains in *.env.)
		AllPatches	(							# (Exclusive with ByPatch)
			Layers ( 
				NumLayersDefined ( int )			# (not sure this is needed )
				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 goes here.)
			)
		# ( any other data useful to defining the water across the whole tile goes here.)
		)
		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.)
				)
			# ( any other data useful to defining the water across the whole patch goes here.)
			)
		)
	)
	# repeat for other tiles as needed )
)

The idea here is only some tiles might be in need of alternative water textures and so assume the *.env file retains the job of being global to the route. That should mean this file, if used, might have only a few definitions. The new file could be called { routename }.water and go in the routes home folder.

Similarly, it assumes that some of those tiles getting alternative watertex files need only one set of watertex files for the whole tile while others might need several sets. With that in mind the specification starts by identifying the tile and then using the exclusive choice between a spec for AllPatches vs. ByPatch to document each of the watertex files for each layer of water.

What I didn't include (because I havn't thought it thru yet) is how to specify any offset to the four corner water height values -- by patch or by layer per patch, nor has any thought been given to specifying alternative shaders or texture tiling factors. I would expect that to fall out fairly easily tho.

As for movement of water... I'm inclined to recommend holding off on that until OR jumps up to a newer version of DirectX.

[rdamurphy]

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