9 replies to this topic

[Nick3d]

Hi all,

I'm doing some research about real-time global illumination to use it for my works ( Architectural Visualization ).
My main goal is to have a proper ( static ) interior illumination ( GI like ) in order to have a really good real-time scene.
Basically I do all the job in XSI and then export into an engine ( Creator ) that do the job properly, but the main problem is the overall illumination system that is good, but nothing like a GI.

So, since in my scene there will be just a camera moving around, everything will be static, is there a way to have a sort of GI in my scene?
I'm talking about a way to let it work properly, but right now the only efficient GI that I saw so far is the Lightsprint demo.

So, since I would like to get something like that, but, as I said, a statioc version, what I need to do to get it?

Since I'm not a programmer I really don't know what I'll need to do that, so please can you explain me in a simple way what I need to do?

I was trying to work with cubemaps and Spherical Harmonics, but I'm not able to let them works :(

Thanks

Nicolas

[Vilem Otte]

If I were you I'd go for precomputed radiosity on per vertex basis, or in some lightmap.
You might also try instant radiosity that gives pretty good results - one real time solution is well described here, you also can look on "deferred rendered instant radiosity", on which I did some kind of research here (still I need to correct the text for mistakes in english, I was writing it on my holiday ... so I didn't care much about correctness)

[starstutter]

well so far what you've listed is mostly solutions for dynamic global illumination, which is far too expensive (in computation power) and complex for what you need. As mentioned above, I think the simplest solution would be to do some per-vertex GI. It assumes that your scene is fairly high vertex count, but for your application that shouldn't be a problem.

However, if you want to capture high detail, you'll need to use lightmapping with a solution like radiosity.
http://freespace.vir...y/radiosity.htm
This paper describes the algorithm in more detail and provides some links to other options.

Overall though, don't worry too much. If the scene isn't moving, global illumination can be (relativley) simple. Dynamic scenes are the tricky ones. We still don't have a good universal solution for those.

[Nick3d]

Thing is with lighmap the process it too long, since I have kind of 400 objects in my scene, so you can imagine how much time it requires to do lightmaps.

What I actually don't understand is how to implement GI in my. I mean, on the link that starstutter give me is explained quite well, and there is a code as well to implement it into the engine....but I'm really not able to...
I see that on the code there are a lot of "lightmap" process, but this mean that that code calculate the lightmaps for any objects or I have to put them from XSI and add to the objects?
Did any of you try to implement this code into an engine?
There are around the web some sort of "already made" ( like a .fx/hlsl file ) solution for a GI like system?

Sorry about that, my when it comes to programming I really don't know that much :(

Thanks for the answers

[starstutter]

Nick3d said:

Thing is with lighmap the process it too long, since I have kind of 400 objects in my scene, so you can imagine how much time it requires to do lightmaps.

Very true. This is why I never particularly liked lightmaps. As for implementing it, I tried once, got it semi-working, but then decided against it.The pre-process time was absurd (my environment was always changing) and its strictly for static scenes. It cant even handle doors opening and closing. I personally use Instant Radiosity, which is for semi-dynamic environments and the preprocess time is usually < 5 seconds. Unfortunatley though, if you use this technique, deferred shading is almost required, and deferred shading is not usually the best for super-realism (although killzone 2 used it).

Quote

There are around the web some sort of "already made" ( like a .fx/hlsl file ) solution for a GI like system?

I think you'd be hard-pressed to find one. Shaders for light source models are absolutley everywhere. They're relativley easy to make and straight forward to implement. This is because shaders only have access to local information (one vertex, one pixel, one light source) and global illumination (as the name implies) needs acess to global information about the scene, so CPU work is absolutley necessary. The reason that GI is such a challenge to create can be summed up in 3 statements:

1. The GPU only nativley has acess to local information, while the CPU has access to everything.

2. The GPU is extremley fast, the CPU is extremley slow (by comparision) so even though the CPU has global info, computing GI on the CPU isn't a feasable option for games.

3. The trick is to gather and compress scene information on the CPU, send it to the GPU (effectivley making it "look like" local information) and using that to compute GI.

The most GPU independant GI method I've ever seen is GPU-based raytracing. It however, still involves much pre-processing (dynamic light sources with a static scene is required) and saying that it's a memory hog is quite the understatement. A good sized scene (such as, I dunno, an architectural visualization) would require a graph in the form of a 3D texture, at the very least 1024x1024x1024 at 32 bits, thats 4.2 gigs of video memory(!!!!!).

Quote

Sorry about that, my when it comes to programming I really don't know that much :(

Thats ok :)
Here's what I suggest:
I think you're going to have quite the adventure trying to find a true GI engine. What I think the best option may be is to use a "fake gi" solution. It involves strategicly placing lights of different colors around the room. For example, if you have a red colored wall, you put a dimly-lit, red light source right next to it to light other objects. This solution is not the most efficient but it will certainly do. This approach was actually used in STALKER.

