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

Thanks for the quick reply. I've tried baking without it which seemed to get further with the bake but then I was getting editor crashes on occasion. I'll see if I can reproduce a crash and get you the resulting log file.

 

OMG, a camera path tracer with results that match/previz the final lightmapped result would be amazing. I'm guessing that could be used for offline renders as well?

 

If you can, also send me the .ftracelog.txt file.

It can be, but I'm not sure how useful it can be. Bakery doesn't get complete material information from Unity, so it doesn't even know about surface specularity.

 

I get the following 2 errors when running without GI VRAM optimization set to Force Off

Error: 1
UnityEngine.Debug:Log(Object)
<RenderLightmapFunc>c__Iterator2:MoveNext() (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:3152)
ftRenderLightmap:RenderLightmapUpdate() (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:2175)
UnityEditor.EditorApplication:Internal_CallUpdateFunctions()

In this case the editor didn't crash just the bake failed.

 

Right. Looks like you really need the optimization working. But I can't help unless you can share a scene causing this bug with me. Alternatively, reduce Texels Per Unit value. If you have more than 4 GB VRAM, then it's very likely you are just trying to bake with extremely high resolution.

 

ok, thanks Frank. Unfortunately I can't share the scene. I've got 8 GB VRAM so I'll try reducing the Texels Per Unit and report back.

-Looks like it was related to Texels Per Unit. Had a few objects in the scene that were too big at the resolution I was using.

 

Hello,
apart of outstanding quality achieved with Bakery GPU I have question about lightmap size.
I have world build with World Streamer and I loaded part of it to perform bake. So in main scene I have let's say 6 different scene files and every one has got different assets.
After bake size of scene file increased from hundred of KB to hundred of MB - for each scene file. If I understand it well - lightmaps are saved in BakeryLightmap folder - so why each scene file is so heavy?
Did I missed something?

 

Good question. There is some lightmap metadata saved inside the scene (in an invisible "!ftraceLightmaps" object). Sometimes it can get big. However, only a small fraction of this metadata is really needed in builds - everything else is only useful for development, and I can likely shrink this data quite a bit in any case. Didn't realize it can make a difference. Noted.

 

This is how it look in explorer:


Meta file is still small but Unity scene file size increased.
and for now lets say I have 200 levels like this to stream. I build it parts and Baking is not a problem but size

 

I am running into all kinds of pop up errors when I try to render out my light maps. First off my scene is set up for mobile (Oculus Go) when I click render I get the following errors twice in a row.

Null Tex PTR
Null Emission Tex PTR

Then when its building at about 55% I start getting more pop up windows, I can't see them all because the progression bar is in front of them. Here are some that I found.
Cant create vertex shader
Cant create Quad.vso
Cant create skyoutput.pso
Cant create cookie output.pso
Cant create vertex buffer
Cant create index buffer
Cant create rasterizer state
Cant create constant buffer

Also at the end something about a Gbufffer error

then it basically crashes my Unity I cant access any menus and the only thing I can do is X out of the program.

plus sever more that I couldn't see to write down, what am I doing wrong? I followed the set up of the bakery to the directional light and skylight in the Manuel.

 

I'm really sorry about that - I'll try to minimize this data in future updates.

Feels like it can happen when your editor is not running under DX11. Bakery is only compatible with DX11 editor mode and shader model 3.0 (at least). If you're under OpenGL or using graphics emulation option, it can be a problem. I actually added a test for the active shader model emulation in the upcoming update.

 

Hi Mr F !

I recently made a thread about an issue i am encountering with bakery, if you don't mind looking at it, you might be able to tell me if it's asset related or if my project is the cause of my problem. Thank you very much for the great tool !

https://forum.unity.com/threads/lightmap-uvs-are-created-but-meshes-are-black.568510/

 

Hi! So it seems like whatever you bake, you just get black color?
Can you try baking not your complete scene, but a smaller one, maybe just one asset and see if it works?
What shaders are you using? Are they compatible with lightmaps in general?

 

I Up vote this fix!

 

It works with a regular plane/cube/capsule, but somehow doesn't with an object and my terrain.
I'm using Game Shaders Volume 1 for my objects and a custom Forge shader for my terrain, simple splat texture blend.

 

Thanks for the reply I went into my "Graphics Emulation" and set it to "No Emulation" and was able to switch my project to DX11 and was able to build my light maps successfully! At the end however I did recieve a denoiser error 505, I am assuming that has to do with the Nvidia AI denoiser? I looked but couldn't see how to turn it on or off, I am assuming there is a setting for it somewhere?

 

Seems very likely that your shaders don't support lightmapping. Did you try baking them with built-in shaders previously?

Denoiser can be turned off in advanced settings. This error is usually fixed by updating GPU drivers though.

 

On the screenshot i provided, my table was using the standard shader, and it's not even casting a shadow on itself. Any other idea what it could be ? Maybe a lighting tab setting or something to do with how i baked my lightmaps in the first place ?

The only discernible difference i can see between baked and non baked objects in my scene (if i duplicate my table for example) is that the non baked table has Light Probes options in the inspector while the baked one doesn't, it also looks lighter than the duplicate.

 

Hello Frank,
I have a question regarding baked Shadow Masks.
In one of your previous posts, you explained how shadow formula works.
On one of the pictures you demonstrate that your baked Shadow Mask looks like that:


But in v1.3 it actually looks like that (Faces opposing light is black):


I understand that shading opposing faces would help to prevent unwanted light appearance.
But on the other hand, it is hard to make good looking attenuation with low-poly hard-edged objects that use strong normal maps on the edges areas, like bevels or stone breakaway.
So my question is: Do you have any plans to add Shadow Bias parameter for lights or materials in future versions?
To make Shadow Masks looks like this for example (do not take the green color into account ofc ):

 

The self-shadowing is not that obvious on both screenshots. Possibly the lightmap resolution is too small to represent this shadow accurately.

Yes, it was originally like on the 1st pic, but then I changed it, because normal maps could potentially catch light incorrectly in shadowed areas.

It's a general problem of combining geometry-based ray-traced shadows with fake normals. I wanted to avoid shadow bias and instead make a solution that just works most of the time, and I think it does a good job currently with lowpoly meshes using even very distorted vertex normals. But because lightmapper has no information of a normal map applied, it can't properly adapt to it.

I don't feel good at all about it... shadow bias can bring more problems (like peter-panning) than it would fix. People will see a new setting and start massively using it for no reason, making bad shadows and blaming me

Of course the best option would be if you had at least 1 polygon for bevels with smooth vertex normals.

Also: v1.4's "Baked Normal Maps" mode actually exports the normal map (albeit low res) and allows the lightmapper to properly adapt the bias. Hmmm. So perhaps the real best option would be taking the normal map into account specifically for shadow masks. That's the most promising idea, I think. Gonna add it to my TODO list
After 1.4 is released, definitely try the Baked Normal Maps mode. Maybe it will be already sufficient to fix the problem.

 

Thank you for the quick and detailed answer, Frank!
I read my post once again and found a mistake in my explanation.

So to clarify my message:
I meant to add Shadow Bias NOT to the faces opposing light direction but to the faces that turned from the light source.
That, in theory, shouldn't bring classic peter-panning problem since all front shadowing will stay the same as it is right now.

I totally agree that you should be very careful with adding new controls, peoples will touch it and after they will blame you for the broken results.
In the project I'm working on, I need to use low-res point-filtered normal maps, so I wonder how Baked Normal Maps could look in that case.
Your idea about baking Shadow Masks with taking Normal Maps into account sounds very interesting!
Hope it would able to handle low-res point-filtered normal maps too.

Btw, did you ever think of creating Patreon account (or something similar) to allow people to provide extra support to your Bakery project?
I would like to support your project on a more constant basis or at least while you busy with developing.

 

I originally thought of releasing the lightmapper as free and open source and opening Patreon instead of selling it, but after I spent > 1 year on it I decided to go the way I did. Some people still ask me about Patreon, and that's heartwarming and surprising, so... maybe yes, why not: https://www.patreon.com/guycalledfrank
Definitely great additional motivation

 

Thanks for sharing Frank.
I hope you'll get more Patrons soon!

 

Hi Frank just bought the lightmapper lovely quality very crisp light maps wonderful ! thanks this is a game changer for me for the reduced iteration times it harnesses both of my 1070 GTX as well ...the GPU threading however gives a OFF/ON (7%/ 100%) on the resource profiler in windows going off and on about Once a second ( the cpu is at 25%) just wondering is there some way off turning the GPU usage up ...i am in HIGH mode and 1024 tile size 50% filled on the uv island charts.

 

There are some CPU/HDD tasks between different passes - e.g. when it finishes baking a light or a GI bounce, it saves the data to HDD cache, then loads different data for another pass... in fact this overhead can be significantly reduced, and lights can be batched together. I had a test version that did just that, but it was unstable, and took too long to debug back then. I'm still planning to enable this batched mode in the future though.

 

Do you think an indirect G buffer map woudl work? I mean for each lightmap pixel, there is a corresponding lightmap 8x8 Gbuffer tiles that represent the most contributing directions (with a weight mask), each tile of the pixel is albedo, world normal and world position and compute direct lighting, then we sum all the pixel of the tile to get the final lightmap pixel color ...
I expend a bit on it here: https://forum.unity.com/threads/segi-fully-dynamic-global-illumination.410310/page-43#post-3783232

 

Right... so we can light up this GBuffer at runtime using any dynamic lights/shadows and then downsample to a single texel value. That's possible to implement. I see 2 problems:
- The amount of data is quite large, and it's better left uncompressed. We can't really apply any GPU texture compression to world position, and it takes a lot of memory (we need precise floats). A somewhat possible alternative would be to convert from world positions to depths and a list of indexed view matrices, but it's a rather complicated task, and it would add another level of indirection to the shader... Normals can be 8-bit, but because neighbouring pixels represent very different values, doing block compression on them will likely break everything. So it's around 1280 bytes of data per tile (compare to 4 bytes for a regular uncompressed color lightmap). In can be used, but with very limited resolution.
- It requires a whole infrastructure of shaders and render passes to work. Can't really use built-in Unity shadows for example, so basically we need a whole renderer to modify direct lighting. An epic task. If someone (you?) wants to work on the runtime part, I can help with baking though.

 

Thanks for the answer. I left some part not sure if it's better:

The original idea was about cubemap anyway

Problem is I'm less experimented than you, I have still more on the theoretical side and don't have enough practice to inform it, so your observation is very valuable.

I'm trying to attack the problem from two angle, simplifying the scene at authorship time to make it work under constraint assumption, and finding a way to cheaply gather the GI, and meet the two in the middle.

I think I will have eventually have to do something like that anyway, so maybe in the future once I have resolve the current problem I'm tackling (parallax hair shader). So stay tunes I'll make good use of your proposed API surely, can't wait to make my 705 to contribution lol

 

I followed your example and crushed some math with the updated proposition, so I woudl know how to use a bakery api but RTGI will always be more expensive...

The overall data cost is 4 x 256 rgb lighting map, 1 lightmap, and 1 indirection map that is lightmap size x tile size (control the quality of the gi). The lighting has a fixed cost, the GI gathering indirect map take all the cakes But the compute cost only need to be update when light change.

edit: Since we need a loop for gather, it's better to store UV indirection as both the RG and BA, and have a single read for two texture, and then move weight into a weight RGBA texture where we could read 4 weight in a single go.
/edit

I still don't know how practical it will be in reality, but basically I would need to find a way to distribute sample point in the world, give them proper weight, then use bakery API to create the indirection map that control visibility of those sample. I'm not there yet.

 

@guycalledfrank I've got the light maps baking and it seems to be working. However When I look at my lightmap in the Bakery Lightmaps the LMO_Final Import setting is mostly black! Seems like it should be shades of gray shouldn't it? Also in my scene file every is looking good but as I move around the scene the lighting appears to change...ie a area looks like it should but as I zoom in on it it goes darker and darker. It almost seems like it depends on the distance the camera is on how the lighting is rendered and displayed. Any idea what I am doing wrong? Please also not that this is a Android build for the Oculus Go.

 

