revisting baking textures

[SgWRX]

once again i've decided to beat my head against the wall and revisit baking textures. i realize there are many levels to it especially in arch viz.

 

i beat my head against the wall because it seems the quality of the baked texture always is very very low. in this particular revisit, i have a sofit that is 15ft long by 2ft wide and i have a nice material created with a bitmap image of wood, inside a "tiles" procedural map, which i also use for bump and reflection maps.

 

when i bake this texture at 2048x2048 it looks terrible! the camera is fairly close, within about 4-5 ft of this sofit, it's a long narrow restroom.

 

is the secret to keep rendering baked textures (say with indirect illumination and shadows) to make them insanely large, 10000 x 10000px? i'm finding no time savings at all, in fact it takes just as long to render out a baked texture in large size as it does to render the actual scene at say 1920x1080.

 

now if you multiply that by two sofits. or 4 doors, it takes a lot of time to do this.

 

so what is it i'm missing about the concept of baking textures - ultimately for something like a 3d walk-thru app like unity or heck even autodesk design review?

 

thanks,

[Scott Schroeder]

You don't bake the entire soffit. You only make a section, bake that, then copy it around. Just because your baked map is 4k, the map on any uv island within the 4k is much much smaller.

 

Modularity is key.

[RyderSK]

The concept is you can't bake everything into single texture. For shadows and GI you need far less fidelity than you need for actual textures. That's why real-time engines use multiple channels where your channel 1 can be used for tiling texture in high fidelity (2k+ but across any kind of surface amount) and second unwrapped channel is reserved only for lightmap & shadowmap (for GI and direct shadows respectively), which can be far less in resolution although for high-end use requires at atleast 1024px per every 4m2 sort of.

 

Now baking isn't fast, when you compare it to Full frame which is 1920x1024 px in screen surface, you're now rendering multiples of that size for every surface (sometimes hundreds of 1-2k maps !). It simply saves time required for repeated computation in fly-through.

 

But since reflections still need to be ray-traced and this is far more costly than GI or direct shadows in ray-tracing, I wouldn't really bother with this approach in offline renderers and instead go for heavily frame-interpolated GI solutions (Irradiance cache) or world-space GI algorithms only (Lightcache).

 

Fully baked approach is best left for actual real-time engines which also provide super fast screen-space reflections which literally compete in visual quality with classic ray-traced ones (but at cost of miliseconds instead of minutes).