Hello Riven,I indeed intend to at least animate them as explained in the paper (dissipation, colors changing). I did not precise but the code on the LWJGL forum is an animation as the sun is slowly disappearing behind the ground producing a cool sunset thus the colors must be also dynamically set. Finally with a shading model (not necessarily complex) the effect will be great.

Note: in the beginning of this level, some ennemy armada will appear behind and through distant clouds.

Anyway the pictures are cool. Do you have one bilboard per cloud? Or are there multiple "particles" possibly animated (RGBA speaking) separately?

Ok, maybe something I could start with (if you propose to share your code).

I think the paper mentioned above uses the same technic regarding multiple sprites but for the colors, it uses some short-cuts (manually chosen colors). You can see some aspects of another implementation of it (according to me) here (see section "Illumination").

Last year, I came up with a much faster algorithm, that I haven't turned into code yet. The idea is this:

You have a massive grid (both in volume and in memory size). Think of it like: byte[w*h*d]

You image the light-source infinitely far, so all light-rays have the same vector, but different initial positions (as in: directional light).

Every cell in your 3D grid is filled with air/watervapor (determines translucency). Naturally, tracing through this grid for every cell is extremely slow, as you'll find yourself doing ray-cube intersections. There is a shortcut however:

Take 1 ray, and make its directional vector length tiny (say 0.05, where the grid cellsize is 1.0). Now slowly advance your position and check in which cell you are (casting x,y,z to int). Once you determine you left the current cell, put that cell in a list. After tens of thousands of iterations, you end up with a path with a reasonable amount of integer 3d coordinates. Compare the adjacent coords in the path and you'll (obviously) see the delta in each axis is either -1, 0 or +1. Put these delta's into a list.

Now you have a list (or array, for performance reasons) of deltas that allows you to step through the grid at incredible speed, no geometry intersection-checks.

Just for me to understand, the massive grid represents a cloud or general atmosphere conditions for the scene being rendered?

Whatever you want it to be. If you want shading per cloud, you can make a grid for each cloud. If you want clouds casting shadows on other clouds, you should make your grid either huge, or come up with a more efficient datastructure (lots of sub-grids, no hierachy).

Yes. But you first have to render the images that will be projected on the impostors. In the end you still have to do volume tracing, because everything else looks fake.

I'm not even going to attempt to understand the differences between the volume tracing algorithm you are discussing here, and the various scattering processes highlighted in that article. (which, btw contains the source to the flightsim demomstrating the clouds.)

However the use of imposters removes the necessity for the algorithm to be real-time, doesn't it?My understanding is that it gives you several orders of magnitude more processing time with which to compute the realistic lighting.

The problem you're having is that your sprites contain shade. They must be 100% white, only the transparency should vary. Once you get rid of all the baked in shading, it's time to add your own.

Otherwise every batch of cloud sprites will look like an explosion. (self illuminating)

Indeed! I set them whiter and the result is really better. However one more question regarding the textures used. The alpha channel is derived from luminosity the texture alpha components go from 0 to 255. Should I set it to 255 or 0 only?

And indeed now, I've got to work the shading; I've thought about you proposal and it may bring good results

However the use of imposters removes the necessity for the algorithm to be real-time, doesn't it?My understanding is that it gives you several orders of magnitude more processing time with which to compute the realistic lighting.

The problem with volume tracing is that even with using impostors, it's hard to get realtime performance. The clouds are also dynamic, so the impostors have to be rerendered every few seconds.

It's not a simple problem. Most game engines cheat, with nice, but far from correct results. It's all about how much priority you give it - faking it often is good enough.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

What about doing "fake" lighting with normal- and specular-maps on the sprites. If you render your background and foreground to textures, you could even use the normal-maps to do "fake" reflections/radiosity to make your sprites fit more into the level theme.

What about doing "fake" lighting with normal- and specular-maps on the sprites. If you render your background and foreground to textures, you could even use the normal-maps to do "fake" reflections/radiosity to make your sprites fit more into the level theme.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org