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

Thanks. As a publisher myself, I understand about limited testing time. That being said, Archimatix was a runner-up for an Asset Store award in 2016 and is a popular asset.

At the moment, I have some tests I can run on my own, so I'm not blocked.

 

Well that is just awesome. That would allow us to do some better dirt in our ship museum without having to do secondary UV's and custom shaders with the new dirt layers.

 

Hi frank, can you guess why after I restart unity, I got different result? Maybe it's because of encoding or the scene?

 

Well, that shouldn't happen. Are you sure you saved the scene before exiting Unity? What Unity version do you use?

 

Can't wait to test with Bakery v1.3!!LOL

 

Yes, I use 5.6.3, and it's more a strange shader problem, my bad, never mind. BTW, we are already got v1.3 now?

 

OK, v1.3 was submitted just NOW!


Changelog:

- Added LOD support
- Added non-physical Indirect Intensity option for lights
- Improved shadow leak prevention algorithm
- You can now disable Point Light shadows by setting Samples to 0
- Added option to control minimum lightmap size in UI
- Added option to let Unity generate occlusion probes
- Improved packing for Lightmap groups with Pack Atlas mode
- Seam fixing step doesn't take too long to process terrains anymore
- Lightmap Group Selector components using Pack Atlas mode don't need to be added on every child object anymore
- Optimized area light sampling algorithm
- Seam fixer is now 64-bit, allowing it to handle larger scenes
- Fixed duplicated lightmap IDs
- Fixed incorrect shadowmask when many lights were overlapping
- Fixed bicubic filtering not working correctly for encoded lightmaps
- Fixed incorrect light probe positioning when LightProbeGroup is a part of complex transformed hierarchy
- Fixed real-time physical falloff acting inccorectly in deferred
- Fixed real-time physical falloff not working on Unity 2018
- Fixed shadowmask baking artifacts on shadowed faces
- Fixed crash sometimes happening during alpha buffer export
- Fixed errors when trying to bake models with 32-bit index format
- Fixed light probe render making objects red in 2017.3
- Fixed area lights looking pink in light probes
- Fixed incorrect light cookie rendering with very low resolution cookies
- Fixed textured area lights leaking memory during scene export and reduced their disk usage
- Fixed cases where models synced via version control could reimport multiple times due to UV adjustment

Plus some small bugfixes I don't even mention. This release is more about making it stable and more easily usable.
Next one will definitely have Directional Lightmaps, I promise

 

+1 on bugfixes first. Adding features to stable code is much safer in the long run.

 

A question: how do I bake a cutout material(actually I want it completely transparent), and in the meanwhile I can make the object emit lights to affect others? I tried several shaders and all failed with bakery.

 

This is useful for shore with water, I don't want water to cast shadow but I want water to cast lights to buildings.

 

So you want something transparent and emitting light? Maybe you can use Light Mesh for that. Check the example_lights scene, there is some glowing alpha-blended text
Having "self shadow" checkbox disabled on a Light Mesh will stop it from casting any shadows, but will still emit light.

 

Yeah, before your post, I've already done that with Light mesh, but the problem is the water is too big(island scale）, but it seems like that the sample is never enough.

 

Hmmm.. maybe then a regular emissive mesh, but also set Backface GI to 1, so it passes the light under itself too?

 

I tried again, light mesh maybe the best solution so far, it's kind of solved by decrease the GI intensity and increase sample to 1024. Still it's nice that we got lightmesh in bakery.

 

You can also try cutting your water mesh into two - one small around the island with high-quality Light Mesh and one distant with another Light Mesh using less samples.

 

Thanks! Will try. By the way, do you think it's possible to repack all uvs charts into one uv before baking, would save some space. I was trying to do that myself then pass the uv data to bakery, until I saw you got all uv process in frender.dll, seems like a dead end now. I was trying to fulfill what they did in frostbite and combine it with bakery, do you think it's possible or worth it?https://media.contentapi.ea.com/con...-precomputedgiobalilluminationinfrostbite.pdf

 

Possible except when you have multiple instances of the same object. Then you would either have to break instancing in favor of having individually packed UVs, or still have to pack those as usual.
It also presents a problem of either overwriting asset UVs with non-reusable versions or replacing scene meshes with new.

No, I don't All packing happens inside ftBuildGraphics.cs. frender.dll is a helper library that doesn't do anything significant (it's more of an interface between Unity and other libraries).

What bit exactly though?

 

Wow, nice, gonna take a closer look at them. I want to pack all mesh's uvs into one 0-1 range, and then bake only one lightmap per map rather than using texel per unit. And with all that uvs, I can get high enough usage, like 96% frostbite did.

 

Well... you can already sort of do that. Not by re-unwrapping, but by forcing Bakery to pack the whole scene into one atlas ignoring Texels Per Unit. This is what Lightmap Groups are for. They are a bit tricky to use in 1.2 though, should be much easier in 1.3.
Take a look at bushes in the Sponza example - they are assigned into their own atlas.
But yes, it won't help to get rid of empty spaces inside every object's UV layout.

 

I have no idea about the complexities of vertex lightmapping, or it's priority/interest. I am planning on using it in a test project with a mess of vertices on some objects(imports/automated from cad), while generating uvs on simpler imported objects(walls). Prior to that I tested some probuilder shapes with it(with your example shader), and when baked they look fantastic from certain angles but broken from others. Is this simply a limitation of vertex lightmapping or is there hope in the future or am I just missing a sampling option?

Spoiler

Two icospheres, other is smoothed with Unitys own import settings. Interestingly the linked Toruses appear clean and smooth in the most shadowed areas as if it sampled more from there.

 

Its cool, not sure if I would be using it tho,
To get it clear, the star mesh how does appear in the sphere, as a texture? is the mesh that is conforming the sphere? is a projector like thing?.. In 2018.3 some sort of decals are coming, can´t recall the name.

 

Currently there is no seam fixing or denoising performed on vertex lightmaps. If you have any splits in the mesh, these will be visible. Some bright splotches are due to the lack of denoising.
While seam issue is possible to fix, I'm not sure exactly what do with denoising, because it's hard to define the space in which the denoising algorithm should work.
What could help and what I should probably do is to specify the amount of sample points on vertex baked meshes, so instead of processing lighting for every vertex, it would instead sample many points over triangles and average them.

 

Aaand, v1.3 is available on the store now!

 

Meanwhile I'm adding a tiny little option that however makes a difference for me and maybe someone else. Selecting render mode individually for a Lightmap Group:



What it means is that you will be able to bake different parts of the scene differently - some will get full lightmap, some indirect only, some will use shadowmask. In practice however it's not easy to teach Unity how to work in such mixed mode, but with custom shaders it's very valuable. For example I'm making a scene where everything has complete lightmap lighting EXCEPT grassy patches where I compute some variation of shadowmask.

 

Hi! Real cool work, but when ever I try to bake with this, the exporting and prepare phases take a long time that the unity progressive light mapper ends up much faster. Is this normal?

 

select all and add components then match to existing lights, simple to me.

 

I get out of memory error, after that if I try to bake again forcing mem optimization option I Get this:
ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
System.Collections.Generic.List`1[System.Single[]].get_Item (Int32 index) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:633)
ftBuildGraphics+<ExportScene>c__Iterator0.MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftBuildGraphics.cs:3079)

 

I'd like to report this:

 

Hello, thanks for the update! Overall the baking seems a bit quicker!

Some points :

#
Upon importing, this exception still occurs requiring us to manually go through a couple of the scripts and comment out Terrain related stuff.

Code (CSharp):

1. Assets/Bakery/ftLightmapsStorage.cs(116,17): error CS1070: The type `UnityEngine.Terrain' has been forwarded to an assembly that is not referenced. Enable the built in package 'Terrain' in the Package Manager window to fix this error.

#
Was wondering if the 'Output Path' could either default to a folder named after the Scene with the same name as the scene... just like Unity does to store it's Scene related data, or a tickbox/option for this?

#
Could all settings be a scriptable object that we can drag in to override the bake settings? This would allow good control over the consistency of many scenes when required.

Thanks for the efforts with this tool!

 

It depends a lot on your scene complexity and the resolution you're trying to bake with. I noticed sometimes people are trying to bake large city scenes with default 20 texels per unit, but that's a very high resolution - not only export/render is slow, but they also get like 100 4096x4096 lightmaps in the end.. Maybe try setting it to 1, see if it works and then increase gradually if needed?

Now I feel very strongly you're trying to bake with a higher resolution that needed.

That's very interesting. I'd like to debug this, but I would need some scene from you where this bug is reproducible. Heard about this error more than once, but all my scenes seem to work fine.
However, you should be able to bake most scenes without the optimization.

Same as above.

Ah yes. Sorry, it's still in my TODO list, but didn't make the cut for 1.3.

Can be an option. On the other hand, Unity gives lightmaps random names like "Lightmap-0", but Bakery defaults to using scene's name like "myscene_LM".

That's a good idea, given how many settings there are now. Noted

 

Hi, bakery 1.3 crashing on my scene (10 texel per unit, ~1 mil poly) with cuda error. Also on some settings its crashes with non informative error (im-something, will take screenshot on next crash, reproducable in 1.2 too)

 

Same scene but now with 5 texel. After that error editor always crash

 

What happens if you set GI VRAM optimization to Force Off?

 

Before implementing proper directional lightmaps, I made another little option that works similar to Beast in Unity4 - allowing you to bake normal map influence inside the lightmap. This is just a single lightmap, not directional:





It's useful for mobile platforms where texture memory/performance is a problem and even for LODs on high-end platforms.

 

Good stuff

 

Yeap, with Force off the bakes is successful. Thanks

 

I have small problem - after last update (1.3), if I setup equal max and min resolution of lightmaps (4096 for example), I will bake 12-14 almost empty lightmaps, and 2-3 almost full. Is it possible to control count of lightmaps?

 

Do you happen to have any LODs? Each LOD level* has to be baked to a separate atlas, but if there are not too many objects on one level, they won't be able to fill a 4k lightmap. In this case it's better to leave minimum size small.

*Bakery splits the scene into global LOD levels based on different LODGroup distances. Several objects showing up on approximately the same distance will join to form a global LOD level. These then get dedicated atlases. LOD0 can't share the lightmap with LOD1, etc.

 

Yes, I have a lot of props with LODs. Ok, I will try to decrease Min Resolution. Thank you.

 

Looks like 1.3, which I just downloaded today, is doing better with Archimatix. I've still got some warning messages, and I found that you have to "Stamp" the AX models out to static objects, but I am at last getting Bakery lightmaps, at least for my simple objects tested so far (an arch and a box). I've got some further work to do, and it looks like there might be a Unity bug with the generation of UV2 maps, but at least I have some progress.

Edit: Bakery reports that the AX models are missing their UV2 maps, even though I told AX to generate them. I'm looking into things to see whether they're really present or not, but regardless, Bakery now seems to be working with stamped outputs from AX. So apparently missing UV2 maps are not fatal to Bakery. Do I have that right?

 

Hi! I'm actually baking with resolution 2 only. However I'd like to mention, my world consists of 3000 sectors(additive scenes). It does bake with unity's progressive if I up my swap space to 100 gigs on an ssd drive. It just takes a few days to bake. I'd like to use bakery's GPU baking so that the turn around time is shorter but with bakery it just has out of mem exception. Do you have any advice?

Thanks.

 

Yeah, I just removed the silent skipping of meshes with UVs having unexpected range. They should still be packed properly.

It will use UV1, if UV2 is missing, yes.

Hmm seems like your world is indeed a very big one. Do you have any screenshots to help me get the idea of it?
GI VRAM optimization seems like the way to go. In which case we need to go back to:

Can you strip the world down to a small scene that still generates this error? I'll be able to properly debug it then.

 

After I changed to force no vram optimization and changed resolution from 2 to 1, it managed to bake, the results are quite good! Only thing is when I press bake light probe, the probes are way too bright, and lowering the directional light(my only light source) and baking probe again, the probes don't get any darker. Do I need to rebake the scene then press bake probe for changes to take effect?

 

Hey Frank,
i broadly can not understand the area light lighting ... i have some emissive lights (objects with emissive material) and setted up an Area light and give a Bakery Mesh Light component to it (project is already switched to linear)
and i copied the area light details (values) to bakery ....
1- Waaaiitt
2- KAAABOOOM Baby !!!!
3- Waaaiit for the magic ^_^
4- Cry (nothing)

is there any exact steps / tutorials on how to work with area light ?
p.s: Match light to material, Match material to light there is no button as this In the area light the names are completely different as :
Match Lightmapped to area light, Match Area Light to Lightmapped

Regards.

 

Hmm can you make a screenshot of a probe or something lit by it? The problem might be not in the probe value, but in the lack of dynamic light occlusion information in the probe (so dynamic light on top of the probe is unshadowed).

Completely nothing? Is this light close to any surface (maybe the attenuation is short?).
There is a scene called example_lights with a bunch of working area lights.

Yeah, Light Mesh can copy values from/to both mesh renderers AND area lights. The buttons you see depend on which components are on the object.

 

http://xgits.com:8181/uploads/tar/images/m_e45e1849afc0beea51179b1ea25184ab_r.png

Hi Frank, my scene is big, but I used to be able to bake with 1.2, do you have any solution?

 

This error has nothing to do with baking, and Bakery in general. Seems like Unity failed to execute EditorSceneManager.SaveOpenScenes(). Why? Good question. Not enough RAM/HDD? Maybe ask Unity devs

 

It's interesting that in Unity, UV maps have to have coordinates in the 0..1 range. When I make models in Blender, there are times when you may deliberately make a UV outside those ranges. Suppose you have a square object, just two triangles, and you are using a tileable texture (for instance, a smooth painted wall). If you want to tile the texture so there are two tiles in each direction (four tiles total over the square), then you just scale the UV map accordingly, and this would result in UV coordinates from (0,0) to (2,2).

In this scenario, if you wanted the UV coordinates to remain within 0..1 range, you would have to add vertices to the model for no other reason. Yes, you can globally scale the material tiling in Unity, but if this texture is used elsewhere at a different size on the same model, that solution would result in undesired tiling for those other places.

I'm not disputing the 0..1 expectation in Bakery -- I consulted the Unity manual, and you are absolutely correct that this is the documented Unity behavior for the UV arrays on the Mesh object. I think I'm going to post to the Unity asset import forum to get some clarification on how this is supposed to work with respect to external modeling tools such as Blender, because I need to understand this better.

In any case, thanks very much for the workaround; my project with Bakery can now move ahead. I'm excited that I'll soon be testing it in my real scene!

Thank you for that feature! It really helps as a fallback while I work with the AX developer on a permanent fix.

 

p.s. great work on this asset and superb support. I am glad you support LOD now as I use that throughout the world.