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

Hey, I have an issue with the bitmask system. I'm using a directional light as sun, and want to simulate some ceiling lights of my factorz by an additional directional light, only affecting certain layers.
The latter I can achieve using bitmasks, BUT this second light is shadowed by the ceiling, Despite the ceiling being on a different layer!
Can you please tell me how to avoid my directional light being shadowed by elements that shouldn't? Thank you very much!

 

HDRP issues 01)

When i auto match this Spot Light with Cookie
i get this bakery setup with Cone Projection Mask.




Then i set Projection Mask to Cookie and the Cookie texture manually.
Is that the right way?

After this Bakery says
"Real- time light doesnt match lightmap:spot shape doesn t match.
What is a little confusing.

 

Sorry for flooding the forum.) But started to use Bakery productive.)

HDRP issues 02)

for all these lights who has set up "Use Color temperature"




the color yo get doesn´t match

Match lightmapped to real time or manually copying the color value to the bakery light does not work and it gives
different results.
Think the use color tepatature is not taken into account?'

 

Hi. Question for Quality of Life improvement.
Would it be possible to add the bakery Light parameters in the Light explorer?



That would give you a good overview and would improve the setup and control of the scene lighting a lot.

Found this in the manual.
https://docs.unity3d.com/Manual/LightExplorerExtension.html

most value:

You have all the seetings on one page whats really great for setup and overview,
In special you can fast compare with the complete setup with older bake iterations.

 

Hi,

I'm just a user as well, but the color temperature is basically nothing else than a "colored white". The result is just a color, and by looking at your screenshot, it seems that the correct color is copied to Bakery Point Light - a slightly reddish white. What if you change to the extremes? The resulting color should be way more blue or red -> is this color correctly copied to the bakery component?

 

Hi. The behaviour is little confusing.

One some lights it seems to take the color temparature into account like you said.

After auto conversion:

Original color + use color temparture -> Bakery color is little different (could be right) -> but displays the message color doesn´t match

on other lights
Original color + use color temparture -> converted Bakery color same like original color (must be wrong)-> but displays the message color doesn´t match


In common: for all lights with use color temparature.

Displays the message color doesn´t match. You can´t get rid of the message.
For now i have no gurantee as lighting artist that the measured light setup with color temparature are correctly converted/matched.

 

I am having issues syncing Bakery lightmaps over GIT. I followed the source control documentation.

So, my GIT is ignoring everything in Assets/Bakery and Assets/Editor/x64/Bakery, with the exception of:

• Bakery/ftLightmaps.cs
• Bakery/ftLightmapsStorage.cs
• Bakery/ftLocalStorage.cs
• Bakery/ftGlobalStorage.cs
• Bakery/BakeryProjectSettings.cs (on v1.9+)
• Editor/x64/Bakery/scripts/ftModelPostProcessor.cs
• Editor/x64/Bakery/scripts/ftSavedPadding2.cs (on v1.7+)

Now when I make a bake on my main machine, it turns out fine and looks great. I sync everything on GIT (Bakery Lightmaps, anything else that was tweaked like .metas and scene)

When I load it up on my second machine, none of the lightmaps are linked up in the scene.
The Lighting Data Asset has no lightmaps assigned to it.
Its not an issue with weird UV's, the lightmaps just aren't even there.

Any help would be great!

 

Does this work on a Nvidia Geforce GTX 1050 TI?

 

Yes.

 

yes, def!! Don't worry. Description says: Nvidia GPU (6xx or newer) and 64-bit Windows (7 or higher). You have 10xx

 

The tool itself works and it bakes fast but for some reason, it's making a huge mess, I can't get it to bake properly I get horrible black patches everywhere and lighting that makes no sense no matter the modes I use. Does anyone have any suggestions, I might try different Unity versions or maybe update my drivers. I'm using Unity 2020.1.3f1 (64-bit)

 

Hi. Did you tried the
Debug Tools
(by Mr F) ?

https://geom.io/bakery/wiki/index.php?title=Community_extensions

With this you get some more informations for lightmap and renderers when you select the storage.

 

Hi,
HDRP problem:
(1)According to real physics,such as the picture below.I made an outdoor daytime scene.I set directional light intensity to 120000,then clicked match button.and I set exposure of post processing to 16.Set exposure of HDRI sky to 16.Is that right?

