| Sun Feb 2 16:41:40 2014 by silent hunter |
| Do you plan to develop generation rivers? |
| Mon Feb 3 17:34:00 2014 by Torben |
| I would love to add rivers, but I can see no way to add rivers without changing the basic premise that you can generate zoomable local maps: You would not be able to know where rivers would enter the local map from the outside. It would be easy enough if rivers should not follow the laws of nature (water flowing downwards etc.), but making them fit the landscape needs detailed non-local information. |
| Tue Aug 18 21:44:59 2015 by Ron Vantreese |
| Hi Torben, for your inspiration... https://andreacasalotti.files.wordpress.com/2013/03/tumblr-fractal-in-egypt.jpg Perhaps a fractal formula can help you stabilize a river pattern. |
| Wed Aug 19 11:54:27 2015 by Torben |
| I can easily enough generate a river network on its own. It is making it follow the contours of the landscape that's challenging. I don't want rivers to flow uphill. |
| Wed Aug 19 18:29:09 2015 by Ron Vantreese |
| Then how about 2 layers.... First layer decides if you "wish" to put river data on a pixel... 2ns layer determines if it can have a river at that pixel.... And therefore it flows with the fractal landscape. *just thinking...* |
| Thu Aug 20 09:14:53 2015 by Torben |
| It is not quite that simple. The planet generation is not pixel-based but based on 3D coordinates on a continuous sphere surface. |
| Fri Mar 11 16:52:11 2016 by Mark |
| Re rivers not flowing up hill... There's no reason that they *have* to flow upwards, they could have easily just cut out a cavern, gully that simply *appears* to flow up hill when in fact it just cuts through. Would it be possible to see some kind of alpha-build with river pattern on? With a possible custom colour setting? (Rivers of lava :D). I don't necessarily mind if this is layered actually onto the world or is actually a separate layer based on the same seed (would actually be preferred). |
| Fri Mar 11 17:11:37 2016 by Torben |
| Rivers don't "cut through" hills. They make cut canyons, but that is through a flat surface, where the rivers initially flow in shallow beds and then gradually cut deeper. Placing a river network on top of an unrelated map will just look strange. I have made some experiments with forcing the landscape to follow a river, i.e., by mandating that a river should flow from one edge to the other and force the map generation to make this possible. That didn't go very well, but the general idea is probably the way to go, so I hope I can find a better way to achieve this. |
| Sun Mar 27 19:18:39 2016 by Mark |
| Assuming of course that they're flowing over the surface... they might be flowing through underground water ways. That is how I would interpret such a map. Perhaps, take the previous known lowest height then if the next iteration is higher then change the colour or pattern of the line? I have no idea how fractals work... and honestly, I'm just supremely grateful this works as well as it does. |
| Tue Mar 29 09:29:18 2016 by Torben |
| You can see a short description of how the planet-generation method works at http://www.diku.dk/~torbenm/Planet/PSIslides.pdf |
| Sun Jul 16 16:05:22 2017 by River lover |
| Please check it out. https://bl.ocks.org/Azgaar/b845ce22ea68090d43a4ecfb914f51bd |
| Tue Feb 26 14:46:47 2019 by Martin |
| Hi, Just checking two years later. Is this project still being developed? If yes, how does it look with river generation at the moment? |
| Wed Feb 27 10:07:00 2019 by Torben |
| I have a student working on rivers generation, initially for 2D maps, but possibly later extended to planet maps. He has just started, so there are no results yet. |
| Sun Jul 25 16:51:40 2021 by Avarus Lux |
| Hi, Just checking two years later. Is this project still being developed? If yes, how does it look with river generation at the moment? shameless copy of above message but seeing it is now 2021 it's valid on the river aspect. i suppose the student moved on since then, still curious if river generation is being worked on in some way or if it has been deemed unfeasible with the current state of the program. |
| Mon Aug 9 12:50:20 2021 by Torben |
| Rivers on zoomable 2D maps worked out fine, but extension to 3D (planets) did not work out. A completely different method is apparently needed, and I have no idea how to do this. |
| Mon Sep 6 22:40:23 2021 by Avarus Lux |
| bummer to hear that, perhaps a fun extra to add mentioned 2d river iteration as a additional option for the square map Mercator or alike map projections even if just as experimental feature for funky results. that said, if things didn't work out for the generator at all and as such it's not useable then so be it, hand drawn rivers and lakes work out fine too. maybe in the distant future you find a novel way to incorporate such a thing. thank you (and contributors) for trying and attempting to make it happen either way, you can say at least that much! :D |
| Tue Sep 7 10:37:22 2021 by Torben |
| The 2D river generation requires a very different map generator algorithm that only works in 2D (a variant of the diamond-square algorithm), so it won't just work on square projections etc. |
| Sun Sep 12 01:27:16 2021 by Avarus Lux |
| yeah, kind of expected an answer like that. thank you for trying though. |
| Tue Nov 16 21:58:45 2021 by Catahoula |
| Thank you for the insight. Right now I'm working on my own modifications to your program to add river and lake generation (and porting it to C++, but that is another story). I thought of one possible river generation algorithm that might work with your program. Right now, stl just thinking it up, so I have no idea if it will work or not. I was thinking of implementing that right after all the vertices are generated via your algorithm, but before they are adjusted for each projection. Am I understanding the code correctly? |
| Wed Nov 17 00:09:51 2021 by Mizuki |
| This is probably not possible because there's no way you haven't thought about this, but is there a reason why you couldn't pick one random point of fairly high elevation, and snake down lower and lower elevation, not going to pixels with higher elevation than the one right before it, till you reach the sea"? |
| Wed Nov 17 10:57:32 2021 by Torben |
| Adding rivers after the map is generated can work, but you need the entire map as you would not otherwise know where rivers enter a zoomed-in portion of the map. Since zooming is an essential feature of the planet generator, I hesitate doing that. The 2D method generates rivers during subdivision, so it is fully zoomable, but the method does not carry over to 3D (I have tried). |
| Sun Dec 5 15:20:57 2021 by Avarus Lux |
| > Since zooming is an essential feature of the planet generator, I hesitate doing that. as i understand from Catahoula and Mizuki, this process they describe would make rivers generate on the 2d result of the initial 3d map generation from your code, but the river generation happens before any projection or zoom modifier is applied, if that is the case then it sounds perfectly fine to implement as an in-between stage of the generation process. to me at least this sounds like it would not compromise any existing features i think. |
| Mon Dec 6 09:53:49 2021 by Torben |
| The problem is that when you make a large-scale map, you do not want to generate the fine level of details you find on zoomed maps, so if you apply your river generation to a full planet map, your zoom is limited to the details you generate there. Conversely, if you generate a zoomed map, you will need information about where rivers enter and exit the edges of the map. This can relatively be handled on 2D maps -- when you subdivide an edge, you just decide which of the two half-edges a river runs through, and when you generate new edges, you decide if these are crossed by rivers. But the edges of a map using the 3D method do not coincide with edges of the tetrahedra that are subdivided, so this does not work. |
| Sun Dec 12 22:30:49 2021 by Avarus Lux |
| hmmm, the issue from the sound of it seems the zooming in part and there not being a reference point for the out of view river-parts that may enter or exit the scene when zoomed in, not so much the actual generation in and of itself for a given seed its topology... for zoomed in maps you would indeed need more details which you don't want or need on the larger scale map which are more of a general overview and one would need references like you said for relevant out of view elements. so.... this is the last i'm going to say on this particular topic since i'm probably annoying people more then helping or anything and it is a feature that has already been looked into in detail thoroughly by others... i'm also probably understanding the program wrong or at least overestimating how flexible things are with existing generation algorithms in their current iteration. that said, as i see it a solution may perhaps be to "simply" (excuse my French, coding is anything but simple) brute forcing these rivers into existence at least code-wise using the seed of a world, with the river details then existing as splines complete with their offshoot branches and x,y,z position data floating around as reference before the map is actually drawn out further be it zoomed in or not. (the river detail a fidelity parameter here that could be a user definable setting as it is intensive computing). after computing all this generated river data while creating a map, which will take more resources such as CPU and RAM (or GPU and RAM perhaps), can then be used to display either a simplified tree variant (delete/merge the points closer and shorter then a set distance from main branch) of this complex data to generate the simplified basic river systems for the large scale map OR used in part as the required detailed reference information for the start, stop, entry and exit points of rivers on a zoomed in map. any spline not touching the viewable area can be erased after the area is defined. this should work in a 2d as well as a 3d environment though i am unfamiliar with how things are done in this program, if it would work with the current system and it is a lot of data to generate which also takes a lot of time too. when going with such splines this also likely does require the processing of a vector images in a way and we are working with bitmaps as the current image output and i doubt it's an option to have this program render and or process vector images as output as is. vector images would be nice to have though and could also solve any of the zooming in/out problem you are facing since zooming in/out within a vector image is very flexible without loss of visual details since it is always maths based unlike a bitmap which detail after creation is limited to the initial pixel count of a given image. A large scale map with its fully detailed rivers, oceans, seas, lakes and the height data computed as a vector image instead of bitmap allows one to zoom in on any area or reposition the zoomed view very easy without (much) loss of fidelity or complex commands. another benefit of vector may be that one can deform the created splines to fit a 3d sphere or 2d map alike using maths which may make vectors a interesting option to look into as well. outputting and converting existing image data as vector data does likely require a full rewrite of the rendering engine of this program and to me seems unlikely and i am also very unsure if brute forcing these complex tree systems of rivers in the current code would be possible either without this process causing crashes due to too much data being generated or too many issues with such an approach to make it viable. i hope my thoughts here made some sense and that it was of some help... if not, my apologies. thank you for this map tool either way, it has been useful quite a bit the past few years. |
| Mon Dec 13 10:39:10 2021 by Torben |
| If all you want is to generate rivers, that suggestion would work, but you would really like rivers to adapt to the landscape, so they don't run uphill and take logical paths from highlands to lowlands. It is the co-generation of altitudes and rivers that is difficult. |
| Fri Feb 18 21:14:24 2022 by Catahoula |
| Hi again! Just checking in on this once more. I haven't had a chance to make much progress with it in the intervening months, thanks to school and work, so I figure I would mention what I think might make rivers work. As Torben mentioned, I don't take into account any issues that may come from zooming in. I'm most concerned with trying to generate a full, realistic world. (This is why I've tended to generate very massive maps with very large scales during my usage of your program.) When a vertex is generated, it has a small chance of being marked as having water; the odds of a vertex being chosen increase with their elevation. Along with this, each vertex has a list of vertices that flow to it. After the generation process is complete, the program goes back and looks at each vertex with water, trying to find adjacent vertices with lower elevations. Any such vertices are then marked as having water, and the current vertex is added to their flow list. If we find an adjacent vertex that is below sea level or already marked as a water vertex, then we add the current vertex to its flow list but do not mark it. If the adjacent vertex is already in our flow list, then it is skipped. When all is said and done, we reduce ("erode") the elevation of each vertex that has water. This should allow for the creation of channels that simulate how water flows from higher to lower elevations. I'm not totally sure about how the rest of the implementation would work, how it could be simplified, or other such details. Like I said, I haven't been able to make much progress in attempting to implement it. I think that during the drawing process, we would draw water between a vertex and each vertex in its flow list. I hope this helps! If I get it implemented, I'll let you guys know. |