Mostly or completely? Can you check it in photoshop or any other software (not Unity preview, it can look darker than it is)?

Sounds like you have real-time lights enabled, and you see the effect of real-time shadow range (?)

 

Hi, I wanted to test your lightmapper and one of my favorite scenes for this kind of things is the renderman kitchen that you can find here : https://community.renderman.pixar.com/article/1767/kitchen-pup-asset-1.html?l=r
I used the fbx version and it looks like when I start the lightmapping there is an issue exporting that fbx.

Also I was curious to know : there is a button to switch to physical light falloff, has it been tested with HD render pipeline ? HD render pipeline uses physical falloff, but I wonder if the units would be compatible.

 

What is the issue? Is there any error message?

Baked physical falloff checkbox on lights is close to classic inverse square (1/(dist*dist+1), but attenuated at the edge. I didn't compare it to real-time physical falloff in HDRP, but I expect them to match, unless HDRP shaders perform arbitrary scaling on top.

 

Looks black to me or has more black then I think a lightmap would have...lol



My lighting is currently on Mixed! Should it be on Baked only?

 

There is however something in the corner... my version would be that you have Min Lightmap Size set to a large value, yet you are using a very low value for Texels Per Unit, and so objects are just a couple of pixels in the corner?

Do example scenes bake for you?
Can you just throw some of your objects into, let's say, "example_lights" scene and see if they bake correctly with that settings?

 

I sure can, I found out my shadow problem was because of my shadow distance. I appreciate all your help I have not been using Unity for long as you can tell...lol! I have just decided to make the jump from UE4 to this since it had better support for the Oculus Go.

 

Do I need to create a new "Lightmap Parameter" to set the min lightmap size?

 

No, definitely not - I only mean the "min resolution" slider in the main window. It's not visible in simple settings mode though:

 

Guycalledfrank, I just purchased Bakery, and compared it against Unity's own GPU baker. Bakery DESTROYS Unity's underwhelming effort. Love it. You deserve real praise for this. How you are unloading the scene and then maxing both my 1080 Tis is just great. The UI and Unity integration is just fantastic. Tested on Unity 2018.3 with HDRP. Thanks!

 

Love the baker so far!

One bug I've encountered after using it for a few days: Baking appears to fail with a cryptic error if there is a mesh with no uv0 and has Bakery Light Mesh component on it (lightmap static checked and scale in lightmap 0). Mesh has lightmap uvs auto generated.
EDIT: Also it looks like self shadowing on Bakery Light Mesh Component has to be on for this to happen.

This results in following error:

xOutOfRangeException: Index was outside the bounds of the array.

ftBuildGraphics+<ExportScene>d__110.MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftBuildGraphics.cs:2897)

ftRenderLightmap+<RenderLightmapFunc>d__150.MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:2273)

ftRenderLightmap.RenderLightmapUpdate () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:2175)

UnityEditor.EditorApplication.Internal_CallUpdateFunctions () (at C:/buildslave/unity/build/Editor/Mono/EditorApplication.cs:198)

Switching to a mesh with proper UV0 seems to fix it. Perhaps there could be a warning to user and bakery would skip the violating mesh.

 

That is certainly a fun scene to test Bakery with automatically generated UVs.

200 resolution + some vertex lightmapped cheerios and onions. Denoising peaked at 9GB VRAM, also managed to hang my PC at denoising when I had 64 GI samples as well, because why not, had to drop it to 32.

Spoiler

The only noticeably ugly things I spotted for now were the ceiling raster edges, but then again it's Unity generated UVs

 

Hello,
I have the problems with speedtree asset "Mesh White_Oak_Desktop_LOD2 on object White_Oak_Desktop_LOD2 has incorrect UVs"
Can you help me?
Thanks a lot

 

Oops. Yeah, I can see why it can happen. Thanks for report, will fix it soon.

Nice!

