News:

SimuTranslator
Make Simutrans speak your language.

Rivers development

Started by Fabio, January 19, 2009, 06:49:21 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

emaxectranspoorte

#35
Quote from: emaxectranspoorte on January 19, 2009, 06:18:14 PM
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. :) :o
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

Quote from: jamespetts on January 20, 2009, 07:12:47 PM
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

Quote from: gerw on January 21, 2009, 08:44:07 AM
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

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.
Parsley, sage, rosemary, and maggikraut.

Spike

Quote from: Dwachs on January 21, 2009, 12:15:00 PM
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?

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

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.
Parsley, sage, rosemary, and maggikraut.

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

Quote from: Dwachs on January 21, 2009, 01:55:21 PM
@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...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

gerw

Rivers are coming ;)

[attachment deleted by admin]

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

emaxectranspoorte

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

The Hood

Quote from: gerw on January 23, 2009, 07:37:37 PM
Rivers are coming ;)

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

gerw

Quote from: The Hood on January 24, 2009, 10:26:49 AM
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

Quote from: gerw on January 24, 2009, 07:57:47 PM
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

gerw

Quote from: jamespetts on January 24, 2009, 08:19:10 PM
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!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

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?

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

jamespetts

#58
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:


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


The second line produces the errors:


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):


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



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



//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:


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


And all instances thus (and similar):


//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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

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

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Fabio

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

VS

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

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

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).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

gerw

Quote from: jamespetts on January 24, 2009, 11:00:13 PM
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.

QuoteUnfortunately, 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.

QuoteAlso, 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

#64
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!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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:
ANode* nodes = new ANode[MAX_NODES];
for creating the ANode array?

jamespetts

Gerw,

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



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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

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.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

gerw

Try this, evil tester ;)

jamespetts

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


riverbuilder.baue();
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.