Author Topic: Atmospheric sight from planets? (Read 11220 times)

Naima · « **on:** November 17, 2014, 05:39:48 AM »

Will be added an atmospheric sight from planetary surfaces? It would be usefull for defining how the stars and the sky as well as the sun is seen from the ground planet when editing the system as well as take nice pictures of the custom planetary surfaces ...

Gordon Freeman · « **Reply #1 on:** November 17, 2014, 07:12:35 AM »

This already exists

Select Body>Click "C"

Naima · « **Reply #2 on:** November 17, 2014, 06:25:24 PM »

I tried that but it shows a very flat and omogeneous color on most planets, and not much freedom , I meant something like in Space Engine?

http://en.spaceengine.org/photo/

smjjames · « **Reply #3 on:** November 17, 2014, 07:40:01 PM »

It won't and will never have the resolution of space engine. At best, we might have a bit of 3D terrain.

Gordon Freeman · « **Reply #4 on:** November 18, 2014, 12:18:12 AM »

Quote from: smjjames on November 17, 2014, 07:40:01 PM

It won't and will never have the resolution of space engine.

Maybe if we wait long (;›-‹؛)

Naima · « **Reply #5 on:** November 18, 2014, 03:20:57 AM »

Quote from: smjjames on November 17, 2014, 07:40:01 PM

It won't and will never have the resolution of space engine. At best, we might have a bit of 3D terrain.

Why not ? if not wrong the materials are there, heightmaps, normal maps , texture maps etc, if they can scale them when in landing mode perhaps we could just explore finely the planets ... but haven't they tought of calling the author of space engine and merge the two projects together? would make the perfect simulator .

Unnamed25 · « **Reply #6 on:** November 20, 2014, 02:51:19 PM »

Quote from: Naima on November 18, 2014, 03:20:57 AM

Quote from: smjjames on November 17, 2014, 07:40:01 PM
It won't and will never have the resolution of space engine. At best, we might have a bit of 3D terrain.

Why not ? if not wrong the materials are there, heightmaps, normal maps , texture maps etc, if they can scale them when in landing mode perhaps we could just explore finely the planets ... but haven't they tought of calling the author of space engine and merge the two projects together? would make the perfect simulator .

I'm sure that its because it would lag a lot because it would have to simulate the really good physics and really good looks and stuff at once which is comparable to trying to use SE or US2 on an older computer

So 3 words: it would lag

Naima · « **Reply #7 on:** November 21, 2014, 06:55:47 AM »

I do not think it would lag at all . Its all procedural you know?

Gordon Freeman · « **Reply #8 on:** November 21, 2014, 07:30:51 AM »

Even though it's procedural, rendering it at all would be very CPU intensive.

Naima · « **Reply #9 on:** November 21, 2014, 06:40:48 PM »

It all what? The same stuff is rendered fine in Space Engine , I don't see why Universe sandbox should be any less .

smjjames · « **Reply #10 on:** November 21, 2014, 06:58:35 PM »

Quote from: Naima on November 21, 2014, 06:40:48 PM

It all what? The same stuff is rendered fine in Space Engine , I don't see why Universe sandbox should be any less .

You DO realize how CPU intensive Space Engine is? Also, it doesn't have all the physics simulation of Ubox, which itself tends to be CPU intensive.

Naima · « **Reply #11 on:** November 22, 2014, 06:30:56 AM »

In atmospheric mode it doesn't have to replicate all other external non visible features apart the trails .

Georg · « **Reply #12 on:** November 22, 2014, 07:37:35 AM »

We enjoy the detailed visualization of planetary surfaces in other applications very much. It's quite an achievement to get them to render both beautifully and fast, so hats off to the folks from Space Engine!

That said: we want to be able to display celestial body surfaces like that in the future. It's not trivial, and it's not our primary focus at the moment, but we'll be working on it at some point.

Sidenote: "procedural" just means "generated by an algorithm" as opposed to being based on pre-authored content. Procedural content is more costly at runtime, but more flexible than premade assets. Procedural methods are used to create details on the fly, on a scale that would not be feasible using handmade textures. The downside: Drawing a nice big heightmap texture takes next to no time at all, procedurally generating a nice big heightmap may take a whole lot of time, time that we need to simulate things!

