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

Happy to help

So, I'm manually applying a packing margin correction depending on the size of the final render bounds of the object in the scene. I guess that's what Bakery does when it adjusts the UVs.
Is there any specific formula for that?

 

@guycalledfrank

Hi, please, how i must bake my terrain, it looks how above, i try a lot of configurations, and nothing helps

 

well, I ended using this formula and seems to work fine for the moment:

Code (CSharp):

1.             var bounds = meshRenderer.bounds;
2.             var maxBounds = Mathf.Max(bounds.extents.x, Mathf.Max(bounds.extents.y, bounds.extents.z)) * 2f;
3.             var pixelBounds = maxBounds * lightmapTexelResolution * objectScaleInLightmap;
4.             unwrapParam.packMargin = math.saturate(8f / pixelBounds);
5.  

Now I'm having issues with edge seams, and since it's a procedural mesh built in the editor, Bakery isn't helping.
What should I do to my meshes to fix the UV edge seams?
What's conceptually the trick?

I mean this:

 

Relevant: https://geom.io/bakery/wiki/index.php?title=Troubleshooting#Whole_scene_is_very_bright_or_black

If you're using HDRP, read this. Otherwise, just turn down the intensity of the direct light, or use a Tone Mapper post process.

 

Oh, I see you're actually fixing the rendered images, not the UVs, so it's already doing it.

Anyway, after a lot of back and forth with the unwrapper config, I managed to generate good lightmap UVs for my procedural meshes after all

 

Constant error - does anyone else get this?

I've tried deleting all my baked data, etc., but it doesn't seem to work.

 

Has anyone gotten alpha clip to work with amplify yet?
I set all the tags to what the Bakery manual says, but no success..

 

Hey, as I understand it Shadowmask + Indirect is the same as Shadowmask + Direct & Indirect. You just specify which lights you want to have direct & indirect lighting baked on per light.

So say for example, you have a bunch of small point & spot lights you want indirect + direct light baked for, you just select those lights & choose direct + Indirect. Maybe you only want to bake indirect light on the main directional light in the scene, & have its direct light be real-time, you would select that light & specify indirect only for baking.

 

Hey, thanks for taking the time to reply!

We are currently having the opposite problem, with dark patches, not light patches. Our HDRI & Directional lights are also working perfectly, we only run into issues when we introduce small lights. We are using exclusively light-meshes & spotlights, with no baked emissive surfaces.

 

I'm having an issue with saving/loading the render settings to a lightmapped prefab. After I bake, I can save and load just fine. But if I switch scenes and switch back, then if I click load, it sets the bake settings back to all the default values rather than what it was when I had clicked save. Am I missing something about this feature, or is this not supposed to work that way?

 

Hi, when trying to Render I get a message saying that the scene has multiple lightmaps present, however I have clear the lightmaps, cache and also cleaned the GI cache. Is there any other folder which I should clean?

Solved it after closing Unity but it is stuck in "Exporting scene" at 50%.
I could bake my scene before but after adding lightprobes and tried to bake again it is not working.

Edit: so apparently the problem are the light probes, I'm trying to fix this

 

Hello,

I got a problem with example_shadowmask scene - no changes done by myself. Just imported Bakery, opened example_shadowmask scene, clicked Render in Bakery tab and got such result:

After baking there is like no baked light, there is only realtime unity light (when I swtich off unity light, scene becomes dark.

What is interesting - on Bakery preview it seems to be fine. Could anyone help with this? It seems that this is most trivial example, just Bakery build in scene for example purposes with no changes made by me).

(Unity 2020.3.33f1, build-in render pipeline)

@MrF please help

 

check this article to understand what Shadowmask does...
https://catlikecoding.com/unity/tutorials/custom-srp/shadow-masks/

 

Some time ago MrF suggested that for such scenario where I need static objects to be baked and dynamic ones to be enlighted/emit the realtime shadows, the best choice should be shadowmask. It would be all fine, but the problem is that it seems that after baking in that mode also static objects are being enlighted with realtime light, not baked (eg. on my screenshots when disabled Light component, the wall is completely dark, not enlighted with baked light on it - like it behaves eg in Full Lighting).

So in fact my problem is not even about casting the shadows, but with enlighting the static objects with the baked light (which I guess should be baked on static object).

Please correct me if I am wrong (I am newbie in lightmapping but I guess what I miss in that shadowmask mode is baked GI, right?)

 

So, deleting the tempScene every time i bake a new scene did not help at the end. A lot of asset bundles with baked scenes in it were rebuild anyway.

For anyone who run into the same issues: I came up with a quite simple solution: put the tempScene in it's own asset bundle. Then this new asset bundle is a dependency from the scene asset bundle, but not the tempScene itself. So the scenes assetBundles do not care if the tempScene in the new linked bundle has changed.

 

It takes some time to get behind all the lighting modes.
Simple click on a wall surface or the ground.
In the inspector you can click on the lightmap to see what s baked in. Study the lightmaps and in scene window you can switch to lightmaps to see the lightmaps applied.

I seems there is some misunderstanding .
Shadowmask is an mixed lighting mode who mainly bakes indirect lighting.

Go over these modes row by row and try to understand the difference between
Full lighting - direct and indirect is baked
Indirect - indirect is baked
Shadowmask - a special variant of indirect...



combine this visually with this diagram,
and you will get a better understanding

 

Is bakery compatible with unity 2022?

 

Small lights by themselves shouldn't pose a problem, unless they're in very close proximity to some surface. In this case the illuminated surface itself becomes emissive and produces fireflies similar to the ones @atomicjoe mentioned.
Avoid small & bright spots on the HDRI. Probably downsample/blur it.
Don't place lights very close to surfaces or don't use surfaces as diffuse reflectors. Instead, make these reflectors Light Meshes. Both options will work, but the Light Mesh option will guide the rays in a much more efficient manner, avoiding the noise.

As atomicjoe mentioned: https://geom.io/bakery/wiki/index.p..._who_doesn.E2.80.99t_have_Bakery_installed.3F

If something's not working, please check this (from my older post):

Please check if it's related to xatlas and try the default atlas packer:
+ other possible causes:
https://geom.io/bakery/wiki/index.p...rting_scene_-_preparing.22_is_taking_too_long

Oh... even better

Actually tried that on 2021.2.4 and it didn't go away... maybe 2021.2.3 is just bugged? (2021.3.0 also works)

Actually there is, in case you know what you're doing (and have shaders that support it).
You can get the latest patch: https://geom.io/bakery/wiki/index.php?title=Github_access
Then you can select this option:



This way color lightmaps will contain full lighting, but the shadowmask will also be generated.

To be continued...

 

Thanks for the reply.
I read a little bit about lighting modes and I wonder if there is any simple way to achive what I want - if using Full Lighting I got great indirect and direct baked lightmaps but no shadows on dynamic objects, when using Shadowmasks I got great realtime lighting/shadows but I can see that lightmap has only indirect lighting baked - it's not performant on low-end devices.
So the question is - can I have something like FullLighting for static objects and then for dynamic ones - lighting from light probes and shadows from realitime lights?
I lose my hope to find an answer and probably will need to use FullLighting and blob shadows for dynamic objects to keep performant on Android.
(maybe someone has some template project to share using Bakery to achive what I need?)

 

Hmm I couldn't reproduce this:



Just in case, attaching the latest graph package to this message.

Yes... since there is no way to create LightingDataAssets from code, and they're needed to store probe data, Bakery creates this temporary scene with nothing but light probe groups and asks Unity to bake it. Unity then generates a valid lighting data asset, which is copied, and probe colors are then modified.

Do they actually link to it? They should use their own copy named after the scene. Can you show me your Lighting window?



The temp scene has no use in the build.

Yes, UV padding adjustment is only applied to model assets that have normal model importers and "Generate lightmap UVs" checkbox enabled. Other assets are assumed to have custom-made UVs that shouldn't be touched.
Having 0 pack margin will of course produce seams. Having higher margin will of course make the islands smaller. You should increase the margin but also increase the resolution a bit, so UV islands are not super tiny. Increasing "Scale in lightmap" should actually help, it's weird that it doesn't. Did you try really increasing it, like 100x?

Interesting, but are you sure that it happens with "alternative scale in lightmap"? I think it should specifically take care of any inconsistencies like this.

Problem is, it's not just an adjustment... it actually completely regenerates the UVs from scratch, using the unwrapper currently selected, with a different pack margin (aka padding) value. In your case it sounds easier to just bake some reasonable padding into your generated meshes.

To be continued...

 

I see. No problem for me: I ended up finding the correct way to configure that damned UV Unwrapper

 

Should "scale in lightmap" on unity the mesh render lightmapping settings be working? I'm trying to make far away objects be smaller by setting the value to something like 0.1 but nothing seems to change.

 

Do you habe some insights to share?.)
I gave up an create all my UV s in Blender and pack them there with UV Packmaster. Then i use Original UV setting in Bakery with Lightmap groups.
Since i do it this way i had have no problems anymore.
However, this is some work.

 

Everything is very bright? Not just the terrain? Are there any realtime lights working over the lightmap? Any posteffects making everything brighter? Just a very bright texture?
Maybe something about the directional mode? Is it set to Dominant direction? Does it work without it (None)?

Hmm "Fix seams" is applied to all geometry, procedural or not. Is there any difference at all with it/without it?

Hmm this one shouldn't affect anything. Lightmaps/probes should still work.

Not sure about Amplify, but you can send the final generated shader to me, I'll check it.

Hmmm do you have any pics of those? Wild guess: check if it happens when Light Meshes have self-shadow disabled. If it doesn't, try increasing Far Samples.

Reproduced the issue. Yeah, it needed applying the override on the prefab. Just pushed a little patch where it's no longer necessary (just adds

EditorUtility.SetDirty(prefabStorage)

at the end of the save button code).

Multiple lightmap storages? That shouldn't happen, not sure how you got it there... anyway, please try:
- Closing Bakery window
- Clicking Bakery -> Utilities -> Clear baked data -> Clear
- Do it twice?
- Reopen the window and try baking

I think you need to disable the "distance shadowmask" checkbox (no rebake needed). It's just a rendering setting, can be changed in Quality settings as well.
https://geom.io/bakery/wiki/index.p...C_but_Unity_renders_real-time_shadows_instead

Do you have any way to see what exactly links to the tempScene?

It'll likely work, although I'd recommend using the latest patch. But personally I didn't test it there yet.

With distance shadowmask disabled, you'll see the direct shadows are also baked.

Yes it should. Try smaller? Or maybe the object is already at minimum atlas resolution?

 

For me, the key was to understand the relation between "margin size" and "scale in lightmap":


JOE'S LIGHTMAPPING CONFIG GUIDE:

When you make the UVs for lightmapping using Unity's unwrapping method, what you actually do is flatten all the meshes polygons and distribute them over a single 2D square surface.


Then this single square surface will be placed inside a larger atlas image, along with other objects, each on their respective square, and this larger atlas image is actually the final lightmap texture.



One object => One Square in the final lightmap

