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

Error from above report, thanks!

 

This seems a amazing project!
Is it possible to integrate Bakery into other game engine?

 

Unlikely, as this would require a complete rewrite. I don't think guycalledfrank has time for that.

 

I've gotten this popup a couple of times now while using Bakery. It seems to happen randomly from my perspective. It has happened immediately when I start baking and has happened 60% through a bake. What causes this and how do I fix it?

Edit: This seems to be caused by using a Bakery Volume in my scene. If I delete the Bakery Volume, I can bake fine. With Bakery Volume, I get the error in the picture. I'm using an RTX 3080ti

 

Hey, I have a problem with the UV packer, when I have hole filling checked my atlas has some parts with nothing.
Picture 1

Also, I don't understand why the pixel ratio is not conserved across all assets, there is a big difference in texel density on certain assets (with a scale of 1, the Same UV padding and Unity generate UV)
Picture 2

Thanks for your help!

 

Just wondering if you plan to support other vendors - or if Bakery already does?
Because, you know, NVIDIA... prices... monopoly... good to have options. But I guess the demand is not very high.

 

Yes I did, it turn out its Tangent Space SH setting was on on skylight , when I disabled it, everything worked

 

Any explanation why this artifact?


This is the lightmap exmaple

 

hello, does anyone know what is happening here :c? so I'm using the MonoSH with a unlit shader using the monosh subgraph, and all my bakes have those rings, I tried to change the compression format to different options and nothing change, I also change the resolution from the L1 monosh directional map and there is no difference, the rings aways appear in the same order, the base lightmap is fine with no rings, so it is coming from the directional map and looks like this only happen with point lights .

 

I've never been able to find out why IES files just don't work for me. I get a weird error that says the IES file is not valid. But every single IES file I try to use is always "not valid".

Normal cookies for spotlights always bake a black room, unless I set the light intensity to an absurdly large number, like 50.

 

Hey @guycalledfrank , is there currently any known bugs with baking prefabs? I followed the steps in the documentation and it seemed to work, until I tried to use those prefabs in another scene. I am experiencing a few issues.

1) The second scene has other geometry which is not part of the prefabs and when I build the scene it still seems to build all the lightmaps for the prefabs. I unchecked the "build prefab" option on the behavior of all the prefabs and it still built lightmaps in the new scene's folder. Checking the lightmap references, the prefabs in both scene one and scene two are now referencing the newly built textures in scene two's folder. This makes my use of prefabs pointless as the goal was to reduce the build size. How can I build the second scene without building all duplicate, unused lightmaps into the scenes folder?

2) If I add the prefabs to the second scene and need rebuild the lightmaps for them, I open my original prefabs and do a full rebuild, but then when I go back to the second scene all the prefabs are black. The only way I am able to fix it is to delete all the baked prefabs from the scene and re-add them, which seems like a terrible workflow.

3) If I bake the prefabs and then create a new scene and add them, they looks slightly different. I attached two screenshots to show what I mean. They difference is subtle, but I wouldn't expect any difference at all. Specifically, the specular highlights / reflections in the bottles are different. I should note that I am not building the reflection maps independently for each scene. They are part of the prefabs and use the custom mode so they use a common cubemap.

Are these known issues or is there a way to work around them?

p.s. What is the difference between SH and SH Mono? It looks like Mono makes less lightmaps, but is the quality the same?

 

It's because of HDRP's sky/camera exposure: https://geom.io/bakery/wiki/index.php?title=Manual#Notes_on_HDRP.2FURP
Either reduce it in HDRP or use a matching bright skylight in Bakery: https://geom.io/bakery/wiki/index.p..._use_Skylight_with_a_procedural_sky_shader.3F
...and reduce exposure in preview instead.
Make sure to match your baked directional light intensity to the real-time one as well.

Possibly the light probe itself is somewhere inside/below some object where it is dark? Can you send me a little test package (e.g. these two objects, the light and the surrounding walls only) to test?

The volumes are also dark?...
BTW, the object on the left "isn't being affected by light probes" - what lighting does it use then? It doesn't seem to be lightmapped either, as there is no shadow beneath.

