Bakery - GPU Lightmapper (v1.96) + RTPreview [RELEASED]

Hey. I'm sorry this has probably been asked a dozen times already. I'm trying to wrap my head around how to set my mesh normals/normal map to get the best results with bakery.

I made a cube with 1 smoothing group (or soft edges, whatever) and a cube with 6 smoothing groups.
With their own normal maps, they look the same with real time lighting. Ofc the normal map for the 1SG cube is heavily compensating the mesh normals and has strong gradients.

When i bake the lightmap, i have huge artefacts on the 1SG version. Little blacks squares, gradients, baked shadow "shifting"...it's completly off.
Can you confirm that normal maps arent taken into account during Bakery calculations, besides Bake Normal Map mode. It would make sense but i want to be sure. But even in Bake Normal Map mode, while more correct, i have weird artefacts (little squares, color off,see the last pictures). And i'd rather use SH anyway.
So basically, is it strongly advised to set the vertex normals so the normal map compensation is minimal ?
Like for a chamfered cube bake, use hard edges or bevels with weighted normals and get the minimal compensation ("gradients") in the normal map ?
Thanks.

 

It does not support baking into texture arrays.

 

@Noors84 the artifacts may be due to the UV generation for lightmaps.
If you're using a 3d modelling software, try unwrapping yourself the UVs and store it in the second channel of UVs and configure Unity's mesh import to keep the UVs instead of calculating them.
If you can't do that, try modifying the ligthmap UV generation on the mesh import or change the unwrapper on bakery's settings.

 

@atomicjoe Thank you but i did the second uv channel manually and i believe it is fine. Besides it bakes correctly on the hard edges cubes. So I do think this is mesh normals related.

 

hi, sorry if this was solved before (can't imagine i'm the only one stumbling upon this), but google wasnt able to help me out and reading through 100 pages is kind of rough..

Question being:
How do you get (if even possible) correct values for your skylight Intensity? I've set up an outdoor day lighting scenario (hdrp, shadowmask) according to all new Unity Lux values and charts for the sunlight and exposures and HDRISky and what not, I can get to the result I want using built-in lightmapper, but obvioulsy it takes ages and lacks control.

Now using Bakery I tried to narrow down the values for Skylight intensity usin the same .hdr, so that it gives at least something - but it's either not present at all, or blown up, or just glitches giving R or G or B mess. I guess there should be some float scaling issues or something of that sorts, is there any guidance on that?

I'm on 1060 461.09, Unity 2020.2.0f1, latest Bakery from the store. If that could be of use.

Thanks in andvance!

 

Is there a way to bake regular lightmaps and a separate AO bake combined into the same texture? Ideally I'd like a single RGBA texture where RGB is light bake and the Alpha is AO.

Thanks.

 

I would like that feature too. It would be excellent to bake AO and only use it when not directly lit by dynamic lights.

 

Your approach sounds good to me. Volume Receiver script won't be a good option indeed for so many objects, but it's only provided as an example. There are other game-specific ways of applying the volume. If you check the Trigger/Receiver code, it's pretty tiny:
- A MaterialPropertyBlock is created and filled with values. You can copy Awake() from the Trigger script without any changes.
- Affected renderers receive this block: meshRenderer.SetPropertyBlock(mb)

You can make a script that iterates over MeshRenderers and applies the block to them. There are many ways to find the objects, e.g. by a tag or a layer or a name or something else...

Are you sure it had proper lightmap UVs?

I didn't document it, but here is the list:

- invisible gameobject named !ftraceLightmaps with a ftLightmapsStorage script stores per-scene data, both bake settings (they are stripped from build) and renderer-lightmap linking data. Most important arrays in the script are:
* maps: list of rendered lightmaps.
* masks: list of rendered shadowmasks.
* dirMaps: list of rendered directional maps.
* rnmMaps0, rnmMaps1, rnmMaps2: list of rendered RNM or SH maps.
* bakedRenderers list of lightmapped renderers.
* bakedIDs: lightmapIndex for each renderer.
* bakedScaleOffset: lightmapScaleOffset for each renderer.
There are also some arrays specific for per-vertex lightmaps, shadowmask channels, terrains, etc..
Most of it could be applied automatically by the engine, but there is no way to access LightingDataAsset, so it's implemented in the script, as Unity suggested.

- All maps themselves.
- Mesh assets, if using per-vertex lightmapping. Applied via additionalVertexStreams.
- Skybox specular probe, can be generated via Update Skybox Probe.
- LightingDataAsset file. Only used to store baked light probes.

- ftGlobalStorage.asset is a per-project file. It stores:
* Global Bakery settings: bake defaults, benchmark results.
* Asset UV padding settings

... now a bit about this UV padding. There is this feature:



What it does is illustrated in my recent post: https://forum.unity.com/threads/bak...tpreview-released.536008/page-99#post-6782480

It complicates asset importing process a bit by adding a mesh postprocessor script (ftModelPostProcessor) that does this:
- Checks if this asset needs UV padding adjustment.
- Checks if it was already adjusted with the same padding values before.
- If it wasn't, re-unwraps the mesh with the new calculated padding settings.

