Baking Illumination:

What's this all about?

As you may have noticed Surface Baker allows you to bake illumination for its own.
But... have you ever tried to do so, and to reapply the result to your objects?
On what channel you map the baked result?
In this tutorial will be described a procedure to keep your original tiling and resolution for color textures, and bake illumination at a minimum resolution, so that the baking process won't take ages.

Preparing for Baker

First of all let's start with the subject.

The example scene is composed by four arches basically...well and some grass and a sky.
Setup your scene in Layout with your textured objects and decide all the settings as usual, light intensity, direction etc.
Now take a look at your test renderings and see if you can optimize something.

In this example we have shadows casted by the arches on a pretty big plane of grass.
We obviously don't want to create a huge texture to bake the shadows on the floor.
So, let's split the floor, and make a polygon big enough to contain the shadows.

This should be enough for quite long shadows.
Final pass, check if there are n-sided polygons (polygons with more than 4 points) and triple them otherwise the baker will not consider them.

Now let's talk about UVs.
We want to keep our color textures, and mapping as is for resolution purposes.
Tiling is a very good thing, so we want to keep it uh!?
Then we're going to prepare a second UV set (New UV Map) using a different name.
This new UV set is the one we'll use to bake illumination so we have to keep in mind few things.

First thing, it's generally good to start with an Atlas mapping for objects with an architectural topology.
We're going to map the arches first. Now start with the Atlas projection and set a Relative Gap Size based on the resolution of you final "lightmaps".
For a 256*256 it's quite safe to use a 120% - 150%, for a 512*512 a 80% - 100%, but it's always good to make some tests, because the required gap depends a lot by UV topology.

If you don't get it right you risk pixels to overlap and overwrite one on top of the other.

Second thing, always remember we're baking illumination and UVs for this second set cannot be simply copied and pasted.
For instance we have four identical arches but all the polygon are in different positions in UV space.
Arches are identical but light is not!


Oh, of course, don't exceed the 0 - 1 limit in UV space for the second UV set! (Unless you want weird psychedelic effects baked on your texture!)

Last but not least of our short list, is continuous (or contiguous) mapping and vertex sharing.
In Baker we find the option Continuous Map that means "Consider all the vertexes merged, whatever happens in reality" or "All the other way around" if unchecked.
Shortly the Baker doesn't care about Smoothing.
But it does care about geometry!
When we set a 89.5 as smoothing value we want everything smooth but anything over 90 degrees angles. Even if we merged all our vertexes in Modeler, Layout will Unweld all those ones that don't match our smoothing angle when rendering.
OpenGL does just the same.
So in order to bake correctly we have to manually decide our smoothing angle.
Simple!
Unweld all vertexes of our arches, select the groups of polygons we want to be smooth, and merge.
In Baker we'll say we want a Continuous Map so it'll try to make it all smooth but our detached vertexes will stop it!

Talking about continuous things let's do some continuous mapping.
The Atlas method is very powerful and quite precise and that saves a lot of time (if you use other 3d packages you know what I'm talking about!).

But sometimes for Baker isn't enough!
Here's our first pass with Atlas:

Really not bad but the inner part of that arch has been divided in three chunks of mappings.
In this case Baker will try to match the pixels on the borders of each chunk but pixel blending usually wins and stitches-like black lines will appear magically!
Avoid this by making a contiguous mapping of that polygons.
Select the polygons in the arch and create UVs in the second set using a cylindrical projection and fit our new mapping with the rest:

Let's bake it!

Simply that! Use just raytracing or radiosity if you want and bake the whole thing checking just "Bake Illumination" in Baker and deactivating fog if any (produces wrong results when baking), and outputting a HDR image.
Why HDR!?
Well simply because we want to be able to darken and brighten with the same lightmap! If you output a 24 bit image it'll not keep all the extra informations to overbright!

Well, if you're sure your objects receive totally no more than 100% from all the lights in your scene, you're done!
In this case just output a 24 bit lightmap from Baker, read till the end of this paragraph and jump the "Huston Problem" part!
...if not....go ahead!

It's time to reapply our cooked textures!
Now that we have the illumination what we should do is multiply our lightmap by the color texture in the color channel, making sure we have set 100% luminosity and 0% diffuse as well as turned off radiosity and turned off all the lights:

And here's a test just with the floor done:

...but hey!...I've done all the steps properly...what's going on!?

Huston we got a problem

Alright, here's the problem:

We're doing the right operation, we're multiplying...but everything is washed out!
It's suggest some sort of gamma problem.
That's it!
Unfortunately it seems that the Texture editor doesn't perform floating point calculations when blending layers.
Well, at least it doesn't do that in the color channel.
A HDR image is stored with floating point values, that are then displayed with a chosen gamma value.
Doing the multiplication it seems that Lightwave is fixing a gamma value (likely 2 or 2.2) for the HDR image and treating it as a normal 24 bit image.
In fact, can you set a color value that is higher than 255 in the color channel using whatever you want?! Nope!
You can boost the layer opacity but values over 255 will be just clamped.
In a way that's right, we got the luminosity channel to boost...yep, but it's monochromatic! Arghh!!

So, we're going to ask for help to Paul Debevec...we're going to use HDRShop to correct our gamma problem.
(if you don't have HDR Shop you can download it for free here: http://www.debevec.org/HDRShop/ but note that "Non-Commercial Purpose" agreement and keep it in mind!)

Now, load your HDR lightmap in HDRShop and select: View->Display Curve->Custom... and type 0.5 as gamma value. (equivalent to a gamma 1.0 for a 24 bit image in this case)
Hit one time the "-" on your keyboard to decrease exposure by 1 step (100% in Lightwave's terms).
Do this for all your HDR lightmap and save them as normal 24 bit bitmaps.
Adjust gamma also for your normal color textures, cos we have to multiply in Lightwave with both textures at the same gamma.
Import color textures in HDRShop at gamma 2.2 and choose : View->Display Curve->Gamma 1.0 and save.

Now we're ok!
Just replace our wrong textures, boost luminosity to 200% (because we took down exposure by 1 step, remember?!)and make a test rendering!

Now that's right!
Well the job's done! You're free to add some bump and specular if you want turning on the lights but setting just the Affect Specular attribute.

Hey, think about how much time you're all going to save!
On an Athlon 1.4 Ghz here're the results:

Not baked:

640*480
Antialiasing Enhanced Low
Radiosity MonteCarlo 1 bounce 2*6 rays
Time: 1m 50s (110.7 secs)

Baked:

640*480
Antialiasing Enhanced Low
Radiosity MonteCarlo 1 bounce 2*6 rays Baked in a grand total of around 5 minutes.
Time: 11.4 secs

Mhmm...9.7 times faster per frame! Not bad!

Comparison

Emanuele Salvucci.

Example scenes objects and textures to be added soon!

Contact:

info@forwardgames.com