Wild guess: did you enable "tangent-space SH" on your skylight?
What directional mode are you using?

You can bake on a remote server machine (not parallelize to multiple machines though): https://geom.io/bakery/wiki/index.php?title=Network_baking

Can you check if it happens with the latest patch?
Additionally, there is a "removeDuplicateLightmaps" in ftRenderLightmap.cs, can you try setting it to true and rebaking? I don't remember exactly why I decided to turn it off.

What if you have multiple lightmaps for the active scene?...
There is no manual way to control lightmap order at the moment.

"Show checker" mode just overrides scene view shaders. It doesn't affect geometry. But if the objects' vertex shader is doing something unusual, it won't work in this mode.
Terrain trees don't receive lightmaps on their own (Unity doesn't support it, terrain trees are instantiated on the fly), but do affect shadows/GI of the scene around them.

Can you show the final baked images of Bakery vs Unity results? Maybe Bakery picks up the wrong LOD as a shadowcaster or something?

I doubt it's the case... would be cool if you could send me some simple test project with these trees + terrain. I haven't encountered this issue before.

Hmm, this looks like GI only...
Not sure why it happens. There was possibly some bug with the subtractive mode before. Can you check if it looks OK in Full Lighting? And if it's the cause, can you try the latest patch?

 

Actually yes. I helped 2 people to integrate it into their tools. Email/DM me for details.

Not sure... this is just a generic crash
- Anything in .ftracelog.txt after the error?
- Any issues with any other 3D software (in case of a hardware issue)?
- Any weird AV (or V...) software which can launch at random times and inject into processes?
- Does it happen with different scenes, not related to complexity?
- How big is your Bakery volume? What is its VRAM size (written on the component)?

What is the resolution of this lightmap? Perhaps it's low, so the padding is big (while UV adjustment is off)?
I don't have much control over the xatlas algorithm overall.

Can you try the latest patch, AND this checkbox:



It actually uses a different scaling algorithm which results in more uniform texel density.
Sometimes xatlas can still violate it in order to fill more space though.

Unfortunately not at the moment, as Bakery uses NV's OptiX API under the hood, and AMD/Intel don't have anything comparable.

Wild guess: smooth normals on a box? Like this:



Such normals can result in many lighting problems. My advice is to use "weighted normals", max/maya/blender and even Unity itself can generate them. So for example, if you have a single-face chamfered box:



The issue itself is probably the result of the sample pushing algorithm that is trying to counteract the difference between the geometry and the normals. You can disable "Adjust sample positions" to turn it completely off, but it can result in more leaks. If you have the latest patch, you can disable only the normal-related part of the algorithm:

Ah, interesting, it looks like encoded RGBM. Just updated the URP package with proper lightmap decoding (only BakeryDecodeLightmap.hlsl has changed), can you try it? (it's on the main wiki page as well)
https://drive.google.com/file/d/1tVtvQ99vlI-8cOzRZzTwsYr_m7HEUtY3/view?usp=sharing

Interesting. Can you send this IES file to me to test?

Well it's not that absurd, especially if you want to light your whole room with GI...
Also take a look at Cone lights, they are more flexible spots with URP-like controls (separate narrow/wide angles).

Do you mean "Enable baking"?

But yeah, that's true, Enable Baking currently only prevents the prefab from being overwritten; new lightmaps are still baked for the prefab's instance in the scene.
In your case you'll need to also set Receive GI = Light Probes or Scale in Lightmap = 0 for all prefab renderers in the scene, so it won't ever generate new lightmaps for prefab instances.

Shouldn't happen if you follow the advice above.

The reflection probe system is fully governed by Unity, it'll work the same without Bakery. Maybe you have other reflection probe in the scene which has higher priority over the prefab one?

Yeah, MonoSH is not in the docs yet, I only recently added it. You can see the difference here: https://twitter.com/guycalledfrank/status/1553479909053538305/photo/1
It's pretty good, unless you have lights with drastically different colors shining from opposite directions.

 

I just Update it, there is no rings but now it looks darker.

so this is just the Main Lightmap

and this is multiply by the bakeryMonoSh

 

Wait, wait, you don't need to MULTIPLY by the MonoSH! MonoSH is the lighting itself

 

Oh I see thank you!

 

Hi

Is this project only alive on git and getting updated there? The asset store version has not been updated in a long time and I just wanted to see what is up. I have access to the git version, just havent used it in a while...

 

The intensity by default should be 1, the preview will look good

if i press the match button on bakery direct light it will set the intensity to 13038
And will look like this



because its very bright

when i baked the hdri exr map and set the direct light intensity to 1 and skylight intensity to 0.001

With preview exposure of 1

(Or setting preview exposure to 0.001 and skylight intensity to 1)
I get this look

 

Baking results:

 

Hello, I have a problem. Why is look like this after the bake? what i am doing wrong?

Thanks

Claudio

********************************************************

Update.

I cant bake my project. apear this message.
I can bake all elements separately but together in the same project throws this error.
I Update my driver and also update bakery with repository and dont worked.
My Card is rtx2060. Windows 10.

Thanks

 

Hey @guycalledfrank, Idk if there is a bug with Mono SH or not, but I figured it is worth mentioning. I was using Mono SH on my Oculus Quest 2 project and it brought everything to a screeching halt. I was averaging 16 fps with some areas not breaking the single digits. This is on a very simple indoor scene, mind you. I switched from Mono SH to just SH and it is now steady at 36 fps. Not the best, but at least playable. It is the same fps I am getting with baked directional normal maps and standard unity shader ( URP ).

 

I also switched back to SH from Mono SH because it produced horrible banding.

 

I had the banding issue at first too with Mono SH. I switched the texture compression to ETC2 and it solved that, but the performance hit remains. I might try switching to ASTC though.

Edit: If anybody is interested, I found the real culprit. It isn't Mono SH or Bakery at all that was causing the drop. It was because I enabled "depth texture" in the URP settings in order to use a screen space decal. It kills the framerate.

 

I have a issue that I was wondering if you could assist with. I got bakery in a humble bundle just over a year ago and today I realized that there were updates on the private github. I didn't know you needed the voucher code to get added to it, but the used voucher code won't show up for me anymore. I can prove that I have a seat and that I bought the bundle.

 

Did anybody experienced issues with baking skinned meshes with LOD Group ? It looks like LODs are not properly switched off and they cast shadows onto each other in seemingly random order. The issue is only with skinned meshes, normal ones even with LODs are perfectly fine.

LOD0


LOD1


LOD2

 

I'm having an issue baking an indoor scene with Bakery. (v1.9 used)

When baking the Lightmap, I’m getting a lot of banding in the texture. It’s really just poor quality all around even though my samples are at 64 and texels per unit at 20…

I’m using a GTX 1080 with RTX mode disabled.



Here's what my settings looks like:


Here's what my lightmap looks like, there's a lot of unused space for some reason... Not sure why most of the texture is unused... It looks like there's a square at the top right where no element can be mapped to for some reason.



I also get an error when baking:



Any idea how to solve that?

 

1. For high quality indoor scenes, you should generally use a Texel value of or around 100. You might also want to use Optix 7 or OpenImageDenoise (if your CPU supports that). And do decrease the Samples count - typical values are from 16 to 32.

• https://geom.io/bakery/wiki/index.php?title=Manual#Texels_per_unit
  
• https://geom.io/bakery/wiki/index.php?title=Manual#Denoiser

2. That much unused space is to be expected since both your minimum and maximum lightmap resolution is set to 4096 - which seems too large for your small scene. Try setting the minimum one to e.g. 1024.

3. Another thing you may want to try is to set the Settings mode to Experimental, use xatlas for Unwrapper and/or Atlas Packer and enable Post-packing + Hole filling.

• https://geom.io/bakery/wiki/index.php?title=Manual#Experimental_render_settings

 

Hey @guycalledfrank, do you know if RNM, SH, and Mono SH are compatible with the SRP Batcher? How about the Volume shader? According to the bakery manual it says that these modes are applied using MaterialPropertyBlock and reading the SRP Batcher documentation it says that Shaders using MaterialPropertyBlock are not compatible with SRP batching. But in unity, if I select the shadergraph for URP SH it says that it is compatible with SRP Batching, so it is a bit confusing. Can anybody verify the support?

 

I have the same issue, tried what Mauri suggested, almost nothing changed .

 

@danUnity @vmsgrg Not sure if this helps:

• https://geom.io/bakery/wiki/index.php?title=Troubleshooting#Denoiser_produces_grid-like_patterns

Which render pipeline do you guys use? Are all your lights in a reasonable intensity range?

Also, could this maybe apply to you?

• https://geom.io/bakery/wiki/index.p...id_project.2C_and_lightmaps_don.27t_look_good

 

The asset store update is planned, but due to the crazy world events and also working on the game, I couldn't find time to run aallll the tests I usually do before releasing anything to the store. So it is recommended to use the patcher in the meantime (hopefully it's automatic enough).

