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

Alright, makes sense. Just added automatic baked/realtime/mixed mode switching for Unity lights. Check the github

If material alpha is < 50%, it will be transparent.

It works. Jumping with your project from version to version can introduce new bugs. Will have to do it some day due to SRP, but not now.

Wow! Thanks!

Hi Mitch. Can you test a single IES light in a simple scene (e.g. a plane)? Can you also check the one IES profile included in Bakery in the same scene (AreaLight.ies)? If my file works, but yours doesn't, there might be something funky about your IES data. Perhaps it's formatted differently and it confuses Bakery IES converter. If you can, however, get your IES working in a simple scene, but not in the main scene, perhaps there is some unrelated problem.

Bakery has its own culling mask system, namely the "bitmask" option on every light. The only problem is that it's not Lights vs Objects, but rather Lights vs Lightmap Groups. If you group multiple objects in a lightmap group (there is a chapter about them in the docs), you can set the mask for this group, and it will interact with lights' masks.

Not really (or I don't know how). In Unity light probe groups are just dummy editor objects. After the lighting is baked, all groups are combined in a single global grid.

What you can do though is to send your own light probe coefficients to the shader. If you run your game with Frame Debugger, you will see all dynamic objects receive constants with names like "unity_SHAb", "unity_SHAc", etc. This is interpolated light probe data. You can try creating a MaterialPropertyBlock for the coin with your own vectors, and they will likely override the default ones.

 

I noticed that the double-sided feature you added to the bakery shader doesn't work on opaque or cutout material settings. I believe the UBER shader has a workaround to this but I was wondering if that is a limitation of the engine, or if you could edit it so it works on opaque surfaces?

 

Hmm really? Just checked, and it seems to work. What version of Unity are you on?

 

Hey,

I ran the lightmapper a couple times on a scene I already had. I'm just getting started in terms of using the asset. I noticed that a bake failed due to a loss of hard drive space. It appears that the lightmapper is adding a folder here:

C:\Users\myname\AppData\Local\Temp\frender

That folder quickly rose to 10 GB in three bakes. I'm guessing it's a GI cache of some sort or perhaps the lightmaps are just getting stored there. Is it possible to change that location? I have a smaller sized hard drive for my operating system that gets clogged fairly easily, but I have a slower, larger hard drive that I put large file or data sets to.

 

Yes. Change settings from Simple to Advanced, and you'll see a Temp Path button.
Also you can clear the folder whenever you want (but not during the bake).

 

I found it. Thanks for the quick reply.

Another question, I have Distance Shadowmask set for the Render mode. I'm seeing my dynamic light flicker when casting shadows onto objects. Is there a way to fix that? Is that just an editor problem and not something I'll see in a build? If I turn the dynamic (Unity) light off it removes the flickering, but I lose the light I would normally have on the character. Am I doing something wrong? My lights are set to Indirect because I want them to provide indirect lighting. Should I set them to Shadowcast instead? Will they still provide Indirect lighting or is this an either or scenario?

What settings should I have for baked/indirect/gi lights and shadows for static objects alongside real-time/Unity?/light and shadow for dynamic objects? I don't think I need real-time shadows on top of baked shadows, but that's what I seem to be getting and the shadows seem to be tied to one another meaning if I turn off the light altogether I lose my real-time light and shadow as well as the baked light and shadow.

 

I never heard of that before - can you record the flickering? Sounds more like Unity bug to me. Dynamic lights are governed by the engine, I don't do anything to them (apart from setting mask ID after the bake).

You'll need both Unity and Bakery lights on the same object, with latter having the Shadowmask checkbox enabled and Bake To Indirect disabled.

They shouldn't be on top. Should properly mix together and look like one combined shadow.

 

I have had things like that happen to me in the past.
It seems to be an editor only thing. It fixes itself randomly and don't happen in builds

 

I have a direct light setup as a Mixed light. After I have baked and run the scene the light is still lighting everything that has just been baked (if I turn it off, I can see that the baked lightmaps are being applied). It's also shadowing everything as though it's just a realtime light. All involved gameobjects are fully static. Bakery is set to Shadowmask mode. The light is setup as below. What am I missing? Thanks.

 

Try clicking on the little arrow with 3 lines in the top of the inspector (next to the little lock) and set it to DEBUG.
Then go to your mixed baked light, inside the BAKINGOUTPUT property and set the ISBAKED propery to TRUE.
Now reset the inspector to normal mode.

This is happening because Bakery is not setting the baked lights as baked for compatibility purposes.
Future Bakery versions should fix this for Unity 2017 or newer versions.

 

Thanks atomicjoe. But that fix does not make any difference in 2018.3 and the IsBaked setting is unchecked again at runtime. Checking it again at runtime makes no difference either. So bakery is effectively useless. I have spent so many hours on this.

I am blown away by this information. Where is this documented? Shouldn't it be scrawled in a massive font across the top of every page? Why is it not mentioned on the asset store? It says it supports up to 2018.3, which clearly it doesn't.

 

If it makes no difference, then it's not because of marking the lights as baked or not.
It may be another problem.
I understand your frustration, but be assured @guycalledfrank will fix it.

 

Apparently you're missing the fact you're in Distance Shadowmask mode, and it was covered in FAQ (first post), as well as in Unity docs, etc.

wat?

wut?

 

I am on 2018.2.2f1. Double sided for the bakery shader only works on transparent materials, fade, transparent, and cutout.

 

Ahh yes. My bad. Seems like it doesn't work in deferred, and I was only properly testing it in forward. I updated in on the github. You can also fix it in the shader with just one line:




Add

Cull [_BAKERY_2SIDED]

to the DEFERRED pass definition in BakeryStandard.shader or BakeryStandardSpecular.shader.

 

EDIT: nothing, I made a mistake...

 

Hi Frank. The project is just using Shadowmask mode not Distance Shadowmask. We're using that setting since it says in your docs:



so we understood that as the rt light would only be shadowing the dynamic objects, not the static ones, but this mixed light seems to both shadow and light the static objects as well as the dynamic ones.

Sorry for my tetchy tone earlier, I've got a close deadline so a bit stressed out.

 

Interesting. Can you show a screenshot of the scene with Unity light on/off?

 

Hi,

This is with the direct (mixed) light off at runtime and shows the baked maps.



and this is with that light on:



Maybe this issue is because our scene is a multi-scene? There is a master subscene, that is the active scene, and contains the Unity/Bakery lighting settings. Then there are 4 art scenes, which have all the geometry and lights (mostly baked - they work fine), and a common lighting scene that just contains this one directional mixed light. These are the lighting settings:



The settings for this mixed directional light are in my earlier post.

I hope this helps.

 

Weird... perhaps the settings used for the bake are coming from another scene? Can you check if baking a single scene works?

 

Morning Frank,

I've done another bake with just that one light and everything in just one scene. The mixed light now works as expected.

This morning I'll prepare the entire scene and do another (it takes 4-5 hours to bake) and let you know how it goes.

One thing... we've noticed that the 'Lightmaps' dropdown in the MeshRenderer component no longer have any refs to the baked LMs. Like this:




What is the simplest way to tell if an object is properly lightmapped by a mixed light?

We've also noticed that sometimes when we do Bakery->Clear Baked Data, it also resets all the settings to the default. Is this intended? It is sporadic.

Thanks

 

Hey, @guycalledfrank, just wanted to publicly thank you for your quick fix to the Bakery Standard Shader. We've been doing some experiments over the past week into getting the best visuals for mobile VR, and we just wanted to say that Baked Specular Lighting is amazing! We were so disappointed when Unity removed Baked Specular from their Enlighten offering, but when we searched and found that you'd added it into the Bakery Standard shader, we just had to give it a try! Compared to other solutions, Unity LWRP does not yet support Shadowmask baking, only Subtractive, and has a limit of 4 concurrent Realtime light sources. In terms of the Standard pipeline, Bakery Baked Specular blows the performance of Standard Forward & Deferred Shadowmask out of the water. It's perfect for Mobile VR. The following screenshots are taken from our test scene - ALL lighting in these scenes is baked, they all bake in under 10 minutes, and they all run at a solid 60fps on Oculus Go & Gear VR!

*Please* continue to support this feature, because there's nothing else available like it right now.

BEFORE:

AFTER:


BEFORE:

AFTER:


BEFORE:

AFTER:

 

Hi, I've been following this thread for a while. I am an architect and passionate about archviz. I have no Bakery, I'm exploring the Unity world now. For work I use 3d traditional 3d applications Max - Revit - Archicad etc ...
I would like to run for RTX beta. My configuration is:
Laptop Lenovo Ideapad Y910 17.3 - WIN10 1809 - 32GB ram - GTX1070 8gb - 512SD - 256SD - 1TB HD - External RTX 2070 as primary card (Omen GA1 Graphic Accellerator Thunderbolt 3) external and 24 Monitor.
Nvidia driver 418.8 (last).
Ciao

 

Just in the middle of a bake. I'm getting loads of logged errors here:

Float overflow
UnityEngine.Debug:LogError(Object)
ftBuildGraphics:exportVBTraceTexAttribs(List`1, List`1, Vector3[], Vector3[], Vector2[], Int32, Boolean) (at Assets/Editor/x64/Bakery/scripts/ftBuildGraphics.cs:422)

Can you explain what causes that and how i go about addressing it?

ta

 

Hello,
we are using Bakery for a few weeks now and getting errors if we try to bake in higher resolutions.

Above all, we are constantly getting various ftrace errors :-(
We are using a GTX 1080 and trying it on differend machines. Sometimes it runs and on the next day everything crashes. We have no clue what we are doing wrong.

-currently facing 719:

-here are the scene settings:

additionaly attached, the ftracelog.

 

I noticed that does indeed happen on 2018.3 and newer versions. As well as other oddities. These things are out of my control - it seems like Unity stopped reading any values assigned via scripts and only uses the ones from Lighting Data Asset (which is not writable).

In > 2018.3 you can only judge it visually. Dynamic shadows usually look differently.

Yeah, it basically clears all Bakery data from the scene... including settings. I should make a more detailed clear dialog.
Also, if you need to reuse same settings on many different scenes, you can try creating a Lightmapped Prefab with them (there are save/load buttons). This is not exactly the main purpose of the component, but it can be used like that.

This is really nice!

I did some RTX benchmarks already and not actively looking for testers right now. I will write you if more testing is needed

RTX status so far:
- RTX mode on RTX cards is definitely an improvement. Actual speedup depends on the scene. Perf boost reported varied from +20% to +400%.
- RTX mode on non-RTX cards (emulated) performs worse that regular version.
- I need to rewrite alpha testing for RTX because of some architectural differences (basically I was directly computing intersections with alphatested triangles, but now the intersection is done in hardware, so I need to do it after it's found a̶n̶d̶ ̶g̶e̶n̶e̶r̶a̶t̶e̶ ̶a̶n̶o̶t̶h̶e̶r̶ ̶r̶a̶y̶ ̶i̶f̶ ̶t̶h̶e̶r̶e̶ ̶i̶s̶ ̶a̶ ̶h̶o̶l̶e̶.̶ ̶I̶ ̶h̶o̶p̶e̶ ̶i̶t̶ ̶w̶o̶n̶'̶t̶ ̶b̶e̶ ̶m̶u̶c̶h̶ ̶s̶l̶o̶w̶e̶r̶.̶.̶.̶)̶
EDIT: finished alpha testing support, seems to work. Was easier than I expected.

Might be caused by too many lightmaps generated. How many are there?
What happens is that the script is trying to pack two numbers into one, first being lightmap ID, second being lightmap U coord. This is done to save bandwidth during tracing. After packing the values it tries to validate them by unpacking back and comparing. If something is different, this error is printed. Can happen by either of values being pretty huge or NaN.

300 texels per unit is quite extreme. What are you baking?
All other settings look reasonable.
The log is weird. Seems like the GI VRAM optimization preprocessing step is crashing for some reason. It's hard to say why without the scene If you set it to Force Off, does it crash, and if so, on which stage? Can it crash on "Adjusting sample points" or any light? If it does, might be somehow related to scene geometry/alphas.

 

Please do. I have been looking at applying xatlas to my workflow, but have not yet done so. Integrated with Bakery would be interesting, and you would undoubtedly do a better job than I.

 

Today its running... somehow.. ^^° I started a test render on our dev notebook which has 2 x GTX 1080. On my dev PC i tried a test render on a dublicated scene. Well, both ran till the end

One weird thing is, my PC with a single 1080 was faster (1h8m) than our dev notebook (1h43m).

For one of our customers we have an indoor showcase scene. He wants to use this for marketing purpose and should be correspondingly high resolution.

It shows the same behavior, no matter what is set.

The next time it crashes I look in the message window.

A thing in which I am uncertain, are the following messages. My 3D Designer can not explain this either.

But they appear everytime i start Rendering...

In the future, I will take a closer look at the error messages and document them.

Btw, we are using perforce as version control and always have to manualy check out the "Editor" folder. If not, we get errors on start rendering because bakery has no access to .denoiserlog.txt / .ftracelog.txt / .uvgblog.txt. ("as far as I can tell")

best regards
Thomas

 

Right, we are getting 100s to 1000s of these errors. But not in every bake. Almost every time we bake something is different, even with the same scenes.

There are < 100 lightmaps generated.

Does this invalidate the baked data then? What should I be looking for?

So only sometimes it does this. For my last half a dozen bakes Bakery->Clear Baked Data did not clear the Bakery settings. Is this going to affect the bake?

 

I had the impression you were using Unity's built-in atlasing system. Is it the case?
How would xatlas improve on that?

 

The implication being that he would stop using the built in one and implement his own.

The Thekla Atlasing tool is pretty excellent.

 

That's a large difference indeed. The second thing Bakery uses heavily after the GPU is... hard drive where the temp folder is located. If the notebook has a much slower drive, it might be a problem... but still, I wouldn't expect such difference.

- Are these objects manually unwrapped for lightmaps?
- Do you use Lightmap Groups?

Hmm. Bakery creates the files if they are not present. Or does perforce somehow mark them as read-only?

I don't. I use the built-in unwrapper (unwraps individual meshes), that is true, but not the atlaser (scales and packs many UV layouts together - it's custom, because Unity does not expose any API for theirs). Both are not great.

 

Got some info for you. I added some more info to your logging. The errors now look like this:



So it seems when unpacked there may be some small precision errors yeah? Would this result in small visual artifacts at the edges? We can live with this at this stage in our project.

 

Hello. I'm using unity 2018.2.11.f1 and bakery 1.45. When rendering, i'm getting this effect in two or three objects. It doesn't happen when i use unity only. Any idea whats going on?

 

Seeing lots of warnings of this type:

"xxx can't generate shadow mask (out of channels)."

Is there anyway of mitigating this? (What is the cause of it?)

ta

 

Unity 2017.4.15f1 have a similar issue on some combined Unity_Point / Bakery_Point lights however its not so much as a flicker as its more like a culling on off at very close range (Unity spot light) , the baked point light looks ok … I solved this by changing the render mode to important however I am not certain if this is the best long term solution

 

1.51 update fixed the error is was having. Thank you. Any chance you will add tessellation to the bakery shaders?

 

Theres quite a lot of pages here, but I would love to know if there is a page that already addresses the large file sizes associated with the bakes? I would love to hear or see a routine from someone who has optimized their workflow. Right now the bakes are coming out massive 5-10gigs in some cases, and the scenes arent too big with low settings in bakery.
Thanks!

 

Yeah in this case it seems to be not too bad.

Possibly the object has a very small size in the lightmap. Try increasing Scale In Lightmap on its mesh renderer. You can use Checker Preview to see if it's enough.

Apparently you have more than 4 overlapping shadowmasked lights. Unity does not support that, so some lights won't bake the mask.

Probably not - there is already too much stuff in there and adding more features than Standard shader and Bakery support can introduce more bugs.

It is the scene file size?! Or the lightmaps?
Regarding scene sizes: yes, Bakery can add some useless (after the bake is done) cached data to the scene. Will fix it. For now you can grab the attached script and click Bakery->Clear useless data

 

Any tips for collaboration with Bakery?
For example for 2 people baking and pushing Lightmaps to a repository?

ftGlobalStorage and ftLocalStorage should be ignored when committing right?
Anything else?

 

That's it. Everything should work

 

I been having some good results using Vacuum beast2018 shader for tessellation

 

Do you know where I can read about this or see where to get a fix? Or if this is fixed in 2018.3? I've been wracking my brain trying to figure out why my lighting won't bake in 2018.3 and I have single passs vr and linear lighting.

 

No, sorry. I only remembered it from the release notes. I don't do VR.
I would try Unity 2019 beta and see if it's fixed there.
Make a basic test project and test it both on 2018.3 and 2019
You can also share this repro project with that guy named Frank. (the 2018.3 version of it)

 

Any way possible to gain a copy of the RNM / SH shaders that has the related script embedded inside the shaders rather than loading at run time ? this question is posted for its use in VRchat games as bakery is not currently whitelisted with VRC

 

I'm having trouble getting lighting to work with larger scenes. I've gotten bakery to work great with smaller scenes, but as soon as I add more of the same tested assets, bakery decides to lightmap everything to pure black. It's definitely working hard to accomplish this too, as my bakes take multiple hours on larger scenes. I don't think it's a VRAM issue, since I've been monitoring the vram usage in task manager. I have a 1080 with 8gb or vram. Most of my scene uses emission materials for lighting. Any ideas?

 

Last night we started another render. To our regret, we had to realize this morning that he has crashed at about 70%.
Since our deadline is fixed and we depend on bakery, we have to work through our open points list:

Yes they are manually unwrapped for lightmaps. No we dont use Lightmap Groups.

We have found out that the UV error messages come because we are working beyond the 0-1 range. is that correct? Does Bakery has problems with this???
We do it this way, to have a uniform UV-scale in relationship to world-scale across all meshes (important when applying different materials). More in the image.



In further analyzes, we also found out the following:
-Space saving packing of UVs causes stretched UVs in lightmaps (seems to happen when the bounding box of UV shells is equal or less than a "square cut in half"-rectangle)!
-To fix this we, we found out that we have to distribute UV shells so that the bounding box of the shells comes close to a full square... This, of course results in wasted texture space, high memory usage and probably a bit of baking performance loss...
More in the image.



What should we do to get a good result? For example, with the two different quads: A, the texture should have the same relative scaling on both meshes, and B, the lightmap should not be stretched and its scaling should also be relatively the same across objects (without having to manually adjust the "Scale in Lightmap" multiplier).

In general: According to which criteria does Bakery position and scale the UVs of meshes in the atlas? Why are some small meshes huge in the atlas, while some big meshes appear only small?

If we accidentally commit them, Yes it does.

Todays crashes are ending in "out of memory" errors, when Bakery is starting "Rendering GI" (as i could observe).

also see .ftracelog

Since we got much noise in dark places in our last rendering, we have increased Global Illuminaton to 32.
And since its crashing all the time right now, we have reduced Texels per Unit to 250.

On top i have duplicated the scene, and started the bake on that one. I have observed, that somehow, the rendering wont crash then. Can there be something to it?
Right now it got over the critical 70% mark...

best regards
Thomas

 

fyi

my question in
https://forum.unity.com/threads/fee...on-render-pipeline.560653/page-9#post-4194913

....
Would it be possible to allow custom lightmaps ( e.g. Shadergraph) and a more open and transparent lightmap asset would be great too.

To have this hard dependencies to Enlighten and Progressive who still have a longer way to go makes everything really complicated.

In our case we iterate the scenario to an fotoreal target quality and bake Lightmaps in Blender Cycles which is in terms of speed, quality, scallings and costs is benchmark for our needs.

Bakery offers some great new possibilities too.

Would be great when if is more easy to inject custom lightmapping to the HDRP.
SRP.)
....

and the answer from SebLangarde...

Hi, can't speak for the lightmapper team, but we have added in ShaderGraph GI inputs (this is in the 5.3.1 changelog I posted). Mean you can provide your own lightmaps / Custom baked GI through shader graph, or tweak the result of existing one (or provide orther UV set / Normal)

There is also callback in the Lightmapping system so you can do some post-step, but I don't know much about it.

[Edit: Just see the screenshots in the answer after your question, this is it]

 

We got the same issue today :-( 6h baking for a pure black scene... At least it didnt crash

Started a new one with 200 Texels per Unit...

 

Can anyone here give advice regarding light probes being too bright for dynamic objects in the scene. I have some baked lights with a fairly low intensity (which bake fine) and then I render light probes (setup around the lights) but nearby trees are lit up as if they're in intense sunlight.

As it's a night scene, and I'm relying on just the baked lights, the scene's ambient colour is set to pure black.

Do I need to select the "Occlusion probes" option when rendering the light probes, and if so, how should I setup the occlusion probes to work best in the scene?

Thanks!