Volumetric light shafts with shadows support

[Xavyiy]

Hi all!,
I've spent some hours las night creating a little light shafts demo.
I'm looking for an efficient way to create "god rays" effect to implement it in Hydrax underwater mode, and... I think that the best way is, before implement it in Hydrax, make a little application! (However, I'm not going to use exactly this approach)

Rigth, this demo is inspirated on the ATI paper: http://ati.amd.com/developer/gdc/mitche ... shafts.pdf (Just inspirated, no code copied)

This is the approach:
- First, declare a camera wich represents the light projector frustum
- Make a rush(100 in the demo) of billboards according with the light camera's frustum
- Attach both to a scene node, so, now we can use the scene node normally, like rotate, translate, etc
- For shadows, we've to declare a RTT with the light camera viewport and render it with a depth material
- After it, this depth map is used in the light shafts material to calcule if the actual pixel is occluded by an object
- All calculations are done using projective texturing
- A little noise effect is applied, to simulate air particles

There're some screenshots:






And the download link: (Demo binary + media + sources)
http://rapidshare.com/files/112339165/L ... s.rar.html [Rapidshare]
http://files.filefront.com/LightShaftsr ... einfo.html [Filefront]

Demo keys:
C - Show/Hide light frustum, default: on
V - Enable/Disable light rotation, default: on
B - Enable/Disable knot rotation, default: off
N - Change light cookie

Hope you like it!

[Praetor]

Excellent work. You've been doing some amazing things here, and your generosity is really appreciated.

[itien]

Amazing work, Xavyiy! Looks like the best godrays implementation so far! Can't wait to see it in Hydrax. And as Praetor already said, thnx for the generosity!

Just seen the demo - great framerates there! Simply astonishing. The only slight problem i noticed - when you get too close to the beams, the fps drops suddenly and rapidly.

[Xavyiy]

Just seen the demo - great framerates there! Simply astonishing. The only slight problem i noticed - when you get too close to the beams, the fps drops suddenly and rapidly.

Yes.. unfortunately there isn't a real solution for this problem. However, you can play with the number of planes(billboards) or/and setting a bigger near clip plane distance value for trying to minimice the issue.

@Praetor | @itien
Thanks for the commentary!

[nullsquared]

Awesome, man, awesome... You have no idea how cool I think this effect is. It all started when some guy had some 3D text dynamically shadow the sun, and I was like ... woah. Now I'm like ... woah²

[eugen]

wow, great work!

[synaptic]

ooooo purdy

[sinbad]

Really nice work.

[dark_sylinc]

Awesome.
I have one question though, I still don't get it... How did you manage to put God inside the monitor??

Hi all!,
I'm looking for an efficient way to create "god rays" effect to implement it

Page here
PDF Here
It's very new and they claim it's pretty fast and cheap. Pherhaps it's useful for you.

Hope it helps
Dark Sylinc

[Praetor]

Their rendering time appears to be measured in minutes. They are comparing this technique to other non-realtime techniques. Perhaps some of the concepts can be used, but it's still too slow.

[Xavyiy]

@dark_sylinc
Yes, as Praetor sais this technique seems to be for non-realtime applications, like movies, trailers renders, etc.

[dark_sylinc]

@dark_sylinc
Yes, as Praetor sais this technique seems to be for non-realtime applications, like movies, trailers renders, etc.

Indeed you're right. Probably I was fooled by the source where I got the link, saying it was a new option for video games.
Times are measured in minutes, at least. Well, that's what we could call a patient gamer, waiting for the next frame to appear in 3 minutes.

Even though, I looked at the ATI's paper, then your code, and it both seems a very different approach. (Ray Tracing vs Planes with noise and blending).

Keep up the good work!
Dark Sylinc

[Lord LoriK]

@sinbad: you should give this guy an "Expert user" badge. IMHO, he's earned it...

[nullsquared]

@sinbad: you should give this guy an "Expert user" badge. IMHO, he's earned it...

Agreed.

[Xplodwild]

Could this could be "translated" in GLSL, or at least CG ? It would be great for Linux/MacOS users

[jacmoe]

If it's HLSL, it's pretty much CG already.

[spacegaier]

I finally tried this nice piece of code, in order to build some kind of basic disco scene with some MovingHeads. I therefore basically just took over xavyiy's code and added a decal to represent the gobo on the floor (as described in the Intermediate Tutorial 6).