Each object only has its own specific 2D square to lay its polygons on. (XATLAS uses a more sophisticated approach, but for calculating UV margins, it doesn't matter)

The final size of the 2D square reserved for a particular object in the final lightmap depends on the actual physical size of the object in the scene, so that larger physical objects have more texels rendered in the lightmap than smaller physical objects in the scene.

All of this is done by default.

Remember: One object only has its one square to put its polygon on, and that square size will be calculated by the lightmapper depending on the objects physical size and the overall render resolution.



The problem:

Lets say you have a very large empty office room, with only some chairs and desks here and there, but mostly empty.
If you adjust the lightmapper resolution for the overall scene size, the empty space in the floor and walls will be rendered ok, but the small detailed objects like tables and chairs will have too little resolution.

(example of lightmap with enough resolution for the walls and floor but not enough for detailled objects)

However, if you set the lightmap resolution correctly for the chairs and tables, you will end up with an insane amount of lightmap textures with lots of wasted space where the floor and walls go, since there isn't a lot going on there.
Even worse, you can easily end up without enough video memory and crash the lightmap render or compromise the runtime performance of your game.

This is why there is an option in every object to set its particular scale in the lightmap.
This scale value is a multiplier by which the size of the final square reserved for the object in the lightmap will me multiplied.
So, if you set an object scale in lightmap to 2, what you are doing is telling the lightmapper to multiply the X and Y size of the 2D square reserved for that object in the lightmap by 2.
This way, the object will always be rendered 2x2 times larger in the final lightmap, no matter the resolution.

Back to our large empty room with some chairs and tables, now you can either:
- set the lightmap resolution correctly for the small objects and then set the floor and walls scale in lightmap to a very small number or
- set the lightmap resolution correctly for the large surfaces like floor and walls and specify a large scale in lightmap for every small object.
And then the rendered lightmaps will be great for each object.

Now, to calculate the scale in lightmap for an object, you have to keep in mind that the Render Resolution you set the lightmapper to is the amount of pixels that will be rendered for every meter of physical surface in the scene.
So, a lightmap resolution of 30 will render 30 pixels for each meter on a straight line. A surface of 1 meter by 1 meter will render a 30 x 30 pixels size image on the lightmap texture.

This resolution is ok for walls and floors but too little for small objects like stuff on a shelve.
Given that we had set a general resolution of 30 pixels per meter, setting the scale in lightmap to 3.333 will give us 1 pixel per centimer, and a scale in lightmap of 6.666 will give us 1 pixel each 0.5cm, which should be plenty for small objects.
Setting a scale that high for small objects is not an issue since they are small and will end up not taking a lot of space in the final lightmap.

That's it, right?
WRONG!



The Bigger Problem: UV overlaps


(example of polygons having the edges of their textures overlapping with other polygons textures)

When you unwrap the meshes UVs the unwrapper has no idea what your final object actual physical size will be in the scene. It will just distribute the mesh polygons over a virtual 2D square with no specific resolution.
It will make sure that larger polygons will use more space than smaller polygons, but that's about it.

Now, the problem is that your polygons assigned space in that square will have to accommodate pixels in the end, and those pixels will not follow the shape of the polygon perfectly.
For that, you have to account for a margin around the polygon to be sure that the final texture bleeds a little over the actual used pixels, otherwise you will end up with ugly dark seams on your lightmapped objects.

(example of texture without any padding or margin)

That's what "Pack Margin" is for: to specify the amount of extra space reserved around a polygon so that it doesn't get rendered by other things or empty space.

The big problem with this pack margin size is that: the bigger you make the margin size, the less space is left for the polygons to actually render!
Remember, we are still confined to the same virtual 2D square: the more space you reserve around polygons, the less space you have to render the actual polygons!

Then, the space you reserve around polygons (the pack margin) must be the smaller size possible while being big enough to wrap around the polygon nicely for a minimum of 4 pixels around it.
And since the final size of that objects 2D UV square will depend on the actual physical size of the object in the scene (accounting its final scale) AND the render resolution you set lightmapper to, it's quite complicated to set that damn pack margin number:

Set it too low and you have dark seams all over your lightmapped objects,
Set it too high and your object will have a much MUCH lower render resolution and will probably ALSO have black seams all over it.

Worse: that's something you can't know when modelling the object. You will only know this value when you are actually rendering the lightmap!
And that's why Bakery recalculates all the lightmap UVs of every imported object it will render: so that it can set its pack margin according to the object size and render resolution accurately.

But if you reuse the same objects on different scenes and change the objects scale or render the scenes at different resolutions, then Bakery will have to recalculate that UV pack margin again! because the final render size of the object will be different!
And since Lightmap UVs are embeded in the mesh itself and it's shared across all scenes, it will mess the lightmap of that object on other scenes.

To alleviate this Bakery can make it so that the pack margin will never decrease from a scene scale to another scene scale, but only grow in size. However its a compromise, and the best thing to do is just to keep the same object at the same physical size on every scene with the same "scale in lightmap" and render all the scenes at the same resolution to avoid any problems.

But for primitives that are meant to be reused and re-scaled on every scene, this is a problem.
And that's why I use procedurally generated meshes as primitives, so that each primitive is a different mesh with its lightmap UVs generated accordingly to the size of the object in the scene.

For the lightmapper, each of this objects are completely different meshes, and for runtime rendering, it's not an issue because all those meshes will get batched as a single static mesh. (for moving objects you will not be using lightmapping anyway, but light probes)

Sadly, Bakery only fixes the lightmap UVs of imported objects, not of code generated meshes, so we have to calculate the pack margin correctly ourselves.

Now, to accurately calculate the Pack Margin of the lightmap UVs for a mesh assigned to a given meshRenderer, I use this formula:

Code (CSharp):

1. float pixelPadding = 32f;
2.  
3.             var bounds = meshRenderer.bounds;
4.             var maxBounds = Mathf.Max(bounds.extents.x, Mathf.Max(bounds.extents.y, bounds.extents.z)) * 2f;
5.  
6.             // set lightmap UVs
7.             UnwrapParam unwrapParam = new UnwrapParam();
8.             unwrapParam.hardAngle = 88f;
9.             unwrapParam.angleError = 0.08f;
10.             unwrapParam.areaError = 0.15f;
11.             var pixelBounds = maxBounds * LightmapRenderResolution * lightmapScale;
12.             unwrapParam.packMargin = Mathf.Clamp01(pixelPadding / pixelBounds);
13.             Unwrapping.GenerateSecondaryUVSet(mesh, unwrapParam);
14.  

Where LightmapRenderResolution is the "Texels Per Unit" setting in Bakery or the "Lightmap Resolution" setting in Unity's lightmapper and lightmapScale is the "scale in lightmap" setting of that given mesh renderer (which is 1 by default)

PixelBounds in the code is the final pixel size the 2D square assigned to this object will have in the final lightmap atlas texture, so I divide the desired Pixel Padding or margin size in pixels by the size of the final square in pixels, which gives me the percentage margin size in percent of the total square size. (the pack margin must be expressed as a percentage from 0 to 1)

But keep in mind the pack margin value is only valid for the specific size of the object in that moment. If you change the size of the object in the scene OR change the lightmap render resolution, you have to recalculate that.
Also, PixelPadding can be set lower depending on the size of your objects, but I set it to 32 to be conservative.

And that's it.
Game development is so easy...

 

Hello, this is a screenshot from a past project I worked on. I just wanted to clarify what was happening here, and the solution if it's useful to anyone.

These artifacts were caused by using an HDRI with my Bakery Skylight. The specific HDRI had a sun visible in it. The sun itself caused the weird artifacting shown here.

The fix was to open the HDRI in photoshop and clone stamp out the tiny spot with the sun. This allows for nice, even lighting from the skylight, free of any artifacts.

 

With bakery I can use the same lightmap in multiple scenes by baking to a prefab. I was wondering if its possible to use the same reflection probes in multiple scenes or do I have to bake them in each scene?

 

Hello, I want to make a procedurally generated dungeon comprised of lightmap baked prefabs. I want to use Bakery Volumes, but because I'm working on mobile, I need to use a single Volume (single set of textures) so that my meshes (all using the same material) can all batch in the same Set Pass call. How would realistic would it be to use a single Bakery Volume for an entire room like this?

 

I want to bake Ambient Occlusion but the result is not good

 

I appear to have found a bug, though I'm not sure if this is a Unity bug or a Bakery bug.

To summarise, it doesn't seem like you can take something out of a lightmap after it gets backed into the lightmap and it instead ends up assigned garbage.


In detail - I'm using region control groups (the new Bakery feature to split maps up) and I had some meshes (the sea) that were baked accidentally that I wanted removed from the lightmap. So I set their scale in lightmap to 0 which Unity states will cause them to not be lightmapped, but still affect others. That's fine. Anyway, I rebake and instead of the sea disappearing from the lightmap, it instead looks like it's been mapped to garbage. What's more odd is that checking the associated lightmap shows that it's the lightmap for a different region entirely (this is the "Pirate" area, the lightmap it claimed the sea was associated with was the "Mall" which is a different control group entirely.

Even marking the sea non-static entirely so that it shouldn't have any influence on the baking at all still doesn't help, rebaking this region doesn't clear the garbage lightmap that has been associated with the sea.

Here was one of the attempts, where even with a lightmap scale of 0 which should result in it not being lightmapped, doesn't clear it and even after a rebake, still shows it assigned to a completely different region. You can see the patchy light



Disabling static entirely and rebaking doesn't help.

Doing a full "clear baked data" may work, but that would clear all lightmaps from all regions/control groups which I'm trying to avoid (kinda defeats the point of the control groups).

So the question is - how do you "unassign" things from the lightmap after they've been baked it to and how has it ended up assigned garbage from a completely different lightmap for a different.

 

Hello,
In Unity 2021.3.2f1 URP, I'm unable to import the Bakery URP shader package. I import the files and don't see any errors, but when I go looking for the shaders in the material setup UI, they aren't there. Has anyone else had this issue?

 

Unity 2021LTS is a nightmarish hive of bugs. I recommend staying away from it until Unity gets its S*** together.

 

Hello
Can Bakery bake lightmaps per prefab with multiple prefabs present in the scene or do I need to bake each prefab in an empty scene?
I want to avoid having lightmap data shared between prefabs.
Thanks

 

It should. As per the manual:

And using lightmap groups you can set them to completely different lightmap textures.

 

Thank you, that seem like a great solution

 

@guycalledfrank I have switched my project over to Bakery and have recently discovered that there is no functionality to have certain lights ignore certain meshes via layers/culling/groups.

I am setting up some tricky interior lighting and would be able to achieve my goal if my spotlights could shine through and ignore the ceiling and ceiling props (I am trying to control the elevation of intersection between spotlights at a certain point).

I have read some previous discussions and it seems like this problem might be an intentional feature, with you recommending people to solve it with IES. This solutions adds allot more complexity when developers could achieve their goals if we just had a little bit more control of Bakery. I am not even sure if I can even find an IES that solves my specific needs.

Could you extend the functionality of lightmap groups and add an option to have lights ignore a mesh if it is not within their bitmask? I have seen other users ask about this exact functionality and we would all appreciate it greatly if this could be added to an already invaluable tool.

 

Awesome guide!

I'll just repeat the basic points in my own way in case some readers get confused:

- UV Unwrappers (Unity's own or xatlas) generate the per-mesh UV layout. By default, it's not bound to final lightmap resolution and that's why (as described) Unity unwrapper has the "pack margin" parameter you can tweak.
When "Adjust UV padding" is enabled and if your model assets have "Generate lightmap UVs" enabled, Bakery will actually do it for you automatically by re-running the unwrapper using the optimal value, which is computed from the smallest model instance in the currently opened scenes (its texel size). This way you don't need to manually tweak the pack margin. On the other hand, auto-adjustment have some flaws, e.g. (as Joe says) having the same model used in different scenes can lead to its UVs being re-optimized for the last baked scene, invalidating the previous one.
This adjustment never runs on meshes that don't come from a model importer (FBX, OBJ, etc). So yes, for code-generated UVs whatever is already there will be used with no modifications.

- Atlas packers (my own or xatlas) pack individual mesh instance UVs (squares) into larger scene atlases. Mesh UVs are untouched, so different instances of the same mesh still share the data, only a small scale/offset vector is supplied for the additional UV transformation in the shader. When using xatlas with the "hole filling" option, the resulting packing can be very optimized, even if individual meshes are unwrapped with the standard Unity unwrapper. https://twitter.com/guycalledfrank/status/1231890428313600000

By default, baked reflection probes are bound to a LightingDataAsset of the particular scene. But you can:
- Bake reflection probes in one scene.
- Change them from "Baked" to "Custom".
- Find your baked cubemap texture. Usually it's in a scene-named folder. Insert it to the custom cubemap slot of the reflection probe.
- Et voila, the probe can be reused in any scene.

If you generate the dungeon at editor time, you can bake a large volume after the generation (just uncheck "Enable baking" from all prefabs, so they're not overwritten).

If you generate it at runtime, it's trickier. I can only see one way: combine the final volume from smaller volumes via code. Basically create large 3D arrays, then read every voxel of every smaller volume, scale/offset the coordinates into the larger volume space and write it to these arrays, then create new 3D textures from them.

Maybe I should write a stock script for it, sounds useful

Are these faces two-sided by any chance? I.e. polygons on both sides? In such cases Bakery doesn't know what is the "right" side that should be optimized.
Also make sure that you didn't disable "Adjust samples positions".

Sounds like something I fixed a long time ago... are you on the latest store version? If so, please also try updating via the patcher: https://geom.io/bakery/wiki/index.php?title=Github_access

Not sure about 2021.3.2, but I definitely tested URP shaders today on 2021.2.19 (URP 12.1.6) and it worked OK. I also re-exported the package with a little fix, so just in case, here's the latest one: https://drive.google.com/file/d/1TYPVZO88ylzP4-csKjnEnrYElRAaaw_Q/view?usp=sharing

You should see new shader graphs if you type "Bakery" in the material shader field.

Yeah, it's actually how it's set up in my example_prefabs_bake scene. All module prefabs are baked at once. It doesn't even use Lightmap Groups, this way all prefabs share the same atlas.

That's very tricky to implement. The whole scene is combined into a single big mesh from which the BVH tree is built for raytracing. There are actually "deltas" for this big mesh used to implement LOD levels. But switching these deltas requires data (re)loading and rebuilding the tree. Having them not only for LOD levels, but also for every light is kinda a mess to engineer (because now you have a matrix of every light mask vs every LOD level). It's not like there is an easy option that I just didn't expose to developers.
And really I don't feel like ceiling-ignoring lights is a great way to do lighting. You can perhaps skip the IES and just use wide cone lights? Or maybe Light Meshes of any shape?
Finally you can just bake the ceiling separately as a Lightmapped Prefab with its own named Lightmap Group, leave it, uncheck "Enable baking" and "Contribute GI", then bake the whole scene again. The ceiling is now ignored, but it still has its previous lighting on it.

 

Hello,

We have a problem with lightmaps that aren't showing on prefabs with build on Nintendo Switch. In editor everything works as indented:

- Every prefab has its own lightmap in separate catalog
- its being baked on separate scene with proper workflow

When prefab is being placed on the scene during gameplay in editor everything works as indented, but it does not work when build on Nintendo Switch - is there any solution for that?

 

Maybe the lightmap textures are not being included in the build?
Try this: save this script as "DummyTextureReferences.cs"

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class DummyTextureReferences : MonoBehaviour
6. {
7.  
8.     public Texture[] textures;
9.  
10.     void Start()
11.     {
12.         for (int i = 0; i < textures.Length; i++) if (textures[i] != null) Debug.Log("Texture " + textures[i].name + " forcefully included in build.");
13.         this.enabled = false;
14.     }
15.  
16. }
17.  

Now put this script in an object in your scene and put your missing prefab lightmap textures in that array, just to force Unity to include the textures in the build.
Rebuild and note if the debug log names correctly the prefab lightmaps.

 

I aborted a bake before it got to the part where it closes the scene for baking, and now I get this error whenever I try to bake on that scene. I've tried to reinstall bakery and deleted the current lightmaps:

Code (CSharp):

1. Exception caught: System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
2. Parameter name: index
3.   at System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) [0x00029] in <695d1cc93cca45069c528c15c9fdd749>:0
4.   at System.ThrowHelper.ThrowArgumentOutOfRangeException () [0x00000] in <695d1cc93cca45069c528c15c9fdd749>:0
5.   at ftBuildGraphics+<ExportScene>d__233.MoveNext () [0x0111e] in C:\Users\conta\Documents\Unity Projects\Dreamwalker\Assets\Editor\x64\Bakery\scripts\ftBuildGraphics.cs:6262
6. UnityEngine.Debug:LogError (object)
7. ftBuildGraphics/<ExportScene>d__233:MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftBuildGraphics.cs:7154)
8. ftRenderLightmap/<RenderLightmapFunc>d__282:MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:5268)
9. ftRenderLightmap:RenderLightmapUpdate () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:4601)
10. UnityEditor.EditorApplication:Internal_CallUpdateFunctions ()
11.  

