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

No worries. It seems like I do have it in ftModelPostProcessor.cs

 

Thats awsome frank . Keep on dude.
btw , wanted to know your idea about the whole process and ease of light baking in Unreal Engine 4 in comparison to available options in unity at this moment , even in terms of quality of realism.
recently wanted to search about it but i thought i wouldn't get a comprehensive idea by a minor search,thought maybe you should know that better than anyone else .

 

But I still have the issue of padding asset not having script
You mind giving me the name of the script that should be attached to the padding asset so I can see if I have that script?

 

This would be worth an official Unity Blogpost.)

 

WOOOOOOOOOOOOOOOOOOOOOOW

I've a 1080, I know nvidia enabled RTX for phascal cpus, not sure how the card would perform tho.

 

Unity should be able to link your components to this script then. Are you sure that saving padding to file on this machine (right now) generates a broken asset?

It's what you see in ftModelPostProcessor.cs. I'm not sure why it doesn't link in your project . Still can't reproduce it. Does it happen it a completely fresh project?

I didn't work with UE4 that much. From what I know, Lightmass is precise, but not very fast (fully CPU). There are some GPU lightmapping experiments going on right now. Also heard about it having user-defined volumes where different quality can be set inside them. The idea is neat, but I'm not sure it does make much sense for Bakery. Directional lightmaps in UE are the same type Unity uses (no RNM, no SH) - small memory footprint, but result is a bit bland.

On this video I'm running it on 1060 + screen capture slowing it down somewhat.

 

game changer. incredible work.. so
after we set up scene in rtpreview, bakery will bake what we see .. yes instantly?

what you see is what we you bake

 

No, it's not like Progressive. RTPreview is separate. It just... previews. After you like what you see, you can ask Bakery to bake as usual.

But that's correct. RTPreview image is identical to what you will see in lightmaps. Except:
- In preview every screen pixel is ray-traced (not every lightmap texel)
- Sample count for preview is "infinite". It just progressively increases, not using lightmapping sample counts.

 

--> May be could be added a "debug" option in panel in advanced that prints every n seconds the currently displayed quality, or futher, a but to capture the current specs so that we can lightmap to 1:1 match ( or almost).

Anyways, I'm seriously impressed, the compute LM without re-exporting scene if no changes was a huge time saver, but this is at another level.

Great to know also its working so good on a 1060.

Unity should feature you soomewhere, in the blog at least. I know it means they've to swalow some stuff but... you deserve recognition.

 

Yeah, I just made a new project with bakery inside, made sure I have ftModelPostProcessor.cs and Public Class ftSavedPadding : ScriptableObject inside, but when I create the padding asset, I still get a warning

No script asset for ftSavedPadding. Check that the definition is in a file of the same name and that it compiles properly

And the padding asset still have no script, but it does have the Data

 

So I started a new project to try to reproduce it.
Im using unity 2019.2.3f1 and the latest Bakery

1. Created a new project and imported bakery
2. imported a simple fbx file and checked Generate Lightmap UVs
3. Create a simple scene with a point light, the model and a plane
4. Baked the scene
5. Select the fbx in Project and clicked "Save UV padding to asset"

Which then I got this


So the asset has data inside it but still no script

After restarting the project, unable to see the data and still no script

 

Rendering massive amounts of point/cookie/cone/cubemap/IES lights just got a lot faster. This option is now enabled by default and it removes the overhead Bakery previously had when switching from light to light. Check the github ._.

Hmmm... not sure if I understand the idea. Printing the amount of lightmapping samples you need to match the preview? It's not exactly possible, because different pixels of the preview image may use different amount of samples for different lights. In the lightmap it's usually a good idea to set different amount of samples depending on light's shadow softness, but in preview all lights have equal weight and equal sampling probability (because even soft lights converge fast enough).

RTPreview doesn't change the way lightmaps are baked. But it helps you to make sure you're baking the right thing.

Thanks!

Maybe 2019.2 problem? I was testing it on 2019.3. Anyway, if the file is not empty it should work perhaps, even it Inpsector doesn't render it?

 

Frank dia a fantastic job with lightmapper than unity lightmapper team. he is an one man army.

 

