Rivers development

[emaxectranspoorte]

Yes, that's correct. Exactly what I was thinking about, as well. We can even have a graphical moving water based objects, to make it even better, IMHO. And add new industries at the bottom of the river flow (say near a city and/or near sea and/or city level), using that river as an irrigation resource (for irrigating farms, adding, maybe, a destination for the bottling industries, etc...) and somewhere during the rivers running we could add (and/or also a source for the bottling industries) a resting place (for example a national park), only with boat transportation to make it more peacefull and somewhere for simutranians to enjoy a wonderfull time with their families. Oh ... you mean the river flowing like trucks moving or people walking, right? :-\ Yes, I have found out about that, as well.
Yes, you're right AP, you aren't the only one Maybe gondolas would be another one, IMHO. :-\

Looking at the magnificent and cool work of all that you veterans, here, have done, I realize we beginners, like me, have to work a long way.

So, in spite of this, may I come up with some not so professional ideas... : :-\

1. We can use lakes, rivers, and especially streams, as natural boundaries to reduce unnecessary population growth (selected appropriately either at the start of the game and/or by a player), besides using fences, signs and the like.
2. We can also start increasing the infrastructure of the game with more additions like water pipes (similar to the waste recycling add-ons and incineration in the game), water recycling and desalination plants to further improve and diversify the current water industry (might become very useful for desert type climates, IMHO). These sort of work, in real life, implies the cost of employment and maintenance of, the number of  people, stated before that must be taken into account (similar to like employing people to maintain and improve traffic and/or train signals (with the appropriate incentives for players) for example, IMHO).

[gerw]

Very impressive! Now, if only Simutrans could be made to do that automatically, there would be a great many very happy Simutransians :-)

I think at least for random maps this is possible. You can calculate the gradient at every point and the 'route' of the river can be estimated by an ODE.

[jamespetts]

I think at least for random maps this is possible. You can calculate the gradient at every point and the 'route' of the river can be estimated by an ODE.

Ahh, I'd love to see that implemented.

[VS]

Gradient is not so easy, as I already found out during work on the rain. Easy, yes, but easy and fast? In the end I settled for gradient module in a given direction, which is easy. Calculating gradient that takes into account all surrounding terrain of any shape is far slower.

Remember that Simutrans terrain is heavily quantized in z-axis. That is the first and foremost obstacle, a kind of data that yields very little about tiles more than one index apart. Try as you might, any gradient will end in zero for most of the space, except for small "bursts" around the edges. Thus I had to smooth terrain height data before finding the gradient itself. And given the usual distances, it is a HUGE gaussian that I had to use - 30x30.

Of course you could laugh at gradient-only operators and go for something that does the smoothing for you, too, in one go, but the amount of calculations will not go down.

What is the notion of gradient here, anyway? Maybe a real gradient is not needed; could direction "to next tile downwards" be enough? Then the task is just sorting. Or maybe which neighbouring tiles are lower; then you simply store that information as 8 bits and choose at random. If this data was used only for rivers, you could simply say that the river's inertial force takes it roughly in the same direction and thus it would overcome areas where this pseudo-gradient is none. Maybe. Such method might easily degrade to prominently changing river's direction only on slopes, though...

[Dwachs]

I think 'gradient' here refers to the fact, that the surface is determined by a smooth(?) function, which is then made discrete. Thus it could be possible to compute the gradient of the smooth surface in the center of a tile. This gradient can then be made discrete again, since it only needs to point at the neighboring tile, which is lower, and which will be the next tile for the river.

See simtools.cc for the functions using perlin noise to generate the landscape.

Computational cost is another issue then.

Edit: I see your point. My remarks are valid only for the map generation phase, where the map is not influenced by player actions yet. For the creation of rivers after some time of play, your considerations come into play.

[Spike]

Edit: I see your point. My remarks are valid only for the map generation phase, where the map is not influenced by player actions yet. For the creation of rivers after some time of play, your considerations come into play.