Correct. RTPreview doesn't have the same exposure as HDRP, so it'll look kinda differently. Reduce this when working with HDRP scenes:

I can see some very weird glitchy reflections all over the place here. Hard to see what is baked and what is not. Can you make a pure-diffuse screenshot?

Feels like objects don't have UV2:
https://geom.io/bakery/wiki/index.p...r_.22Can.27t_create_rasterizer_state.22_error

Really weird, the shader is almost the same, but
- Slightly simpler
- Uses 1 texture instead of 3
- L1 map is passed as standard "directional" map
- (thus batching works)

I wonder if the perf difference is somehow related to static batching actually working? Can you check if using MonoSH + disabling static batching will be as fast as full SH?

What is your render pipeline, btw?

Interesting, can you show comparison pics? Also what's your render pipeline + build platform? What format is used for L0 and L1 lightmaps (shown in preview if you select them)?
If it's Android, make sure to force ASTC: https://geom.io/bakery/wiki/index.p...id_project.2C_and_lightmaps_don.27t_look_good

Ah... so MonoSH perf is actually OK?

You should have some email from HB with the code. Please DM/email me if you have it or anything else.

Ah, interesting... can you send me a little test package with a scene/prefab with this LODGroup / models? I'll test it.

Looks like mobile texture compression again, so please check this: https://geom.io/bakery/wiki/index.p...id_project.2C_and_lightmaps_don.27t_look_good

Possibly there are some black faces that we can't see on the lightmap.
For the best possible packing, try this:



...well, exactly as Mauri said.

Interesting one. Is there a stack trace if you select it? Otherwise I'm not sure where it's coming from (from the UI?)...

Also, this, yes. Good catch.

RNM and SH: no (because of MaterialPropertyBlocks).
MonoSH: should work, because the L1 map is passed as a regular directional map.
Volumes: depends on the way you apply them. A "global" volume is applied using Shader.SetGlobalTexture, therefore not breaking batching. If you apply the volumes selectively using MaterialPropertyBlocks (like in my example_volumes_advanced), then it'll break batching for the affected objects. Technically you can use other ways of selectively applying volumes, e.g. in my SRP I sort volumes by distance and then objects by volumes, so I can draw object groups one by one, changing SetGlobalTexture in between. But I don't know how to do it in existing pipelines.

What is your lightmap texture format (if you select the asset)?

 

I believe so, yes. I'm trying to make a build now which has the same scene with different lighting modes / shaders in order to test the performance on the Quest 2 and decide which to go with. However, I am running into an issue which may be an actual bug.

My scenes were originally setup using prefabs and had the bakery prefab script on them. I created a brand new scene and brought in those same prefabs. I then upacked them completely, removed the prefab script, and rebuilt the lighting. After the rebuild, the meshes were all pointing to the new lightmaps. However, after pressing play, stopping, and checking the meshes again they have reverted to pointing to the old prefab's lightmaps.

I tried using the bakery utility to clear all the data and rebuilding again, but that did not help and ended with the same result.

Do you know what I need to do to unlink them?

