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

You're right. I was under the assumption that when I set the unity light component to baked, I won't have shadowmask problems any more, but the Bakery Point Light still had Shadowmask ticked on. Which is to say that the Bakery Point Light was "set to mixed" by the fact that its Shadowmask was ticked on, regardless of the unity light setting.

 

Hi,

We want to have mixed lights that have baked shadows but do not cast shadows from dynamic objects at runtime.

To achieve this we've set Realtime Shadows -> Strength to zero. Is this correct?

Here's how we have it setup:



Thanks

Mat

 

Ok I'm really confused now.
How do I achieve the following:
8 point lights that are 100% baked with baked direct light/shadows onto all static objects.
4 point lights that are mixed, such that they bake shadows for static objects, and also cast shadows from dynamic objects.

Right now I have:
8 point light GOs with Unity Light set to Baked and Bakery Point Light having everything unchecked, bitmask 0.
4 point light GOs with Unity Light set to Mixed and Bakery Point Light having Shadowmask checked, bitmask 0.
My Bakery panel settings are attached.

Why is it that it only bakes indirect light? There are no errors or warnings. Most materials are the unity Standard shader.

PS: I also have a directional light set to mixed, and shadowmask. It also doesn't bake any direct lighting/shadows.

 

Unity will still calculate dynamic shadows, but they won't be visible. I'm not even sure Unity supports shadowmask *only* without any realtime shadow mixing. You can do it with custom shaders though.

- Bake to Indirect: ON
- Shadowmask: OFF
- No Unity light

- Bake to Indirect: OFF
- Shadowmask: ON
- Should have Bakery + Unity light

 

You understood correctly : )
I'll send you a pm

 

Thanks for the quick reply. We have to have the render mode in the Bakery options set to 'Shadowmask' because we have just one light (the moonlight) that shadows dynamic objects at runtime but we'd like several other lights to have baked shadows on static objects but also light dynamic objects at runtime (with no shadows, so it's not as expensive).

What's the best way to setup Bakery to do this? (Or should we be using light probes?)

Thanks

 

- Bake to Indirect: ON --- was confused by the wording, why I should add direct light to the indirect light map, thought that's something custom or not what I wanted ^_^

Final question: the 4 lights limit applies to any and all kinds of lights? Directional, point, spot, and bakery area light?

 

Hmm interesting case. Is it a problem to have everything fully baked and just use regular light & reflection probes? Specular from the moon can be baked into reflections.

In shadowmask mode dynamic objects use 2 sets of probes: color and occlusion. The difference is that regular color light probes may lack contrast/detail, and with additional light occlusion information the final formula becomes:
lighting = bakedColorProbe + realtimeUnshadowedLight * bakedOcclusionProbe.

The "realtimeUnshadowedLight" part is pretty cheap and will give you more contrast, so I understand if you want it.
Just did an experiment, and I think I got it working:

I agree, the wording is confusing. I wonder what would be a better name for it?

It's engine limitation, so it applies to all lights Unity supports (direct/point/spot). Bakery area lights aren't represented as realtime lights in Unity, so the shadowmask option isn't even available for them.

 

Bake to indirect tooltip: "[Also bake the] direct contribution from this light [into the] indirect lightmaps. [Use it to fully bake any unimportant lights, to get around the 4 lights per object shadowmask limit in unity (see docs). Turn off the unity light component when using this setting to avoid double lighting.]"

Shadowmask tooltip: "Enable [baking for] mixed lighting. Static shadows from this light will be baked [to the shadowmask lightmaps], and real-time light [from the unity light component (when set to realtime or mixed)] will cast shadows from dynamic objects. [If more than 4 unity lights hit an object, it will not be baked at all. (engine limitation, see docs)]"

That's my 2 cents as I understand it. Not the most compact tooltip text. But feel free to use it!

If there's no reason to use both Bake to Indirect and Shadowmask at the same time, make them radio buttons, it makes things clearer.

 

Hey @guycalledfrank I updated to the latest store version (1.51) and every now and then see these log entries:

Code (CSharp):

1. Error: Unknown error (old driver?) (505)
2. UnityEngine.Debug:Log(Object)
3. <RenderLightmapFunc>c__Iterator3:MoveNext() (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:4126)
4. ftRenderLightmap:RenderLightmapUpdate() (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:2827)
5. UnityEditor.EditorApplication:Internal_CallUpdateFunctions()

By old driver do you mean the nVidia GPU driver? Thanks!

Edit: ignore my query - just been through your manual and noticed the FAQ about the 505 error, and that it is indeed the GPU drivers that need to be updated. Thanks.

 

Hello,
Just updated to 1.51 and get three errors.

[CompilerError] 'LightmapEditorSettings.Lightmapper.Radiosity' is obsolete:
'Use Lightmapper.Enlighten instead. (UnityUpgradable) -> UnityEditor.LightmapEditorSettings/Lightmapper.Enlighten'

Compiler Error at Assets\Editor\x64\Bakery\scripts\ftRenderLightmap.cs:1827 column 55
_____________________________________________________________________

[CompilerError] 'LightmapEditorSettings.Lightmapper.PathTracer' is obsolete:
'Use Lightmapper.ProgressiveCPU instead. (UnityUpgradable) -> UnityEditor.LightmapEditorSettings/Lightmapper.ProgressiveCPU'

Compiler Error at Assets\Editor\x64\Bakery\scripts\ftRenderLightmap.cs:1831 column 58
_____________________________________________________________________

CompilerError] 'LightmapEditorSettings.Lightmapper.Radiosity' is obsolete:
'Use Lightmapper.Enlighten instead. (UnityUpgradable) -> UnityEditor.LightmapEditorSettings/Lightmapper.Enlighten'

Compiler Error at Assets\Editor\x64\Bakery\scripts\ftRenderLightmap.cs:3108 column 55

 

Yup.

Reimport the package again, and when Unity asks something about upgrading the scripts, click "go ahead, I made a backup". Unity will automatically upgrade all obsolete API references in the code.

 

Apologies if this is a dummy question, however I'm having trouble baking spotlights in a scene. They have the Bakery Point Light component on them, but there's no illumination in the scene unless I enable the Light component. The settings match the directional light which does show illumination if the Light component is disabled, but the spotlights don't. Is that how it's meant to be?

If I want to setup a night scene with just streetlights along a road (the spotlights) how could I bake the illumination in this case? Thanks.

 

Here is another issue I am having with Lightmap Groups besides the one I commented on here: https://forum.unity.com/threads/bakery-gpu-lightmapper-v1-51-released.536008/page-44#post-4176181

In addition to the above when I use "Render Selected Groups" my other lightmaps that have been previously baked in my scene get misaligned. Black chunks appear on game objects that were fine before. I am selecting the parent game object with the "Bakery Lightmap Group Selector" attached and then selecting "Render Selected Groups" in the Bakery render panel. Am I doing this correctly?

A solution is just to bake all game objects in the scene together but that defeats the purpose of "Render Selected Groups" which is a nice feature for faster bakes.

 

Have a question for Multiple LOD levels check, can it be LOD0 compatible with gameobject with no LOD? For now it seems that if they mix together,bakery would throw a warning.

 

just updated 1.51, stuck on last step of writing maps into the foler. Strange..
I'm using shadowmask mode.

 

Seems like only happens with mask .tga. And I think I noticed a key phenomenon. When I taskkill the unity.exe and reopen unity, the .tga that was stucking would be generated into my folder. So maybe the program is fine but something else made it pause.

 

Seems like only happens with mask .tga. And I think I noticed a key phenomenon. After I killed the unity.exe and reopen unity, the .tga that was stucking would be generated into my folder. So maybe the program is fine but something else made it pause.

 

Are you using any scripts on your rock prefabs for instancing? I am having the same issue.

 

Just run into a compilation error with the Bakery Standard Shader. In Bakery.cginc, bakeryVertForwardBase is trying to reference o.PosWorld on line 318, but o.PosWorld has not been defined because UNITY_SPECCUBE_BOX_PROJECTION || UNITY_LIGHT_PROBE_PROXY_VOLUME are not defined.

I tried replacing this if condition with UNITY_REQUIRE_FRAG_WORLDPOS on line 287, but then the FRAGMENT_SETUP macro failed with no FragmentSetup function.

Any ideas?

 

Should work. Are receiving objects being mesh renderers or is it a terrain? Also maybe try increasing the cutoff value.

There are too many pitfalls with this button, so probably don't use it.

NoLOD and LOD0 are considered different LOD levels, so that kinda doesn't work yeah.

The whole atlasing system really needs a complete rewrite. I wonder what if I'll try to integrate THIS... could improve the FBX unwrapping as well.

Any errors in the console? Or is it like completely frozen?
The "hold on" dialog is Unity's so it seems like the editor is taking too much time to compress textures for some reason.

If any of you guys can send me a unitypackage demonstrating this issue (non-emissive object emitting light), that would be VERY helpful, as I'm not sure how to reproduce this. The only possible cause I know is related to emissive/non-emissive objects sharing the same texture atlas, but it doesn't seem to be the case here.

Seems like an unfortunate combination of defines in the shader. How does the material is set up/by how many lights is it affected/is it forward or deferred/I assume it's using a box-projected cubemap probe? As with the previous problem, a unitypackage with a bugged sample scene would help a lot.

 

Thanks for getting back to me. The scene is just mesh renderers (no terrain). Where's the cutoff value you mention? I just used the default (simple) bake settings with Render mode = Indirect.

A couple of comparison images showing my settings on the spotlight:

 

Cutoff = Range (forgot I renamed it).

The problem here is that you're using Physical Falloff on the light and it fades out faster than Unity's realtime (non-physical, pretty arbitrary) falloff. Remove the physical falloff checkbox, and they should match. Or increase the range.

 

Thanks Frank,

As a simple solution could I attach a component to each Unit/bakery setup light to set 'light.shadows = LightShadows.None' at runtime?

 

Any news on the Bakery Standard Shader compile error? I did send a repro project in a private conversation.

 

Thanks for your help! Disabling physical falloff and extending the range helped sort the problem.

 

Hey, sorry for the delay. I opened the project and it looks fine. However, I don't have Android stuff installed for Unity, so maybe it makes a difference. Will install tomorrow and test again.

Not sure it will work, but try it.

 

Hi Frank I was wondering if it would be possible for you to integrate something like the occlusion probe system as seen in the Book of the dead project? It seems very fast and efficient to just drag a large box around the scene and press "bake" for those I know that there's already the occlusion probes support in the Bakery asset, but just wondering if it would be a good idea to do something like this. Thanks

 

That's a great idea indeed, but a bit out of scope of Bakery. I already have a huge pile of features to support. I still will make an additional volume-based light probe system though, so perhaps will be close enough.

 

Oh boy, look at this:




Good news for everyone having RTX cards Will try to integrate it as soon as possible.


If you have an RTX card and are willing to participate is some little beta testing, write me up!

 

I don't get the part saying: "RTX acceleration is supported on Maxwell and newer GPUs but require Turing GPUs for RT Core acceleration"

So.... RTX acceleration is supported on GTX 9xx and later but not really?
I don't get it.

 

Thanks a lot for your consideration, and I do recognize this is out of your scope I do wonder though, why is it that the occlusion probes in the Botd demo are so much faster than the light probes in bakery with "occlusion probes" checked? Is it because it bakes both the occlusion and the lightprobe itself? Can it be sped up in any way, if one was to bake occlusion for a large forest for example? Anyways top product, I'm really liking it and it beats the **** out of the current builtin solutions

 

Yeah it's a confusing one. The answer is

"On GPUs without RT cores the bulk of that new code path[i.e. the new RTX mode] will still be used for shader compilation, acceleration structure builds, multi-GPU support, etc. "

https://devtalk.nvidia.com/default/...is-supported-on-maxwell-and-newer-gpus-quot-/

So it's like the software path for the RTX can work on many GPUs, but the actual HW acceleration part requires RT cores.

Unity does not allow writing custom occlusion probe data, therefore they are processed by Enlighten/Progressive. The best I could do is to make sure they are not doing anything extra.
Light probes baking itself is also not very efficient right now as it relies on rendering regular cubemaps in the engine to gather indirect lighting (directional part is computed in the lightmapper though).
With the new probe system I'm going to offload everything probe-related to the lightmapper.

 

Awesome thanks!

 