I finally managed to bypass some of the Bakery's quirks and created a working baked lighting switching system. It stores lightmap scale-offset vectors per lightmap, so lightmaps won't break between bakes with different lighting setups. It also stores reflection probes, lightprobes, lighting props and switches everything on the fly. Tested on Oculus Go - works like a charm.

Thank you, Arthur, for this amazing lightmapper and a raytracing preview window!

 

I failed in sharing my scene to others in my team who does not install Bakery. Our Unity version is 2018.1.6f1. My Bakery version is 1.65. I commit these five .cs files with tutoriseSVN, he check out, than get the ERROR: Timestamps(55418) and assets(55420) maps out of sync - repair failed. And the scene he check out does not reference lightmap correctlly.
Help me please !

 

This error is not related to Bakery. Maybe try these links:
https://answers.unity.com/questions/236053/timestamps-566-and-assets-567-maps-out-of-sync.html
https://forum.unity.com/threads/assets-maps-out-of-sync-repairing.535750/

 

Thanks. I will give a try.

 

Hi, today I went to the crash:
Function _rtContextLaunch2D caught exception: Encountered a CUDA error: cudaDriver().CuEventSynchronize(m_evnent) returned(999) Unknown.
I found that the user Liudian208 reported similar problem to your, but I can't found solution in the posts. Do you remember how you solve the problem ? For example some kind of mesh is bad?

 

Are you sure your geometry has non-overlapping lightmapping UVs? Can you show me your .ftracelog.txt? Were you using Render Selected/Render Light Probes/"Export geometry and maps" checkbox?

 

Setup new test project with 2019.3 and the same issues.
After some investigation found that we could get Unity to link padding file if ftSavedPadding class is extracted to own file called ftSavedPadding.cs, this allowed it to be maintained across Unity restarts.
The next issue was this file was not being used when the asset was reimported. This seems to be due to the fact that storage is always null in OnPreprocessModel() as GlobalStorage hadn't been read. This can be resolved by calling Init() at the start of OnPreprocessModel()?
The next issue is these files don't get used when reimporting project for the first time (clean install with no libraries). I think this is due to the fact that ftGlobalStorage.asset has not been imported (so is not available) when models are imported? therefore we get the same issue as above.

I hope these findings make sense? Perhaps our understanding of how it should work is incorrect?
Any Idea of how we can fix the issue in a clean startup?

 

Sorry if this is a repeat question but I can't find it.

What files, if any, should we be adding to our .gitignore from Bakery? ftGlobalStorage and ftLocalStorage in particular I'm wondering about.

Reason I ask is when we check in our Bakery result (lightmaps and other files) and pull it to another machine, the result is different (and corrupted looking).

 

Kinda confusing, because it works for me:

I can separate ftSavedPadding to its own file then, but it will break padding assets for everyone else who had them working before. Or I'll need to do some backwards compatibility...

Hmmm... yes. Not sure why I only called in OnPostprocessModel. Seems like a bug. Fixing it. Thanks!

All I can possibly say is here: https://geom.io/bakery/wiki/index.p...2Fother_version_control_system_with_Bakery.3F

 

This part works for us too, it's when you restart Unity that it loses track of the asset. Have you tried shutting Unity, reopening again then checking asset?

Seems to be seeing same issues as us perhap new problem crept in?

 

I solved the problem by using another project to bake. Still thanks for your help.
But the problem sharing the scene to others is still unsolved. The problem timeStamp error for that five .cs files is solved, and the logs CreatedGlobalStorage, CreatedLocalStorage were showed on my teammates computer, but the scene still does not reference the lightmaps. Please help

 

Oooh. Oh. OK, indeed it doesn't work in 2019.3 (somehow still works in 5.6).
Many apologies for wasting your time. Just pushed fixes to github.

I updated the link with another known issue.

- Get my debug tools
- Click Bakery -> Debug select storage
- Click Show Debug Info on the component
- Check maps and bakedRenderers arrays. These should contain your lightmap assets and mesh renderer references. If they don't, you are likely incorrectly copying the files. Unity will often break any inter-asset references when simply copying files around. Check if exporting/importing them as .unitypackage works. Maybe your version control setup is not configured right for Unity.
Do you synchronize .meta files as well?

 

