|
3D water and clouds
|
|
| Voekoevaka | Date: Thursday, 06.02.2014, 15:33 | Message # 46 |
 World Builder
Group: SE team
France
Messages: 1016
Status: Offline
| 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.
Want some music of mine ? Please go here !
|
| |
| |
| Destructor1701 | Date: Thursday, 06.02.2014, 15:50 | Message # 47 |
|
Pioneer
Group: Users
Ireland
Messages: 533
Status: Offline
| 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 |
| |
| |
| Voekoevaka | Date: Thursday, 06.02.2014, 15:53 | Message # 48 |
|
World Builder
Group: SE team
France
Messages: 1016
Status: Offline
| 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.
Want some music of mine ? Please go here !
|
| |
| |
| Destructor1701 | Date: Thursday, 06.02.2014, 15:58 | Message # 49 |
|
Pioneer
Group: Users
Ireland
Messages: 533
Status: Offline
| Oh yeah - like procedural lightning drawing programs.
It could be a similar amount of work for the system, ensuring that the landscape doesn't form in illogical ways around it - rivers becoming unnatural viaducts, for example.
I think that, whatever way it's done, naturalistic rivers are going to add to the overhead... and post-processing of the height map is in Space Engine's future, regardless, since Space Engineer intends to add things like dynamic craters in future versions.
|
| |
| |
| JCandeias | Date: Thursday, 06.02.2014, 16:37 | Message # 50 |
 Pioneer