To check if this asset needs to be unwrapped differently during the (re)import, ftGlobalStorage holds asset_name/mesh_name/padding_value.

Additionally the same data (mesh_name/padding_value) is written into model *.meta files. Previously adding custom data to meta files was not possible, so both options now exist to support different Unity versions.

There is also a per-project ftLocalStorage.asset. It also stores similar entries. The idea was that if you copy/commit global storage (or meta files) to a repository and other developers download it, the postprocessor script will detect a difference between local/global storages and trigger a reimport with adjusted UVs (that's why you should never commit local storage).

That's all, I think (not counting the data created in the temporary folder).

I assume your scene is very small at the moment. With larger tile size or larger sample count or simply a larger scene, the jobs should be fully utilizing the GPU. They run in serial, but many texels are shaded in parallel.
CPU is used for scene export (start), asset import (end) and data compression/decompression between passes (not very intensive). It is possible to create a scene where CPU will be a bottleneck, e.g. very simple geometry and lots of undersampled Light Meshes. In this case scene export and pass switching would take more than shading itself. It was once a case with point lights as well... now they can be processed in bulk. I was thinking about doing a similar thing for Light Meshes, but you can also just attach them to a combined mesh and use it as a single Light Mesh with similar success.

Haha I was waiting for this question since release
During development Bakery was simply called "ftrace" (the exe still retains this name), hence "ft". And it was called so simply because it traces rays and I add "f" to every tool name (similar to how Valve's tools all have "v" prefix).
"Bakery" name was invented much later because it turned out there is already some unrelated tool named ftrace and because it sounded a bit too obscure. On the other hand "Bakery" is harder to google. Sad.

Make sure to read this:
https://geom.io/bakery/wiki/index.php?title=Manual#Notes_on_HDRP.2FURP

And this:
https://geom.io/bakery/wiki/index.p...ok_black_or_have_bad_quality_in_an_HDRP_scene

It happens because default HDRI Sky exposure is super high and baked lighting is invisible under it.

Oh, by the way, I implemented it (at least post-bake rotation)
Grab the latest github patch. There is now a checkbox on the volume:



Bakery shaders also have a similar checkbox in the patch.

For URP, try this updated package: https://drive.google.com/file/d/14gKWpEl_adF0euOMHLbGBcF7Fqm310Jb/view

Use the graph named BakeryURPVolumeGraphRotatable. Together with a checkbox on the volume it should work.

Note: do not bake volumes when they are rotated, this is still not supported. They can be only properly rotated after they are baked.

You can write a little script that combines lightmaps into a 2DArray texture. I didn't do it because existing shaders in all pipelines don't support reading lightmaps from texture arrays.

 

You're the best! Thanks. I guess I really should send invoice/unlock github. Have I done that yet? I honestly can't remember but no biggie

 

Yeah it happens because the normals are too different from the actual geometry. You can also try disabling Adjust Sample Positions:



It applies some compensation for vertex-interpolated normals, but can look weird in extreme cases (and round normal over 90 degrees angle is an extreme case).

BTW, for chamfered boxes it is best to use face-weighted normals. Since you mention SGs I assume you work in 3dsmax, and if it's so, I totally recommend this script: http://www.bytehazard.com/articles/wnormals.html
Might be even good enough to remove the normal map.

Correct.

Looks like the normal map is not correctly applied. Maybe there is something different in the tangent space I use, although it should be the same MikkTSpace. Anyway:
- I'd be happy If you can send me this box + normalmap to check tangent space correctness and possibly fix something.
- I still recommend face-weighted vertex normals.
- As a last resort, try disabling Adjust Sample Positions.

Bakery doesn't like huge intensity values, so make sure to read this first: https://geom.io/bakery/wiki/index.php?title=Manual#Notes_on_HDRP.2FURP

But it is possible to use correct value ratios, even if absolute values are smaller... I explained it in this thread:
https://twitter.com/guycalledfrank/status/1358038418035531778
Knowing the logic behind Lux and EV and how they relate to each other, you should be able to get what you want.

Well there is no such option out of the box. Another problem is that there is no valid alpha channel in HDR lightmaps. on desktop they are compressed to BC6H (no alpha channel), on mobile they are ETC2/ASTC-compressed RGBM textures, where alpha is "M", used to recover the intensity range. Could fit in a dLDR lightmap though.
Anyway, it's possible to script it. For example:
- Enable AO, but set intensity to 0.001, just to force its generation.
- Bake.
- Iterate over your lightmaps. They are named like "somename_final.hdr".
- Look for files named "Bakery_temp_folder/somename_ao_Mask.lz4". This is the AO-only lightmap.
- In ftRenderLightmap.cs there is a definition for a DLL function named halffloat2vb(). Copy it to your script and use it like this:

var aoTexels = new byte[lightmapWidth * lightmapHeight];

var handle = GCHandle.Alloc(aoTexels, GCHandleType.Pinned);

try

{

    var pointer = handle.AddrOfPinnedObject();

    int errorCode = halffloat2vb("Bakery_temp_folder/somename_ao_Mask.lz4", pointer, 3);

    if (errorCode != 0) Debug.LogError("Error for some reason");

)

finally

{

    handle.Free();

}

This should give you the AO map, as an array of bytes. You can then create e.g. an array of Color32[] and fill rgb with your lightmap and alpha with this.

 

Thank you for the response
I've followed those instructions. Specifically, I have my sky exposure set to 1, and global volume fixed exposure set to 1, direct light set to 15, skylight set to 1, and simple inderect bake settings:




With no dynamic lights at all it looks alright, although weirdly washed out
[BAKERY]


But once I add a mixed directional light with lux intensity of 110,000 the scene is completely white from overexposure. Dropping the lux intensity way down away from physical values to something like 60 makes it not blown out, but looks terrible
[BAKERY]


I hate the progressive built in lightmapper, but simply as a comparison, it "just works" with mixed light at 110k and the exposure values set back to normal values.
[PROGRESSIVE]

Something to note with the progressive image above is that adjusting the exposure roughly linearly washes out the image, so the shadows start washing out at the same amount as the directly lit areas, which means that it is very easy to make it look exactly how I want. Here you can see that I've washed it out with exposure, but everything is "evenly" washed out.
[PROGRESSIVE]

Now look again at the bakery image up above, and notice that the boxes are washed out while the shadows are dark, which seemingly makes it impossible to get a natural look like the progressive pictures.

 

Using multiple scenes I go to advanced and bake the lightmaps with the Split by Scene options. And the results are fine. However, all the lightmaps are included in all the individual scenes. Browsing the forums it says to set removeDuplicateLightmaps in ftRenderLightmap.cs to true. But, then when I bake the results are poor.

I'm just testing with simple primitives with URP.

Any thoughts on how to improve this?

 

I know this is a topic that has been brought up a few times, but I would definitely love and appreciate a DX12 compatible version of bakery to use inside the HDRP pipeline with ray tracing Right now I am just doing baking in DX11 then switching over to DX12.

 

Small Feature Request:
Could you put a button somewhere to force-reload the lightmaps and directional lightmaps in the scenes?

Sometimes, randomly, my directional lightmaps vanish after baking with Bakery and I can't make them reappear unless I redo the render or go to play mode and back.
I don't know what does this happen, it's a bug that's being happening since the very first version of Bakery and I never understood when or why does this happen. Sometimes after saving the scene, sometimes after recompilation... it's quite random and annoying, because I really need those directional lightmaps for normalmapping and specular reflections on my custom shaders.

 

Same issue. With multiple scenes it almost seems bakery is attaching the lightmaps to the wrong scene objects.

 

hi, i bought your plugin, however im facing some issues

Error (1282):Memory allocation failed EDIT: problem fixed by searching for the wiki

keeps getting an error, when baking, xxx pack lod failed
also where is this ftrace.log?


help pls?

 

Hi Frank,

Question on padding:
Can atlas packer padding be adjusted? (both default and xatlas)
The problem is on the edges of lightmaps there is a leak due to anti-aliasing.
We hope increasing the padding could solve this issue.

 

I noticed that when using Bakery Volume with the included URP shadergraph shader, materials aren't getting "specular" from the volume data. Is there any way to simulate specular/metalness using light data from a bakery volume?

 

Nevermind, I managed to do it both with Amplify Shader and with a Shadergraph. Give me a while and I'll share it here in case anybody wants a functioning Bakery Volume shader with support for metallic/smoothness.

Update:

Code (CSharp):

1. void BakeryVolumeSpecular_float(float3 posWorld, float3 normalWorld,  float3 viewDir, float3 albedo, float metalness, float smoothness, out float3 diffuseSH, out float3 specularSH)
2. {
3.     bool isGlobal = dot(abs(_VolumeInvSize),1) == 0;
4.     float3 lpUV = (posWorld - (isGlobal ? _GlobalVolumeMin : _VolumeMin)) * (isGlobal ? _GlobalVolumeInvSize : _VolumeInvSize);
5.  
6.     float4 tex0, tex1, tex2;
7.     float3 L0, L1x, L1y, L1z;
8.     tex0 = _Volume0.Sample(sampler_Volume0, lpUV);
9.     tex1 = _Volume1.Sample(sampler_Volume0, lpUV);
10.     tex2 = _Volume2.Sample(sampler_Volume0, lpUV);
11.     L0 = tex0.xyz;
12.     L1x = tex1.xyz;
13.     L1y = tex2.xyz;
14.     L1z = float3(tex0.w, tex1.w, tex2.w);
15.     diffuseSH.r = shEvaluateDiffuseL1Geomerics(L0.r, float3(L1x.r, L1y.r, L1z.r), normalWorld);
16.     diffuseSH.g = shEvaluateDiffuseL1Geomerics(L0.g, float3(L1x.g, L1y.g, L1z.g), normalWorld);
17.     diffuseSH.b = shEvaluateDiffuseL1Geomerics(L0.b, float3(L1x.b, L1y.b, L1z.b), normalWorld);
18.  
19.     const float3 lumaConv = float3(0.2125f, 0.7154f, 0.0721f);
20.  
21.     float3 nL1x = L1x/L0;
22.     float3 nL1y = L1y/L0;
23.     float3 nL1z = L1z/L0;
24.  
25.     float3 dominantDir = float3(dot(nL1x, lumaConv), dot(nL1y, lumaConv), dot(nL1z, lumaConv));
26.     float3 halfDir = normalize(normalize(dominantDir) - -viewDir);
27.     float nh = saturate(dot(normalWorld, halfDir));
28.     float perceptualRoughness = SmoothnessToPerceptualRoughness(smoothness);
29.     float roughness = BakeryPerceptualRoughnessToRoughness(perceptualRoughness);
30.     float spec = GGXTerm(nh, roughness);
31.  
32.     specularSH = L0 + dominantDir.x * L1x + dominantDir.y * L1y + dominantDir.z * L1z;
33.  
34.     specularSH = max(spec * specularSH, 0.0);
35.  
36.     // Convert metalness to specular and "oneMinusReflectivity"
37.     float3 specularColor = lerp(float3(0.04, 0.04, 0.04), albedo, metalness);
38.     float oneMinusDielectricSpec = 1.0 - 0.04;
39.     float oneMinusReflectivity = oneMinusDielectricSpec - metalness * oneMinusDielectricSpec;
40.  
41.     // Directly apply fresnel and smoothness-dependent grazing term
42.     float nv = 1.0f - saturate(dot(normalWorld, viewDir));
43.     float nv2 = nv * nv;
44.     float fresnel = nv * nv2 * nv2;
45.  
46.     float reflectivity = max(max(specularColor.r, specularColor.g), specularColor.b); // hack, but consistent with Unity code
47.     float grazingTerm = saturate(smoothness + reflectivity);
48.     float3 fresnel3 = lerp(specularColor, float3(grazingTerm, grazingTerm, grazingTerm), fresnel);
49.  
50.     diffuseSH *= oneMinusReflectivity; // no baked GI override: modify diffuse
51.     specularSH *= fresnel3;
52.  
53.     diffuseSH = max(diffuseSH, 0);
54.     specularSH = max(specularSH, 0);
55. }

Add that function in BakeryDecodeLightmap.hlsl and use it with a Custom Function node in Shader Graph. You add the diffuse SH, specular SH and Emission, and connect it to the Emission node of your graph. Remember to set the output Occlusion to 0 to disable native baked GI.

 

I knocked up a script to combine full lightmap and AO bakes by copying away the results as this seemed safter long-term. However the encoding problem has me slightly stumped.

I'm combining the results into a texture as TextureFormat.RGBAHalf (16-bit float per channel, four channels) and using EncodeToEXR to save it to disk. That works fine as long as in the import settings I force the format to "RGBA Half" as well, and change my shader to sample the texture directly and skip DecodeLightmap.

However, if I change the format to (say) RGBA ASTC 6x6 on Android (because i'd rather not use a full half-float texture) then unity decides it's an RGBM texture, and the texture preview shows it as RGB and the A channel cannot be previewed (with the little channel buttons at the top-right of the texture preview display). Even more weirdly, the format label on the texture preview shows it as "RGBA Compressed ASTC6x6 UNorm RGBM encoded" - which suggests it's still actually got an alpha channel, but it's converted it to RGBM.

How does Unity magically decide that an RGBA texture should be RGBM? It it something in the filename? Some process in Bakery that flags it as a lightmap? The import settings have the texture type as 'Default' not lightmap. Changing it to 'Normal map' does appear to force it to RGBA rather than RGBM, but I don't want Unity to do any other weird processing it might do on a normal map either.

I just want to tell unity to back off, don't do any weird processing and let me manage the format myself (probably as dLDR).

 

Don't. Real-time light intensity must match the baked light intensity. "Match realtime to lightmapped" button should do the job, then tweak exposure to make it look non-washed out.

Maybe HDRP's tonemapper reacts differently to different ranges of absolute values? Anyway, if you can send me this project, I'll check it, will try to find the way to make them match.

Also this kind of washed-outness looks very much like a reflection probe intensity mismatch problem. Check if proper saturation returns if you dial down reflections.

In general... yeah, I know using Bakery in HDRP becomes more and more cumbersome with each HDRP update.
I'll have to properly account for its current way of managing lighting in the next version.

Thanks for reporting. I found the problem with removeDuplicateLightmaps and fixed it.
It should work now, you can get the patch from github: https://geom.io/bakery/wiki/index.php?title=Github_access

It's compatible now, if you get the github patch

Weird! Can you check if this script works?
https://drive.google.com/file/d/1C4sIo4c4wNW6eOZ7G4pWSu-1PFEYMMxQ/view
(Adds "Bakery -> Update lightmaps")

Try disabling GI VRAM optimization. And apparently reducing Texels per unit.

.ftracelog.txt is in Assets/Editor/x64/Bakery by default (it's not visible in the asset explorer)

Hmmm... it shouldn't leak. Are you sure it's the inter-object leaking, and not leaking inside one object's UV layout? (padding unadjusted?)
You can try it anyway. If you get the latest github patch and open ftAdditionalConfig.cs, I added these settings there (not in the UI, because I'm not sure it's a good idea to change them unless you really want to use lightmaps with mipmapping):

    // Padding values for atlas packers

    public const int texelPaddingForDefaultAtlasPacker = 3;

    public const int texelPaddingForXatlasAtlasPacker = 1;

There is a specular version of the graph (it's separate from the non-specular one): BakeryURPSHSpecGraph.shadergraph
URP graph pack was patched a few times after the store release, the latest one is here: https://drive.google.com/file/d/14gKWpEl_adF0euOMHLbGBcF7Fqm310Jb/view?usp=sharing (I also post them to Discord #announcements)

OK, I pinned them to the wiki:

Good question! I think:
- ASTC doesn't support HDR (at least in Unity)
- Unity is asked to import a HDR image into an LDR RGBA format
- Unity decides that the best option is RGBM

I guess using a non-HDR source asset (e.g. a PNG or a TGA) will make it import it as a regular texture without thinking of RGBM.

 

Hmmm... it shouldn't leak. Are you sure it's the inter-object leaking, and not leaking inside one object's UV layout? (padding unadjusted?)
You can try it anyway. If you get the latest github patch and open ftAdditionalConfig.cs, I added these settings there (not in the UI, because I'm not sure it's a good idea to change them unless you really want to use lightmaps with mipmapping):

    // Padding values for atlas packers

    public const int texelPaddingForDefaultAtlasPacker = 3;

    public const int texelPaddingForXatlasAtlasPacker = 1;

It was leaking due to antialiasing. For unknown reason, it seems that antialiasing is picking bordering pixels from the lightmap.
I updated Bakery from github, changed padding and it solved the problem!

 

It works! Thank you!
Usually directional lightmaps disappear when I save or when I compile code. (color lightmaps are ok though)
If you are just using DirLightmaps for normalmapping, it can be hard to notice at first glance. But when you use the directionality for specular highlights, it's very easy to see, obviously.
Maybe you could call "Update Lightmaps" automatically when the user saves the scene?

EDIT: I can confirm my directional lightmaps disappear consistently each time I recompile some C# and sometimes when I save the scene (not always).
Pressing the new "Update Lightmaps" fixes it.

 

Huh! What values did you use? I wonder if I should just make them default.

I couldn't reproduce the disappearing by recompiling or saving (tried my old 5.6 project and a newer URP 2020.1.4 test project). But I had a similar problem with the volume disappearing from objects (it was set via Shader.SetGlobalxxx) after the scene is saved. Current version of Bakery has ftFixResettingGlobalsOnSave.cs script that detects saving and calls SetGlobals again. Try adding ftLightmaps.RefreshFull() call there, will it work?

 

Hi. Thanks for your detailed answer.

Indeed disabling Adjust Sample Positions fix most problems, at the cost of problematic dark lines where meshes intersect.
Still i notice 2 issues one the soft edges cube :



- Faces looks slightly bent, as if it wasn't using the same tangent space. But in real time they are fine.
I'm using URP, and in Substance Painter, i have to use "Compute Tangent Space Per Fragment" to get the correct normal maps. This option has to be off when baking for built-in renderer (if that is of any help to you).
- The GI color seems slighly off, like desaturated. But maybe it's due to the bent normals.

 

I putted ftLightmaps.RefreshFull() first in "static string[] OnWillSaveAssets(string[] paths)" and yes, it fixes directional lightmaps on save now, which is great!
It still loses directional lightmaps every time I save a C# script though. (is there a callback for that in Unity?)
I do use scripted importers to automatically set texture properties by filename, but they only get triggered on texture import so I don't think it's that.
The weird thing is it only loses the directional lightmaps, not the color ones.

Unity 2019.4.20f1
Latest Bakery from GitHub
Built-in forward pipeline
Regular directional lightmapping mode

 

I had an issue with Bakery I was hoping someone might be able to point me in the right direction.
- I added the BakeryPointLight script to all of my Point lights
- Set the properties to the Unity Light properties
- Rendered Indirect using 1024 resolution.

The first time it worked out ok. But when I altered some options, cleared out the previous lightmap and built again, I got an overlapping UVs error on all my Meshes. I had Unity generate the UVs and increased the padding but still nothing changed.

I looked at the Scene using the UV Mapping view and Unity did not show any overlapping UVs.

Any ideas?

 

Ok so im back to bakery. I just cant handle the kind of hell unitys lightmapper is putting me through. Im hoping bakery wont just crash on me again though Also Bakery is giving me A LOT (hundreds upon hundreds, maybe thousands!) of warnings about incorrect uvs (uvs are out of 0-1 bounds OR has overlapping uvs), is there a way to get it to output a list to disk? Because a) its highly annoying tapping conyinue, and I keep hittigng stop since dialog box changes size and b) Id like to fix them (presumably I just tick generate uvs on the import settings?). It would be good if there was a way for bakery to auto fix these for the user.
Any why all these uv errors? unity never mentioned these, and most of these are pretty good quality imported assets so not sure why they would have issues. And if not fixed will they not be baked?

Sorry for all the questions but also what does "waiting for unity to initialise the probes" mean and do? Takes A LONG time..

EDIT: OK so the same as it has always been for yrs, bakery doesnt actually make any visible results. It does bake light maps now but mostly very dark and so subtle cant see anything but dark blues (I expect bright colours all over my map, red, green yellow lights etc not showing). Back to Unitys own light baking hell I suppose. Not sure why Bakery has never worked for me, but will keep it for future projects in case it ever does work for me

 

I am currently facing an issue and would like to know if it is a bug or just the way that Bakery works.
I am lighting an indoor scene. A Directional Light is shining through the windows. Also I am placing Bakery Area Lights (Light Meshes) in the Windows for blue daylight and turn off their shadow casting. As soon as I place the Light meshes in front of the windows the Directional Sunlights GI Bounces are blocked by the Light Mesh. So the Direct Light Rays still shine through the window but no Bounce Lighting is calculated. This can be seen in Realtime Preview and in the final Bake. My workaround is that I place the Area Lights further away from the actual windows so the Directional light is shining past them and not through them, but this solution is not suitable, since the player can also walk in the outdoor areas and the area lights now cast a very bright blue light on the outside of the house so that at least a little bit of blue light is coming through the windows.
I am Using Unity HDRP 2019.4 LTS with the most recent Bakery Version.
Is this a bug or just the way Bakery Light Meshes are working right now? Am I doing something wrong with the setup of the lights?
Any help or answers are really appreciated!

 

I also bought Bakery RT preview, but it just shows all the models as black, ideas?

 

Hi
I ask for help with the settings, I can't bake a large scene, an out of memory error appears GPU.

For terrain to bake properly I need to turn off Terrain optimization, but this results in a bake error.
I also tried to reduce the maximum resolution to 2048 and 1024.
I also included the option GI VRAM optimization.

When Terrain optimization is enabled, the terrain surface is baked without light sources.

 

Are there known issues with Bakery and the fbx asset import pipeline for unity 2019.4. I ask because I'm trying to import some fbx into my project that were used in a scene that was light baked by Bakery and it seems that some of these fbx are causing a never ending unity hang during import. The only common thing I've managed to tie it back to is all the fbx I have that are giving problems were at some point in a scene that was baked with Bakery. I've not got any further than this in working out what is causing the import hang. Sorry for the vague description but very little information is given by unity when it hangs on asset import so I'm just clutching on common things I know about the fbx that are failing to import.

 

Legacy lightprobes are broken on my side now (wrong lighting)
L1 works great though, but I need more detail than that because I make full direct light bakes (not only ambient).
Unity 2019.4.20f1

Edit:
Updated Unity to 2019.4.21f1 since they fixed some issues with reflection probes not rendering in some cases anymore but no luck: legacy lightprobes are still broken
Bug report:
https://issuetracker.unity3d.com/is...bake-button-in-the-per-probe-inspector-window

@guycalledfrank , have you thought about implementing actual L2 lightprobe rendering instead of just L1?
You know, that would be great, now that legacy L2 is not working anymore.

 

Rendering L1 lightprobes only via the "Render Light Probes" button makes the directional lightmap disappear for good: no way to make it come back unless I re-render the whole scene.
Unity 2019.4.21f1

 

Hi, Any idea why these objects aren't sharing the same lightmaps? Some of them are sharing but not all of them. What could be the reason?
these objects share same material and same mesh. Even scale in lightmap is same for all of them. They are just a simple plane with 2 tris and 4 verts.

 

yes: lightmap is full and needs another one to accommodate the other objects.
You can try increasing the lightmap max resolution to 4096 in bakery, reducing the texels per unit in bakery or reducing the scale in lightmap for unimportant objects.

 

We're experiencing issues with LMs looking blown out . This occurs in Scenes made up of several scenes loaded in additively, and depends on what is the activeScene. (looks similar to this previously reported issue)

We have one scene that does the loading (the top one shown), and the view renders fine when that is the active scene. However the view is generally broken when another scene becomes active. The LMs are clearly present, but its like their effect is massively contrasted.

In some cases the view might be correct from another activeScene, but there is no clear pattern behind this.


Scene format look like this:


Note that the baking is performed with only the Lighting and the Geometry scenes Loaded, and with the Lighting Scene Active.

We're on Unity2020.2.1f1 , Rendering URP , All surfaces currently using URPLit shader

 

Hey, For some reason lately in the past week or 2 my RTX 3070 cant bake lightmaps anymore. It says that denoisers are not supported when I detect settings

and when i try to bake i get an error message saying that none of them are supported.
Sadly this also happens when i turn denoising off.
I've tried reinstalling both game ready and studio drivers, as well as updating bakery.
Also tried reverting back to older drivers and still no joy
Cant find anyone else here with this issue so im wondering if its something im doing wrong.
Thanks in advance

 

Try uninstalling both nvidia experience and nvidia drivers and reinstalling them using the "full" installation mode (the nvidia installer lets you choose between fast install or full install when you run it)

 

Just did that and no joy, still getting this

this is the driver im currently on

 

Try this until Frank looks at it:
Donwload "Blender Benchmark" and run it. (its a standalone app)
Run the benchmarks using the GPU and set it to use OPTIX.
If the benchmarks can run without issues, it's a Bakery problem.
If they fail or doesn't let you choose Optix, then it's something on your system.
Try also using CUDA instead of Optix to test if it runs and how fast it is.
Optix should be minimum as fast as CUDA.. If it isn't, then something is wrong with Optix on your system.

 

Ok, so Optix benchmark worked on the blender benchmarks
hopefully there's a fix but for now i have no idea what to do haha

 

I'm on 461.72 studio too and bakery works great for me (denoiser and all)
I have an RTX3090 though but should be the same for the 3070.
You said it was working fine some days ago.
If you know roughly when, you could try to roll back your windows to an older restore point (if you have them enabled on your system).
It will just roll back windows and installed apps, not delete any user data.
This feature has saved my ass more than once

 

I'm using unity 2020.2.5f, when I try to render light probes appear this error


Lighting data asset ‘emptyLightingData’ is incompatible with the current Unity version. Please use Generate Lighting to rebuild the lighting data. Realtime Global Illumination cannot be used until the lighting data is rebuilt.
UnityEngine.StackTraceUtility:ExtractStackTrace ()
ftRenderLightmap/<RenderReflProbesFunc>d__239:MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:2706)
ftRenderLightmap:RenderReflProbesUpdate () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:2359)

OnDemand baking in progress...Can't read reflection probe lighting data asset until it's done.
System.Reflection.MethodBase:Invoke (object,object[])
ftRenderLightmap/<RenderReflProbesFunc>d__239:MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:2736)
ftRenderLightmap:RenderReflProbesUpdate () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:2359)

 