Code (CSharp):

1. ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
2. Parameter name: index
3. System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <695d1cc93cca45069c528c15c9fdd749>:0)
4. System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <695d1cc93cca45069c528c15c9fdd749>:0)
5. ftBuildGraphics+<ExportScene>d__233.MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftBuildGraphics.cs:7155)
6. ftRenderLightmap+<RenderLightmapFunc>d__282.MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:5268)
7. ftRenderLightmap.RenderLightmapUpdate () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:4601)
8. UnityEditor.EditorApplication.Internal_CallUpdateFunctions () (at <a5bc71bb4d98498aba1f868b89d20d47>:0)
9.  

 

I am having a very strange issue with prefab lightmapping. I can successfully bake prefabs, but once I bake a new one all of the previously baked prefabs have their lightmaps shifted over about 1 unit.

My workflow:

1. Create a room prefab from a model and prop prefabs
2. Duplicate finished room prefab so that I can unpack the nested prop prefabs
3. (Unpack the nested prop prefabs)
4. Add lightmap group selector component
5. Generate/chose a unique group for the room prefab's lightmaps
6. Add lightmapped prefab component
7. Add room prefab into scene
8. Bake
9. Remove from Scene and then begin again with a new room separately

This will generate a lightmapped prefab that I can then remove and add back into the scene with no problems. Once I do this to a new room prefab all previous ones will have their lightmap's messed up.