Rivers must "fix" the landscape height like buildings do, otherwise we face some very tricky coding questions.

[VS]

Dwachs: True... but what about heightmaps?

[Dwachs]

@VS: then your smoothing approach is needed.

@hajo: I meant, the information from the map-generation process became invalid after playing some time on a map, that is, if the player will manually insert a river.

[Roads]

One approach could be what Dwachs hinted at.  Present the player with pre-made maps like you do now but give him some additional tools to add lakes, streams and rivers.  It seems to me all you would need are the terrain tools you have now and then some shore tiles and water tiles.

After all, this is almost exactly what SC4 does.

It probably would not allow for the rivers to look like they are flowing or have waterfalls but it certainly should solve to problem of determining a direction and width that looks realistic.  Also it would provide a basis for further development and ideas. 

[Spike]

@hajo: I meant, the information from the map-generation process became invalid after playing some time on a map, that is, if the player will manually insert a river.

I think it's good enough if there are rivers initially. It doesn't need to be a function that can be triggered any time.

[VS]

There is now a feature-complete editor mode, accessible from public player. I guess it might be needed then...

[gerw]

Rivers are coming

[attachment deleted by admin]

[jamespetts]

Rivers are coming

This looks very promising!

[emaxectranspoorte]

It really looks like a good start to improving the rivers issue... IMHO.

[The Hood]

Rivers are coming

Was this generated at the start of the map?  If so this is an exciting development...

[gerw]

Was this generated at the start of the map?  If so this is an exciting development...

Yes, it was. But I fixed (hardcoded) the starting point and the end point. Next step are alternating starting / end points.

[jamespetts]

Yes, it was. But I fixed (hardcoded) the starting point and the end point. Next step are alternating starting / end points.

That is indeed a good start :-) I wonder whether you could make the propensity for a river to have a source compatible with VS's pending weather system? That would be rather excellent. The end point should be a lot easier: any randomly selected bit of coastline should suffice.

[gerw]

I wonder whether you could make the propensity for a river to have a source compatible with VS's pending weather system? That would be rather excellent.

I think this can be done easily by adopting the probabilities.

[jamespetts]

This looks very promising indeed :-) Bridges will *really* be useful now!

[gerw]

Currently, you can just remove a tile of the river It's a canal build by the public player, but everyone can erase it...

[VS]

What I am planning - if I ever get to it - is that every tile gets a number describing its "water amount". For the climate purposes it is sorted into three categories, but it could be used directly when adding rivers. Anyway, I don't know how long will it take me to finish this, so...

[gerw]

Here comes a first - indeed very beta - patch for rivers. It will creates at most one river when creating a map, but sometimes it fails anyhow. It is very slow and sometimes the river isn't connected everywhere.

Feel free to test

[VS]

So... you find peaks and from them run to random water tile?

[jamespetts]

Hmm, your code doesn't compile because the part in simmain.cc has problems with arrays that aren't dynamic being treated as if they were in places such as:

Code Select Expand


uint16 river_len = tmp->count+1;
koord river_route[river_len];

The second line produces the errors:

Code Select Expand


error C2057: expected constant expression
error C2466: cannot allocate an array of constant size 0
error C2133: 'river_route' : unknown size


Edit: Have fixed it by changing the following lines (old lines are commented out):

Code Select Expand


//uint32 MAX_NODES = 200000;
const uint32 MAX_NODES = 200000;
ANode nodes[MAX_NODES];


Code Select Expand


uint16 river_len = tmp->count+1;
//koord river_route[river_len];
vector_tpl<koord> river_route(river_len);


Code Select Expand


//sint8 river_hgt[river_len];
vector_tpl<sint8> river_hgt(river_len);
river_hgt[0] = lookup_hgt(river_route[0]);


Edit 2: Unfortunately, the first change produces a stack overflow: an array of 2,000 ANode type is evidently too much for my CPU! I am trying to make it work with a vector, but get out of bounds errors at present...

