Would like to know @INovaeFlavien s view on this one. Have these people solved the impossible procedural rivers problem or is this something that couldn’t be applied into something like Infinity?
it’s never really been impossible, just if you try your rivers will likely be unrealistic and not always flow in the correct direction… if you look at that video closely, well at least i notice some rivers that go up in both directions.
It looks nice, but nothing says it’s being rendered in real time. It’s not on a planetary scale ( in the video you can clearly see the limits of the horizon ).
The paper is about terrain generation, nothing to do with rendering.
The main problem is that the terrain is generated through an algorithm that needs to know about all the terrain, and not just as a function of a given planetary position.
That XNA Planet Renderer with the ship flying around looks a lot like the Infinity 2010 Tech Demo (although much less refined). It even has similar looking wedding cake mountains.
It surely must be possible to have realistic procedural rivers on a procedural planet, yes the water flow is dependent on the actual height data instead of just some position seed, but there must be ways around this. Splitting/generating terrain to the lowest/acceptable level around the river, so that you can generate river data comes to mind…
Yes, it does look a lot like Infinity @LucasFIN, he might be using a similar algorithm for the height data that INS is using.
Found a fun game/project over at RockPaperShotgun
Innovative visual effects
Featuring procedural real time exploding/slicing/collapsing of buildings, and an Universe-scale rendering engine.
What engine is he using? Space Engine?
Another Interesting scene from that trailer:
Found a video with not so seamless planetary transition, though other interesting things:
So… Play as Super Man against Martians?
And take out a building full of people if you miss with your lazer beam Sounds fun to me. And surely something to do with such an engine. Fly arround blow shit up
I think it would be pretty revolutionary to create hydrologically (semi)-accurate river structures in a single-pass of procedural terrain generator - and IA, please correct me if I’m wrong, but the Inovae Engine’s terrain heights are generated in a single pass (are you still doing lateral vertex displacement? If so, perhaps that counts as a second pass).
If you’re willing to make several generation passes over the data, however I can see it being very feasible to develop an algorithm which only depends upon local data (i.e. only on neighboring patches) to approximate flow basins. I bet to make it really good, however, you’d need to do multiple iterations upon that, which is where the real performance hit comes from. Not sure though, I haven’t studied the existing techniques.
*Offtopic - @InfinityAdmin (hah, nope… but I’m leaving that for old times’ sake) - @INovaeFlavien I’m curious, when computing dx and dy for your terrain normals, are you using a differentiable noise function, or do you use a second pass and measure finite differences?
I don’t see how you’d generate rivers based only on neighboring patches. Depending on the camera distance, the neighboring patches could be 100 km x 100 km, or 50 m x 50 m. You don’t work at a constant resolution / area size. What you need is a procedural function R = f ( x, y, z ) where R is the altitude of the generated terrain and xyz the coordinates in planet space. And that function R must generate a heightmap with rivers, erosion, or any cool feature you’d want. But by definition, such a function is only a function of a single planet coordinate, so it doesn’t have any knowledge about altitudes in neighboring areas.
Of course you could call a bunch of f ( x + dx, y + dy, z + dz ) and do something with it, but to get decent terrain features you’d need to call it thousands of times, which would be too slow. So I don’t see any good solution to this problem. And the fact that nobody has published any algorithm to do it, makes me think it’s a non-trivial problem…
I agree with you that this is probably impossible using a simple height function - the ‘single-pass generation’ terminology I used above.
What I had in mind for a multi-pass algorithm would be to compute the gradient of a tile at a fairly low level of detail (so this wouldn’t work for tiny streams, mainly just large rivers), then perturb the terrain based upon that. Even then, coming up with a decent river approximation using a ‘single-pass’ WITH this gradient information would be tough, as you’re having to predict water accumulation / downstream effects. Again, not familiar with the existing techniques, but I’d imagine a large number of iterations are used to ‘erode’ the terrain, and the gradient is re-calculated after each erosion step.
Definitely not a trivial problem!
Something that I’d like to see attempted is to tackle surface hydrology in reverse. It is impractical to derive surface hydrology from terrain in real time, so derive the terrain from the surface hydrology. Find a function that can spit out a convincing surface hydrology structure, then go back and fit terrain to it. The process of fitting terrain to hydrology should be much more data-local than trying to go the other way around.
Here’s an image that somebody assembled based on a fractal.
The challenge would be to find a good f(x,y) or f(x,y,z) for surface hydrology.
I vaguely remember asking why this didn’t work on the old forums - because if it did work, someone would have done it, right? But the answer probably went over my head, as I absolutely don’t remember it
Wow, great idea. Part of me wants to drop everything and try that out now
How about doing both?
It’s impractical to derive surface hydrology from terrain in real time on a single consumer-grade computer, especially while running a game at the same time, but with a large enough server farm dedicated to the task I imagine it’d be possible to do in a small enough timeframe that gameplay mechanics could be tweaked accordingly.
Reduce the accuracy of the data to where it can be compressed and sent over the minimum expected internet connection to play the game, then apply reverse function there (with procedurally added local detail).
It wouldn’t be perfect, every so many planets you’d probably see Lake Victoria sized bodies of water popping in (or large rivers apparently being soaked up by the ground), and of course servers aren’t free - but they are dirt cheap, comparatively speaking. Oh yeah, and it’d give rivers that looked like they, for the most part, followed gravity rather than the other way around.
Note that the dedicated server-farm and heavy bandwidth use is only necessary for games with arbitrarily large numbers of planets; I:B could probably be shipped with the high level hydrology data, calculated over many weeks on a spare laptop, included for each planet.
This is a bit mind bending, coded in Java…
Here’s his updated version with some added features, like plants and some rudimentary clouds:
Although the atmosphere looks less smooth now…
Just noticed the caption, “A question remains, where should this project go?”, looks like he moved on to different things, also, very interesting that something like this can be done in Java, it’s not really a language you would associate with real-time planet rendering.
Actually, all the stuff I’ve produced has been in Java, using LWJGL. It’s surprisingly fast.
I sometimes wonder if it’s necessary to use C++ these days…