Jump to content
  • entries
    232
  • comments
    1463
  • views
    961048

Nebulaes, part II

Sign in to follow this  
Ysaneya

713 views

Ah, i'm reading your mind. You asked, "part II" ? How many parts will there be this time ? Answer: hopefully, not a lot. I certainly still have more work to do on nebulaes, but i can't see it take more than a week or two ( and anyway, i do not want to spend too much time on nebulaes, there's other things to do too ! ).

So, what have i been doing since the last update ?

Main thing: experimentation. Testing new colors, new algorithms, new variations of existing algorithms, to get a good feeling of what's possible or not.

Technically, i switched from rendering particles to rendering point sprites. Took a day or so to code in ( especially as i had to keep the interface clean to be generic enough for a future DirectX implementation, if needed ). But i'm very happy with the results, especially the memory saving. Think about it: all my clouds are one million points. With particles ( orientated towards the camera in a vertex shader ), it required 32 bytes per vertex, 4 vertices per particle, and 6 indices per particle. That's 1,000,000 * 32 * 4 = 128 MB for the vertex buffers and 1,000,000 * 6 * 4 = 24 MB for the index buffers, so a total of 152 MB of video memory to render my nebulaes.

Now, with point sprites, i only need 1,000,000 * 16 = 16 MB for the vertex buffer, and no index buffer. 16 to 152 is a saving of 9.5 times less video memory ! ( and of course, that's 9.5 times less bandwidth for filling this data by the CPU ). The problem with point sprites is that i had to switch to a rendering that has a constant max point size ( while before, points of the clouds could be of variable sizes if needed ) and that i can only use one texture.

Fortunately, i found a good trade-off: i render the "large features" ( variable point sizes ) with normal billboarding ( where i can control the size and the texture coordinates in a vertex shader ), and the "small features" ( constant point sizes, around 95% of the cloud ) with point sprites. So there's no loss of quality at all. Performance also improved a lot, and i'm now getting from 15 to 60 fps depending on where the camera is located in the nebulae ( don't forget it's fully volumetric ! ).

I optimized the points generation loop by pre-allocating a memory buffer and removing some temp variables, and also optimized the cos/sin calls as David mentionned in my previous journal entry. The net gain is around x3.4 faster than before.

I've added some code to deform the cloud point with some Perlin noise, to give a "turbulence" effect so that "straight lines" generated by strange attractors appear a bit more natural. Of course, as everything in the algorithm, the amount / type of distortion can be randomly generated to have more variety.

On my "todo" list, i still have to:
- test a multi-pass color accumulation algorithm, to avoid the loss of color precision at very low transparencies
- use negative blending for some features like bok globules. Why negative blending ? Because i don't want to have to sort 1 million particles due to alpha blending :)
- experiment 3D IFS ( another equation for generating the cloud points )
- add "main stars" to the nebulae and light it based on the color and distance between each point and these stars.
- i've also been considering rendering particles with normal mapping, but i'll probably drop that since i believe it'll look "good enough" without it :)

The following screenshot is a cloud point ( yes, it is made of one million points ! ). I thought the result was looking very mathematical, and the code is dead simple. Bonus points for anybody who can guess how it was generated :)



The next two images are a nebulae deformed with Perlin noise and rendered from 2 different viewpoints:




Sign in to follow this  


10 Comments


Recommended Comments

Guest Anonymous Poster

Posted

I think this is something we'd need a video made of.

Share this comment


Link to comment
Nice effect!

I'd be very interested to see what could be done to this with geometry shaders...

Share this comment


Link to comment
Man i would really love to see you engine implementing some kind of real volumetric nebulae stuff you can go to, or an (animated / re-rendered) skybox that fools you of moving through it. I think it would add so incredible much to the athomsphere if some planets would be embedded or near some kind of large nebulae. I think it increases gameplay too if you have some areas when vision is limited by natural stuff like nebulaes. Even, refering that nebulaes are large objects, even if its only some kind of "dusty" look. It gives the universe a "larger" feel and makes it believeable.

I think if you are playing a space shooter continous some time, going from planet to planet and the surrounding not changing a bit, you fast get that feeling of being fooled and travelling in an skybox all time (which rise if you see a "small" nebulae somewhere far away and not changing a bit in scale while traveling to it). My first interesst is alway when playing a new space (combat) game is "can i go to what i see". I think it was Wing Commander Prophecy that once added nebulae areas where you could actually go through. It was cool, and added much to the gameplay.

Maybe you could scale the nebulaes (decrease-/increase) the nebulae rendering, fade in/out various nebulae renderings and add (to the real geameplay space) some dust- or fog-effects that refer to the color of the nebulae rendered, to give the player the feel that he is somewhere inside it.
Well just a thought. But i think stuff like this adds much to the gameplay, and a single not changing skybox would not serve you great planet engine and all that stuff enough (even if the skybox itself looks incredible).

Well. Just my thoughts. :-)