Group: Translators
Portugal
Messages: 387
Status: Offline
| Quote Voekoevaka (  ) 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.
There's another blunt force approach, which is more or less what has been done with pseudo-rivers: to dig precipices or valleys whenever local heights are found. Vladimir wrote that pseodorivers aren't generated in higher areas, so he does have a way to check at least large scale height conditions. He could define large scale, coarse river flows by that large scale height map, and then divide the planet into sectors and dig valleys to local minima, thus avoiding the creation of a succesion of lakes, or at least forming them only if the next local minimum is higher. Major differences in local minima would result in waterfalls, and this would go on until the river met a pseudoriver (to avoid having it flow into a closed crater or something.
This would inevitably tax planet generation, but it's something that can be done in steps, following the general generation and stopping at the adecuate level of detail.
They let me use this!
|
| |
| |
| Destructor1701 | Date: Thursday, 06.02.2014, 23:51 | Message # 51 |
|
Pioneer
Group: Users
Ireland
Messages: 533
Status: Offline
| I think Voekoevaka's idea was more nuanced than the pseudo-rivers as they are currently implemented - I presume (s)he meant that there would be height mapping, and that the heightmap generation algorithm would work forward from the river height map to map out a sensible terrain context for them.
|
| |
| |
| SpaceEngineer | Date: Friday, 07.02.2014, 10:47 | Message # 52 |
 Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
| Quote Destructor1701 ( ) 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".
You talking oа something that can be easily implemented on CPU. But on GPU you can't take a pixel, compare with another pixel, write a pixel. Unless you using CUDA or OpenCL. Also, it sounds very simple - "place springs here and there", but on GPU it is almost impossible. GPU is not designed for higly branched code, for recursion, etc. Without additional precomputated textures, it is impossible to detect direction and distance to the sea shore, only height above sea level and its gradient.
Quote Voekoevaka ( ) 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.
Yes, this can be easy done on CPU, but ot on GPU.
Quote Destructor1701 ( ) Couldn't an optimised version of this process be run on the heightmap, in memory, prior to creation of the planet terrain mesh?
Only if each terrain texture being downloaded to CPU memory, processed, and then uploaded back to GPU. This will increase generation time a lot.
|
| |
| |
| SHW | Date: Friday, 07.02.2014, 11:10 | Message # 53 |
 Astronaut
Group: SE team
Pirate
Messages: 76
Status: Offline
| Probably, it is possible to create hybrid terrain generator. Main height and textures make on GPU, rivers on CPU. Actually, for rivers we don't need to know the whole terrain, we just need height on river's path. So, it is possible to regenerate it on CPU with any suitable resolution without looking up into GPU generated height map. I think, it is possible to reuse existing terrain generation code to use it directly for C++. And, finally, we can use generated vector river to update textures on GPU. Or even to render them as separate layer. Yes, it is more complicated, but, I think, possible. Also, it solves problem with terrain lods, but does not solve problem with rivers lods.
Your mind is software. Program it.
Your body is a shell. Change it.
Death is a disease. Cure it.
|
| |
| |
| Destructor1701 | Date: Friday, 07.02.2014, 20:09 | Message # 54 |
|
Pioneer
Group: Users
Ireland
Messages: 533
Status: Offline
| Ah, I wasn't aware of the peculiarities of coding for GPUs. The games course I was on was ~10 years ago now (HOLY SNOT!), and since the course was new, its structure and syllabus were still being designed around us, with lecturers not at all familiar with games or gaming hardware... it was frustrating, as you might imagine... so if they ever dealt with GPU coding, it must have been at a point after I dropped out.
Interesting to learn that there is such a vast difference. Is there a simple way to explain it? I don't want to waste your time.
EDIT: Actually,
Quote Without additional precomputated textures, it is impossible to detect direction and distance to the sea shore, only height above sea level and its gradient.
Isn't gradient all I was trying to find out with my pixel-checking? And height above sea-level is useful for the precipitation top-up thing... still, I get what you're saying - a GPU iterates through its code differently, making post-processing like this difficult. I still don't understand the difference, but I get what you're saying.
Thanks for reading it, though!
Edited by Destructor1701 - Saturday, 08.02.2014, 03:18 |
| |
| |
| SHW | Date: Monday, 10.02.2014, 07:46 | Message # 55 |
|
Astronaut
Group: SE team
Pirate
Messages: 76
Status: Offline
| In short, CPU can run huge and complex code with circles, branches and so on, but in few threads, because modern CPUs have several cores.
GPU can run short and simple code usually without branches ('if'-s and switches) and fixed circles (no 'while'-s only 'for'-s), but in hundreds or even thousands threads, because modern GPUs have very many cores.
So, you cannot run long while loop to simulate one spring on GPU. But you can run hundreds springs for about several hundreds steps in one go, and then run them again and again by running full algorithm from previous step. So, it is possible to adopt your algorithm to high-parallel GPU, but it is quite complicated task.
Your mind is software. Program it.
Your body is a shell. Change it.
Death is a disease. Cure it.
|
| |
| |
| SpaceEngineer | Date: Monday, 10.02.2014, 14:59 | Message # 56 |
|
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
|
|
| |
| |
| JCandeias | Date: Monday, 10.02.2014, 15:19 | Message # 57 |
|
Pioneer
Group: Translators
Portugal
Messages: 387
Status: Offline
| LOL!
They let me use this!
|
| |
| |
| Destructor1701 | Date: Tuesday, 11.02.2014, 16:58 | Message # 58 |
|
Pioneer
Group: Users
Ireland
Messages: 533
Status: Offline
| I'm not seeing anything in Space Engineer's post - just emptiness. Did I miss the funny?
|
| |
| |
| HarbingerDawn | Date: Tuesday, 11.02.2014, 17:03 | Message # 59 |
 Cosmic Curator
Group: Administrators
United States
Messages: 8717
Status: Offline
| Quote Destructor1701 ( ) Did I miss the funny?
Yes, there is a video
http://www.youtube.com/watch?feature=player_embedded&v=-P28LKWTzrI
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
|
| |
| |
| Destructor1701 | Date: Thursday, 13.02.2014, 21:11 | Message # 60 |
|
Pioneer
Group: Users
Ireland
Messages: 533
Status: Offline
| Ah, thanks. No idea why it's not showing up here for me.
That's an excellent illustration of the difference in approach, Space Engineer, thanks!
It only increases my admiration for your skills.
|
| |
| |
ENG
New site
France 
Ireland 
Portugal 
Russian Federation 
Pirate 
United States