|
Nebulae
|
|
| SpaceEngineer | Date: Sunday, 25.12.2011, 22:05 | Message # 16 |
 Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
| Quote (HarbingerDawn) I suppose my question is: can SpaceEngine generate nebulae with absorption particles like it can for galaxies (dust lanes)? And if so, what parameters need to be specified in the model files? My goal is to get a nebula model that looks like the galaxy model I posted, and I am wondering if this is possible in the current version.
Galaxies and nebulae are generated and rendered with the same system. However, nebulae are rendered with a different shader, where dust sprites lighting is calculated in a specific way, with a scattering-like function. So they look like bright "em" sprites. It seems impossible to obtain Irr-galaxy-like looking of nebulae, the only way is to modify the nebulae shaders. I plan to remake or improve nebulae (and galaxies) at the next release hopefully.
*
|
| |
| |
| HarbingerDawn | Date: Sunday, 25.12.2011, 22:59 | Message # 17 |
 Cosmic Curator
Group: Administrators
United States
Messages: 8717
Status: Offline
| I see. Thank you SpaceEngineer!
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
|
| |
| |
| Retsof | Date: Saturday, 04.02.2012, 04:17 | Message # 18 |
|
Astronaut
Group: Users
United States
Messages: 56
Status: Offline
| Well, I'm sure you have thought of this already, but have you considered using fractals to make nebulae? Here's a render I did yesterday after discovering the program that does it:
Now, i realize that this is 2d, and would likely be different to implement in 3d, not to mention keeping the parameters in ranges that look good. But, if I'm thinking right, by their nature fractals should work well with a LOD system to keep them from killing your computer. Just a thought. *dons flak jacket and prepares to be shot down*
|
| |
| |
| SpaceEngineer | Date: Saturday, 04.02.2012, 10:56 | Message # 19 |
|
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
| Nebulae are already generated with fractals, but the limit here are number of particles that a PC can render in real-time. At present, it's about 20-50k particles (sprites).
*
|
| |
| |
| Retsof | Date: Saturday, 04.02.2012, 18:02 | Message # 20 |
|
Astronaut
Group: Users
United States
Messages: 56
Status: Offline
| Ah, I see, I suppose I misunderstood how such things work.
|
| |
| |
| Teto | Date: Tuesday, 07.02.2012, 15:06 | Message # 21 |
 Space Tourist
