what is done in Orbiter so that the specular reflection has some apparent "texture" to it, rather than a smooth spot
This would help from space, but up close- as in orbiter- it's still very flat. I'd suggest a procedural water texture for looking at it up close, but this would probably look kind of weird. Perhaps - until some fancier water rendering is implemented- there could be three layers:
1. From space: Orbiter style!
2. From very high up: A faint texture pattern that approximates the following:
3.Up close: a single, animated texture, repeating over and over again; and only one copy is stored in memory; even if the animation is just a few different seamlessly tiled textures, blending the first to the second, and then the second to the third, etc.
I don't think that an animated texture could be implemented without significant work. And if you're going to invest significant time and effort into the water then you should just do it all the way and make it truly fancy 3D water.
Orbiter style seems like the best way to improve it without involving many weeks or months of effort. It doesn't matter much if it's flat, as long as it's not smooth (meaning a smooth reflection). And keep in mind, some worlds will have flat or nearly flat seas, like Titan. A little texture gives the illusion of an active and varied surface well enough. Height is not always necessary. And animations can sometimes look worse than the original static presentation. All else being equal, keep it simple.
All forum users, please read this! My SE mods and addons Phenom II X6 1090T 3.2 GHz, 16 GB DDR3 RAM, GTX 970 3584 MB VRAM
Edited by HarbingerDawn - Tuesday, 26.02.2013, 04:37
Couldn't SE just add a tiled, perhaps animated, bump map?
To the water? For issues with animation, see my post above. As for the bump map, an ocean with swells that don't move looks even less real than a flat ocean, though it could possibly look ok if the layer rotated, but then the features would move at different rates at different latitudes and would look weird.
All forum users, please read this! My SE mods and addons Phenom II X6 1090T 3.2 GHz, 16 GB DDR3 RAM, GTX 970 3584 MB VRAM
Well, I don't know how difficult it would be for SE, but I know in max, animating a texture is simple. And I would disagree on flat being better than a nonmoving bump map. Sure it would look odd, but it does now, too.
would it be possible to generate clouds similar in quality as seen over Earth? speaking of Earth, I don't see well defined continents on any other earthlike worlds...
The problem is not the generation of continents, but the erision of coast lines. There are more well defined and eroded coast lines in earth than in Space Engine procedural planets. And sometimes, I find some landsapes made of small isles . I think these need to be more rare.
I wonder how easy it would be to implement a simple erosion proccess? It doesn't neccesarily have to be some kind of complex proccess, just use a fractial procedural thing and have it randomly erode n for x number of times (yes I know that is actually an oversimplication).
If anyone's seen the latest versions of Gogle earth with the atmosphere effects, the newer water surface actually looks really good. I think they are using an animated texture (with an animated specular map), except it's a higher resolution than it used to be. I know animated textures have been talked about a bit, and that it may take lots of work to implement them, but maybe Google's method could provide some more insight?
I was having a think about the pseudo rivers while being driven on a long journey. I thought of something that Space Engineer has probably thought of, for how to implement realistic rivers in what seems to me to be a reasonably straightforward way. I got out a notepad and jotted down some thoughts.
I used to do game development in college, but I wasn't cut out for the physics maths or intense data structures, but I got a good way into programming.
That said, it's been at least 4 years since I wrote any significant amount of code, so I'm beyond rusty, but I think I have retained a feel for how a system runs through code, and what ought to be possible, and relatively inexpensive to process.
I'm neither an expert in programming, nor computer logic, nor fluid dynamics, so I'm on shaky foundations, I concede that. Apologies if this is an idiotic approach. I'm posting it here because I couldn't find an exclusive "rivers" thread, and I'm not sure it deserves a thread of its own (though mods, feel free to move it to one).
The idea is roughly this (warning, long-winded):
When a terra or titan (or lava, or whatever) planet's surface is being generated, "springs" are procedurally dotted around the map. Springs have an "outflow rate", or similar variable, which affects the way the water behaves.
The "terrain" heightmap is duplicated as the "water" heightmap, both of which are altered as the process continues.
A sea-level is still set in the planet's script, but the current implementation, the water-sphere, is not used.
Starting at each "spring", the game compares the neighbouring pixels of the terrain heightmap with the current pixel. the lowest of the neighbouring pixels becomes a "water" pixel. If there are no lower pixels surrounding the "water" pixel, each of the surrounding pixels is "flooded", and each of those checked until a lower pixel is found, and the "river" can flow out of the "lake".
The "outflow rate" of the spring becomes the "water volume" (or a more suitable term) of the pixel of flowing water. This affects the chances of the pixel "flooding" neighbouring pixels that are lower than it, but not the lowest. Slope angle will inform this, so that rivers on a shallower slope spread out more, and stand greater chance of bifurcating. This should allow for river divisions, delta behaviour, and multiple out-flows from lakes with reasonably level banks. Each such bifurcation will take a chunk of the "water volume" for itself, and perhaps a "precipitation rate", attenuated for altitude could top it up as the river flows on.
For lakes "forming", some evaporation function, derived from the planet's atmospheric pressure and the altitude of the lake decides the fill-height of the lake, which is to say, the cut-off level if the hole it's filling is so deep as to not find a lower pixel before a certain depth.
The game passes a variable for the "lowest point" yet encountered by water from each "spring" from pixel to pixel as it checks.
Once the outflows occur, or the evaporation point is reached, the surface level of the lake is set to the height of the rim pixels. Note, I don't see lakes as requiring any special data structure, save perhaps a pixel flagged at the lowest point of the lake in order to propagate the surface height back to... not sure if that's necessary.
As basins fill, they may overflow and subsume other lakes filled by other springs. The "lowest point" variable is overwritten in those cases by the lowest value. They may also inundate existing "springs". These "springs" are deleted, and their "outflow rate" is added to the "water volume" of the water that passes over them.
Once all evaporation points are reached, the body of water with the lowest "lowest point" variable on the planet becomes the sea, and floods to sea-level, regardless of it's evaporation point.
This would allow for inland lakes and isolated seas to have a lower level than the ocean.
That's the general idea. I was thinking that the water surface could be written to the blue of an RGB file, the green would be water-carved bottom of the rivers and lakes (subtracted from the terrain heightmap by the "water-volume" of each pixel), and the red could be... I don't know - whatever else needs storing - energy, flow-rate, perhaps, for deciding on the speed of texture-scroll, based on slope angle.
Now, one potential flaw I can think of is how the LODs generate smaller and smaller detail, and that, what might have been a smooth slope at low detail, with a straight river course, suddenly becomes rugged at higher detail, affecting the course of the river, and even breaking it up. I have a half-formed thought in my head that the lower-res LOD could be blended into the higher-res one, somehow, with each progressive LOD, in such a way that would imitate the effect of epochal erosion by the changing course of the river over time... but that one needs more thought.
I'm sure that there are plenty of flaws, like that this would require so many iterations through the terrain generator as to grind the game to a halt... but I'm not sure whether that's the case or not.
Hopefully smarter brains than mine can take a look at this, and I'm really sorry if I'm wasting everyone's time.
Edited by Destructor1701 - Thursday, 06.02.2014, 14:43
I've got some basic knowledge on programmation, but also on numerical analysis and optipization, and the method you described is similar to some optimization algorithms : you take the derivative of the bump function (the normal map, or gradient), and you draw lines following the angle where the gradient is minimal, step by step.
The problem on your method is it is way too long to compute, as it is a flow simulation.
Space Engine doesn't use simulation to create the planet terrain, but it tries to emulate the results of such simulation with a simplified algorithm.
So, It will be useful to study your algorithm, and to find, under some simplifications, analytical and easily computable solutions, and implemnt them as function on the terrain generator.
Thanks for taking the time to read it - I figured it was probably a blunt-force approach that could be heavily optimised, if indeed it wasn't just the rantings of a mad man!
I understand that SE doesn't use simulation to generate the heightmap, but regardless of how it was made, it does output a heightmap bitmap into memory, doesn't it? Couldn't an optimised version of this process be run on the heightmap, in memory, prior to creation of the planet terrain mesh?
Sort of post-processing the heightmap.
Again, I'm really grateful that anyone has taken an interest in this. I kinda felt like I was down a rabbit hole.
Edited by Destructor1701 - Thursday, 06.02.2014, 15:54
I thinkit could be optimized. But I don't know if it can be optimized enough to avoid a performance drop on terrain generation using this method.
In my opinion, something which could be faster, is to draw the shape of the rivers before, and after creating the height map of the montains according to the river map.
ENG
New site
Pirate 
United States 
Canada 
Italy 
France 
Ireland 