USÂ² focuses on simulation first and foremost, which means that we don't get the benefit of computing only what's visible - whether you're looking at the surface of a planet or at a whole galaxy, we're simulating everything all the time. So no smoke and mirrors for us... sometimes it would be simpler to write a first person shooter, we could do all kinds of tricks to reduce complexity!

- George

creeperz1211 · « **Reply #13 on:** November 23, 2014, 01:04:51 AM »

Why would it be CPU intensive? I have space engine and it runs fine and smooth. I don't get how putting that in Universe sandboxÂ² would slow down the Central processing unit.

Georg · « **Reply #14 on:** November 23, 2014, 01:43:07 AM »

Here's how it works.

Rendering a planetary surface the simple way (what we do now):

Get some heightfield data, project it to a sphere, store it in a texture. Apply texture to sphere. Render sphere with a (fairly complex) shader to display terrain, liquid level, molten effects, climate results, impacts, materials, transitions... done!

Rendering a planetary surface the procedural way (like Space Engine):

Cut a sphere into parts, trying to get the geometry to be as high resolution as possible for whatever part of the sphere is in view depending on what the camera is looking at. Run an algorithm for as many height samples as possible to get a detailed height field. Displace geometry (on CPU, GPU, or both) to extrude mountains, valleys and other terrain features. For USÂ², on top of all that, still render liquid level, molten effects, climate results, impacts, materials, transitions... phew, done!

The difference: the simple case doesn't have to do anything costly with the sphere or heightfield data. The complex case needs to generate view dependent geometry (semi expensive) and generate height data (quite expensive) in addition to everything that the simple case does.

We will be able to do that at some point. It's just expensive (both in terms of development cost as well as in terms of CPU and GPU processing time). Space Engine doesn't focus on simulation nearly as much as we do - in USÂ², your hardware is already hard at work simulating things (gravity, collisions, composition, stellar evolution, and so much more...). That means that our time budget for visuals is more limited than it would be for an application focusing mainly on visuals.

Hope I could clear that up,
- George

Naima · « **Reply #15 on:** November 24, 2014, 09:16:00 AM »

Quote from: Georg on November 22, 2014, 07:37:35 AM

We enjoy the detailed visualization of planetary surfaces in other applications very much. It's quite an achievement to get them to render both beautifully and fast, so hats off to the folks from Space Engine!

That said: we want to be able to display celestial body surfaces like that in the future. It's not trivial, and it's not our primary focus at the moment, but we'll be working on it at some point.

Sidenote: "procedural" just means "generated by an algorithm" as opposed to being based on pre-authored content. Procedural content is more costly at runtime, but more flexible than premade assets. Procedural methods are used to create details on the fly, on a scale that would not be feasible using handmade textures. The downside: Drawing a nice big heightmap texture takes next to no time at all, procedurally generating a nice big heightmap may take a whole lot of time, time that we need to simulate things!

USÂ² focuses on simulation first and foremost, which means that we don't get the benefit of computing only what's visible - whether you're looking at the surface of a planet or at a whole galaxy, we're simulating everything all the time. So no smoke and mirrors for us... sometimes it would be simpler to write a first person shooter, we could do all kinds of tricks to reduce complexity!

- George

do you know of fractal terrain ? That program is just great and allows to create incredible varied and belieaveable heightmaps for whole planets ... sure some further editng might be needed to make it look more real , but its already a big step foward ... Perhaps you could take a look at it ...

Naima · « **Reply #16 on:** November 24, 2014, 09:26:15 AM »

Quote from: Georg on November 23, 2014, 01:43:07 AM

Here's how it works.

Rendering a planetary surface the simple way (what we do now):

Get some heightfield data, project it to a sphere, store it in a texture. Apply texture to sphere. Render sphere with a (fairly complex) shader to display terrain, liquid level, molten effects, climate results, impacts, materials, transitions... done!

Rendering a planetary surface the procedural way (like Space Engine):

Cut a sphere into parts, trying to get the geometry to be as high resolution as possible for whatever part of the sphere is in view depending on what the camera is looking at. Run an algorithm for as many height samples as possible to get a detailed height field. Displace geometry (on CPU, GPU, or both) to extrude mountains, valleys and other terrain features. For USÂ², on top of all that, still render liquid level, molten effects, climate results, impacts, materials, transitions... phew, done!

The difference: the simple case doesn't have to do anything costly with the sphere or heightfield data. The complex case needs to generate view dependent geometry (semi expensive) and generate height data (quite expensive) in addition to everything that the simple case does.