(2)How Do I use Skylight in HDRP project？The match button of sky light is invalid, isn't it? Thank you.Is there a tutorial on hdrp?

(3)I used Bakery Real-Time Preview.How do I see the correct preview effect? because post-processing exposure is not related to real-time preview.

 

Hi there,

is it possible, to have one lightmap per prefab baked object?
At the moment the Prefab shares the same lightmap with the room, but I want seperate lightmaps for the interactive objects in the scene.



Thanks in advance.

 

Hello

I been using bakery for a scene, and now whenever I try to bake the lighting this happens, im using unity 2019.4.18f1 and URP and the lastest bakery version.

This also crashes unity.

 

Thanks for the link. I checked out the tools, and found that on my destination machine, the hidden storage object in the scene has a "missing" reference to the lightmap storage script. That script is definitely included in my project. On the source machine, that hidden scene storage looks how it should with lightmaps properly assigned.

 

Never mind, I update my drivers and it works perfectly, I'm impressed! 10/10

 

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

 

Not sure what's going on there/what's causing it as there is not enough info from the description/screenshots. Kinda looks like broken UVs. Can you send me any small test project to debug?

atomicjoe's answer is correct, most sunshaft effects depend on realtime shadowmap being available.

This is something on BetterLit HDRP side, not related to Bakery integration. I did some debugging on my own today and shared some thoughts with Jason.

Yes, BetterLit custom GI override seems broken in HDRP for non-normally-lightmapped objects.

On your comparison it doesn't look so? L1 is a bit flatter, but not darker.
If you mean light probe gizmos, then who knows. Real affected objects don't look this way.

Some legacy rendering methods seem to be unsupported in HDRP. For example, scripted camera rendering doesn't draw HDRP skybox, showing gray color instead. As Legacy probes are legacy for the exact reason of being too bound to in-engine rendering, thus being easy to break and hard to port to different pipelines, I just recommend using L1 or Volumes instead (Legacy is also crazy slow on HDRP for some reason).

If there are overlapping shadowmasked lights, "Stop and select" should help you locate them:



I don't have a visualization. Point lights are represented as spheres, spot lights as frustums. These shapes should fit on 4 non-overlapping layers.

For example, you can fit all these lights into a 4-channel shadowmask:






But if you make the circles larger, they'll overlap, and you can fit less:

 

Time to upgrade those L1 probes to L2 Frank!
Really, L1 will never be enough for fully baked light.
I'm still on built-in forward and don't plan to go anywhere near SRPs, so I'm still good with the legacy generation method, but we both know Unity will break the legacy generator at any given point in the future and screw us.

 

Bitmasks decide which lights affect which groups. However, they don't filter any shadowcasting objects. All objects with "cast shadows" enabled cast shadows on all other objects, whatever their groups are.
Bakery also casts shadows from backfaces, so even if the ceiling wouldn't cast a shadow, the floor still would.
Perhaps you can just disable shadows on the directional light (shadow samples = 0)?

Hmmm I think older HDRP versions didn't have the cookie option. So currently Bakery has two spotlight modes:

- Cookie: texture projection only, matches standard pipeline.
- Cone: parametric spotlight, matches HDRP/URP.

But there is not Cone*Cookie combo yet. Will add.

If you get the latest patch, it's now taken into account!

Huh, didn't realize it was extensible.
But it can be rather tricky, especially given I have very different settings for different light types.

I've added a little fix to it yesterday, can you check?

- Are the lightmap files synced?
- Any active console errors in the project?
- If you get my debug tools and click Bakery -> Debug select storage -> Show debug info, is the "maps" array filled?

Yes!

Should work on v1.9+.

Do this: https://geom.io/bakery/wiki/index.p..._use_Skylight_with_a_procedural_sky_shader.3F

Yeah, just try decreasing RTPreview's own exposure (quite a lot).

You can use Lightmap Groups for exactly this purpose: https://geom.io/bakery/wiki/index.php?title=Manual#Bakery_Lightmap_Group_Selector
Just use a unique group on each prefab.