1. The problem is that I use now a new RTT per light (and also cloned materials per light) which slows down the whole scene a lot (currently 8 lights at ~ 90 FPS, 1.500 FPS without the lights). Do I need that many RTTs and stuff (I wasn't able to get it running without, but I am not that proficient in this specialized stuff)?

Any other tips how to fasten that up? I already set the number of planes to 200.

2. I tried to make my own gobos, but somehow I am missing something: I made a .PNG file with one color set to transparent (via IrfanView), but that results in strange effects at runtime. Could someone enlighten me on that one?

3. Is there a way to change texture colors at runtime except via shaders? Then the same gobo could be used for all colors.

EDIT: Forgot another thing. If you look carefully on the screenshot you see that e.g. the two outer lights create some strange artefacts, leading from their decal on the ground horizontally and vertically to the end of the floor. As far as I can tell this only happens with decals that are blurred on the border. Any thoughts on that?

[Xavyiy]

@spacegaier
Hi! It's a pleasure that this code example is being helpful to someone!

1. RTT's: One RTT per light is needed if you want objects intersections with this light.
For example, if you're sure that a light isn't going to intersect any object in the scene or you assume that it isn't a matter, then you can siable the RTT for this light.
You can manage this by a LightProjector class(or something like this) and check if any object is intersecting the projector frustum(use Ogre built-in functions for this) and enable/disable the RTT acording to this.
You'll have to code a simple version of shaders, which must avoid the z-checking part, just a very simple shader which projects the texture based on the tex projection matrix of the light frustum(like the complex shader does) and swicht between the complex and the simple material depending of if the RTT is active or not.

2. I use Photoshop to make the .png textures, don't know why you're getting artifacts(just try to save them with any other painting program).

3. You can always change the texture colour by locking it's buffer and changing colours by code, but this is not a efficient way IMHO, I think you must do it in the fragment program just using a "uniform float4 uColor" and "oColor = finalcolor*uColor;" and then changin it by pass->getFragmentProgramParameters()->setNamedConstant("uColor", yourcolour) in your code, with this you're going to be able to use the same light projector for different light colours, or event changing it progressively you can get nice transitions effects

About the artifacts of semi-transparents borders in the projector texture, any idea , maybe something related with z-fighting ?, try to set a bigger nearclipdistance of the main camera, maybe..

Xavi

[spacegaier]

Thanks for the response!

1.I want these light intersections / additions, so I guess there is no way around the eight RTTs.
So, do you have any other idea, on how to speed the whole thing up, because the current FPS is not acceptable . I have an almost empty scene on a rather fast PC here, but only that few FPS...
Just tested it again: With the lights there but without Billboards, without RTT and without Decals ~ 1.200 FPS. Only with Decals ~300, only Billboards and RTT ~30, Billbaords, RTT and Decals ~24. So the main problem is the RTT stuff, but I am also really suprised that even the 8 Decals cost that much. Will have to look into their code again (I think currently each light adds an extra pass to the basic floor material).

The coloured artifacts are in fact caused by the decals (they disappear when only enableing the Billboards and RTT).

2. So you just made one arbitrary color transparent?

3. Already thought, that a simple shader would be the best. Will try that.

Concerning the possible Z-Fighting: Changing the clip distances of the main camera (the one I watch the whole scene through, right?), doesn't change anything .

Would be really thankful for any hints on how to get a better performance with this!

[Xplodwild]

Could someone reupload it somewhere else ? Like Filebeam ? Filefront link is dead and RapidShare says that there's no slots free since some days.

[spacegaier]

I was lucky and got it in one of the rare possible timeslots from rapidshare .

I temporarily uploaded it to my webspace: http://www.spacegaier.de/Ogre/LightShafts.rar

Let's wait for xavyiy where to put it statically.

[Ident]

this is awesome but, damn it really costs a lot of performance, especially if you're close to the light


is there any approach on volumetric light that doesn't cost as much performance (but also doesnt have to look just as awesome) as it seems there is no easy way of improving the performance of this a lot, and i'd like to have some visible light-cone effect? keywords or hints are good help for me.

demo is awesome, thanks for the upload spacegaier and thanks for making this xavyiy

[spacegaier]

Still no ideas on how to increase the performance?

[Ident]

i think it's a problem of having too much of the billboards on the screen creating heavy load for the fragment shader interpolating the colors of the texture and additionally applying transparency for every part


I programmed a lightcone consisting of lightcones of smaller radiuses and got a similar problem (huge framerate drop when pointing it at the camera itself) else it runs smoothly and nicely.

[nickG]

reupload,please