We will be able to do that at some point. It's just expensive (both in terms of development cost as well as in terms of CPU and GPU processing time). Space Engine doesn't focus on simulation nearly as much as we do - in USÂ², your hardware is already hard at work simulating things (gravity, collisions, composition, stellar evolution, and so much more...). That means that our time budget for visuals is more limited than it would be for an application focusing mainly on visuals.

Hope I could clear that up,
- George

Or why not use instead a procedural generation the other way , no need to subdivide the planet but just run a small script to procedurally generate some heightmaps ?

Georg · « **Reply #17 on:** November 24, 2014, 09:33:09 AM »

I know of Fractal Terrain. Some of the things I liked best during my career are related to coding terrain rendering and manipulation. So I'm probably as passionate about it as you are

Also you might have an idea about how long it takes to make a nice heightmap with Fractal Terrain (just the map, no geometry subdivision) and how large the generated files are. Now think about having a few dozen planets (or more, we could do *way* more

) in a simulation... and we might only have a few milliseconds to spawn those... or we could ship the finished heightmaps, but they're huge... and we would need many of those to do enough planets that are different... ouch, tricky problems!

Still, as said before: we love it, we want it, we'll get to it eventually. Hang in there while we're making it work

Cheers,
- George

phinehas · « **Reply #18 on:** November 24, 2014, 10:45:26 AM »

Naima · « **Reply #19 on:** November 25, 2014, 04:07:37 AM »

Quote from: Georg on November 24, 2014, 09:33:09 AM

I know of Fractal Terrain. Some of the things I liked best during my career are related to coding terrain rendering and manipulation. So I'm probably as passionate about it as you are

Also you might have an idea about how long it takes to make a nice heightmap with Fractal Terrain (just the map, no geometry subdivision) and how large the generated files are. Now think about having a few dozen planets (or more, we could do *way* more ) in a simulation... and we might only have a few milliseconds to spawn those... or we could ship the finished heightmaps, but they're huge... and we would need many of those to do enough planets that are different... ouch, tricky problems!

Still, as said before: we love it, we want it, we'll get to it eventually. Hang in there while we're making it work

Cheers,
- George

Ok Perhaps I am not understanding still how the US^2 works yet , I tried some simulations and I only could see one solar system at time and most of time the other planets are dots .
Anyway I thrust you will be doing something on this regard as I think its one of the most interesting features :=) ... Just please don't do it in a Sandbox ^3 lol ...

raxo2222 · « **Reply #20 on:** November 25, 2014, 01:55:33 PM »

Ehh can't we wait with it? cmon in 10 years we will have much more powerful computers.
Its too expensive in cost of computer calculations now.

Just look where computers were in 2004 or 1994 year.

im4space · « **Reply #21 on:** November 26, 2014, 09:05:50 AM »

In 1994 we had Pentium 90 MHz CPU and 1 GB hard drives

In 2004 we had Pentium 4 3.8 GHz and 250 GB hard drives
That is 40 times increase is speed and 250 times increase in hard drive space

In 2014 we have Intel Quad core 4.0 GHz and 6 TB hard drives
That is about a 23 times increase in speed and 24 times increase in hard drive space

In 10 years from now we might have a 10 times increase in CPU speeds and hard drive space. The rate of increase speeds and space is slowing.

(the increase in speeds of the CPU is my best guess)

Electrodynamix · « **Reply #22 on:** December 04, 2014, 04:57:20 PM »

According to Moore's law, which states computer processing power doubles every 2 years or so, is actually true. Ever since the creation of personal computers that were commercially available, their power apporoximately doubles every 2 years. I only have a weak recollection of Moore's law... I first learnt about it quite a while ago.

Bla · « **Reply #23 on:** December 04, 2014, 05:11:05 PM »

Actually it doubling every 2 years would mean it getting 32 times more powerful after 10 years: After 2 years it has doubled to 2, then 2 years later it doubles again to 4, then to 8, then 16, then 32, like an exponential function. Pretty amazing to think about.

im4space · « **Reply #24 on:** December 05, 2014, 07:43:44 AM »

Moore's law is that every 2 years the number of transistors in an integrated circuit doubles. This does not necessarily mean that the power doubles. CPU clock speed increased until sometime around 2004 and has not really increased since, it hit a roadblock at 4GHz. They added more cores and made each CPU cycle more efficient. Also they are making CPU's that use less power.