Group: Users
France
Messages: 28
Status: Offline
| For me, nebulae is the cosmic object that I prefer to watch in a space engine. And surface of planets of course.
I dream of nebulae that look like the ones which can be seen on photos (with false colors). And travel inside them, of course.
On Celestia, many nebulae are present, and other ones are made by modders. The problem is that they are just skins, without thickness, and it's beautiful until you go through them. At this time they look thin, and small, without volume (but 2-3 exceptions). You have no deepness. So volumetric nebulae would be much much better.
I've read this thread and I do understood that the biggest problem is to do something volumetric and that doesn't look too flat or spherical. Before today I was sure that something volumetric and believable wouldn't be too hard to do. Noob. 
If I were a programmer (I'm not...) I would try this :
- First, when you are far far away from the nebulae, you would see a texture on a 3D model. Basically, a mix between translucent volumes and/or skins/surfaces with different shapes to fake the general shape of the nebulae. Textures would be 128x128 to 2048x2048 for different LODs.
- This point is important : when a pixel of the texture (or material) on the screen becomes to be bigger than a pixel on screen, the texture at this point (not all of it, just pixels that become too big) becomes a volumetric fog. A cube if it is surrounded by other textures, other shape if it is on the edge, with the good color of course.
- Of course that means that the volumetric model must be baked before loading game. The texture is not flat, so 'fogs' would be contained in space along the 3 axis. By using voxel technology ? I really don't know. But I'm pretty sure that it would give outstanding results. 
- With Blender, it's easy now, without money, to sculpt wonderful skins/volumes.
I would like to answer about shapes of a nebulae also. Yes, we don't know how they look like, we just have a flat vision of them. But as we won't be able to travel in a ship to watch them closely, it's less important to be exact. And we can guess how they should look like, especially when we know where the exploded star was. 
Anyway, I hope that you'll work a lot about this. 
|
| |
| |
| SpaceEngineer | Date: Tuesday, 07.02.2012, 21:20 | Message # 22 |
|
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
| Quote (Teto) - First, when you are far far away from the nebulae, you would see a texture on a 3D model. Basically, a mix between translucent volumes and/or skins/surfaces with different shapes to fake the general shape of the nebulae. Textures would be 128x128 to 2048x2048 for different LODs.
Currently nebulae (and galaxies) uses the impostor system: far nebulae rendered (as volumetric cloud of sprites) in a texture one time, and this texture is used on a flat billboard. Then camera moved, this texture updated with some rate, dependent on a distance and velocity. But then camera enters the nebula, impostor being disabled and nebula rendered as 3D model every frame. This is the cause of limitation of number of sprites: modern PCs can render <100,000 sprites at interactive frame rates. If I make nebula model very detailed, say 1 million spritres, it will be rendered at 1-2 frames per second, when camera flies inside it. For example, in Infinty engine (If I'm not mistaken) they don't need to render volumetric nebula every frame, because their spaceships have a "jump drive" and can't do a continiously interstellar flight. So they can use very detailed model with 1 million sprites and just render it into a skybox as the ship exits a hyperjump. SpaceEngine have skybox system too - when camera stops moving, milky way (and close nebula) have been rendered into a skybox, which have been updated only when camera moves far enough from previous point (0.001 pc or so). Theoretically, I can use detailed nebulae and galaxy sprite models for skybox and impostors, but I should drop their quality when camera moves fast inside them. This will look ugly.
Quote (Teto) - This point is important : when a pixel of the texture (or material) on the screen becomes to be bigger than a pixel on screen, the texture at this point (not all of it, just pixels that become too big) becomes a volumetric fog. A cube if it is surrounded by other textures, other shape if it is on the edge, with the good color of course.
Textures can't become volumetric fog. Video cards can draw only flat triangles with texture and transparency. To render volumetric models, there is a several methods: cloud of sprites (current approach in SE), rendering a set of billboards with 3D texturing, ray-tracing in 3D texture (very qualitatively but very slow and limited in resolution). I plan to try the last method, but it can be used only on hi-end PCs.
Quote (Teto) - Of course that means that the volumetric model must be baked before loading game.
It is impossible - SE has no "loading stage" (not counting the loading of catalogs, shaders, interface textures, etc). Every object is generated on-the-fly when it appears in field of view first time (pushing out from memory the old objects created before).
Summing this up, the biggest problem is not to do something volumetric and that doesn't look too flat or spherical, but the PC performance limits the resolution of this volumetric model.
*
|
| |
| |
| Teto | Date: Wednesday, 08.02.2012, 10:27 | Message # 23 |
|
Space Tourist
Group: Users
France
Messages: 28
Status: Offline
| Quote (SpaceEngineer) Currently nebulae (and galaxies) uses the impostor system: far nebulae rendered (as volumetric cloud of sprites) in a texture one time, and this texture is used on a flat billboard. Then camera moved, this texture updated with some rate, dependent on a distance and velocity. But then camera enters the nebula, impostor being disabled and nebula rendered as 3D model every frame. This is the cause of limitation of number of sprites: modern PCs can render <100,000 sprites at interactive frame rates. If I make nebula model very detailed, say 1 million sprites, it will be rendered at 1-2 frames per second, when camera flies inside it.
What do you mean by sprites ? Does the nebulae become a cloud of sprites and the number must be < 100 000 or sprites means faces of the 3D model < 100 000 ?
-> When you talk about 1~2 frames per second for rendering, it's just about the nebulae or all elements ? Because if it's just nebulae, you could imagine 2 3D models : one with < 100 000 sprites when you velocity is high and one > 1M sprites when you velocity is low, the framerate would be good enough. Cry Engine 3 is a great engine that uses global illumination (100% dynamic light) where the calculation of sun-rays is not done every frame, but every 7 frames -> that saves cycles to do something else. It's not possible in SE?
Quote (SpaceEngineer) It is impossible - SE has no "loading stage" (not counting the loading of catalogs, shaders, interface textures, etc). Every object is generated on-the-fly when it appears in field of view first time (pushing out from memory the old objects created before).
You misunderstood me. In an engine like UDK, you create your level with lights. When you level is done, the editor bakes the lights, the lights won't be rendered in real time in game, but the effects of lights (shadows, rays, and so on) are saved in light maps and shadows map, that are rendered in game.
-> So, for me, baking 3D models of nebulae would mean : When your 3D model of nebulae is done, with its texture in high precision (about 2048x2048), an application would bake it and change every pixel of the texture in a set of sprites, and all this stuff is in a file (or more) and is loaded on the fly by the engine. So the location of the sets is calculated during baking, artist has nothing to do except give the size of primary 3D model and its location is space.
Quote (SpaceEngineer) Summing this up, the biggest problem is not to do something volumetric and that doesn't look too flat or spherical, but the PC performance limits the resolution of this volumetric model.
OK.
Sorry to insist about nebulae but for me it's very important in a space rendering engine. And I think that I'm not the only one. Poor/bad rendering can be a deal breaker for me, and I think that if nebulae in many games are just outstanding (but there are only drawn on skyboxes, I agree) it's for a good reason.
By the way, you talk about 1 3D model for nebulae. What about many models, especially when they have weird shapes ? In that case, the nebulae wouldn't be fully rendered, it would always be a mix, when you are inside it, between cloud of sprites and impostors. A tutorial about making nebulae could help me to understand how they work and try ideas I have to improve rendering (by making multiple 3D models for the nebulae).
|
| |
| |
| SpaceEngineer | Date: Wednesday, 08.02.2012, 10:56 | Message # 24 |
|
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
| Quote (Teto) What do you mean by sprites ? Does the nebulae become a cloud of sprites and the number must be < 100 000 or sprites means faces of the 3D model < 100 000 ?
Nebula (and galaxy) is a cloud of sprites - polygons that always face to the camera. The issue that the PC can't render millions of sprites with interactive framerates. The only way is caching rendering in impostors/skyboxes and update them not every frame (this is already done in SE). But if camera moves fast, we have a problem: if nebula or galaxy is updated once at 10 frames, it will jerk on-screen. In this case nebula should be rendered for every frame, but it is only possible by reducing number of sprites, ie decreasing quality.
Quote (Teto) When your 3D model of nebulae is done, with its texture in high precision (about 2048x2048)
I don't understand what you mean. Nebula have no texture. It is a 3D cloud of sprites. Sprites themselves have some texture, but it is very blurry; to hide sprite structure of a nebula.
Quote (Teto) By the way, you talk about 1 3D model for nebulae. What about many models, especially when they have weird shapes ?
Every nebula has its unique model. This is not a problem for SE - look at planets and stars, all are unique.
Quote (Teto) A tutorial about making nebulae could help me to understand how they work and try ideas I have to improve rendering (by making multiple 3D models for the nebulae).
I've written a tutorial about making galaxies. Nebulae use the same technology.
*
|
| |
| |
| Teto | Date: Wednesday, 08.02.2012, 14:06 | Message # 25 |
|
Space Tourist
Group: Users
France
Messages: 28
Status: Offline
| Quote (SpaceEngineer) Nebula (and galaxy) is a cloud of sprites - polygons that always face to the camera. The issue that the PC can't render millions of sprites with interactive framerates. The only way is caching rendering in impostors/skyboxes and update them not every frame (this is already done in SE). But if camera moves fast, we have a problem: if nebula or galaxy is updated once at 10 frames, it will jerk on-screen. In this case nebula should be rendered for every frame, but it is only possible by reducing number of sprites, ie decreasing quality.
I understand well that. What about having the number of sprites in accordance with you velocity ? Faster you go smaller the number of sprites...
Quote (SpaceEngineer) I don't understand what you mean. Nebula have no texture. It is a 3D cloud of sprites. Sprites themselves have some texture, but it is very blurry; to hide sprite structure of a nebula.
That's the trick. When you watch a photo from the NASA, nebulae has a lot of different colors (even if they are false most of the time). So:
- You are far away for the nebulae. You see an impostor with many different colors, red, blue, pink, whatever.
- You're approaching, the impostor becomes a 3D model that has a texture on it. Each pixel on the texture has its own color.
- You're approaching more, and some pixels are becoming big on screen. In a distance, they are changed by clouds of textures (a cloud by pixel changed) and the cloud has the same color than the 'pixel' that it replaces.
This approach could give more diversity and color to nebulae IMHO. The more I think about this, the more I think it would be great.
Quote (SpaceEngineer) Every nebula has its unique model. This is not a problem for SE - look at planets and stars, all are unique.
That's I'm talking about. Having few or several 3D models for 1 nebulae would allow many effects, colors, shapes, and mix impostor and 3D model and clouds of sprites when you are inside the nebulae, it would help the framerate.
*
|
| |
| |
| SpaceEngineer | Date: Wednesday, 08.02.2012, 14:50 | Message # 26 |
|
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
| Quote (Teto) - You're approaching, the impostor becomes a 3D model that has a texture on it. Each pixel on the texture has its own color. - You're approaching more, and some pixels are becoming big on screen. In a distance, they are changed by clouds of textures (a cloud by pixel changed) and the cloud has the same color than the 'pixel' that it replaces.
I don't understand these two paragraphs. Can you show a drawing?
Quote (Teto) That's I'm talking about. Having few or several 3D models for 1 nebulae would allow many effects, colors, shapes, and mix impostor and 3D model and clouds of sprites when you are inside the nebulae, it would help the framerate.
Did you suggest using several sprite models for one nubula (i.e. make pillars in M16 as separate models) or what?
*
|
| |
| |
| Teto | Date: Wednesday, 08.02.2012, 21:23 | Message # 27 |
|
Space Tourist
Group: Users
France
Messages: 28
Status: Offline
| Sorry for the delay.
OK. The, well, first sketch (2196382.png) below roughly represents a nebulae. To be easily understood, I draw something basic. So it's a spherical nebulae (blue) that is open (aka without dust or parts of the nebulae) in front of the drawing. reddish color represents the interior of the nebulae (but in reality it's blue, it's just to be understandable). The blue thing on the top of nebulae is another part of it. I'll explain why I drew it after. The red ball is the rest of the supernovae that made the nebulae. The green circle is where I want to go.
So here you have 2 3D models, the main part and the blueish thing on the top. The dead star is not in the model, it's just the origin of 3D models. These models have 3 or 4 LOD, that means that if you are far away, a small model is used (low poly, poor texture) and if you are near, the high-poly model is used instead.
On the model you have a texture, basically 128x128 for low-poly, 2048x2048 for high poly. This texture is done by a UV map (like a basic mesh). It's the second sketch.
The second sketch (3015932.png) represents the UV mapping of the main part of nebulae, top, middle, bottom, you get the idea. As usual, the green point is my destination. Here it's green, but it could be another color. The texture, in its best resolution is 2048x2048.
Now in game, I'm approaching the nebulae, and I'm inside it, near the dead star. The nebulae is in its 3D form, a static mesh that is so big that it's look like a skybox, it's surrounding me. Now I'm going to the green point. At a distance, I'm too close. The texture of 3D model at this point become transparent (or the face of the model at this point), and is replaced by a cloud of sprites, which are green, because the color in this region is green.
By the way, the other part of nebulae (the small model on the top that I talked before) is in 3D, because I'm not close to it. If I go there, the part of this mesh would become a cloud of sprites, and the main part of nebulae would stay a 3D model.
Was I more specific ?
Edited by Teto - Wednesday, 08.02.2012, 21:26 |
| |
| |
| SpaceEngineer | Date: Wednesday, 08.02.2012, 23:57 | Message # 28 |
|
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
| I understand now. You suggest making nebula as a thin deformed spherical mesh with texture, like a cloud layer on planets. But this is a bad approach. Real nebulae are volumetric. Only a few of them can be represented as a thin layer (or several layers).
For example, this nebula could be rendered as a transparent mesh, but what about the boundaries? How to make them look thick and smooth?
This nebula is obviously not a thin layer surrounding a star:
And this is a diffuse nebula, not even a supernova/red giant remnant:
Such a high quality image like the last photo can be rendered only by ray tracing in 3D texture. This texture should have a resolution of at least 512*512*512, and would consume 512 Mb of video memory.
*
|
| |
| |
| DevonX | Date: Thursday, 09.02.2012, 01:26 | Message # 29 |
 Space Pilot
Group: Users
Norway
Messages: 113
Status: Offline
| Quote (SpaceEngineer) Such a high quality image like the last photo can be rendered only by ray tracing in 3D texture. This texture should have a resolution of at least 512*512*512, and would consume 512 Mb of video memory.
Uhm i'm not sure, but can any GPU ray-trace on the go? Last time i checked a ray-trace is so demanding that just one frame would take a couple of minutes to render.
*
|
| |
| |
| SpaceEngineer | Date: Thursday, 09.02.2012, 01:46 | Message # 30 |
|
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4800
Status: Offline
| The GPU can almost do everything! Ray-tracing is just a rendering of a cube that represent the bounding volume of a 3D texture, but with a complex fragment shader that do ray-tracing calculations for each pixel of the rendered cube.
*
|
| |
| |
ENG
New site
Russian Federation 
United States 
France 
Norway