No, I'm not sure how the inverse of the heightmap would be used to identify rivers, was just responding to the need to invert the values but wasn't sure how you needed to implement.
I don't know what the best or mathematical solution is to identify rivers (delauney triangulation may be involved though?), there may be some papers on it somewhere?
I had this in mind for how I would do it jankily:
And to be clear 'agents' makes it sound fancier than it is. In janky pseudo-code I'm imagining:
cutoff = texture_width/2 # seems sane but less/more may be necessary
drop_paths = []
accuracy_mod = 0.2 #speed/accuracy trade off. Below a certain point your not gonna get any rivers
simulation_range = texture_width * texture_height * accuracymod
For i in range(simulation_range ):
iterations = 0
pixel = random pixel #with a heightmap value above say 0.8 (start at tops of mountains)
while iterations < cutoff:
pixel = min(nearest pixel (eg. indices like
-1, 0, +1
-1, SKIP, +1
-1, 0, +1)
drop_paths [i].append[pixels index]
iterations+=1
This should give you an array of rain drop paths, which you then would need to iterate and check for where paths overlap.
This is I think obviously computationally expensive and I doubt it's the 'best' way, but if it's for say procedural level generation and only needs to be run once or in background threads at a chunked scale, I think it would be practical even on a modest CPU. SebLague mentions he does 70k CPU iterations on a 255*255 heightmap in 0.75s (which would be accuracy_mod = ~1.1, way higher than what we would likely need to identify rivers)
Though as mentioned a Compute shader could simulate something similar in a fraction of the time.
This totally sounds like fun so I might try and hash something up myself just to see how well this method does/doesn't work, but won't be any time soon (work -.-)