Share this comment


Link to comment
i was bored, so i decided to do a little photshop work:


hope you don't mind if I used your pictures and made that. i'm not going to sell it or anything. but if it really bothers you, i can delete all copies on my computer.

Share this comment


Link to comment

It's very beautiful and "nebula" looking but I have some questions with it's use in the game. It's very demanding on the CPU/GPU, so presumably you will just use it to generate skyboxes? If thats the case, what does it look like from the inside? Moreover, if it's volumetric, how will this be implemented in game - presumably the cloud density is so low in space you wouldn't need to provide volumetric fog in game to represent it?


Share this comment


Link to comment
These screenshots are, as always, beautiful [smile] Especially a good job on turning 152MB to 16MB! (Optimisation is always fun). I'd love to see them in action.

PS Nebulae is a plural word. Nebula is the singular.

Share this comment


Link to comment
Quote:
I think this is something we'd need a video made of.


Yeah, a video will come in the next update (maybe tomorrow?)

Quote:
I'd be very interested to see what could be done to this with geometry shaders...


I'm not really sure to see what geometry shaders could do with that effect, after all it's already particle based.. but if you have some cool ideas.. :)

Quote:
Well just a thought. But i think stuff like this adds much to the gameplay, and a single not changing skybox would not serve you great planet engine and all that stuff enough (even if the skybox itself looks incredible).


Sorry ? Please read my explanations again, it's not a single skybox never changing. It's a skybox rendered to "cache" the nebula effect, so as soon as the viewpoint under which the nebula is seen, the skybox is updated and re-rendered. The nebula is fully volumetric.

Quote:
i was bored, so i decided to do a little photshop work:


Nice, just coming a bit late :) Many players on the game forums have done the same, and somebody even made a mod for the combat prototype which replaces the old nebulae textures with the new ones.. :)

Quote:
It's very beautiful and "nebula" looking but I have some questions with it's use in the game. It's very demanding on the CPU/GPU, so presumably you will just use it to generate skyboxes? If thats the case, what does it look like from the inside? Moreover, if it's volumetric, how will this be implemented in game - presumably the cloud density is so low in space you wouldn't need to provide volumetric fog in game to represent it?


It's rendered into a skybox and only updated when your position inside/around the nebula changes. What does it look like from the inside ? Well, pretty much like the outside, but at 360°. It does not obscure the view too much like a "fog" effect if that's what you mean, as nebulae have a low density. Actually, most nebulae seen in nasa pictures would be invisible to the human eye. But it's a game, heh.

Share this comment


Link to comment
Quote:

Quote:
Well just a thought. But i think stuff like this adds much to the gameplay, and a single not changing skybox would not serve you great planet engine and all that stuff enough (even if the skybox itself looks incredible).

Sorry ? Please read my explanations again, it's not a single skybox never changing. It's a skybox rendered to "cache" the nebula effect, so as soon as the viewpoint under which the nebula is seen, the skybox is updated and re-rendered. The nebula is fully volumetric.


Wow thats great "news" for me :-), i thought the skybox would be static once rendered. Simply got it wrong before, sorry for that. That it is going the be recalculated when your position changes is great for me. This is certainly making a really awesome and believable effect! Can't wait to see that.

Share this comment


Link to comment
My thought was to move the particle-field generation from the CPU to GPU via a geometry shader/shader chain. You could then totally eliminate the need for the transfer of nebula data across the bus to the GPU, and easily support true volumetric nebulae trivially without worrying about extremely expensive sorting and culling on millions of particles (since you can just generate the particles that lie within the view frustum directly on HW).

Of course, unless you plan on requiring SM4 hardware, that's all rather academic [smile]

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!