Orxonox

My goal in this semster's pps is to implement nice godray (light ray scattering) and nebula effects in orxonox.
The main difficulties are programming the shaders itself and their interface, to have a fluid and novel game experience.

You can find all my notes and steps on my wikipage.

Don't hesitate to comment on this topic.

looks great

in which language do you write the shader program?

does this only work if the light is in front of the camera and is visible through some "clouds" or does it also work if the light is to your left (or right) and the rays go across the screen?

Thx for the compliment!

x3n wrote:
in which language do you write the shader program?

Main language is Cg (C for graphics). The "wrapping format" for defining gui-variables, techniques, passes and rendertargets is CgFX. It is supported by Autodesk Maya or Nvidia FX Composer, a popular free shader IDE, where I'm testing and tweaking my shader. FX Composer's advantage is to have one click conversion between many Cg dialects, GLSL and HLSL (since there's no huge difference between them).

Then in Orxonox, OGRE-Material and -Compositor-Scripts will take over the function of CgFX.

x3n wrote: does this only work if the light is in front of the camera and is visible through some "clouds" or does it also work if the light is to your left (or right) and the rays go across the screen?

If you meant "out of the screen", then the former:
In my implementation, the sun is rendered as a white 3d sphere on screen. Then it can be overdrawn by black light-obstacles. Z-Buffer may be enabled too. A 35x 2D radial blur is applied, with the sun as the centerpoint and is combined with the regular renderbuffer - altogether very efficient.

When the sun is out of boundary it does not get drawn on the godraybuffer, and therefore is not radial blured.

But there are probably many workarounds. One would be to extend the rendertarget around the edges. Another to determine mathematically the sun's dimensions... everything sort of slow.

The simplest one I've already implemented. At the begin I clear the godraybuffer with the hazecolor, at least brighter than black. Obstacles are then blured like shadows, and even when the sun says goodbye, there are still rays with the right direction.
I believe that godrays which are too present in every camera-view, distract from the game itself... although it could be a tactical gameplay feature to dazzle the enemy . What do you think?

sounds cool...

Cg is good since we use that anyway together with Ogre, so there's no need to write both GLSL and HLSL programs (even though they those are easy to translate as you say, but I still prefer to keep the code DRY). Is there a simple way to convert from CgFX to Ogre's scripts? Or is that a straight forward task anyway.

I understand that the shader only works if the sun is visible on the screen. I wouldn't worry about the other case, because that's probably beyond the capabilities of a normal shader. There are other approaches though that could help there, since rays are basically just shadows multiplied by -1 So if there's a way to make shadows visible in the fog, we already got our solution. There's one particular technique in Ogre, I guess it's called volumetric fog, which could be interesting in this context. (edit: nope, it's actually just a sample that ships with the ogre source, which is called VolumeTex. maybe still helpful.)

There's one potential issue that came to my mind regarding your shader: currently you use a model as the sun, right? However in Orxonox we currently use a skybox - so the sun is not a model, ist just part of the skybox texture. Now maybe we can sort that out by enhancing the skybox material (add an alpha layer which is white at the sun's position and black otherwise, then use that to define the light emission of the skybox material). however there's no 3d coordinate that defines the sun's position in a skybox... Maybe in future we'll have planets and stars in 3D, but right know we have to deal with this situation (or we really add the sun as a model right now - but very far away of course). I'm not even sure if this is actually a problem for your shader, but I still wanted to note it here.

Hey Atok,

I talked to l33t and x3n, and currently - as x3n mentioned above - Cg is only available on Windows. As far as Ubuntu/Debian is concerned, we have l33t working on it (thank you!) and the OSX integration is my trouble. I've already updated the dependency package, but don't download it yet for you won't be able to use the changes until our CMake code is adjusted. I'll post an edit here as soon as it's done (I'll merge the changes into your environment branch too).

x3n wrote:Maybe in future we'll have planets and stars in 3D, but right know we have to deal with this situation (or we really add the sun as a model right now - but very far away of course). I'm not even sure if this is actually a problem for your shader, but I still wanted to note it here.

A pps student is working on the textures, and I'm working on the models (sun included) - I can't stand the skybox sun .

Cheers Kevin

youngk wrote:as x3n mentioned above - Cg is only available on Windows

Did I say that? Because it's of course available on all major platforms: http://developer.nvidia.com/cg-toolkit-download

youngk wrote:A pps student is working on the textures, and I'm working on the models (sun included) - I can't stand the skybox sun .

Awesome! (and now that you say it I remember the planet ticket and commits)

x3n wrote:Did I say that? Because it's of course available on all major platforms: http://developer.nvidia.com/cg-toolkit-download

Well - no. If you're putting it that way, then of course you didn't say it. What I was going for actually, was that Cg was only integrated into Orxonox on Windows currently.

Cheers

Some clarification:

Whether Orxonox supports Cg or not dependes soley on CgProgramManager, an OGRE plugin. That is currently always shipped with the OGRE SDK on Windows, but only recent versions of Ubuntu and Debian have an extra package for that in their standard repository. We can add that to our recommended dependencies.

Recent changes in Orxonox now make CgProgramManager optional, meaning that it will be loaded if found on the system, but it is not required. Previously, it was enforced on Windows and not loaded on Unix.

As for an actual test: Two days ago, I was able to test Orxonox on an Arch Linux machine (thx ultimA). Unfortunately, it only runs with the kicklib branch because Arch has very recent dependencies (like CEGUI 0.7). The CgProgramManager change however was done in the trunk and I'm not very happy about merging it. So I cannot de facto test whether shaders actually work on Linux.
Maybe I'll just create a patch manually and send it to my colleague if he doesn't mind the extra work.