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

Thanks! But that option is already on, I have it on 3. It doesn't seem to have any effect unless the surface is very close to the leaves.

 

Ahh, I get it now... so as soon as Bakery gets initialized, it sets default values, including "is realtime GI enabled?", which is by default false... but there is no need to change it if no lightmaps are baked.
Fixed, it won't change the realtimeGI option anymore until you bake the scene (pushed to github).

It uses the surface, offsets a tiny bit away by normal.

Hmmmmm that shouldn't happen. Actually on your screenshots it looks more like your mesh geometry wasn't properly exported, so "near" rays can't touch it. Check if your light mesh object doesn't have the EditorOnly tag (it's the only reason for such behaviour I can recall - no EditorOnly geometry gets exported).

OK, fixed! On github.

Yeah, sometimes xatlas does that for some reason. I did not write it, so I don't know why. You can switch to default atlas packer in this case:
https://geom.io/bakery/wiki/index.p...rting_scene_-_preparing.22_is_taking_too_long

My tree receipt:
- Use single-sided geometry and double-sided shader.
- Set backface GI to 1. This will scatter the light leaves receive from backfaces.
- If any direct/point light affects the tree, put the leaves in a separate lightmap group and enable transparent selfshadow. This will make leaves react on lights even if their normals look the other way.

Looks like some denoiser/driver issue. Can you try it with legacy denoiser?

 

Thanks for the reply. My trees meet your criteria but it doesn't seem to have any effect. The area beneath the trees is still very dark. No light is transmitted through the leaves.

 

Frank,
I managed to use the wrong username to try to access the gibhub repo. And now it won't let me link a new user to the invoice number. Any ideas on how to reset it this access?

 

Actually looks pretty soft, I like it! Since it's not pitch black I think light IS transmitted... now I can only suggest increasing your sun or sky intensity.

Just PM me your old and new username, will fix.

 

Hi Frank,

I have another question.
Am a lighting dummy here so bear with me.

I tried using Bakery lightmapped prefab on a lighting static character in a scene and bake the lighting.
Baking is ok.
But when i say uncheck static, rotate the object 180 degrees, the lighting is gone or the face becomes darker.
Doesn't matter if i put point lights or direction lights all around the character, it the same.

My question is, are we unable to rotate lightmapped objects once baked? Is it a lighting limitation or rather feature?
Isn't lightmap a texture on the object.
So when i rotate the whole object, the light map won't be affected since it's not real time.
Just like a face won't change no matter how you rotate it.

Sorry for my basic question.
Thanks.

Jason

 

The lightmaped objects must be marked "lightmap static", when you move a baked object you need to rebake the lighting if you whant correct lighting on your object. This is independent of Bakery.

 

It does look like light is transmitted but it doesn't reach the ground underneath, or even the trunk.


Some areas have many trees and after baking it becomes very dark under them.

 

I believe its the time to rely on postprocesing stack, may be you could also try GI boost, but the way to "lit" those dark areas to me look like the exposure compensation with eye adaptation.

 

I already have auto exposure on but that doesn't help much if the bakes are too dark. If I turn it up too much everything else becomes too bright.

 

well, if GI boost parameter is not enough then, its time for hacking may be.
For the baking only you could set the leaves to have "emisive" value, and as emisive you could add the leaves texture itself. Play with the emisive strenght and see if you can get desired ressults, once done dissable emisive checkbox on material.

 

Maybe I'm doing something wrong, but I have so much troubles with Bakery, tried on couple scenes and never had any luck with baking. Most of the times it's stuck in progress bar or have some weird errors. Unity build in lightmapping bake lights without problems on these scenes. Today for example I'm facing issue attached. It's stuck on 4% and cannot go further. Any help would be highly appreciated. Thank you Unity version 2018.4.12

 

When it gets stuck , I have this error, when I press cancel. RTX2070S

 

Thanks, emission has helped a bit but I had hoped for a more clean solution.


Maybe frank has a better solution?

 

I have the same problem as @Goldenvale does. I want unlit areas to be brighter (referring to places that doesn't get any light, even indirect). I think in older Unity there was an option to set ambient darkness colour for baking. There is no such option now. I believe it is currently set to complete black, hence our dark areas where light is not reaching are completely unlit. My implementation requires to disable or enable some objects in the scene, and it looks ugly when it is completely black underneath. Maybe there is a work around? P.s. no post-processing can solve this issue, as you cannot brighten up something that is completely black - it has no colour information anymore. Furthermore, you want these areas to be visible without brightening other areas. I did some testing with Photoshop, it is possible to manually adjust these darker spots in lighmap textures, but it is simply to much work. Maybe I could try batch processing these.


@guycalledfrank
"Hmmmmm that shouldn't happen. Actually on your screenshots it looks more like your mesh geometry wasn't properly exported, so "near" rays can't touch it. Check if your light mesh object doesn't have the EditorOnly tag (it's the only reason for such behaviour I can recall - no EditorOnly geometry gets exported)."

All three objects were not tagged, so it is not the issue. Also, these cubes are standard Unity cubes and not imported geometry. However, this is not an issue for me, since I don't need self-shadow anyway, disabling this solved my issue.

 

Thanks for the reply.
Your reply helped to confirm that.
I thought after baking the lightmap static object's light into its uv, i can just move it the same.
But doesn't seem so.
Now I understand better.
Thanks a lot.

 

I recommend adding a log prior to calling xatlas.xatlasPack "If it freezes here, see https://geom.io/bakery/wiki/index.p...rting_scene_-_preparing.22_is_taking_too_long"

It took hours to determine that line of code was the culprit and if that had been the last line of the log I would have known how to proceed

 

We have those white square-dots on some places and we have no idea what causes them. On different machines, they appear on different places when baking.

Apart from that, it is confusing that the store asset version number didn't changed since a while but files in it changed. Maybe bakery could update the version number each time they change asset content, would make it a lot easier for us.

 

It's good for my project. RTPreview is very useful.
But, when I move non-static mesh, Preview don't move it.

I show ftPreview.cs file..I think you have Update scene feature in todo list.
When do you plane to update it?

 

Hello

When you decrease or increase the "Min resolution" value of the lightmaps in the parameters, this affects the size of the UV in the lightmaps. It seems normal to me that this is the case for the value "Max resolution" because it allows UV to take more space in the lightmap, but the value "Min resolution" should only play on the number of lightmap created?

For example, we bake a small scene that occupies only a small part of a lightmap of 4096. To reduce the weight of the lightmap, we decrease the min resolution to 2048 and we leave the max resolution to 4096, and we get the same occupation in the lightmap as before except that the number of pixels in the UV has been divided by 4. Is this normal?

 

This scene here has a lot more of those false white square-dots. We tried everything to fix it. Those errors are not a lightmap that we can deal with, it's way too much to correct manually, unfortunately. It's all around the scene as well.

 

I have the same issue on my scene. I tried to find source of this dots and I found it. Its GI bounces in my case. Without bounces - no more white dots. But if GI bounces = 5, my scene turned to the white "explosion" of light.

 

Not sure if I understood your issue correctly.
- Baked a skinned mesh.
- Rotating this mesh.
- Lighting on the mesh dynamically changes as you rotate? Are shadows/occlusion still in place? Did you use any directional mode?

You should be able to bake a skinned mesh and then transform it, but lighting should remain static.

Do you use any AO? And just to confirm: are leaf planes single-sided (and using a double-sided shader)?

Try disabling terrain optimization first, if it's enabled.
https://geom.io/bakery/wiki/index.php?title=Troubleshooting#I_get_a_.22Launch_timeout.22_error

Yes:
https://geom.io/bakery/wiki/index.php?title=How_do_I...#How_do_I_add_fake_ambient_lighting.3F

Ouch... well, usually this is the only reason why scene exporting may get stuck

These can appear if you have very small and very bright emissive patches easily missable by rays. The problem is similar to this, but instead of a tiny sun on the HDRI it is caused by a similarly tiny/bright spot on the geometry itself.



Here most rays from the wall will never end up at the ceiling spot illuminated by the lamp, but once in 10000 rays (likely even less frequently) some will land there, hence this "firefly" effect. There is no good solution at the moment, because Bakery doesn't know how to guide rays to brighter spots. Possibly Fix Bright Edges might reduce the problem.

Actually I can just develop an additional filtering effect on top of the denoiser, it's not so hard to detect them. Just confirm if fix bright edges doesn't work, aaaand I'll have to do it then.

Hmm? You can't see non-static meshes in preview anyway.

There was no plan to implement realtime geometry updates. "Update scene" likely refers to something else I forgot. Actually this TODO list is outdated, e.g. I definitely remember fixing IES axis

There are many rules involved in atlas packing, including some rounding and slight stretching to better fill holes. Any change to any atlas packing parameter may result in different sizes for individual layouts inside the atlas.

oook that's not normal. are you sure there are no super wide or super tall objects like this:

 

"Fix Bright Edges" fixed our problem, thank you so much!

 

Yes I do use AO but it's on 0.5 intensity, baking with it at 0 doesn't change much. The leaf planes are single sided and using a double sided shader. It's a custom shader, does it need something specific to have light transmission?

 

Hi I am not sure if this is answered, before I bake the scene, Environment lighting source color can be previewed fine realtime, but after I bake environment lighting is completely dark, is there a way to bake the scene with environment lighting and bakery light? or it it just not allowed?


My scene is closed area, I tired 6 directional light, but all directional light are blocked by my level, so no ambient is baked inside the scene.

 

I'm sorry, but turning off terrain optimization didn't help. I bought Bakery preview also it's crashing as well, spinning wheel, ftrace.exe not responding. I was trying to bake lights using your Bakery for about 2 months, not a single luck. Tried 5 different projects on 2018 and 2019 Unity versions. no luck, just constant frustration. I would be happy to get refund

Today for example I have this error. I can leave it like that for a week and nothing will happen and GPU will work on 100%

 

I have no super wide object.
I did a test on a simple scene with only one plane and 9 identical cubes with the same value of "scale in lightmap" at 1.
The number of pixels per object remains almost identical up to a min resolution value of 512. From 512, all objects are on the same lightmap and more the "min resolution" value is increased, more the pixel number per object increases. See screenshot.

 

On FBX import, if I don't tick Generate Lightmap UVs in Unity, can Bakery create the lightmap UVs also, or it cant create lightmap UVs, only bake them?

 

I am stuck at the exporting stage (50%) when I use your real time preview tool. It just freezes and nothing happens. This only happens on unity 2018.4.24f1 which is unfortunately the LTS version I have to use. I tried on 2019.4.1f1 LTS and it worked fine. Any clues on why this is?

 

Hi yall!
I'm considering buying Bakery for the main purpose of baking different layers with different light sources. Unity's buildin lightmapper doesn't support Culling Mask layers and will just bake every light to every layer.
Is this supported in bakery? Not really shown in the documentaion.

 

Hello,

i am in the final process to move my project to HDRP.
my biggest issue is the automatic HDRP Material converison.
I have around 160 materials. All of them are Bakery Standard Shaders in SH Directional.

So the HDRP conversion runs only with Unity BuiltIn RP Standard shader.

Could you provide a workflow that i can convert all Bakery Standard Material to HDRP with the auto conversion?

This would help a lot.

 

I find it strange that skylight rotation act in opposite direction.


It's also make it realy frustrating to setup skylight+directional light system because of that.

 

If your shader has correct meta pass definition or just uses standard property name conventions for albedo, it is enough (see https://geom.io/bakery/wiki/index.php?title=Manual#Material_compatibility).
For opacity maps to work, they actually must follow these naming conventions and your material must have some tags - check the same part of the manual. If you have RTPreview, I wonder how does the tree look there?
I also recommend checking if using Bakery shader with double-sided checkbox produces anything different. If it does, this will indicate something with the shader; if it doesn't, your shader is not the problem.

This property is not used by Bakery. Instead, use the Skylight component for the same purpose: https://geom.io/bakery/wiki/index.php?title=Manual#Bakery_Sky_Light

Interesting. If you can send me any scene that causes a freeze/crash (as a project or unitypackage), I can debug it for you, tell you why it happens and how to fix it. If there is any bug in Bakery, this will help to fix it.
For now my bet is on either texels per unit or geometric complexity being too high.
Anyway, I can give you a refund if you can't do it and if your scene is not a suitable case for lightmapping, DM me.

Ahh, that's the problem. SH data is world-space, meaning SH directions do not rotate with the model. Rotating anything SH-baked (not just skinned) will break the lighting. Same goes for dominant direction mode. RNM can be rotated, because it's tangent-space.
Try rotating planes in my example_mixed_directional_mode scene to see how different modes behave.

OK that looks more or less expected. First min resolution affects lightmap count (multiple -> single). Then indeed you get denser texels... which may not look expected, but caused by some rounding in the altas packing code. I.e. if you have a large lightmap, but it's too empty, it will attempt to scale up the objects to remove that emptiness, preferring more resolution over holes. In fact it works different with Default vs xatlas atlas packer, so check with both.
Oh and I don't see atlas packer selector on your screenshot, you are probably using a rather old version...

You must either have lightmapping UVs pre-made or click Generate Lightmap UVs. Just in case, I added it to the wiki today: https://geom.io/bakery/wiki/index.php?title=Manual#Quickstart
Bakery can adjust or even re-unwrap the UVs using both default and xatlas unwrappers, but the checkbox must be set to identify that this model needs UV generation.

Checked this?
https://geom.io/bakery/wiki/index.p...rting_scene_-_preparing.22_is_taking_too_long

There isn't much difference between 2018/2019 implementations, so sounds weird. 2018.4 is tested/supported. Are you sure you don't use different project settings or third party assets apart from different Unity version?

Kinda, but it doesn't use Unity's culling layers. Every Bakery light has a "bitmask" property (you can search the docs for it).
Bitmask can be also specified for a Lightmap Group (a collection of objects). Lights will only affect the groups with the same bitmask flags.
Note that currently there is a problem with Lightmap Group + LODGroup compatibility, i.e. you will need to put every LOD level to a separate Lightmap Group. Apart from that, it should work.
Also note that global illumination is still global: even if some light is excluded from affecting some objects, its indrect reflection can still bounce on them.
The example_mixed_directional_mode scene from the package is a good example of bitmask usage.

Oh. I don't have such a conversion tool at the moment, and there is no "Bakery Standard" shader for HDRP. What I have for HDRP right now is a bunch of example shader graphs that are not meant to be used as is, but rather as an element when building your own graphs. They also don't support all extra features present in Bakery Standard: https://geom.io/bakery/wiki/index.php?title=Manual#Feature_support_across_shaders
Making something like Bakery Lit for HDRP is something I need to do at some point, but it's complicated because HDRP is ever-evolving! Everything I do for it often becomes incompatible a week later.
If you don't use extra features (SH/RNM/per-vertex LM), just use regular HDRP Lit shader, it will work.

Yeah, it's a bug. Problem is, if I fix it now, it will break existing projects for everyone. So I'm not sure what I can do about it.
It's like when OpenGL decided that camera Z vector is backwards and images start from bottom, and now we're stuck with it for the sake of compatibility

 

Ahh, that's the problem. SH data is world-space, meaning SH directions do not rotate with the model. Rotating anything SH-baked (not just skinned) will break the lighting. Same goes for dominant direction mode. RNM can be rotated, because it's tangent-space.
Try rotating planes in my example_mixed_directional_mode scene to see how different modes behave.


So that's why.
I wouldn't know this unless i spend more time in lighting.
Thanks for your help Frank.
I'll definitely go take a look at the example.
Thanks again.

 

I've added a fix to make LODGroups bakeable within Lightmap Groups. You should be able now to to put a single lightmap group on an object containing many different LODs. If this is useful for you, please test the latest github version.

 

I've tried the standard bakery shader with double-sided checked but it doesn't produce anything different. And unfortunately I don't have RTPreview so I can't tell you how it looks there. Maybe the GI is just not strong enough so it doesn't reach the ground? I'm at a loss here, I've tried everything.

 

Hi frank, bought your preview tool, which is super awesome, thanks!
Albeit I have a little problem with the baked shadow spread for pointlights/spotlights. It seems fine in Preview tool, but as soon as I bake it seems bakery doesn't blur the spreaded shadows and I get these stadium shadows.
I am using URP and Unity 2019.3.1f1

 

Okay, thank you.
Hm. I get that...
Can't figure out acceptable workaround for this problem..

How about some sort of checkbox in skylight "experimental tab" to make it behavior as expected for those who need it...?

OR, or maybe adapting importance sampling method for skylight, and so there will be no need for a systems like skylight+direct light ; )

 

Hey @guycalledfrank, I tried solving my problem of unlit areas being too dark with 6 directional light setup. As expected it is not a good solution for me - everything just gets brighter, but the contrast between black areas and light areas is not affected. Also, in my bigger scenes, I have a performance drop because of those additional 6 or 5 directional lights.

Is it possible to implement a threshold as an option to control how dark or bright areas can get at maximum ? In Bakery interface this could be two values from 0.0 to 1.0. If let's say pixel is (0.0, 0.1, 0.1) and the dark threshold is 0.1, this pixel would be pushed to (0.1, 0,2, 0.2). Not necessarily exact formula, but I guess you understand what I am trying to say.

I learned a little bit of image processing, and I have done this in the past, but currently I don't really understand HDR textures, nor there is great tools in Photoshop for me to do this easily.

 

Hello,

I've NVIDIA GeForce 610M (along with Intel Graphics 4000)



and while using the Bakery asset, and after hitting the Render button
it says "A supported NVIDIA GPU could not be found"




isn't 610M supported?

 

Firstly I just want to say how amazing Bakery is. It has fundamentally changed my project and delivered such high quality results. I am currently struggling with one major issue right now:

I have multiple scenes. In each of those scenes I have multiple bakery prefabs. When I bake a scene it will affect the lightmaps of another scene. For example, in scene 1 I will bake it and it will look perfect. Then I will bake scene 2 and it also looks perfect. Then I go back to scene 1 and the lightmap on the couch, or a pot plant have changed and look broken. I check the model to see what lightmap is assigned to it and it is the correct one.

How are scenes affecting each other like this?

 

Hi Frank,

Almost completing my project. Hitting one last issue.
Hope you can help. Thanks.

I built my Android project on Windows and use SH directional mode to bake my scene's lights. Managed to get the specular highlights in the scene in Android.

When I copy the whole project to a Mac to build the IOS project with no changes, the specular highlights do not appear in the game in the iPhone device.

I'm using asset bundles to load the lights before loading the scene.
There is no issue with the baked lights as everything else in the scene are baked and are lit.
It's just lacking the specular highlights.

Any additional configurations I need to apply for IOS or any settings I can check to find out what may went wrong?

Appreciate your help.
Thanks again.

 

Found this on youtube. Mr. F are you making tutorials ?

 

OK, then your shader must be fine.

Maybe. Try messing with indirect intensity?
You can also send a simple scene (tree + lights) to me (unitypackage or a project) and I'll see if I can make it more vibrant.

Oh yes, it's because (as noted in the docs):

Any sample count settings (GI samples, shadow samples for various lights) have no effect on preview. Preview uses infinite, progressively increasing sample count for everything

In this case you don't have enough shadow samples on the light, so just increase it. The higher is your shadow spread, the more shadow samples you'll need. Each "shadow sample" is basically a single sharp shadow. When you blend many of these, you get a soft shadow. For slightly blurred edges something like 16 is usually fine, but in this case you may need as much as e.g. 1024.

OK, fixed! You can get the fix from github.

MIS is definitely on the list. I don't think it should replace the direct light, because it has a separate and more efficient sampling strategy and because it supports the shadowmask, wires to subtractive mode as "main directional light", etc... but actually it's possible to make something like "adapt direct to HDRI" that would set light transform and settings to the brightest point on the HDRI.

It's not hard to implement, but I'm not sure it should be in the lightmapper. Similar environment constant in built-in Unity lightmappers is additive (like these 6 dir lights), you want something like a max() function, sounds like a very special case to me. Have you tried setting indirect intensity to 0 on these dir lights? (in case their bounces produced more unwanted brightness).
Bakery also doesn't have a post-processing step, it's just lighting -> denoise -> fix seams. Adding a filter like that to any of those stages can be a source of unexpected bugs.
Best thing I can do is to provide a customizable post-processing callback where you can stick your own function (or a shader? Shader is better for performance, but not everyone likes to write them?) that would receive pixels as input, process and output back, but I don't have it right now (it's also tricky because I never read original pixels directly to Unity, they get converted first to .hdr, then via Unity texture importer...).
Performance/compatibility-wise the best option I can add is "Run this HLSL shader on pixels before converting them to .hdr", where you provide a hlsl file with a function where you apply any color correction. Tell me if that's something you think is useful. It won't be possible to set shader constants (colors, textures, floats...) to this shader though, unless they're hardcoded.
I might be overthinking this...
With Photoshop it's also fairly easy, just add a dark gray layer and set blending to "Lighter color":

They are like regular textures, but can go above 1.0 (aka 255) in intensity.

Apparently 610M is based on Fermi architecture, which is too old to run Bakery. Kepler is the minimum requirement.
I know Bakery's desription says "Geforce 6xx", and it's my mistake, I thought they are all Kepler.
Turns out:
610 -> 640 are Fermi.
650 -> some of 7xx are Kepler.
Confusing! I will update the description. You can ask for a refund.

Caused by this: https://geom.io/bakery/wiki/index.p..._in_one_scene_breaks_its_UVs_in_another_scene

If you are using Bakery Lightmapped Prefab, make sure to only set "Enable Baking" checkbox in the scene where you actually bake them. If you instantiate baked prefabs in another scene, uncheck it to prevent overwriting.

I don't know about any specific differences on iOS. Are you sure diffuse lighting is correct there? Do bumpmapped surfaces look correct? If they do, there must be something about the specular code; if they don't, it can be related to maps not being loaded correctly. Does standard specular from regular light sources work? If it doesn't, it might be something about gloss/specular/metallic maps not being loaded correctly...

No, it's not me. I should do my own, but I don't have the time

These tutorials are not great TBH. I'm afraid they can confuse beginners even further. Left some comments.

 

oh i see.

i found this really helpful, actually it really depends on the individual of their understanding. Overall helpful.

 

Thanks Frank.
Diffuse lighting is correct as it has the same look after baking without specular highlights when i baked the scene non-directional.
There are no bumpmapped surfaces. Just a simple scene.
"Does standard specular from regular light sources work? " Whole scene is baked and uses Bakery Standard shader. If you refer to realtime/mixed lights I don't have any. Nothing is glossy in the scene so i guess no.

So most probably the specular HDR maps are not loaded correctly. Anywhere I can check if they are not loaded/has errors?
Only difference is Android uses ASTC 6x6 HDR for the specular HDR texture files but IOS uses RGB 9e5 32 bit shared exponential float.
IOS does not have that ASTC 6x6 HDR option.

Thanks again.

 

Is it possible to start Bakery via script and use a callback to know when its done?

I currently have a custom script that bakes all of my scenes with one click. It opens one scene at a time, bakes it, closes it and moves on to the next scene. It also copies light probe data between scenes.

Would it be possible to replace the standard unity command for baking "Lightmapping.BakeAsync()" with a call to Bakery instead?

 

Sounds like you will benefit more from the "dominant direction" mode. It should give similar specular quality, but use way less memory. SH is more important when you also want diffuse normal-mapping to look good.

I asked just in case your gloss/metal maps got broken or in case there is any problem with running GGX specular maths on the device. Testing with a real-time light would remove/confirm these.

Additional SH maps are just regular non-HDR color data, they should be compressed correctly on any platform...

There is actually a script that does just that, and you can modify the code to fit your needs: https://geom.io/bakery/wiki/index.php?title=Community_extensions#Batch_scene_baker