Hmm… I am thinking that I want exactly the same result as a normal render, at least when I am gonna do lightmaps for games. Maybe I do not understand what you mean…?
It’s not really about lightmaps. When you’re rendering the final picture for example, you may want some 1000 samples a few bounces, no AO. When you’re baking a map, you may only need 100, no bounces, AO.
And when you are using lightmaps, you may want 16 bounces on the lightmap, but 0-2 bounces on the final render.
So I don’t think there’s much of a correlation between the settings you’d use for baking and the ones for rendering. Without separate settings we’re going to have to keep changing them all the time.
Nothing should stop you from turning up the samples as much as you like. The idea is simply to have a separate panel for bakes and a separate panel for renders.
Shouldn’t it be easier to use a bake “render preset”, to keep things consistent ? or do you mean a system like the old BI baking panel ?
Ok, I think a complete seperate panel, with separate settings would be a good idea, and maybe it could have an option “use render settings”.
I guess that’s an option too. A separate panel for bake settings would be more comfortable I think, but let’s not get too much into bikeshedding here. As long as we don’t have to change them all the time, it’s fine.
There is no “diffuse only”. You should try: DIFFUSE_COLOR, DIFFUSE_DIRECT or DIFFUSE_INDIRECT.
Thank you,
Did a few tests today
Seams are visible (no margins), on diffuse or other maps.
A question about normal maps.
These are object space nor maps. OK for cycles.
But, tried to preview/setup them in GLSL or BI. How to edit the RGB? It doesn’t seem compatible.
IMO margins and normal maps space are of first priority
To be able to work with this new tool and provide better feedback
Using box mapping (baked as DIFFUSE_COLOR), NORMAL map, AO map. (2k maps)
Cycles render
I am not sure if I understand you correctly but object space does not work in GLSL, you must use UV maps.
i think the box mapping can be the issue
Cage-based baking with Blender, in a nutshell:
- Create high-poly model H.- Create low-poly model L.- Unwrap L.- Create cage C from a copy of L.- Bake from H to C (object space, selected to active = on).- Assign baked map to L as material M.- Bake M to L (tangent space, selected to active = off).
The whole point of cage-based baking is to get a normal map encoded to the tangent space of L but sampled through C. The above workflow will give you that. In fact it is somewhat superior to xNormal because it can handle split edges and does not require the topologies of C and L to be identical. Which means you can guide the bake vector either by deforming C or by inserting additional geometry (edge loops, insets, outsets).
Hi, My test using Bake to pre calculate light and reapply in scene as emit map. Some Glitches in corners yet but i think it can be fixed with a bit more samples in Bake or with separated cubes for the wall instead a big cube with Solidify. To this test i used 30 samples to bake with 512x512 (Made in About 30seg ) in CPU (i5 2500K ) and render the scene with 2000 samples ( finished in 4mim 7seg ) with CUDA in a GTX560 TI so the total render time was ( 4mim, 37seg) what is just INSANE for that kind of noiseless!!!
For my Test i change a little bit the node config posted by Piotr Adamowicz and i think a get a good workflow for complex interior scenes:
- Make your scene and config all objects to a simple diffuse color approximated ( if you will apply a texture green in that object, apply a diffuse color green to it)
- Put all lights, HDR in Background if you want…
- Join the Walls and some huge Objects that envelop of the scene ( Like a Column ), Open a UV and Bake it as “Combined”
- Apply the lightmap back into the Objects as the example node:
- Put the rest of your material configurations (Glossy etc…)
- Re render it with GPU
I can imagine a Add-on that can handle all that work made by hand and option such as “COMBINED_DIFFUSE” in bake that Join Diffuse Color, Direct and Indirect hold be nice to the workflow too ( That way, we can just make the final scene and bake it anytime after put all material configurations ).
Could you post your lightmap? I have a theory why you got artefacts in the corners and I didn’t, but I’m not sure.
To comparation here is the Direct render without the bake as emit and with the same render config (2000 samples, CUDA) it took 9mim and have a lot of noise as usual. Who knows how many hours it will take to clear all noise.
Piotr: About bleeding the border? i test do it by hand in GIMP but without results in render. Anyway here is the file: http://www.pasteall.org/pic/66577
Hmm. Nope, it wasn’t what I thought. Seems it could simply do with some more samples.
I think it might be an issue of multiple UVs, if you have one UV for textures, and another UV for lightsmaps, make sure to add attribute vector with the correct UV map name to your textures, I got blotches like this because of this before.
As of now the branch has support for margin 
Margin is 16 by default, so even if you don’t specify the margin in the operator, you get some margin. Let me know how it goes. Nothing fancy is going on there, it’s the same code Blender internal uses.
I dont get it… I mean wow that is great! but how can it bake the light in 30 sec noiselessly if it takes more than 9 minutes to reach 2000 samples still with noise?
Martin.hedin - The UV is ok
Piotr - More Samples not did the work so well. I fixed it increasing the bake size to 1024 e applying bilateral blur in the Bake file with GIMP. No much difference in render times and a clear image =)
dfelinto - I will try the margin =)
ejnaren - The Bake is not noiseless, it have just 30 samples. But when you get it and reapply in your objects as a emit map the render time decrease in a incredible way. I can’t explain the technical details because i’m trying to get how it works too, but looks like it works as Photon Map + Final Gather of Mental Ray / Vray. Just try it. =)
Even if the lightmap is a little noisy it’s ok because what matters is not the particular value of the lightmap at that point, but the averaged value of what that pixel ‘sees’. The other reason it’s fast is because when you’re making the final render that way, Cycles only usually has to trace a single bounce, which is of course faster than doing it three-eight times like normally. And when that single bounce hits, it doesn’t have to shade it, reading all the textures and performing all the slow calculations for the material - it’s a single texture lookup. It’s simply cheaper to calculate a tiny lightmap once and use it over and over, than to keep recalculating the same info for each sample you take.
Final Test: Render time 4mim 26seg. 50% of FullHD. 30 Samples 1024x1024 CPU Bake + 2000 Samples CUDA Render. Without any Post Process.
CPU: Intel i5 2500K
GPU: Nvidia 560TI 1GB