The only solution I currently have is to bake all separate prefabs at once, which will become impossible as more room prefabs are added and updated.

Additional Info:

1. Compression has no effect on this problem
2. I am only baking in one scene, not creating any local render settings in the groups, which are also using the same resolution as global
3. Separate lightmaps are being produced for each individual prefab
4. Very Strange Observation: If I point the editor view at a prefab with this problem, and then hit Render, for a split second I can see the lightmap shift back into place right before everything disappears as the Render begins.

(Also, @guycalledfrank thank you very much for the insight from my previous question)

 

Have you tried:
Bakery -> Utilities -> Clear Baked Data -> All (Data and Bake Settings)

Up there in the Unity application menu.

 

Those screenshots look like the UV padding is being adjusted between bakes.
Set Bakery's "asset UV processing" render setting to "Remove UV adjustments" and try again.
Read my lightmap guide up there to understand what it does.

 

Hey Frank, I use directional maps for specular highlights in my shaders but I keep having seams on UV boundaries of the directional map, with or without the "fix UV seams" option enabled.
Is there anything that can be done to improve it?

Without "Fix UV Seams":


With "Fix UV Seams" enabled:



Color lightmaps are fine, it's only the directional maps that have this issue.

Maybe the SeamFixer would do a better job for directional maps if it reconstructed the normalized -1..1 values, applied the fix and then packed them again in a 0..1 range?