Uhum... that's an interesting read.
Does this mean Optix will now be slower than before on GTX cards, since they are favoring a new RTX approach?
As per Nvidia's explanation, the new optix version is deprecating the GTX approach for a new one specifically done to make use of RTX cards:
"What it means is the new "RTX execution strategy" in OptiX, which is just a name for the new core OptiX 6.0.0 implementation. It's in contrast to the "mega-kernel execution strategy" used so far in all previous OptiX versions."

Call me a "planned obsolescence paranoid" if you will

 

Right now the old code path should work the way it did. The "RTX execution strategy" is enabled via a global flag and will run another code path then.

 

Hi, another newbie question:

After baking, the Unity light component should be disabled to avoid double brightness.

Is that because the Unity light is acting like a realtime light in these cases (even though it's set to baked)?

 

No, it's because Bakery doesn't actually mark the light as "baked" once it is baked.

I don't know why this guy called Frank thought it was a good idea to make it that way, but since he's a F***ing genius and Bakery is so awesome, nobody dares to tell him.

 

That's only because older versions of Unity don't have a way to mark light as baked. Newer versions allow it by modifying bakingOuput, but since Bakery supports anything from 5.6, there needs to be one workflow that supports everything.

 

I knew there was a reason.
Anyway, you know you can use compile macros for this kind of stuff, right?

Code (CSharp):

1. #if UNITY_2017_1_OR_NEWER
2.           bakingOutput.baked = true;
3. #endif

 

That's assuming the code that deals with this is in a C# script and not one of their libraries. If so then yeah that'd be a good option.

 

I certainly can, but then it will be kinda confusing if you switch from one Unity version to another and suddenly everything works differently.

OK, probably it will make sense as almost no one is using versions older than 2017.3 (riiight?... except me, who is still on 5.6 most of the time...)

 

I think a software should cater to the majority user base and normality of workflow.
This kind of thing is an anomalous workflow that people just have to know and still always forget, so I would hope everything that is not intuitively straight forward is mentioned with a warning text in the app dialog, or preferrably handled automatically.
In this case, if it's only necessary to be manual for Unity 5.x users, which exist but are a minority, I would give those users a warning text and handle automagically for others.

 

Although I am new, I have read the documentation and have made numerous bakes. I am learning a lot about the bake parameters and the relationship between computing time and the results quality.

In my scene, there are some windows with glass. I understand that if you disable shadow casting on window glass, the light enters correctly after the bake (without the need to have a realtime Direct light).

But is there any kind of material or shader that I can use? In the Unity baking, I can use the glass material while projecting the shadows of the window. Note: I'm doing a VR project with LWRP.

Thanks a lot!

 

Now I'm curious. Why?

 

And by the way, don't take my criticism badly: you know I'm your biggest fan
Bakery is the best light mapper I have ever used. It needs a coat of user-friendliness but it's still one of the must-have plugins in the asset store. If it doesn't win any prices from Unity this year, it only could be out of spite, since Bakery is so much better than their half baked and buggy light mapper...

 

Hey guycalledfrank,

So im running into an issue with ies lights I have a scene with 30 lights about using ies profiles and all i get from my bakes is black any ideas?

Thanks,
Mitch

 

Thanks @atomicjoe.

Next question for @guycalledfrank : is it possible for bakery to respect culling masks when baking?

This has been a bugbear of Unity baking for years and they're still no closer to fixing it: https://forum.unity.com/threads/are-baked-light-culling-masks-honored-during-lightbake.339948/

 

You can use Bakery's baking groups for that. No regular light culling masks though.
Check the manual.

 

Hello,
This question is not directly related to a Bakery question but more of a general lighting question.

I was wondering if it is possible to separate light probe groups so certain objects can be exclusive to a specific light probe group.

In my game I have no real time lights. !00% baked. I Do Use light probes in my level which overall I am happy with.

The specific game object I would like to have an exclusive light probe group for is my "coin" instances throughout my level. I want to use a simple light probe group for them. My reason is that I don't want my coins to be dark in shadowed areas in my game which will happen if they use the lightprobe group I have set up now. The coins "spin" and I want them to have a illuminated effect but still benefit from a simple exclusive light probe group.

Not sure if this is possible.

Thanks,
Raymond