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

Any chance support for Multiple Importance Sampling of HDRIs will be added? We light our worlds with high-range HDRIs with the sun within the capture. Unfortunately this causes incredibly blotchy and noisy bakes, probably because it's sampling the HDRI uniformly.

Unity's lightmapper handles this case correctly, so this is really the only big downside of Bakery at the moment, for us.

 

Had exactly the same problem, it took me like 2 months to find out the reason of the noise. It always leaves the same artifacts no metter how your UV2 channels are set. It is caused by really bright values like the HDRI sun. Tonemapping HDRI a bit removes artifacts but the overall effect of the bake is not the same.



@sacb0y most likely you have the same problem, are you using HDRi map in Skylight?

 

Not sure what I changed, but now every time I try to bake, the process starts and then I get this error:

"Error Exporting Scene (Can't fit Tree (1) NaN NaN) - see console for details"

I can't tell what's wrong with the trees in question, as they've worked before.

 

+1 from my side.
Also losed a lot of bakes due to this.
Sun removal or manual crafted ibls for bake are not the way.)
The new Unity MIS implementation has issues too. I cannot get what they do.

However. In Blender it is solved perfectly since ages.
You could have a look in the Blender source code and copycatit.
It s part of the World settings. see Map Resolution who is set to 2048 per default in Blender which eliminates this problems.
Set to 0 to generate same problems like in the shot.



Here you can
Online browse of sources is available for:

• Standalone Repository
• Sources within Blender

go Sources within Blender and search for multiple importance or click here
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/?grep=multiple+importance

Also an actual work about advanced sampling
https://graphics.cg.uni-saarland.de/papers/konda-2019-siggraph-optimal-mis.pdf

and an old GPU based one
https://developer.nvidia.com/gpugem...ring/chapter-20-gpu-based-importance-sampling

 

Can happen if objects are hovering a bit above the table, but moving them slightly inside should fix it by triggering Bakery's inside/outside shape detection. Samples are pushed outside of areas surrounded by backfaces.
Additionally, take a look at bicubic filtering (shader tweaks).

Which ones? Texel resolution is a bit too low here, I recommend increasing it, otherwise denoiser will have a hard time telling the noise from the UV charts and can smudge them together a bit.

How do you want them visualized? It should draw a box gizmo when the volume is selected.

Hmmm works in my project (Unity 2020.1.14, HDRP 8.2.0, default settings apart from lowered HDRI intensity):



Maybe it has something to do with HDRP render settings?

Not sure, it should work. You can also try using the volume system instead of the probes (see example_volumes_shadowmask). It doesn't depend on the black-box nature of the occlusion probes system and should be more reliable. Occlusion probes in Unity are not readable or writable, so the only thing I could do with them is to call Unity's own lightmapper to generate them (without calculating the rest).
What Unity version are you on? Pre-2017 versions have more troubles with occlusion probes and shadowmask in general, because Unity didn't even have any API to set shadowmask channels for lights back then.

Very weird that it helped... can you confirm you get the same behaviour in the example_shadowmask scene on your version?

Sounds like you need mixed lighting (shadowmask or subtractive):
https://docs.unity3d.com/Manual/LightMode-Mixed.html
https://geom.io/bakery/wiki/index.php?title=Manual#Shadowmask

Yeah "enable baking" tells it if you want new lightmaps to be generated for the prefab (or leave it as is). All prefabs (even when it's off) will still participate it lighting computation, i.e. if you have pre-baked houses and put them on a terrain, set "enable baking" to OFF and render, all houses will affect lighting on the terrain, cast shadows, etc, but won't get their own lightmap generated/updated.
If you want to only bake a single prefab without even taking other prefabs into account, try disabling other prefabs' GameObjects or just having them in separate scenes (most reliable option).

Hmm no What light type are you using for them and what settings do they use?

I agree. But I didn't have time for it (yet).
Videos would be better for tutorials, but wiki is good when you want to search for something specific.

Sounds good. I'm using the same GPU, so yes, it will work

All objects you want to be lightmapped must be marked as "Lightmapped static" (or "Contribute GI" in newer versions).

Same lights, same settings. Different geometry? Possibly broken UV/normals?

Definitely a chance, I'm also interested in it. Currently I recommend against using the Sun in HDRIs. Having it in HDRI is also not useful if you want any mixed lighting:
https://geom.io/bakery/wiki/index.p...oduces_scattered_bright_spots_.28fireflies.29

You tree (1) object possibly has NaN UVs. Don't mark it as static or do generate UVs for it.

If you have any dynamic objects in the scene, you want mixed lighting, and you want mixed lighting, you don't want the double sun, so removal is the only correct way IMHO.

MIS is still a good idea though, not for the Sun specifically, but for getting better contrast in sky lighting.

 

This is what is happening:
Both scenes share 90% of the assets, except for some props on the rooms.



And this is how it looks in the other floor. (which is the correct ilumination)

I need some help on how to fix this please.

 

@guycalledfrank

I have been using Unity progressive gpu to bake, I have an rtx 2080, however it switches to cpu after a while as I am guessing the gpu runs out of memory baking my large scene, this switching back to the gpu results in slowing down my bake tremendously, does bakery have the same limitation with GPU baking? thanks

 

Hello,

i did a little reserarch what´s behind the new hdrp light setup.
Like i explained in the post before, if you want to convert a HDRP light setup to BAKERY it not works by simply converting the values because high exposure and light settings produce strange bake artifacts in bakery.
You have to setup according to your FAQ lower values.

However here some information whats the logic behind from Unity side.
(copied video url at current time did not work and screesnhots.)

setup sky with these values

This is all done to work with real physical values and to match real physical camera. values





Check the videos from
pydonzallaz | Pierre Yves Donzallaz
Some nice stuff.

It woulkd be great if you could work work with the same values for
Exposure Range (-3 to 16),
Light strenght (Lumen, Nits, EV) and
Physical Camera (Iso, Aperture, Sensitivity)

in a Bakery setup in

Bakery Lights
and
Bakery Sky.

Thats not possible for now and you have to redo all light setups and also more time consuming the camera and post process settings.

 

I tried baking the lights again, but the scene shared 90% of the same assets, it can't be the UVs, but i got this error message now.





How do i fix this?

 

Hi, how can I set Bakery Volume and what type of light is currently support? Is there any step by step explanation? Thanks in advanced.

 

Did you checked this?
https://geom.io/bakery/wiki/index.php?title=Troubleshooting

I get an “Out of memory” error
This means rendering needed more video memory from your GPU than it has available.

First, try closing any other graphics-intensive programs (browsers too).

If the problem persists, the most likely reason is that the resolution you selected is unreasonably high for the given scene. Resolution is defined by Texels per Unit (this section also has a list of reference values) or set explicitly in Lightmap Groups. Reducing it will help. You can always selectively use high resolution for important objects via Scale in Lightmap.

If you have terrains in your scene, make sure Terrain optimization is enabled.

If you have a very high amount of painted trees on your terrain, try disabling the Export terrain trees option.

 

Well i didn't had anything else open while batching the lights. One thing i noticed is baking lights on other scenes which are 90% identical takes 30 minutes, while trying to bake the lights in the problematic scene takes 2-3 hours (when it works). im gonna try lower the resolution for this one to see if it works. Im not using terrain or trees.

 

Hi. I've seen xatlas dependency in Bakery. Is it possible to generate not only final atlas, but also specific (or all) mesh lightmap UVs? Default unity lightmap UV generator generates really sad UVs.

NVM. Found your wrapper. Lightmap count decreased twice and with more consistent texel density. Many thanks for you tool. It is multipurpose.

 

Hey, I get this error where bakery says my cpu does not suppport OpenImageDenoiser, and asks me to run "Detect Optimal Settings" I do this, and no denoiser is found. I'm asked to update gpu drivers, which I do, but that does not change anything. I've used bakery before, so this error message is new. Any suggestions to how this can be fixed?

I tested unitys lightmapper, and the denoiser seems to work fine there.

Thanks a lot!
Kjetil

 

Bakery seems to not pay attention to this setting, where an object can contribute to global illumination but not be lightmapped itself. It would be extremely valueable to have this option as some objects in my scene don't need to be lightmapped but absolutely need to cast shadows (like say for example a mirror ball, small objects, or a car)

(also has there been an update for light temperature support yet?)

 

Still really weird texel density. Definetely not regular and definetely not 8px per unit.And same mesh inside XAtlas Viewer. Perfect fit to 8px.

 

We're using HDRIs for two reasons:
- We don't use mixed lighting. We can't afford it on mobile. All dynamic objects are lit with probes.
- HDRIs w/ suns produce a much better color gradient around shadows cast by the sun, especially when the HDRI has a heavily scattered sunlight. The colored scattering of the atmosphere around the sun is surprisingly bright, especially at dawn and dusk, and can drastically change the feeling of a scene, so it's important to capture accurately.

We're trying to get a really nice "golden hour" effect.

 

Another update on the problem with Bakery not finding any valid denoisers. So, if I do a fresh reinstall, and then start baking I get a question if I Bakery should find optimal settings. If I let Bakery do this, it will not find any supported denoisers. If I skip this step, then it will render lightmaps fine. The diagnostic step fails. So, I wonder what's the best fix for this. I have reinstalled drivers, and have the latest version of Bakery, and I have reinstalled Bakery multiple times.

 

I'm having an issue where if I reuse the same model in multiple scenes, when I bake the lighting for one scene it messes up the lightmapping for that model in the other scenes.

 

I think that's because it changes the uvs to fit to that specific lightmap. You can disable this in the settings.

 

Ah yeah I think you're right. Thanks!

 

Hard to say anything from the images alone. Could be caused by incorrect UVs (likely, as both images look wrong to me). Can take a look if you can send me a unitypackage/project.

Bakery never switches to CPU (there is no CPU baking logic). VRAM can be a limitation, but Bakery
- Generally uses less VRAM.
- Can unload the scene from the editor, thus freeing some additional VRAM.

Currently you can't use the exact values, but it should be generally possible when using a different unit origin/scale... e.g. taking overcast as 1 and bright sun as 120 instead of 1000 and 120000.
I can add some global offset/scale option for light brightness, I guess.

https://geom.io/bakery/wiki/index.php?title=Troubleshooting#I_get_a_.22Launch_timeout.22_error

You can check the docs: https://geom.io/bakery/wiki/index.php?title=Manual#Bakery_Volume
And the example scenes (example_volume_simple, example_volume_shadowmask, example_volume_advanced).
Volumes support all light types.

Yes, you can set xatlas as both Unwrapper (what you want) and Atlas Packer separately:
https://geom.io/bakery/wiki/index.php?title=Manual#Unwrapper
As Unwrapper, xatlas can generate better UVs for meshes, but it's slower (sometimes significantly), so I disabled it by default.

Sounds like either:
- You didn't correctly upgrade (not all files were copied): https://geom.io/bakery/wiki/index.php?title=Manual#Upgrading_Bakery
- Possibly related to Bakery folders moved to different subfolders after import, although it normally shouldn't cause a problem.
Most CPUs can run OpenImageDenoise, so there is a 99% chance of it just not finding the executable.

Fresh project, freshly imported package? Or the original project? I wonder if you moved the folder and somehow ended up with two different copies of the package?

Yeah, this particular option is not respected, because it didn't exist in older Unity version (which are still supported). But the same thing can be achieved differently: https://geom.io/bakery/wiki/index.p....2FGI_without_having_a_lightmap_on_its_own.3F

... not yet...

Hmmm. I wonder if in xatlas viewer it uses a non-square UV layout? With Bakery it can get a bit stretchy with xatlas due to it having to fit into a square.
Can you send me this mesh/scene and the viewer you use? I'm eager to compare it myself, maybe there is something I'm missing.

https://geom.io/bakery/wiki/index.p..._in_one_scene_breaks_its_UVs_in_another_scene

 

Hello, I been having some issues with the Cutoff, I'm using URP and some costume shaders, after seeing the manual still, haven't manage to solve the issue. The shadows of the objects with cutoff are square. Any ideas?

 

Having a nightmare with Unity GPU lightmapper constantly switching to CPU even for fairly smalls scenes just using pro builder built layouts as a test for it using a rtx 3090.
Googled about and found Bakery just now. Eager to try but basically my question is does this suffer the same issues as the Unity inbuilt mapper?

Help Appreciated.

 

@guycalledfrank thanks for the help.

 

Hi Frank!
I use URP and Bakery in subtractive mode.
I used the BakeryURP shaders and set the directional mode to RNM then SH, the baking works fine in both cases but the shadows cast from non-static elements don't work. Do RNM and SH modes not take into account "Realtime shadow color" in subtrative mode?

 

Hi, I get strange shadows when using Bakery Point Light (see attached screenshot). I manage to get smooth lightmaps by increasing "Texels per unit" when using Bakery Sky Light only. But adding Bakery Point Light (behind the sphere) to the scene produces strange "cell shaded" shadows. Is this correct behavior? I would expect smooth shadows, like when rendering using Mantra in Houdini. Unity 2019.4.13f1, latest Bakery version. Thanks for checking!

P.S. Ok, managed to get it smooth by cranking samples to like 512 for the Spot Light. Now it somewhat smooth. But is it expected behavior to get smooth shadows by heavily increasing samples?

 

I leave this here.
There a new version of the HDRP Lit Shadergraph with Keywords in this branch

https://github.com/RemyUnity/SG-HDRP-Lit/tree/keywords

Would be nice to have an HDRP Lit Shadergraph with all Bakery Directionals someday where you can autoconvert the HDRP Lit to the Shadergraph version.

I started with it but i have less time next weeks.

 

hi there is a small problem with me whenever i tried to bake the light with bakery this weird artifacts appear around objects. any solution to this will be great help. i have attached the pics kindly see them

 

Hello,

I'm running into an issue, and not entirely sure where to start looking for a fix. In the attached scene screenshot, the floor is made up of a 3x3 grid of meshes. The left most column is a lot darker than the rest, as though the center lights are stopping before reaching them. The left column is also not baking any light from the corner lights (what's shown is the realtime portion).

If anyone could point me in a direction of what could be wrong, it would be much appreciated.

Thanks!

 

Sure. I've tested with custom XAtlas bindings. I suppose main reason for bad unwrapping is a packOptions.blockAlign set to true. It's producing most of stretching and inconsistency. Probably need to expose most options of XAtlas packer to Bakery window for best results.

 

Hello!

We've been thinking about buying Bakery, since the lightmapper present in HDRP doesn't really satisfy us.
Just one question though, is it compatible with HDRP 7.1.8? I've seen a lot of people use HDRP with Bakery, but I wasn't able to find anywhere in the manual as to which versions it supports.

Cheers

 

okay i just wanted to report this matter.. i was getting constantly unknown error 1073740791

and some members were reporting such an error.. then i discovered the root cause for it.. my antivirus..
i use avast and it has active protection shields.. for some reason it react against Bakery when trying to bake maps.. adding project folder in exception list solved the issue..

 

Sounds like the shader is using non-standard name for the opacity map. Can you show how alpha is computed in the graph?

Well it definitely doesn't fall back to CPU.

URP graphs have very hacky implementation (because of how URP is designed; there are some notes explaining how they work), and it indeed doesn't mix with subtractive shadows. Here is the latest revision of the URP shader package, it includes BakeryURPSHGraph_Subtractive.shadergraph and BakeryURPSHSpecGraph_Subtractive.shadergraph. These should give you both SH and subtractive shadows.
https://drive.google.com/file/d/14gKWpEl_adF0euOMHLbGBcF7Fqm310Jb/view?usp=sharing

Yeah, it's just you have VERY high "shadow spread" and relatively low sample count. Either reduce the spread or increase the samples. Basically for point lights each sample is a separate sharp shadow. When you blend many of them, they converge into one soft shadow.

Finally! I tried keywords in shadergraphs, but they seemed to be broken. That's why I still have many separate shaders instead for different features.

Most likely caused by using OptiX 6 or 7. Check this: https://geom.io/bakery/wiki/index.p...oduces_bright_edges_around_geometry.2Fshadows

Weird. Are these tiles copied directly in Unity? Do they have lightmapping UVs? Can take a direct look if you can send me a unitypackage with these tiles (no need for other objects or textures, etc).

Looks uniform to me, what texels per unit value did you use?



This is 5.
I always set blockAlign to true, since Unity uses block compression for lightmaps, so it's a good idea.
Anyway, updated xatlasLib to make blockAlign configurable:
https://github.com/guycalledfrank/bakery-csharp/commit/19caf9a8cdfacef53be16c2abb63d4dab31334d3
You can try setting last xatlasPack argument to false if you want to compare without it (used in ftBuildGraphics.cs and xatlas.cs by default).

Last version was tested with 8.2.0. Baking itself will work anyway, but I'm not 100% sure about shader graphs' backwards compatibility (but they're only needed if you want to try RNM/SH/Volumes/baked specular).

Thanks for noticing! Seems like it's not the first time: https://twitter.com/HarryAlisavakis/status/1331630028665348096
All exes/dlls are clean (according to all antiviruses VirusTotal lists), it just seems like Avast hates any new exes that are executed... indirectly (i.e. via a script)? Not sure.
Added to the docs, just in case: https://geom.io/bakery/wiki/index.p...g#Baking_any_scene_crashes_with_unknown_error

 

Hi! I have a problem with painted terrain trees. They don't receive any light or shadows (2), but cast shadows on a terrain.
I use a Speedtree, it's baking good when i use it as an ordinary static mesh (1). The problem is apperiang only with painted terrain trees.

 

Hi, It is really a amazing tool! I have bake the scene and get a great result. However for some reasons, we don't want to put the tool in the dev branch ,which means when artists bake the textures, all the bake data need to be transferred. I have view some scripts and found that bakery actually doesn't use LightData. It seems a little bit different with Unity's original workflow. And I actually met trouble to transfer baked data between the meshes. Even when I set the lightmapUV and index, it still not correct. Is there any suggestion?

 

Basic questions:

Is it necessary to use bakery if the scene will use real-time raytracing?
Is it possible to mix both global illumination solutions?
Does it help to ease calculations somehow?

 

I started getting this error.
ftrace error: can't decompress UVGBuffer position (5091)


I've tried removing Bakery settings, removing Bakery completely, clear Unity asset cache and then redownload and import Bakery, putting GI Vram optimization to off, decresed texel count to 5, I even removed all game objects from the scene leaving just a plane, updated Unity to 2020.2.1f1 but I still got this error. I then created an empty project and imported just Bakery to it, added a plane and a cube and lightmapping works so it must be something with the other project, right?

What could be causing this and how to fix it? I'm using GeForce GTX 1060 6 GB and I've got 32 GB of RAM.

 

Painted terrain trees only receive lighting from light probes (that's how Unity decided it). So the question is: do you have light probes around this area? How are they positioned?

Thanks! Lighting data asset is only used to store light/reflection probe data. Everything else is stored on an invisible object called "!ftraceLightmaps" (in a ftLightmapsStorage script). It works the same way as described in this article: https://support.unity3d.com/hc/en-us/articles/206869046-Using-external-lightmaps-in-Unity-5-0

Key scripts involved are listed here: https://geom.io/bakery/wiki/index.p..._who_doesn.E2.80.99t_have_Bakery_installed.3F

Additionally, Bakery can postprocess mesh UVs. This is only done on models with "generate lightmap UVs" checkbox AND if "adjust UV padding" is enabled in Bakery main window. You can disable it (set to "remove adjustments") or follow these guidelines: https://geom.io/bakery/wiki/index.p...2Fother_version_control_system_with_Bakery.3F

Not necessary. Depends on which effects you use real-time raytracing for and if you're OK to sacrifice performance for them. If you already have real-time GI and shadows and happy with their performance and quality, then it should be enough.

I didn't try. You can check it with the built-in lightmapper. Bakery's lightmaps will be used the same way as built-in lightmaps.

Well, sampling one texture is usually faster than intersecting many rays with lots of triangles and trying to denoise the result in real-time.

Can you check if it's related to:
- Possibly low disk space on the drive where the temporary folder is located?
- Some odd characters in scene/project/LMGroup name?

 

There's more than 500 GB of disk space available on the drive.
I've not created or changed scene/project names. It's been working very nicely. By LMGroup names you mean manually defined lightmap groups? If that is the case I've not defined any groups.

 

I restored my project from backup which was for Unity 2020.1.16f1 and baking works now without errors. But I noticed that I have Bakery version 1.71 in that project.



Problematic project is using Bakery 1.8 and Unity 2020.2.1f1.


I created a fresh new project with Unity 2020.1.16f1 and imported just latest Bakery. I opened example_volumes_advanced scene and tried baking and I got errors:



In play mode it seems lighting was not baked.

 

Thanks for reply and it helps me step further a lot. I have tested and found Unity lighting data asset actually manage more. It also records the mapping of lightmapInfo and mesh info after baking the scene. Based on my test, I assume that the data is processed and saved to the Unity combined mesh when building. For Bakery's solution, there has a pre process by script when loading scene at runtime.(What do you think about this?) I believe I just need to evaluate the performance things, and I also think Unity's workflow is almost impossible to hake without source code.

 

I checked all the objects in the scene and I found out that there was a prefab with a "ä" character in the name of it. Is this a Bakery limitation? If so could you consider adding support for those (unicode?) characters too?

 

Bakery was not (yet) tested on 2020.2. As noted in the asset store description, the latest tested version is 2020.1.14 (it was the latest version just a month ago).
I'll check 2020.2 soon (next year already...).

Correct, lightmapID/scaleOffset renderer mapping is stored in the lighting data asset when using built-in lightmappers and stored in the preprocessing script when using Bakery. I don't know any reasonable way to patch the lighting data asset, so it was the only option. Performance-wise it shouldn't be terrible (only loops over renderers once on scene load).

Hmm, does it work if you rename it? Object names shouldn't be a problem at all. Also, after the error, can you check the last lines in .ftracelog.txt? It should at least clarify which file it tried to access.

 

Well I'm not

Well, I'm not sure if it made any difference. I did rename those objects but I also tried disabling some of my antivirus protection (Comodo) and Bakery seems to be working better. I did notice that I am using a version that has not been tested with Bakery, but all of this may be the sum of many things. I inspected the .ftracelog.txt but it is a very long log file, so I'm still looking at it. But anyways lightmap baking seems to work now!

 

Just a few lines in the end should tell the details.

Oh, and happy new year, everyone!

 

Not sure if its related to 2020.2 but in my small scene tests it worked fine but in my large scene it just says Exporting scene - preparing for a long time. This happens in both baking or with the realtime preview button. Maybe its fine and its just doing alot of stuff, but its really annoying because the "exporting scene - preparing window" is in the middle of my screen and "always on top" of everything. I even tried to have unity on my second screen but when i click that the stupid "exporting scene - preparing" pops up in the center of my primary monitor again. Because of that, I havn't run it for very long so I can't say if its fine and just taking a long time, or if there is actually an issue. While this is happening on the Unity Editor itself there is a progress bar saying "Hold on ( busy for xxxxx)..." and text saying its running EditorApplication.update.

 

Possibly related to xatlas, try disabling it?
https://geom.io/bakery/wiki/index.p...rting_scene_-_preparing.22_is_taking_too_long

Yup, it's annoying. I've finally fixed it yesterday There is a patch on github: https://geom.io/bakery/wiki/index.php?title=Github_access

The window is still on top during asynchronous tasks (baking), when you can properly minimize it, but not on top during synchronous ones (scene export). I didn't want to make it not-on-top all the time, because often I would not notice the window.

 

dont think its related to x atlas, when i tried by setting the atlas packer to default and it still takes a long time ( thats the setting where you need to switch to experimental mode right ? )
I've never left it on for more than i dunno 10 or 15 minutes though, how long would an "exporting scene" normally be expected to take in a sizable scene ?
ok i'll try out the patch thanks.

 

I'd say 1-2 minutes maximum. Possibly just lots of lightmaps to generate? If you enable Checker Preview, it'll print the lightmap count to console.