Well that's interesting - GI samples shouldn't affect denoising VRAM level at all. On top of that, denoiser has a fallback system when it goes out of VRAM, allowing it to split the lightmap into smaller tiles and still finish the job. I wonder did it actually fail all fallbacks for you?... that would be strange. Any remains of editor console log after it failed?

Vertex lightmaps have some unwanted seams at the moment... known problem, but I'm going to improve it. Currently it just bakes each vertex individually, even if there are multiple verts at the same position (coming from normal/uv seam). Ideally I should detect such vertices before rendering and only run one lighting sample for them.

Also I highly recommend enabling bicubic filtering (Bakery->Shader Tweaks... may require Unity running under admin), it will improve the jaggies significantly. Only available for the standard render pipeline at the moment though.

Hi! Bakery is not currently compatible with SpeedTree assets. Or at least I never tested them.

 

I didn't see anything out of the ordinary, I'll try to crash it again later today.

Right, I actually did think I had it on already, but alas I had forgotten to launch under admin. Now you get comparison pictures, though slightly darker exposure setting:

Spoiler

 

v1.4 was finally submitted and should be available soon!

Changelog:
- Added 4 directional modes making Bakery lightmaps compatible with normal maps and specular:
* Spherical Harmonics (SH): high quality, based on Frostbite technique.
* Radiosity Normal Mapping (RNM): medium quality, based on Half-Life 2 technique.
* Dominant Direction: just like built-in, compatible with existing Unity shaders.
* Baked Normal Maps: allows to simply bake the normal map effect into regular lightmaps. It is possible to customize Meta Pass in your shader to output procedural normals.
- New Bakery shader with full support for new lightmapping modes and vertex bake. Not required for standard color/directional/mask lightmaps.
- New HDRP Bakery shader with support for SH.
- New LWRP Bakery shader with support for SH and RNM.
- Vertex lightmaps now support Shadowmask, directional and SH lightmaps (requires Bakery shader or tweaks to your own)
- You can set different resolution for color/shadowmask/directional lightmaps
- UVs in automatic atlases are now scaled up to fill up empty space
- Improved packing using both manual Lightmap Groups and auto-atlasing
- Fixed reflection probes not being saved when no LightingDataAsset was assigned to a scene
- Fixed half-empty atlases generated for LODs
- Fixed shadowmask breaking on some objects after "Render Selected Groups"
- Fixed using Area Light + Light Mesh + texture on one object
- Fixed not respecting "Scale in Lightmap" option on terrains
- Fixed manual lightmap groups not working properly for terrains
- Fixed not detecting overlaps in models without UV2 and subsequently not packing them correctly
- Fixed meta pass multimaterial support
- Fixed render settings not always being taken from the active scene (thanks E-Cone)
- Fixed UV padding adjustment not being applied to objects using manual Lightmap Groups
- Fixed light probe render getting stuck when Occlusion Probes is on and real-time reflection probes are off in quality settings
- Fixed some models getting reimported for no apparent reason
- Fixed light probes not receiving lighting from LODs
- Fixed crash during GI calculation when there were many area lights in the scene
- Fixed rare crash when compressed UVGBuffer texture was larger than uncompressed

 

Feature list sounds incredibly delicious. Сan't wait to try it!

 

Great! its time to purchase this asset! Cant wait to try!

 

Hi i think it can be very useful even if it cant hand the surface specularity (at least for my workflow)...even just rendering the Global ilumination in one image would be great so we can have a rapid idea if the light is enough or not...if we are overexposed or not...

This guys of https://www.shapespark.com/ made a somekind of gpu renderer also for their software...and before baking all the lightmaps we can do a render of just one image (wait like 5 min) to see if we are ok on ilumination and not wait a couple of hours to see the result and discover that all of our scene is too dark hehehe

Anyway i can imagine this is not the most important on your roadmap and i can imagine also theres more importante issues and feature to deal first but would be nice to have it somewhere along the way

Thanks

 

This is something I would really like to add actually.
But apart from this and bug fixes, the next big thing I would like to work on is the light probe system. I'm a bit tired of fighting Unity's own light probes (almost no API, many limitations, too many awkward workaround to modify the data), so I'm thinking of making another independent system.

 

That would be great!! ) awesome!