Thanks for providing the scene! But it looks like normals on the soft cube are not generated correctly. If I clear the lightmaps, this is how it looks with just realtime direcitonal light:



Something is really off with that cube. What software did you use to bake normal maps? Have you checked this article? https://bgolus.medium.com/generating-perfect-normal-maps-for-unity-f929e673fc57

Maybe you attached a wrong model or a map? On your screenshots both look OK in real-time. Or maybe your shader was using a different normal map decoding method? I'm using Standard shader here. It looks OK from some angles, but it's easy to see the problem.

Good question. Looks like there is: https://docs.unity3d.com/ScriptReference/Callbacks.DidReloadScripts.html
Try adding

[UnityEditor.Callbacks.DidReloadScripts]

static void OnScriptsReloaded()

{

 ftLightmaps.RefreshFull();

}

Maybe it reloads the lighting data asset which has some conflicting directional mode comparing to the one set via scripts? If you remove the asset, reload the scene, then save/recompile, will it happen? (obviously you need the asset for the probes, but maybe I can hack Unity to store the desired directional mode in the asset, if that's the case).

Did it bake though? This error is non-blocking, i.e. you could previously bake it even if you already had it. Sometimes the UVs are slightly off, which triggers the message, but it might be not critical.

Firewalker, it's absolute, in pixels. I think I understand what happened. Denoiser doesn't care about padding or chart boundaries, it denoises the image as a whole. Possibly it could smudge a bit over the edge... if you have time, I wonder if the issue exists when denoising is off.

Oh, you can just disable the message box for these warnings (it's actually disabled by default):



The messages will still be printed to console. And Unity console is dumped to \Users\You\AppData\Local\Unity\Editor\Editor.log

They will (see my reply to jnbbender)

Unity has no API to generate the Lighting Data Asset and probes by yourself. Therefore if you want to bake the probes, I have to force Unity to generate the asset with the probe grid, then I compute actual probe colors and set them.
Unity's light probes are a massive PITA. They have to be manually placed, they can't be moved at runtime, they have no ways to extend them, no way to create from code... consider using Volumes.

This sounds like light sources are not set up correctly (lightmapper doesn't see any lights in the scene?). Maybe send me some of your scenes and I'll check it.
Or you can ask on Discord. There are many awesome folks who can solve these kinds of problems

I usually recommend just using a Skylight for the windows (unless they're very small).
Do you turn off shadowcasting on the mesh renderer, or also "selfshadow" on the light mesh component?
Light meshes with selfshadow enabled will block other rays. But these with it disabled may produce lower quality contact lighting (unless you increase samples a lot).

Whole sun is blocked. I assume your directional part of the sun is just realtime (mixed light?).

Was skylight quality not enough for you? I'm definitely going to improve it by adding skylight "portals" that will give higher sample density around windows.

Indeed, there was a bug, sorry. Optimized terrain's bounding box was not correctly computed, so some point lights were culled.
Fixed it (you can grab recent patches from github: https://geom.io/bakery/wiki/index.php?title=Github_access)

I'm not aware of any.

Were you using xatlas as unwrapper? It can take a while to unwrap some models. I recommend using the default unwrapper, but xatlas as atlas packer.
ftModelPostProcessor.cs is hooked into the asset importing pipeline. It reads additional unwrapping instructions from model *.meta files. These instructions tell:
- Which unwrapper to actually use (default/xatlas)
- What padding value to use for each mesh.

Rebaking with default unwrapper or with Asset UV Processing = Remove UV Adjustments will reimport the affected models without using xatlas.

You can also reset meta files and reimport with default settings this way:
- Get debug tools: https://geom.io/bakery/wiki/index.php?title=Community_extensions#Debug_Tools
- Select model assets (not scene objects)
- Bakery -> Clear asset meta

Baking with Asset UV Processing = Adjust UV Padding patches them again.

I don't have 2019.4.21f1, but I have 2019.4.3f1 and I can't repro it there on example_shadowmask. Can you maybe check it there?

It's possible. I worked more on L1 because probes/SH lightmaps/volumes can all basically bake the same way, it is very universal (can't go L2 with lightmaps or volumes due to memory constraints). Still, first check if legacy probes work on 2019.4.3f1, I doubt that upgrading from 4.2 will bring any compatibility problems, but it can as well fix it for you

Can confirm on 2019.4.3f1 as well. Fixed it, check github...

I guess they just don't fit into one? Is your Max Resolution set to 4096?
You can also just use a lightmap group with Pack Atlas mode: https://geom.io/bakery/wiki/index.php?title=Manual#Bakery_Lightmap_Group_Selector
Everything affected by the group will be packed in one lightmap.

Such thing happens if you try asking Unity to render directional lightmaps where they aren't present. Is it the case, i.e. first scene using directional mode, while second scene is not directional?

Also please try using the latest github patch. Since you mention scene order, I think I've fixed something related about a month ago.

Very similar issue recently, check this thread: https://twitter.com/glassbottommeg/status/1364278406423080961
Turns out, they marked Bakery folder to be used with Perforce/SCM, and it set all Bakery files as "read-only". My benchmark tries to render a tiny lightmap, overwriting hwtestdata\image.lz4 file. If this file is marked as read-only, denoisers fail.
I've just added a fix that checks for the read-only attribute and removes it in advance (check github).

Also, you can still bake, just ignore the benchmark.

That's a bit too drastic The issue is surely simpler than that. I don't think there is any actual hardware/OS problem because OpenImageDenoise works on almost any modern CPU.

This is fine, can be ignored.

But this one is weird. Also you said you were renering light probes, but the error is from the reflection probe render?...
Sounds similar to the bug atomicjoe mentioned: https://issuetracker.unity3d.com/is...5.1696381044.1613929252-1257434621.1522062178

The error is in "invoke", and what it does it exactly this:

        var bakeFunc = typeof(Lightmapping).GetMethod("BakeAllReflectionProbesSnapshots",

            BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Static);



bakeFunc.Invoke(null, null);

Which is the same as using this button without even having Bakery:



So sounds like a bug in Unity? Try a different version (bugtracker mentions where it was fixed)?

 

Where did you get 2019.4.3f1 ?? It's not available anywhere in the UnityHub or download page!

 

Here: https://unity3d.com/get-unity/download/archive
Didn't realize yours was LTS

 

Oh, that's an old version yes. The up to date version is the LTS one. That's the reason I'm on the 2019 version, so it's stable.
Anyway, I'm testing it on a new project from scratch and legacy lightprobes seem to work fine now. Something must be wrong with my main project. I'll let you know if I find something.

 

Ok @guycalledfrank I found the bug in the legacy lightprobe renderer:
The reflection probes are being scrambled when rendering a lot of lightprobes. This is only noticeable with LOTS of lightprobes, hence it only shows in large levels with lots of differently lit probes all around:

This is a test scene rendered with L1 lightprobes:


This is with legacy lightprobes:


Notice how it scrambles the probes badly.

Not to fear though, since I fixed the code too:
Simply put this in line 4314 in "ftRenderLightmap.cs":

Code (CSharp):

1.             yield return null;

That's it. LOL
Now it renders correctly no matter how much lightprobes are in the scene.

The same scene with Legacy Lightprobes after the fix:


No more scramble.

Basically you have to wait a frame between rendering the reflection probes and reading them back.
Just in case the code lines are not the same in your code and in mine, this is the section were you call the probes to render with the fix, for context: (lines 4309 to 4314)

Code (CSharp):

1.             int[] handle = new int[currentThreadsCount];
2.             for (int ip = 0; ip < currentThreadsCount; ip++)
3.             {
4.                 handle[ip] = probe[ip].RenderProbe();
5.             }
6.             yield return null;