Jump to content


What Lighting/Shadowing method to choose


3 replies to this topic

#1 Hydrael

    Member

  • Members
  • PipPip
  • 34 posts

Posted 20 March 2006 - 11:21 AM

Hello everyone,

I'm currently stuck with choosing a lighting/shadowing method, that suits my needs...

In my project I will render indoor scenarios which are partitioned in an AABBTree.
At current state I will only use variable amounts of static omni lights.
Since I don't need super-accurate smooth realtime shadows, and all of my lighting is static, my first thought was:
"Hey - I'll just use lightmaps".
So a few days ago, I started implementing lightmap generation in my editor. It didn't take too long for me to find out, that lightmap generation isn't as easy as it sounds - and so I ran into a serious problem:

Since having a single lightmap for every face within a scene would probably have a heavy impact on rendering performance (texture changes every face), and I'd end up with having thousands of texture files for each scene, I wanted to pack several lightmaps into one bigger texture (just like it's normally done). But I couldn't come up with an algorithm, that decides whether the lightmap for face x belongs to lightmap set a or b (documentation on the net for exactly this problem is very rare).
And also, I'd most likely get memory problems in bigger scenes, as facecount increases. I could reduce the amount of needed lightspace memory, by DXT5 compressing the lightmaps, but I will anyway have to dynamically load and unload lightmaps while runtume.

To make it short - after seeing, that it will probably take some time to get lightmaps up and running, I started looking for other methods, that could be implemented with less work.

After looking around a while, it seems that shadow mapping could be just what I need. But regarding shadow mapping, I have a couple of open questions:

As far as I understand, shadow maps work like that:
- render the scene from the light source's point of view to a depth texture, which will then be combined with the real rendering in a second pass - everything that was visible from the light's pov, will be lightened
- for creating a shadow map for omni directional lights, I'd have to render a cubemap

The first question now is:
In all the articles on shadow mapping I've read so far, shadowmap generation is done in realtime.
Couldn't I, as long as I can guarantee that my lighting is 100% static, precalculate the shadowmaps and just reuse the same shadowmap for each light?

Second:
How will I handle multiple light sources?
Will I somehow combine all the shadowmaps, that currently affect the scene, or will I have to do a seperate pass for each light?
In one of Yann's older threads, he has shown a screenshot of a cathedral with several hundred lightsources - so I can't really imagine that this is a multipass thing.

Does anyone have any comments or hints?
Are shadowmaps suitable for my environment, or should I stick with lightmaps?

Thanks a lot for any response in advance

Greets
Chris

#2 roel

    Senior Member

  • Members
  • PipPipPipPip
  • 678 posts

Posted 20 March 2006 - 02:09 PM

the easiest way would still be static lightmapping. did you read this: http://www.blackpawn...ps/default.html ? i can give a longer reply later, with answers to your other questions regarding lightmapping, if you want.

#3 Hydrael

    Member

  • Members
  • PipPip
  • 34 posts

Posted 20 March 2006 - 02:21 PM

Thanks for the link roel - I haven't read that yet.
Let's see, if I got that right:
I would create a lightmap for each face, let's say 32x32.
After I'm done with that, I would use the algorithm explained in the link, and start packing all those small lightmaps into a larger texture (i.e. 8192x8192 - which would be enough for 65k faces).
Once the texture is "full", I'd create another one.
After that, I'd reassign lightmap texcoords and would be ready to go?

Please correct me, if I'm wrong ;)

#4 roel

    Senior Member

  • Members
  • PipPipPipPip
  • 678 posts

Posted 20 March 2006 - 08:12 PM

Yes, you are right. Some minor notes though:
1. I can't recommend you to have a fixed size per face, use more texels for larger faces and vice versa. Having a fixed size per face would also make the packing algo a bit redundant, storing fixed size chunks in a larger texture is way muc heasier than storing random sized chunks.
2. 8192^2 textures are not supported by all 3d cards





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users