To use this method, the most efficient solution is to find an engine that uses deferred shading or lighting. If you're wondering why this is, its because a forward renderer requires one scene-render (sort of) per light. Deferred shading requires only one scene render... ever (unless you're doing shadows).

Here's to hoping this helps :)

[Nick3d]

Well, that is a little bit better, at least I know more or less why is so hard to have a GI lighting properly done...

Right now, since I can use only spot,point,directional lights I'm trying to do the best I can to have some decent interior illumination, unfortunately without shadows ( but with SSAO ) because there is too much geometry and too many complex shaders ( mirrors, reflections, and so on ).
Your solution will probably do the job, even if the engine don't support deferred shading, but since now placing lights to simulate a decent lighting works.

There are some free .fx shaders though, and the results with those shaders are really good looking...too bad that you need diffuse/lightmap/normal to let them work properly!

One last thing:

I saw that Vilem Otte said something about precomputed radiosity on per vertex basis, is something that you need to do in an outside 3d application ( in my case XSI ) and then put it into the engine, or is actually a feature within an engine? just to know at least what he was talking about!

Thanks again!

[starstutter]

Nick3d said:

precomputed radiosity on per vertex basis, is something that you need to do in an outside 3d application ( in my case XSI ) and then put it into the engine, or is actually a feature within an engine? just to know at least what he was talking about!

It depends on the capabilities on that specific engine. In general though, yes, and it usually takes pretty long to compute. This is if you're talking about PRT (pre-computed radience transfer) though, which is usually for things like subsurface scattering and very complicated shadows on surfaces.

Now, radiosity computed per-vertex (not per pixel) on the CPU is quite possible (in full realtime). Lightsprint is an example of this (don't give into his whole, realtime %100 per pixel global illumination BS, it's a blatant lie which becomes evident when you view the demo). This solution is good, however it involves coorperation with art assets and a fairly high tessenation of the scene. It can also be difficult to get it to work with normal mapping.

[Kenneth Gorking]

ATI has a sample in their SDK from 2007 that does GI, using the geometry shader and cubemaps.

Spherical harmonics might be worth a look, but it does have some pre-calculation associated with. These calculations can be save to disk however, so it would only have to run once, or when your enviroment change. It 'only' supports soft shadows, so if you need sharper shadows, you would need to implement some shadow-mapping technique to use along with it.

[Nick3d]

I've actually searching a little bit and found a lot of interesting stuff that might be what I'm looking for...
Is basically baked radiosity, but the results are very nice.

http://www.youtube.c...r/pureLIGHTTech

http://www.ambiera.com/irredit/

This seems a very good method to have a "radiosity like" lighting exported into a game engine...

My engine can handle quite a lot geometry, but when it comes to light, like most of the engine nowdays, its start to go terribly slow...so I think that this will be the solution...for now...too bad that in XSI I can't bake decent lightmaps! but at least irredit seems faster to bake ligthmaps...well, I'll give it a try!

[Vilem Otte]

Okay, here goes instant radiosity solution, more description is in video desc. (This solution is very good due to its "instantness" - you might just try it out)

This one has also secondary shadows! Also with some SSAO present - to do local ambient occlusion.
Just forgive my strange talking (I was a little ill, so my voice sounds really a bit drunk plus combination with my not-so-english-accent) and overally bad audio quality (but it's not about audio of course).