Hi, I'm getting some weird issue with Unity 2019.2.16;
I've got bakery installed from the Asset Store w/o github tweaks;

When I bake, some of the object's coordinates in the lightmaps get -infinity / infinity values causing them to be pitch black.

What can be the cause of this?



Edit: NVM, it seems like Generate UV's were disabled on the models.

 

I'm having difficulty with using bakery and git. Every time I pull commits made by someone else all my baking breaks.

• I'm the only one with bakery installed on my machine - the bakery files are not committed
• Meta files and lightmaps are committed
• I've tried:
  • Baking with adjust UV padding
  • Baking with UV padding increase only
  • Reimporting assets
  • Save uv padding to asset as shown here

 

You'll still need other machines to have some of the files: https://geom.io/bakery/wiki/index.p..._who_doesn.E2.80.99t_have_Bakery_installed.3F

 

@guycalledfrank , i have noticed a weird thing,while i add two different IES files to my lights, one type of them gets replaced by other IES type arbitrary , and it seem it tends to just render one type of IES file at same time.

 

Hi there,

I got bakery today, and I really like it so far. Much faster then Unity baking. However, I got one issue. I have a very huge scene and my lightmap is over 1 GB in size :33 Non Directional Lightmaps with Shadowmasks: 33x4096x4096. Is there a good way to reduce that size? It's for a mobile game.
My settings are almost default, except:

- RenderMode: Shadowmask (no distance shadowmask)
- RTX Mode
- only one directional light

Thanks!

 

Weird, sounds like a bug! Can you make a simple scene with these lights and send to me (as unitypackage) for debugging?

Surprised you managed to bake 33x4096x4096. The only way to reduce lightmap count is to lower your resolution. Reduce Texels per Unit globally, then you can increase Scale in Lightmap on important renderers.

 

Hey Frank, I'm trying to use your awesome bicubic lightmap filter on GLES3.2 but it's not working.
By default, it's not applied on mobile (still linear) while on the editor it's bicubic.
I have modified the "ftrace.cginc" file in CGIncludes inside the Unity folder to bypass the "#ifdef SHADER_API_D3D11" conditional compilation and force the bicubic methods but now the lightmaps have no filter at all on mobile! (I mean, it's pixelated, nearest neighborhood on the Oculus Quest (adreno). Not even linear. On the editor it's still bicubic filtering.)
I have checked your code but it doesn't seem to include anything that GLES3 wouldn't do.
What kind of witchcraft is this?
How can I make it work on GLES3 ? HEELP!

 

Yeah, problem is, you need to know texture resolution (or texel size) for the bicubic code to work. Alas, Unity doesn't supply this information for lightmaps - I tried unity_Lightmap_TexelSize but it was zero; so I had to work around it by using HLSL tex.GetDimensions() function, but it required shader model 4.0+ and as far as I know Unity CG compiler won't compile it for GLES, hence #ifdefs.

Probably Unity just stripped GetDimensions away and values are all 0.

Technically, for your particular scene you can send lightmap resolution constant to shaders yourself (e.g. via MaterialPropertyBlock), then use it instead of GetDimensions. I didn't go for this option to avoid sending additional constants when not totally required (it's not exactly free and may affect batching).

 

sure , ill do that over the weekend, where should i send you

 

Private messages here on the forum are fine.

 

Another nice comparison of 1.65 vs new 1.7 atlas packing

 

Thanks for your help. I got one more questions. Where can I see the size of the bakery lightmap. I think yesterday it was just under "Lightning" Settings. But now there is no information, although the lightmap is visisble in the scene view?



Is there any other place where I can check the lightmap size? Thanks!

 

Unity is bad at counting external lightmaps in its lighting window since 2018.3 and I don't know what to do about it. Well, at least they still work in the scene.

 

ok, thanks for the info. Seems to work at least sometimes. Is there any other way to check the size of the lightmap in a later build? When I check in the Assets-Folder, there are tga and hdr files for my scene, but when I add all those together, it is almost 4 GB. So I guess not all those files are used, right?

 

Not really. You are weighting source files that don't go to builds. Unity applies GPU-friendly compression to all textures. If you select lightmap assets in the project window, it will tell their actual size (but unfortunately it only shows it for one selected asset).
Also Bakery doesn't delete old unused lightmaps... so what's in your folder is not necessarily what's used in the scene and what will go to builds.

 

Thanks for the info!
I did some research and, as you probably know already, it's no easy task to access lightmaps sizes from shaders, since Unity is not sending _TexelSize for lightmaps as opposed to every other texture and, also, lightmap access from shaders is not "officially" supported.
I searched for an alternative GLSL function for GetDimensions, and it does exist, but it seems it gets the pipeline to stall and the HLSL converter to GLSL doesn't support it anyway so...
As I really, REALLY wanted your bicubic lightmaps to work on the Oculus Quest, I just specified a fixed size for lightmaps (2048) and passed this as an uniform to the shader
It's not pretty, but it works. And my lightmaps are always huge anyway, so whatever
Later on, I found that I can get away with smaller lightmaps too even having specified a larger fixed size for the bicubic filter, as sizes are multiples anyway, so in the worst scenario you end up with a linear filter instead of a bicubic one.
I'll stick to fixed 2048 anyways.
I really like that bicubic filter

 

mmm... seems like a talked too fast:
On the Oculus Quest, even with hardcoded fixed values for the lightmaps size, I still get pixelated lightmaps like if no filtering was enabled!
On the editor it's working fine, but on device all filtering is disabled, even though I commented out GetDimensions and used actual hardcoded sizes!
I don't know what's happening

 

Just guessing - you're seeing the Quest rendering an intermediate "blit" texture, which currently really messes up how lightmaps look in general. There's a way to force the blit not to render, but that also scratches all of your PP options.

 

I'm doing postpro directly into each shader code, so no worries there.
Could you elaborate?

 

Weird. Does it work in any builds (e.g. desktop build) in general? Did you hardcode 2048 directly in CGIncludes/ftrace.cginc and not via MaterialPropertyBlocks?

 

I haven't tried to build for PC, only Oculus Quest. I'll try that now.
And yes, I have hardcoded the lightmap size (4096 currently) in the ftrace.cginc in the CGincludes folder.

Code (CSharp):

1. float3 ftLightmapBicubic( float2 uv )
2. {
3.         float width = 4096.0, height = 4096.0;
4.         //unity_Lightmap.GetDimensions(width, height);
5.  
6.         float x = uv.x * width;
7.         float y = uv.y * height;
8.  

I'm currently trying different approaches to pinpoint were the problem exactly lies: I have replaced all bicubic methods with "defines" just in case the HLSL to GLSL compiler was getting entangled somehow but it behaved exactly the same.
I have even checked if the code in ftace.cginc was being executed at all and it is indeed executing.
I'm trying the PC build now but I expect it to behave just as in the editor. (edit: I expect the PC build to correctly do the bicubic filtering while the Oculus Quest build does not)

 

As expected, the PC build has luxurious bicubic filtering while the Oculus Quest is having no filtering at all (big razor-cut pixels).
This is with hardcoded lightmap sizes and disabled "#ifdef SHADER_API_D3D11" conditional compilation on both builds, effectively forcing bicubic all the time on every platform.
Right now I'm short of ideas.

EDIT: Keep in mind the regular linear filtering with the regular ftrace.cginc code included with Bakery is working fine on the Oculus Quest. It's just the bicubic filtering that isn't working no matter what I do to enforce it.

 

wait a minute 1.7 released ?

 

After spending lots of time on this, I can only conclude GLES3 has not enough precision on the sampler coordinates to perform the bicubic filtering the way Bakery does it.
Every sample ends up landing on the same spot as the others and that's why it ends looking like there is no sampling at all.
Maybe on Vulkan it would work. But Vulkan is currently too slow on the Quest to be an option.
I stand defeated!

 

I got an issue with artifacts on a terrain.
Tried lot's of different settings, but so far I was not able to solve it.
Setting Terrain-Optimization helped a little bit, but not all artifacts go away.
Any ideas how to solve this? Do I need to tweak the terrain somehow?

Here are some pictures of a small part of the terrain. The effect can be seen on many more places.

- bakery (shadowmask/RTX Mode)


- bakery (fullligthning/RTX Mode)


- bakery (fulllightning/Terrain Optimization)


- plain terrain without any lightmap:


- unity build in lightmapper: