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

Awesome, wasn't aware of this - thank you!

 

@atomicjoe are you aware which shader should be used? Doesn't seem to be clear from the supplied shaders:

 

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

 

@atomicjoe thanks for the reference but still not completely clear to me for MonoSH - I'm guessing BakeryURPSHGraph but not sure. I'll stick with my dominant directional for now

 

Hi Mr F,

Do you have any idea why lightbakes might be causing different results with different lightbakes?
I have the same exact setup but whenever I bake I get different results.
Like when the issue occurred, area A, B and C looked weird. I did a rebake and area A looked fine, but B and C look wrong (like the shadow spreads looked incorrect).

I gave the file to somebody else and the bake the got was looking normally.

Any idea what could be causing this? Cheers

 

I have the same question, I'm trying to find the correct shader, but it is working with the URPDirSpec, I really don't know if is working correctly.

 

Still seeing Bakery (or rather XAtlas) create overlapping UVs when baking separate Sectors (with "Only increase padding" enabled).

 

Did you update it through GitHub? That’s weird it’s not showing up for you.

 

Bakery worked the first couple of times i tested it, now whenever i try to render, its stuck in a continuous import loop, just reimporting prefabs from the same dir over and over again.

Any ideas?

Edit:

Okay, it finally completed. Unusually long though.

 

Yes updated via GitHub. Should we expect to see a different shader not in the list?

 

Hi, is it possible to bake this part of the lighting (shadow) for a prefab?
I have the indirect lighting baked to the prefab and it works great but would like to include the casted shadow as part of the prefab.

The prefab is just the cube.

Thanks

 

You'll have to do a full lighting render for that. Check the manual.

 

That only works if the "floor" quad is part of the prefab as well right?

When I tried the full lighting the shadow was baked as part of the floor quad. So if I disable the prefab the shadow casted is still there.

Basically I want to be bake the full shadow for each prefab so I can place it on different tiles, so I can't include the floor with the prefab.

 

Ok you cant bake the shadow and still be able to move it around.
But you could make a prefab with a piece of completely white floor attached to it, render the prefab with the shadow casting on it, and then assign a multiplicate blend shader to the floor material in your prefab, this way the prefab floor chunk would darken anything that it goes over (like other floor tiles), but you would need to make a custom shader for that or find something like that on the store.

This is how old school isometric games made 3d tiles with shadows that could be placed over different tiles.

 

I am getting such strange colored spots, and there are also strange black spots on the ceiling. Texels set to 200. Area light windows with high samples
https://imgur.com/a/ZxWq8oG

 

Looks like fireflies to me:
https://geom.io/bakery/wiki/index.p...oduces_scattered_bright_spots_.28fireflies.29

Try:
- enabling the denoiser and fix bright edges

- replace any small very bright emissive surface (like bulbs) with Bakery mesh lights

- increase the lightmap's texel render size

if that doesn't fix it, use point lights instead of mesh lights.

 

I have mesh light, after changing to point light it looks like this. (fix bright edges make things worse)
https://imgur.com/a/cJ89VP9

 

Have you tried to remove the compression to the light maps and set it to RGBA32?

 

yes, lightmaps are uncompressed
I don't know what's going on because there is nothing to improve at all, strange colored stains and leaks. I've already burned various scenes before and this is the first time that there are such bugs

 

I tried up to 200 texels, it doesn't affect anything.
But there is a very interesting situation, I transferred to a new project from the oldest I have very old bakery and there is no problem with that (also denoise does not work)
https://imgur.com/a/bwQMMEn
In the newest bakery, there is always no color with light mesh (along with these strange errors)

 

Try higher scale-in-lightmap values (e.g. 100 instead of 2).
Bakery's original interpretation of this value is not exactly linear. If you update via the patcher or github, there is this little option:



...which makes it more consistent and similar to the built-in behaviour.

Did you try it without the "terrain optimization"?

Possibly it's trying to compile all variants of Bakery shader? Do you use it in your scenes? I wonder if removing it will reduce build sizes.

Not sure then... possibly some xatlas bug. If you can send any small test project, I'll try to see if there is some mesh export issue or submit a bug to xatlas dev.

Yeah, totally. That what lightmap groups are for: https://geom.io/bakery/wiki/index.php?title=Manual#Bakery_Lightmap_Group_Selector

You'll need to also use culling mask / layers to exclude the full-lighting objects from the real-time light influence though.

As Joe said, there is BakeryDirSpec.shadersubgraph, you can just add it as a node in any other graph and add on top as emissive, like this:

Does it LOOK normal though (in case it's just frame debugger bug)?
How do you load your scene at runtime? If you use async loading, please try calling ftLightmaps.RefreshFull() after the scene is fully loaded.

Yeah, it seems to be an issue in case Unity is installed to Program Files. Usually you don't need special permissions if Unity is in some non-system folder.

Yeah, you can currently try it via the patcher / github, I'll update the store version later.

I was going to!

No

 

We will never forgive you for putting twitter before us!

 

I don't have an URP shader for MonoSH just yet... but it's coming.

I guess you mean area lights (Light Meshes). Their sample distribution is randomized on every run. If you increase the Samples Far value, the difference between bakes will be minimal.

Not really
MonoSH maps are applied as directional maps, but without a proper MonoSH shader, the results will be off.

Check this: https://geom.io/bakery/wiki/index.p...rting_scene_-_preparing.22_is_taking_too_long

Reunwrapping the models can be long, but only happens once for the chosen resolution, and it's optional anyway, you can turn it off.

Exactly what I would suggest

It's texture compression.
Setting texture compression to none on lightmap assets will fix it completely:



...but the memory usage will be higher of course.

You can also try baking with Backface GI = 1, as it'll prevent texels inside walls from being pitch black, making it friendlier to compression algorithms.

Are you sure? Did you check the assets? Can you make an inspector screenshot?
Bakery always compresses lightmaps by default.
New patched versions also have this option:

What do you mean by "no color with light mesh"?

 

Sorry It's just quick to post on twitter, and here I would properly answer everyone first before posting about something new.

 

Yes, I am sure, lightmaps certainly do not have compression, the first time I have such errors (and I have burned in bakery for over 2 years)
If you look at the pictures, you can see colors from global ilumination indoors in the older version. The progressive unity version of cpu burns similarly, in the newer version bakery usually burns white

 

Just kidding! LOL

 

Unity Hub installs Unity versions to Program Files so I assume it'll be an issue for most people because of that.

 

So I'm trying to automate the whole baking process but I keep running into issue after issue, mainly because I don't really know how much of this works behind the scenes.

Anyway, the issue I'm running into seems to stem from the fact the scene is reloaded when bakes are performed, so simply looping through Sectors won't work as it'll lose the hierarchy each bake. I've managed to work around that by blindly using child numbers and looping on that, but the issue I'm having now is that the unwrapper seems to unwrap everything each time I bake as if it's not saving them for some reason. I don't mind this as a one-off, but it's using XAtlas so it's taking like 12 hours for each bake.

Are there any caveats when baking using scripts to ensure this works properly? The way I'm currently doing it is I set Padding Adjustment ON and do a full bake of the whole world (this is for the sake of all objects having good padding and baking the lightprobes). I then turn off all the locations and loop through the Bakery sectors one by one (with Padding Adjust OFF), turning on only the sector in question and setting the sector via:

storage.renderSettingsSector = GameObject.Find("Polyworld Zones").transform.GetChild(i).gameObject.GetComponent<BakerySector>();

Due to references getting lost, I have the following immediately before each bake:

LoadBakerySettings();

And that function just consists of:

    static ftRenderLightmap bakery;

    static ftLightmapsStorage storage;



   static void LoadBakerySettings(bool quickBake = false)

    {

        bakery = ftRenderLightmap.instance;

        storage = ftRenderLightmap.FindRenderSettingsStorage();

        bakery.LoadRenderSettings();



        if (quickBake)

        {

            storage.renderSettingsUnwrapUVs = true;

            storage.renderSettingsForceDisableUnwrapUVs = false;

            storage.renderSettingsDenoise = false;

            storage.renderSettingsGISamples = 16;

            storage.renderSettingsSampleDiv = 4;

            storage.renderSettingsSector = null;

        }

        else

        {

            storage.renderSettingsUnwrapUVs = false;

            storage.renderSettingsForceDisableUnwrapUVs = false;

            storage.renderSettingsDenoise = true;

            storage.renderSettingsGISamples = 64;

            storage.renderSettingsSampleDiv = 1;

        }

    }

So yeah... what am I missing? Why does it keep unwrapping the UVs for everything each time I do the initial full bake?

EDIT: I set Adjust UV Padding to false in the config in the script now to get it to just leave UVs alone for now and I immediately get a "Adjusting UV padding for (blah)" so it's clearly still doing it, despite being set to false (via "renderSettingsUnwrapUVs = false"). So yeah, not sure what I'm supposed to be doing here but it's not working as I'd expect.

 

You have to get the storage reference, modify it and then save it with bakery.SaveRenderSettings() LoadRenderSettings(), and save the scene so that it stores your config in the scene, because Bakery will reload the scene no matter what.
You can make a copy of the original render settings before modifying them using ftLightmapsStorage.CopySettings and then restore the settings once the batch rendering is done. (you'll have to use SaveRenderSettings LoadRenderSettings() and save the scene to make them stick)
I have done my own batcher and I was having issues with that too.

 

Wow. Did it happen after a specific update? Do you have RTPreview, can you check how it looks there?

Ah, damn... makes sense. I just avoid using the hub at all.

Are you sure it's actually unwrapping and not just packing the atlas? Did you actually set Unwrapper to xatlas? Or is unwrapper default? Or do you have Hole Filling enabled, maybe it makes the atlas packer slow on your scene?
Personally my favourite perf/quality combo is default unwrapper + xatlas packer + hole filling, but when I want to iterate faster, I do the same without the hole filling.

I think you updated the storage but didn't make Bakery reload the settings from the storage. Try calling bakery.LoadRenderSettings() after any changes to the storage.

No, it's the other way around
LoadRenderSettings() makes Bakery load from the storage,
SaveRenderSettings() makes it save current settings (as in UI) to the storage.

 

Oh, crap, yeah, I meant apply the settings using LoadSettings and then saving the scene to make it stick.
I told you I had problems with that
I made it work but it was a pain.

 

"Wow. Did it happen after a specific update? Do you have RTPreview, can you check how it looks there?"

Rather not from any specific version, out of desperation I installed the oldest one I have and there are no these bugs, from 1.9(1.9 does less errors than the newest from github) to the current patch, there are bugs in this scene. I threw all the assets out of the stage, only the walls were left - there are still these strange loungers (both colored and black). I have no idea anymore. It is also not the amount of texeli after the leak sometimes overlaps a dozen.

Unfortunately, I don't have a preview license

Gpu progressive baked this
https://imgur.com/a/1IYCLoR
I do not use it because the contact lines of the walls always come out

 

Heya, loving the asset! It's been so much better than the native unity lightmapper, great job!

We are trying to get the shadowmask to work with the Bakery Volume. It works perfectly fine with the "Full Lighting" mode, but when change to the "Shadowmask" mode, the Bakery Volume doesn't seem to be applied.

Full Lighting:


Shadowmask:


It appears that the Bakery Point lights aren't rendered the same and also the character is not being affected by the volume in the Shadowmask mode. Are we doing something wrong? Is there something that isn't supported?

Thanks and greetings!

 

In the 2021.1.28 uniy the bakery lightmap looks like this
https://imgur.com/a/VW6XF6F
there are no leaks, there are colors in the rooms. In unity 2021.3 the rooms are burned white (don't know why) and there are errors with the leak

Update( in 2021.2 the same errors as for 2021.3 - 2021.2 and 2021.3 are on hdrp 12.x 2021.1 with no problem is 11.x)

Update2
I buy rt preview, updated from github. This is what it looks like for 2021.3 and 2021.2
https://imgur.com/a/o296zO9
2021.1
https://imgur.com/a/NcBg0kZ

I did a new clean project, the problem is definitely on 2021.2 and above

 

I'm having a really annoying issue that makes Bakery unuseable to me as it is.
It suddenly appeared, idk what happened. Worked like a charm before.

So I'm having this HDRP project, whenever I wanna bake, Bakery "unpacks" and imports the FBX forever, until I kill Unity with the task Manager.
After restarting Unity, the whole Model is missing, and in the fbx inspector it says "This default asset was generated because the worker process has crashed since last import".
When I then try to import the asset again from Maya, import again takes forever and never finishes.

It worked when I only exported part of the meshes though! (Thankfully!! I thought my project was broken!) And then gradually added all of them and exported again (nothing all too crazy, a house with about 60k Triangles, without embedded textures, the whole thing has about 6 MB)

However, after every import, the "generate Lightmapping setting" needs to be applied again (which I never experienced before, but this is HDRP which I haven't used a lot, so I assumed it was because of that?)

When I don't tick this option, Bakery works (but the lightmaps are obviously F***ed)
Whenever I generate the lightmaps again, I have the same problem when trying to bake (with bakery)

What gives?!

Working on this project for about 2 weeks now and it worked before, until last weekend to be exact.
I'm using the latest LTS (2021.3.8f1) I tried baking with the GPU Lightmapper at first (after generating lightmaps, that one works) and used all 3 bakery modes (simple, advanced and experimental) didn't change a thing.

Is this maybe a caching thing? The disk the project is on has about 48 GB left (I could try to free up space but tbh don't wanna spend time on that if it isn't necessary and was therefore procrastinatingby doing other tasks in the meantime.)

Would appreciate an answer, thanks!!

 

I'm not really using area lights as the lighting feels rather bland then. Stricly only using point lights with IES profiles to them.
Like some bakes all of the IES lights will randomly turn 90 degrees, some bakes the shadow spread is incorrect etc.

Honestly it sounds like freak accidents and it would be very difficult to troubleshoot, just wondering if you had seen this issue before.

 

It's definitely the unwrapping, I can see it in the logs. The packing is actually very fast.

The issue stemmed from what you and Atomic picked up on which I realised myself shortly after posting, that I need to call LoadRenderSettings() after making the changes. In my head I thought I'd call that, then make changes and that all the changes were live, I didn't realise that this function is what essentially fed back my settings to Bakery, so each time I was asking it to read my settings before doing anything, setting some settings which didn't get used, and then repeating that process. It seems fine now

 

So my "bake all, then bake sector by sector" script almost seems to work, now that I have the Load Settings pulled from the storage after setting the options, but the issue I'm running into now is that changing the sector doesn't seem to work. The initial set works, but then further changes don't seem to apply as far as changing sectors goes.

Scripting wise, what exactly is required to bake a sector? (the order of commands/functions, etc).

 

So, bakery bad baking in unity 2021.2 and up (in hdrp in urp is all right)? Similarly with preview rt, it also goes completely crazy with uv1 during the preview in hdrp in unity 2021.2 and up
Some solution?

 

Aha, looks like they flipped the meta pass again? Just to confirm, are you using the latest patch?
Can you try following please:
- Open ftUVGBufferGen.cs
- Look for

bool isHDRP = rpTag == "HDRenderPipeline";

- Replace with:

bool isHDRP = false;

And see if it works (also try = true if it doesn't).
Not sure how to reproduce it exactly, as I did try the latest HDRP (?)
I'll check it again.

Ah, you're using URP. There are some caveats:
https://geom.io/bakery/wiki/index.php?title=Manual#Using_BakeryURPVolumeSpecShadowmaskGraph

It's UV padding adjustment, which is optional, please check this: https://geom.io/bakery/wiki/index.p....22_happens_too_often_and_takes_too_much_time
(especially if you used xatlas as unwrapper)

90 degrees?... that's weird, but also sounds like an old caching issue I've fixed.
Please try using the latest patch: https://geom.io/bakery/wiki/index.php?title=Github_access
You can also just try clearing Bakery's temp folder before baking, if that's the bug I'm thinking about.

Hmmm, just doing storage.renderSettingsSector = bakerySectorObject should be enough (and saving the settings later)

 

thx, is work
yes, i have latest patch

 

Looking at the documentation, it recommends values of 20 - 100 samples depending on the scene. If I'm content with the lighting positions and exposure I have and am ready to bake it for the final time, should I increase the size of my object lightmaps or increase samples, and if so generally by how much? I don't care about how long it takes, only how it affects game performance. Thank you for taking the time to read my question.

 

Always use the smallest values you can while the results are good in game to your eyes.
The larger the texel resolution, the larger the final lightmap textures and the more of them there will be, which will lower the performance in game.

 

why lower performance? only more memory

 

Hmm. The issue I have is that it seems to bake the first sector fine, then all the subsequent ones fail with the error that no objects are marked static which implies that either A) it's not toggling the sector game objects on and off correctly (which it appear to be doing correctly) or B) it's not switching sectors properly and is still trying to bake the original sector again (which is now disabled).

The only other thing that came to mind (I don't know enough about Unity to say whether this is even possible) is that the bake command is running too soon after the game object containing the sector is enabled, thus there's nothing to bake yet, but that doesn't seem likely.

Do I need to call anything else after "storage.renderSettingsSector = bakerySectorObject" but before the bake command?

 

what shader should I use for mono-sh?

 

No. It also affects performance, especially on mobile chipset, the Switch and the Quest.
The GPU has an intermediate cache where it puts the textures it is going to sample. If the texture is too big, it will fill the cache and the GPU will be forced to constantly load and unload chunks of textures inside it. This is called cache miss.
This will lower overall performance up to alarming rates on mobile chipsets and cause stuttering in your game even on PC.
This is especially noticeable with lightmaps, since they don't usually use mipmapping and the GPU is forced to always read the full size texture even for small polygons in screen.

 

That's also the reason why using uncompressed textures in general will lower the performance of your game: they are bigger in memory than compressed ones and memory transfers are much more expensive. It's not really clear to me if compressed textures get decompressed when loaded in the cache or if they are stored in the cache in compressed form, and it could also depend on the GPU.

 

Filamented by Silent works well. Orels Shader should also work.