Edit 3: I have finally managed to get it working by converting all instances thus:

Code Select Expand


//ANode* tmp = &nodes[step];
ANode* tmp = new ANode;

And all instances thus (and similar):

Code Select Expand


//river_hgt[0] = lookup_hgt(river_route[0]);
river_hgt.insert_at(0, lookup_hgt(river_route[0]));


At present, I only get a large, sea-level river hewn out of the landscape: no canal-based shallower rivers. Is that intentional? Also, no matter how many rivers that I set it to create (by changing the number in the argument "create_rivers(uint8 number)" to 5), it creates only one.

Edit 4: I have managed to get it to create the correct number of rivers using a for loop in the rivers creation method, although that slows map initialisation a little. Still cannot get shallow rivers to work.

[jamespetts]

Some screenshots from the rivers patch as currently released (and as I have fixed it):

[Fabio]

WOW, this is EXTREMELY promising... i really like it!!! thank you all!

[VS]

Errr... these steep valleys are a "fix" ?

[jamespetts]

No, the steep valleys are not a fix that I have applied - they were part of how the patch worked. All that I did was fix the compile-time and run-time errors that made it not work at all: I didn't change the behaviour, except in relation to the number of rivers created. I think that the idea is to use canals as rivers at the higher altitudes, but that does not seem to be working in this version of the patch (see my previous post).

[gerw]

Hmm, your code doesn't compile because the part in simmain.cc has problems with arrays that aren't dynamic being treated as if they were in places such as:

Ok. I set MAXNODES and river_len to const.

Unfortunately, the first change produces a stack overflow: an array of 2,000 ANode type is evidently too much for my CPU!

Mmh. This are only 22*200,000 bytes = 4,2 megabyte.

Also, no matter how many rivers that I set it to create (by changing the number in the argument "create_rivers(uint8 number)" to 5), it creates only one.

This is the intended behaviour


The flat rivers are caused by your changes.

[jamespetts]

Gerw,

hmm, that's extremely odd. The patch that you uploaded did not have those values set to const, so I had to change them (and did indeed get a stack overflow). I managed to modify the river creation system to produce the number of rivers desired (with a simple for loop), but I'm not sure why my alterations have caused the rivers to go flat: as stated, the original version caused a stack overflow. Remember, 4.2Megabytes on the stack is a huge amount - most CPUs only have a cache memory of 512Kb!

Do you think that you could make a version that does not cause a stack overflow on computers that do not have CPUs with 4.2Mb of cache...?

Edit: Incidentally, I could only change one of them to const (even with the stack overflow): the other required me to use a vector, since the array size was set by a variable!

[gerw]

I mean, I changed the values to const in my current source code. And I think, the 4,2 megs aren't in the processors cache. Can you test the appended version?

Edit:
If it doesn't work, can you test:

Code Select Expand

ANode* nodes = new ANode[MAX_NODES];
for creating the ANode array?

[jamespetts]

Gerw,

I've tested it: it still produces 6 compile errors:

Code Select Expand



1>.\simworld.cc(1066) : error C2057: expected constant expression
1>.\simworld.cc(1066) : error C2466: cannot allocate an array of constant size 0
1>.\simworld.cc(1066) : error C2133: 'river_route' : unknown size
1>.\simworld.cc(1075) : error C2057: expected constant expression
1>.\simworld.cc(1075) : error C2466: cannot allocate an array of constant size 0
1>.\simworld.cc(1075) : error C2133: 'river_hgt' : unknown size


The line numbers may differ from yours because my code is modified.

[VS]

Hardware stack on x86 is 64 kB if I am not totally out. Windows default stack is 1024 kB and maximal 32768 kB. I had this problem with Shades, too. Large data tasks can not be done with simple recursion, it seems.

[gerw]

Try this, evil tester

[jamespetts]

It compiles, but now I get an access violation at this line:

Code Select Expand


riverbuilder.baue();