Feels like xatlas crash (something it doesn't like about the geometry?). Try setting atlas packer and unwrapper to Default? https://geom.io/bakery/wiki/index.php?title=Manual#Atlas_Packer

If you have ftLightmapsStorage.cs in the project, your scene should reference it. This is not unique to Bakery; just any scene referencing a script should keep referencing it. If it doesn't, then there is something wrong with the sync process (maybe asset UID messed up or something).

Kinda h a r d
(also doesn't scale to Volumes; L1 were implemented as a stepping stone for volume implementation; original light probe system is a mess anyway)

 

Admittedly, I don't have a clue how to calculate this myself
The math involved in it is like alien language to me.

 

check this.
https://github.com/kayru/Probulator
after reading this
https://mynameismjp.wordpress.com/2...te-history-of-baked-lighting-representations/

It helps to decode the alien language for me.)

 

Wow! Thanks!
Seems super interesting!

 

Hello, when I set "Scale in Lightmap" of MeshRenderer to 2.
There some white "spots" on my lightmap, which make my scene looks weired on some corner.
I don't know why and how to fix it, any advice would be appreciated.

 

Use the clone stamp in Photoshop.
Ok, it's a joke, but sometimes this kind of hacks are the easier and quicker solution.

 

My lightmaps are black when I re-bake the lightmaps for ArchViz Pro 6.
RTX3060.
Thanks.
This is what it looks like before re-baking:


And this is what it looks like after re-baking.
I see only 2 lightmaps instead of 8, and both are 2 black:



The author of ArchViz Pro 6 uses Bakery as well, that's why I bought Bakery.

 

I remember this... and repaired it like so.

Try this setup for skylight



blue marked area lights , intensity 10



blue marked area light , intensity



my result. Bakery setup with 140 texels and L1 probes.
You can use less for beginning.



resulting Lightmaps with 140 TpU.
Don´t forget to rerender reflection probes after bake.

 

in version 2021.2 in hdrp it works realtime gi but bakery want enlightend enabled but enlightend is depraceted

 

Although this case may not be the one happened in real projects, I'm just curious, why increasing the emission's HDR Color intensity would make baked lightmap totally mess?
It seems when emission color exceed some particular value, the resulting lightmap would go wrong.
Here is the difference

 

And built-in Unity Lightmapper would work fine for each case of different HDR intensity
I think maybe the precision of the Bakery lightmap pixel is the point?

 

Yeah I've checked these before. There is another problem though: currently both SH lightmaps, L1 light probes and volumes hit almost the same code path, as they have similar per-sample data. Adding L2 means adding/maintaining exclusive code in a lot of places. It's also kinda cumbersome because currently lightmapper is optimized for working with a moderate amount of large maps and naively adding L2 support would generate a large amount (one per SH coefficient) of small maps, making it less efficient than it should ideally be. So currently it's more of an architectural problem. Given that the existing light probe system gives me the "please don't use me" vibe with its black-box API and given that putting L2 into volumes is impractical memory-wise, I wasn't sure if it's worth the effort.
Although certainly it could be an improvement for low-end platforms where volumes are not feasible.

Can be a firefly?
https://geom.io/bakery/wiki/index.p...oduces_scattered_bright_spots_.28fireflies.29
They can be caused not only by bright/tiny spots in the HDRI, but also by similarly bright and tiny emissive surfaces. If you have such lights implemented as emissive surfaces, I highly recommend using Light Meshes instead: https://geom.io/bakery/wiki/index.p...ces_between_Light_Mesh_and_emissive_materials

Also check if using a different denoiser (e.g. OpenImageDenoise) removes it.

Did you add Bakery lights?
https://geom.io/bakery/wiki/index.php?title=Manual#Quickstart
For this ArchVizPro scene I just added one white Skylight with 1.5 intensity and made sure that glass geometry has "cast shadows" disabled (I didn't even use any area lights, still pretty good).

I didn't test 2021.2 yet, as it's in beta. Do you mean you want to use "Combine with Enlighten real-time GI" option? Well yes... if they removed Enlighten, then it can't work.

Bakery computes GI by randomly casting rays from every surface point and sampling the surface at hit points. The chance of hitting an emissive object becomes smaller with distance, resulting in increased noise. When the emissive object is also very bright, then the noise is also bright / covers larger distances; eventually it becomes too bright and sparse for the denoiser to fix. Bakery also uses a sort of Radiosity instead of path-tracing. While it has some unique benefits, the way it works means there is a lower (noisier) chance of bouncing/reflecting an already very noisy image.
Use Light Meshes! https://geom.io/bakery/wiki/index.p...ces_between_Light_Mesh_and_emissive_materials
They are made specifically to alleviate these issues, forcing rays to sample their area directly, instead of relying on a random hit chance. Light meshes can be of any shape, brightness and range. Note though that placing very bright sources very close to geometry can result in an emissive-like situation where a small lit surface will become a prominent light source itself.

 

Hi,
I understand, but I'm not quite happy with that solution.
The thing is, I have a factory hall, where the sun shines through a roof with glasses, which results in beautiful shadows on the floor. Then there is the ceiling light as additional light source, which would be weird not to cast shadows in some occasions. Currently I'm relying on an additional realtime directional light for my purposes. Any chance that bitmasks will take care for shadowing elements only on their assigned layers in the near future?
End of project is start of October, so do you see a chance in your roadmap to add/fix this feature within August oder September?

 

Tried different denoiser and found OIDN could fix it.
Also tried 'Denoise' disabled and light spots disappeared, so I think maybe bright emissive surfaces is not the case?

Tried Light Mesh and it seems works fine for any intensity

 

I'm having some really weird issues where lighting when loading a scene additively looks completely different than what I get in the editor preview or if I load the scene normally. Is there anything special I need to do to make everything (lightmap, occlusion probes, light probes, and reflection probes) work properly with additive scenes? I want a total override to the scene people are in.

I'm calling SetActive but it seems like certain info is still being dropped as the scenes just don't look the same. 2020.3.14f1

 

Hi, Is there any way to fix these overlapping mesh artifacts? Like ground and these two overlapping rocks. AO is disabled with 0 intensity. Tried increasing Scale in lightmap but didn't help. Tried increasing things in Bakery settings but didn't help either. Any fix for this? Attaching my bakery settings as well [BUILDING FOR MOBILE].



SETTINGS:

 

Hey! I was wondering, if I want to remove Bakery from the project, is it enough to delete the "Bakery" and "BakeryLightmaps" folders?

Thanks

 

no. you need to delete this folder too: Editor/x64/Bakery

 

I think i already asked this but it still confuses me.
I have no idea of the correlation between texels per unit and scale in lightmap. It is infuriating to set.

Why isn't the Scale in Lightmap simply a multiplier of Texels per unit ?
That's the way Unity lightmapper works and it makes way more sense, (eventhough scale in lightmap is a terrible terminology.)
What if i want object A to have the double ratio of object B, then push up the overall quality by adjusting only the Texels per unit ?
What if i'd like a precise ratio on objects e.g 256 texels per unit ?

Actually it's just guessing work with the checker on and if you change the Texels per Unity, it ruins everything.
Objects may have very different Scale in Lightmap settings and still end up with the same ratio.

I'm at 20 texels per units, and i have crazy lightmap scale settings from 0.0001 to 100 for something like 1 texel per 10 meters to 1 texel per cm.

 

check adjust sample position

 

There is a switch to make this work more like the Unity lightmapper in PROJECT SETTINGS -> BAKERY -> ALTERNATIVE SCALE IN LIGHTMAP

 

Hello guys! We have a problem, I hope you can help us. We are using Unity 2019.4.0, and the latest version of Bakery (1.9), we have problems with some elements of the baking, as you can see in Image 1 and 2 it looks correct, but after uploading to gitlab, they look like image 3 and 4,
We are using Gitlab as version control and when we bake the scenes we preview them fine, but when we upload and download the project on another computer, the bakes always crash on the same items that we are baking on the PC and launching for Android and Settings iOSSS rendering.

 

https://geom.io/bakery/wiki/index.p...2Fother_version_control_system_with_Bakery.3F

 

Thanks alot, you saved me. Perfectly fixed. <3

 

Oh, i didn't update for a while and missed all the great new options.
THANKS ! And thanks to Mr F!

edit : erm, it seems to be buggy no ? It doesn't react at all like Unity behavior. I get completly different ratios with similar objects with the same settings.
Sometimes a scale*4 makes almost no difference. i'm confused

Tweaking the min lightmap resolution is changing the texel ratio. It's weird. The lightmapper should pick up the lightmap resolution that could handle the texel ration i want (until 4k)

 

Spoiler

By the way, the Optix denoiser v7 is badly corrupting the lightmaps on RTX3090 with RTX mode ON with the latest studio drivers (just checked) and latest Bakery version.
Setting the RTX mode OFF and using the Optix denoiser v7 crashes ftrace (unkown error on "rtBufferCreate" at CUDADevice.cpp)
Using Optix denoiser v6 and Open Image works fine though. (but Open Image is sloooooooow (but flawless) and Optix v6 makes some dithering patterns on gradients.)

 

Open Image denoiser is only using half of my CPU threads. Is that expected?

I mean, I have 12 real cores but 24 windows threads, and Open Image is only using 12 threads to denoise.
The thing is that all modern CPUs (since intel's Hyperthreading was invented) REALLY benefit from using 2 threads per each single core. So it's actually losing between 30% and 50% performance by using just 1 thread per core.
Using ALL the threads at once will choke the CPU though (and can crash windows sometimes), so ideally you should use 2 cores less than the total amount.

I know that in C++ you can either get the total amount of THREADS or the total amount of PHYSICAL CORES.
I guess the Open Image code is using the amount of physical cores instead of the virtual threads of the system.

In C#,

Code (CSharp):

1. System.Environment.ProcessorCount

actually gets the total THREADS of the system (twice the physical cores if hyperthreading or similar is available, or just one thread per core if it's not), so just instructing the Open Image denoiser to use:

Code (CSharp):

1. max(System.Environment.ProcessorCount - 2, 1)

should do the trick and use all the available threads in the system minus two to avoid choking the system.
At least that's how I usually do multi-threading stuff.

 

I'm not sure why a ceiling light should skip some shadow casters or even be a directional light? Directional lights are useful for things like the Sun, it's their main purpose (infinite distance, orthographic shadows). Ceiling lights are usually localized area lights (you can use a Light Mesh for that).

They have a kinda different purpose.

If you can send me some simplified scene (no need for the real scene, just something resembling it, e.g. made from primitives is OK) and a reference, I can try setting up this ceiling lighting for you, without using bitmaks/directionals.

Sounds like an artefact actually coming from the denoiser then? OptiX 6/7 seems less accurate after some driver patch. OptiX 5 should be still fine though (doesn't depend on the driver much).

Any pics? It can be different in different ways. But if it looks like extreme black&white, then it's caused by Unity being in directional lightmap mode and trying to render a non-directional scene. Make sure that all of your loaded scenes have the same directional mode (that is, all baked in Dominant Direction or all without it; other modes, like RNM/SH don't have this issue).

- Close Bakery window.
- Click Bakery -> Utilities -> Clear baked data -> Set "clear from scenes" to "clear all" -> Clear.
- Delete the editor-time folder (default path is Assets/Editor/x64/Bakery)
- Delete the runtime folder (default path is Assets/Bakery)

Yeah the relationship is kinda non-linear (almost exponential) in the original implementation. I just tweak it with Checker Preview enabled until it looks right.
But recently I also added this:

It should work in a more linear fashion, similar to the built-in behaviour.

Hmm are you sure? Can you check it with the default atlas packer? xatlas can additionally stretch objects to fill more atlas space. It would be great if you could send me some test package where "alternative scale" doesn't work predictably.

Yes, there is something weird after the new driver update:
https://twitter.com/guycalledfrank/status/1423741040108969987

Let's ask NV: https://forums.developer.nvidia.com/t/optix-denoiser-is-broken-after-recent-driver-updates/186076

Defaults are like this:



I didn't change it. So perhaps there is some inefficiency (or secret wisdom) in not using hyper-threading?

Maybe not, so let's try forcing it to the number of logical cores. Can you try the attached denoiser?
It will also print "Using X cores" to .denoiserlog.txt just to make sure it's the number you expect (should be 24 in your case).
In my case (6 physical cores, 12 with HP) I don't see much difference. Seems to be 16 sec vs 15 sec denoising a large volume.
Perhaps the way it works doesn't benefit from HP?

 

Mmm... I just tested it and it does say it uses 24 threads in the log, but it's not actually using them: it's actually using 12 threads instead. (checked the CPU usage and detailed per core usage in the task manager)
I put the results here for future references.

Benchmarks:
Ryzen 9 3900X @ 4Ghz OC (3200Mhz RAM)

Default: (12 threads from 24)
2 x 8k directional lightmaps: 73s
2 x 8k color lightmaps: 38s

 

Also, the times are exactly the same before and after changing the denoiser exe.