ENG New site

Advanced search
[ New messages · Forum rules · Members ]
3D water and clouds
Destructor1701Date: Thursday, 06.02.2014, 15:58 | Message # 46
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.





 
JCandeiasDate: Thursday, 06.02.2014, 16:37 | Message # 47
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!
 
Destructor1701Date: Thursday, 06.02.2014, 23:51 | Message # 48
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.




 
SpaceEngineerDate: Friday, 07.02.2014, 10:47 | Message # 49
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.





 
SHWDate: Friday, 07.02.2014, 11:10 | Message # 50
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.
 
Destructor1701Date: Friday, 07.02.2014, 20:09 | Message # 51
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
 
SHWDate: Monday, 10.02.2014, 07:46 | Message # 52
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.
 
SpaceEngineerDate: Monday, 10.02.2014, 14:59 | Message # 53
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline





 
JCandeiasDate: Monday, 10.02.2014, 15:19 | Message # 54
Pioneer
Group: Translators
Portugal
Messages: 387
Status: Offline
LOL!




They let me use this!
 
Destructor1701Date: Tuesday, 11.02.2014, 16:58 | Message # 55
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?




 
HarbingerDawnDate: Tuesday, 11.02.2014, 17:03 | Message # 56
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
 
Destructor1701Date: Thursday, 13.02.2014, 21:11 | Message # 57
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.





 
FastFourierTransformDate: Saturday, 15.03.2014, 19:36 | Message # 58
Pioneer
Group: Local Moderators
Spain
Messages: 542
Status: Offline
One day in SE we will see this kind of things:

http://www.youtube.com/watch?v=eoD672IB9gw

The volumetric clouds would take account of the different star light of a multiple star system



We would fly through the clouds of extraterrestrial gas giants





And we will see the planetary rings through the clouds of those gas giants




And see tuntherstorms beneath the clouds (or meteor strikes) illuminating them in the freezing night os some Neptune like planet



And we will see complex cloud behaviour when the chemistry of an extraterrestrial atmosphere is different than those we imagine



And all other of nature's epic spectacles



Attachments: 9964910.jpg (72.8 Kb) · 3621991.jpg (34.7 Kb) · 8017266.jpg (368.0 Kb) · 4790871.jpg (21.1 Kb) · 9025155.jpg (50.2 Kb) · 5348361.jpg (83.2 Kb) · 7540062.jpg (120.6 Kb) · 5127743.jpg (181.5 Kb) · 9459932.jpg (39.0 Kb) · 6632587.jpg (30.4 Kb)


Edited by FastFourierTransform - Saturday, 15.03.2014, 19:39
 
Tca_11aDate: Sunday, 16.03.2014, 00:02 | Message # 59
Space Tourist
Group: Users
Portugal
Messages: 26
Status: Offline
cry It's so... Beautiful ;_;
 
KubeQ11Date: Sunday, 30.11.2014, 11:37 | Message # 60
Observer
Group: Users
Poland
Messages: 12
Status: Offline
What do you think about oceans like this in Space Engine? That would be super cool, wouldn't it? smile Also, I thought that the faster and stronger the wind, the waves are higher and move faster. Of course, it would also depend on the composition of the liquid. Do you think that would be possible in SE? The liquid existing in the current version of SE is boring and flat.

P.S. I'm sorry for my bad English. It's not my native language. happy
 
Search: