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

Probably bad UV wrapping. Select the model (FBX or whatever) in Unity and make sure Generate Lightmap UVs is enabled.

 

That is now fixed (@DigitalJacksonWork can confirm).

Ah yes. UV scaling is always uniform, so non-uniform scaling still keeps the square UVs, hence the mismatch. But it's not related to the quoted issue.

Same settings, bakes fine... can you send me a little test project/package? I'll check the difference.

Not as dramatic for sure... are you certain that none of your compressed textures are marked as sRGB for some reason? They should be linear. If you don't know, try doing pow(color, 2.2) on your L1 compressed textures and see if that makes them look right.

You can take a look at BakeryDecodeLightmap.hlsl, which is included in URP/HDRP packages. It has this function for specular:

void DirectionalSpecular_float(float2 lightmapUV, float3 normalWorld, float3 viewDir, float smoothness, out float3 color)

{

#ifdef LIGHTMAP_ON

#ifdef DIRLIGHTMAP_COMBINED

    float3 lmColor = DecodeLightmap(unity_Lightmap.Sample(samplerunity_Lightmap, lightmapUV), half4(LIGHTMAP_HDR_MULTIPLIER, LIGHTMAP_HDR_EXPONENT, 0.0h, 0.0h));

    float3 lmDir = unity_LightmapInd.Sample(samplerunity_Lightmap, lightmapUV) * 2 - 1;

    float3 halfDir = normalize(normalize(lmDir) + viewDir);

    float nh = saturate(dot(normalWorld, halfDir));

    float perceptualRoughness = SmoothnessToPerceptualRoughness(smoothness);

    float roughness = BakeryPerceptualRoughnessToRoughness(perceptualRoughness);

    float spec = GGXTerm(nh, roughness);

    color = lmColor * spec * 0.99999;

    return;

#endif

#endif

    color = 0;

}

You can call it in your surface shader and add the result to e.g. emission.
- lightmapUV is uv1 * unity_LightmapST.xy + unity_LightmapST.zw;
- normalWorld is the world normal, and you can use WorldNormalVector to get it: https://docs.unity3d.com/Manual/SL-SurfaceShaders.html
- viewDir is normalize(worldPos - _WorldSpaceCameraPos). Or maybe normalize(_WorldSpaceCameraPos - worldPos). Choose the one that works

Not sure... I was thinking about YT tutorials before, but I would start with the basics, going to more advanced topics gradually, and I wouldn't just record my screen and voice, there should be thorough explanations and illustrations, like in Freya Holmer videos and... and then I realize that I don't have time for it

It's not "worse", but it's slower and potentially less consistent, as it uses Unity camera rendering to gather lighting. In the Legacy mode, what probes "see" is the same as what Unity camera sees, plus point and directional lights.
Are you baking the probes when no sector is selected, after all of their lightmaps are finished? (if not, try it)
Also if you're using Unity area light components + Bakery Light Mesh, can you try using just quad geometry (mesh renderer + mesh filter) + Bakery Light Mesh instead and see if it works? Light Mesh can be synced to both Unity area lights and just any geometry. See if applying a bright emissive material to the Light Mesh quad will reflect in light probes? If that's the case then it's probably because Unity area lights are not visible to camera (and then I can actually fix it and autocreate temporary quads when you bake probes in Legacy).
Using Light Mesh + geometry was actually the original workflow, then I added Unity area light sync later... Legacy light probes might be stuck in these Legacy times a little bit.

??? I don't know what these dots are. Bakery Lights don't carry any light probes. This is probably something coming from your render pipeline UI.

This is not an option if all your Sectors don't fit into your memory. Legacy probes require less VRAM to render.
(And having a Volume per Sector is the best option anyway. Probes are a never-ending source of my frustration).

It looks as if the lightmaps were tiled all over your scene.
It is likely that you don't have any lightmapping UVs? See Quickstart: https://geom.io/bakery/wiki/index.php?title=Manual#Quickstart

Interesting. Can you send me a tiny test package with a scene set up like that? Maybe I can improve workflow so it's not causing any problems.

 

Just for my own benefit: Volumes aren't usable in a scenario like VRChat where I can't control the shaders being used by other dynamic objects, are they? (as I cannot control what shaders people's avatars are using, and thus there's an almost zero chance it'll be a Bakery Volumes compatible shader - as per "To sample the volume, a special shader is needed, and these are included in Bakery.".

 

I think you can easily reproduce it by yourself. Make for example a big cube as lod0 and big sphere as lod1, then set lod1 to 100%. You should see baked shadows casted on each other. I was using Shadowmask

 

Here, this is my test scene and its settings.

 

@guycalledfrank I randomly discovered these bakery-compatible SH baked specular URP shaders from Not-Lonely, and they give me fantastic results: https://not-lonely.com/blog/tutorials/amplify-shaders-for-bakery-urp/

comparatively, the URP shadergraphs provided with Bakery all give sub par results, even when compared to the packaged shaders for the built-in pipeline. Here's a comparison between Not-Lonely's shader and the URP SH Spec graph that comes with bakery:



the ShaderGraph's are all pixelly and don't look nearly as good. Is there something wrong with them?

 

Is "Bake Light Probes" supposed to be usable? It only works if you switch to Legacy probes, but at that point, Bakery just produces nonsense. The lightprobes produced by Bakery in a Legacy "Bake Lightprobes" run appear to be complete nonsense as though it's not bothered rendering most of the lights (or maybe emissions?) thus rendering the functionality useless.

Doing a normal bake in L1 mode produces accurate probes.

Are there some catches to doing a Legacy Probe bake that are likely to be causing this result?

 

Have you since came up with ways to make this happen?

Regardless, excellent work on the asset and the support alike.

 

Hi, I'm having issue when bake result. The scene in build (Android) look darker than what in the Editor and Editor game view. Like wrong color space or gamma or something. Any idea what might cause this? Is it something to do with my device?

Some infos:
- URP on Unity 2021.3.16f1.
- I'm not sure which Bakery version but it should be the latest (timestamp in doc pdf is 12/11/22 9:44 PM)
- Linear color space, ASTC texture compression, and high quality lightmap encoding
- Camera has post-processing enable with global volume. The in-used effect are: Bloom, Color adjustments and Vignette
- AA is enabled in the URP asset and in the Camera inspector.
- Scene has Bakery SkyLight but the intensity and color of the light does not match skybox material (on purpose).
- Bake setting is attached. (Yeah, I know, 500 texel/unit is kinda crazy haha. I'm trying to make it as realistic as possible)
- Android 10, Mali-G76 GPU. Problem persist both on Vulkan and OpenGLES 3.0.
- It used to happen on another project with different Unity version and rendering pipeline before. However, a build from both project were running on the same device.


Any info appreciated. Thanks!

 

I had to pull Bakery out of my project for now sadly as it is conflicting with the Meta Avatar shaders (being fixed by Meta), but even after removing it, I am still getting BAKERY_INCLUDED under script compilation. I can delete it here on the GUI or in the backend project setting files,but it always comes back. I am at a loss as to where it is coming from and am hoping you can provide some insights on how to permanently remove for now. Thank you

 

Why Bakery Volume (BakeryURPVolumeSpecGraph) so bright compared to static lighting (BakeryURPSHSpecGraph)? Is it normal situation? I am testing it on example scene (Unity 2020.3.38f1).



More real example with BakeryURPVolumeGraph(left) and BakeryURPVolumeSpecGraph(right):

 

Yes, in this case you can't use them

Ah... so the problem is not related to the volume itself. The reason why volumes can't be baked separately without also baking the lightmaps, is because volumes (as well as L1 probes) just gather lighting from the lightmapped scene. I.e. every voxel shoots rays in all directions, which then hit the scene, but instead of evaluating every GI bounce for every ray hit for every voxel, it just reuses the cached data already computed for lightmaps. However, when your geometry is set to "Receive GI = Light Probes" and/or "Scale in Lightmap = 0", Bakery assumes no UV data and... caches lighting in vertices instead, which is fairly okay when it's a separate object in a static environment, not environment itself, or if it has more vertices than... a cube. In your case what Bakery is doing is basically computing very crude per-vertex lighting for cubes and then re-gathering it into volume voxels. When I did my tests, I actually only had one copy of the cubes. Both the lightmaps and the volume were baked once, but then I switched my materials to volume-only. If I do it in your scene, it works well too.
So to sum it up, to generate high-quality volumes, you need to bake with lightmaps of comparable quality; but then you can throw these lightmaps away and use just the volume.

Yeah, Not_Lonely added a bunch of his own features, like some specular anti-aliasing and fresnel softening. It does look better indeed, but it's a bit out of scope of the basic SH-supporting shader
You can check Not_Lonely's graphs for the source of these additional features.

It is supposed to be usable for Legacy light probe mode.
Are these Unity area lights by any chance? Or points/directionals? Example scenes seem to work.

Not yet, but thanks!

Might have something to do with a different texture (de)compression implementation (Unity software decompression VS actual hardware), I'm not sure. Is there any issue if you try building on PC (to separate build issues from hardware-difference issues)? Also what happens if you use the built-in lightmapper, is there any brightness difference too?

Hmm I wonder what parts cause the conflict? Maybe I can do something on my part.

Oh. So yeah, the define is never actually removed (and I don't know how to run any keyword-removing code right before all the code gets deleted from the project, especially if it's deleted simply via Windows explorer).
The script adding the keyword is ftDefine.cs. If the keyword reappears somehow, then this script must be still somewhere in your project.

There is some difference due to low precision currently (and lightmaps knowing their surface normal in advance, unlike probes/voxels). You can try reducing GI intensity in the volume graph a bit to match it.
But yeah, it's annoying and I should take another look, maybe there is a way to make it more matching out of the box.

 

All lights in the scene have a corresponding Bakery component (and the Unity component disabled). It's entirely possible the problem areas are ones where that part of the scene is only lit via area lights (with corresponding bakery mesh light component) or emissions. Is there some issue when using legacy probes with either of those specifically?

 

Does anyone know why Bakery isn't baking LOD 0? I have an issue where it looks great in editor, but when it's built for Android, it doesn't bake the tree lighting on LOD 0.

 

Also,what do these errors mean? The don't seem to make my scene not play, but might be related to my LOD 0 issue.