Edit: For others who might run into the same issue, deleting the bakery prefab component itself is not enough. You also need to delete a generated child object with the name BakeryPrefabLightmapData. If would be nice if that was more clean. Perhaps a button on the prefab component that allows you delete that generated child so you are aware of it or something. Or even delete it whenever the prefab script is removed if possible.

 

Hey, thank you for this tool I just bought it. I've tried to find a way to change lightmaps during runtime but I didn't really find anything on this. Can anyone point me into the right direction?

All that I want to do is to generate and switch between two lightmaps kind of like switching between day & night (but not exactly).

 

It's quite complicated to do on your own but there is a tool on the store that does that and it integrates with Bakery. I haven't tried but as per the reviews, it works:
https://assetstore.unity.com/packages/tools/utilities/magic-lightmap-switcher-built-in-srp-196489

 

I attached a screen of how it looks like in the editor. Unity 2021.3, latest bakery, Android, URP, Linear color, Lightmap quality high, lightmap compressed as ASTC HDR 4x4, point light with 32 samples and legacy sampling disabled. Mono SH. Open Image Denoiser. 20 Texels per unit. Light probe mode L1 but there are no probes involved, its a baked prefab.

No banding in RT Preview or with SH.

 

Hi people

So I have set up a clean project + HDRP Core with unity 2021.3.11

I imported the Bakery from the package manager and then updated it to the latest patch through the invoice and github username.

Then I added the Bakery HDRP package support as well.

set my environment on static, clicked on render, and nothing!
it bakes the lightmap, I can see the textures and everything.

But the result is not visible in the scene
please see the image below.
the lightmaps are generated.
in the material setting, you can see that lightmapped data is loaded. but nothing is applied to either scene view or game view

can anyone assist me in solving this issue? (other than restarting unity, starting a clean project, and re-import all assets because I already have done these).

 

Hi, what do you mean by pure diffuse screenshot?

 

without any specular highlights or reflection probes.

 

EDIT:
Restarting my pc fixed this issue.




Heya, I get this error when trying to bake:


With these settings:


I can't find anything useful in the console about this issue.

My C drive has 200gb of free space, I'm not running out of ram and I don't think I'm running out of video memory either.

Any ideas?

 

I am having issues with lighting a chunk of my scene too far away from world origin...is there some limit to this? It appears that bounces do not function and I get some very black shadows until I move the chunk closer to 0,0,0.

I am working in meters in Maya so 1m will equal 1unit. 1 bakery direct light and 1 bakery skylight.

 

So, the Unity unwrapped is producing... bonkers... results, so I ticked 'xAtlas'. After over 24 hours of prepping to bake, I killed the process and come here for help. UnwrapCL.exe was using up like...0.6% of my CPU time, but some of the meshes were taking over FIFTEEN MINUTES to unwrap - what the hell's going on there? And if 15 mins is expected, but for some reason it's barely touching my CPU, can we pretty please have an option to fire off like a hundred unwraps at once? The meshes aren't particularly complex or odd, but it's SO slow, and on top of that, normally-importing meshes has become horribly slow.

Just to re-iterate; the unity unwrapper was producing atrocious results, almost splitting apart every polygon and leaving huge gaps between them. >_<

 

Well since you can delete the script before the object... well, added a more clear note to the docs: https://geom.io/bakery/wiki/index.php?title=Manual#Bakery_Lightmapped_Prefab

If all you want is to switch lightmaps, it's actually not that hard.

All scene lightmaps are stored in https://docs.unity3d.com/ScriptReference/LightmapSettings-lightmaps.html
Light probe colors are stored in https://docs.unity3d.com/ScriptReference/LightProbes-bakedProbes.html

You can create multiple versions of these arrays and just swap them.
E.g. you can bake multiple times with different lighting using a different Output Path, then cache array values somewhere and swap different versions via a script.

Reflection probe textures can be also swapped, if you set refprobe mode to custom.

If you want something more complicated or even smooth blending between lightmaps, then Magic Lightmap Switcher can be useful.

L0 and L1 maps have different compression. L1 are never HDR. Can you compare their compression please? (e.g. lightmapName_L1x.tga for SH vs lightmapName_L1.tga for MonoSH). If you can screenshot their asset inspectors, it's even better.