An example of a worst case scenario.
As it's a specular reflection, it can be as big as the whole screen

 

I tried that, didn't work, but what did work for me was finding any bakery related temp objects that were left behind in the scene. There were several object generated by Bakery after I aborted the bake, I deleted them and the scene would bake again.

 

I'm getting strange blotchyness in my lightmaps where the built in lightmapper had no issues with. It seems to be struggling where objects meet walls, even when unit perfect side-by-side using pro grids.
Anyone know what I can change to solve this?

Examples:



My settings:

 

That completely fixed it, thank you very much.

 

Spoiler

 

@atomicjoe unfortunately I have just realized that this now causes very thin and bright seems to appear on my walls. If I revert back to "Adjust UV Padding" (only option that fixes it out of the 3) the problem is gone but the original issue obviously reappears. "Denoise: fix bright edges" does not help.

What would you recommend? I have Unity generate the lightmaps automatically and can't tell If I should adjust the padding or not.

Example:

Spoiler

Context:

Spoiler

 

- Enable Adjust UV padding
- Use the same lightmap render resolution for every scene and prefab.
- Use the same imported mesh always at the same world scale on each scene
- If you have to change the scale of an imported mesh, make a copy of the original imported mesh asset and use this new imported mesh always at the same scale. (don't make a copy of the gameobject, but a copy of the original imported asset FBX or OBJ)

The key is to adjust the UVs and then NEVER change the world scale of the same imported mesh in any scene.
This way, the padding remains always the same.