Probably because the lighting is too dark for HDRP camera/sky exposure, please check this: https://geom.io/bakery/wiki/index.php?title=Manual#Notes_on_HDRP.2FURP

Feels like a race condition when Unity locks the TGA file for reading while Bakery tries to write it.
Please try:
- Using the latest patch: https://geom.io/bakery/wiki/index.php?title=Github_access
- Using PNG or Asset format for masks:

Very interesting. [23, -132, -84] doesn't look like a very far distance that could affect numeric precision. I tested multiple thousand distances before the original release.

Are you on HDRP by any chance? (in case it's this issue: https://forum.unity.com/threads/bak...preview-released.536008/page-126#post-8432270 )

Also, if you have RTPreview, how does it look there?

Also... could it be that your sun is real-time, and is shining through some backface (some "ceiling" polygon above the cave), but it occludes the baked version of the sun?

Can you also send me some little test package/project where I could reproduce/debug it? (if it's not something I mentioned)

Yeah, I believe it's single-threaded. Not sure if Unity can run it for multiple assets at once.
Is it some super complex multi-million triangle mesh? These can freeze it for a long time (per-vertex bake might be a better solution).

 

The SH lightmap is named _LM0_L0 but in the bakery settings the light probe mode is set to L1. Its the same name after deleting the teture and rebaking. Not sure if it matters but as mentioned - I dont have any light probes in the scene.
I set the lightmap texture to ASTC HDR 4x4 via Android/iOS platform override.

 

[QUOTE="guycalledfrank, post: 8529116, member: 275716"Yeah, I believe it's single-threaded. Not sure if Unity can run it for multiple assets at once.
Is it some super complex multi-million triangle mesh? These can freeze it for a long time (per-vertex bake might be a better solution).[/QUOTE]

Nope. I have ~560 meshes in the scene that need lightmaps generating. In 24 hours, the process managed to hit about 240 of them; so 10 an hour, or averaging 6 minutes each. The longest I saw was a 15 minute mesh. They're all 32-bit meshes, not a single one will have over 65535 verts in them.

It does look like multiple instances of UnwrapCL.exe are running, too.

 

Has anyone seen this error before when clicking the Render button in Bakery? Is this something fixed from some of the patches mentioned in the documentation?



I'm on Unity 2020.3.8f1 and just downloaded the packages from the Asset Store. It was working perfectly previously, but just started not working in a different Unity scene.

I tried to see if there were any patches, but purchased it via the Humble Bundle and didn't keep the code (which apparently I can't view anymore on Humble Bundle). Could I send some screenshots from my purchase history and/or by my account email?

I can spend more time trying to figure out how I get to the error, but as you can see on the right image, it looks like Bakery crashes, and I have to restart Unity to get it back.

 

Hi,

are volumes supported in WebGL builds since they seem to require some kind of 3d textures?
Can there be more than one global volume per scene?
We have a mix of static and procedurally generated level environments - the levels themselves are not saved into scenes but instantiated from prefabs (one for the static stuff, several for instancing the rest of the level).
I would like to lighten the dynamically placed assets with irradiance coming from the static lightmap - thus utilizing bakery volumes.
What is the suggested way to deal with bakery volumes in this case?

 

I am building a VR game. The lightmaps look great on PC and in the editor. On the Quest 2 (Android) they look great for the most part, but I am seeing some white pixels that pop in and out (almost like the surface is sparkling). It only happens on certain parts of the texture so I am guessing it has something to do with the texture. You can see one of these spots in the screenshot below. Do you have any idea why the textures would have this issue on the Quest 2 and not on the PC? I'm using ASTC compression. I am wondering whether it is an Android issue or something specific to the Quest 2.

 

I've had issues like that with custom shaders that don't check for the final pixel color to be greater than zero. It then results in a NaN and makes random white or black pixels on some platforms.

 

Thanks for the tip. I am using URP with the URP lit shader. Nothing custom in this image.

 

Are your lightmaps using mipmaps? If they are, either disable mipmap generation for lightmaps or double the padding in the Bakery settings in the project settings.