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

Hi, is there a way to bake subscenes? I dont understand how it should work. I baked with the subscene open but bakery unloads the scenes anyway. Is it possible to do it with bakery?

 

I've tried some larger areas and it seems like it works well, I'm doing some conversions to my character and scene shaders to the bakery one, I'll see about posting an example when I have a clean build.

 

Have not had an issue until recently but am now consistently getting a memory allocation error, even though I should have plenty of GPU memory available.

Any other ideas as to what might be causing this issue? I have been using bakery in a few scenes without issue but am suddenly hitting this wall with no clear cause.

Here are the last few lines of the ftracelog.txt....
"
Skipping pass HDR2
Used host memory: 2819mb, available GPU memory: 7115mb
Launch 10x10 tiles...
Tile 0x0...
Streaming...0
npHD
Launching...
Error (1282): Memory allocation failed (Details: Function "_rtContextLaunch2D" caught exception: Memory allocation failed)"

 

Thank you for this info!

 

I'm not sure then. There is no difference (that I'm aware of) for the shader if the lightmap it's using is indirect-only or full lighting. Both are just the same texture in the same slot, being read with the same code. With indirect-only you just have real-time lights on top... if it doesn't even work with the built-in lightmapper, then the issue is not Bakery-related, more like some general Shadergraph issue.

I heard about some shipped projects with them.

Correct.

It's a bit tricky to integrate into a surface shader (but possible). If you can't use the Bakery Standard shader, drop me your surface shader, and I can try integrating the volumes into it (well in case it's hand-written and human-readable and not generated by some node-based tool).

But overall you can just look for "#ifdef BAKERY_VOLUME" in Bakery.cginc for all volume-related code.
And since Surface shaders don't allow overriding GI (or do they now?), it may require some weird hacks like writing albedo*GI to emission instead and zero-ing real albedo, so built-in GI won't apply.

I would just decide it per-project. I don't know any good reason to use both options in one game.

Ah. In fact it's the default behaviour for Lightmap Groups, they will always try to stretch everything to 100%. If they don't though, try using xatlas as atlas packer + enable Hole Filling (if it's a hole in a single object's layout, not between different layouts). Can you show me how your atlas looks?

 

You can bake separate scenes and then add them together. You can also bake all scenes at once, when they are added. How were you baking exactly?

Seems like it's happening in the GI phase. How many lightmaps do you have in the scene? Apparently there are too many of them/they are too big. Try to profile them with Checker Preview / Atlas Preview: https://geom.io/bakery/wiki/index.php?title=Manual#Checker_preview
How many of them/what is their size?

Also the classic "turn off memory-intensive programs" (like browsers) might help:
https://geom.io/bakery/wiki/index.p..._get_an_.E2.80.9COut_of_memory.E2.80.9D_error

 

Hi, I have a baking issue I can't resolve. Can you see any reason why Bakery isn't rendering the lightmap for this light, and only the Unity Realtime light is lighting the area? You can see the render results, one with Bakery handling indirect and shadowmask, the other indirect only. Essentially, Bakery isn't baking any light for this light:

Bakery baking:


Unity RT lighting taking over:

 

I have run into a similar issue. I am using a blank Unity 2021.3.13 URP project with Bakery. I am using SH directional mode and have changed all of the shaders/materials to "BakeryURPSHGraph" but when I go to bake most of the materials are black.



Any clue on what this could be or any know fixes?

 

Here is a picture of a room using a light volume and baked lights. The dark character has the standard shader without light volume enabled, the rest use the bakery/standard shader with light volumes enabled.

 

@guycalledfrank for the light volumes, can they move with the camera, or do I need to have them cover my entire scene?

 

Is the light shape marked as static? Bakery treats all backfaces as opaque, so the light is trapped inside the object. Unity doesn't by default, but you'll have the same result if you set "Cast shadows" to "Two-sided". So don't mark the lamp (at least its yellow/translucent part) as statc or "Contribute GI".

Thanks for reporting!
I tested it and indeed faced the same issue.
It turned out to be caused by an inconsistency in channel packing. My shaders used red channel for occlusion, while URP shaders used green! As the red channel is black on some materials, big part of this scene became black.
So the fix is just to rewire it in BakeryLitBase and save:




I've updated the graph archive: https://drive.google.com/file/d/1FDGBs6-Om8loMw0Msfm2rzdv-s5KmgYu/view?usp=share_link

(Also linked on the main wiki page now)

You can move them with the camera if you're moving your scene with the camera too... if the scene is not moving, then you need to cover it all with one or multiple volumes (see example_volumes_advanced for the multi-volume scenario).

 

hi @guycalledfrank

I'm trying to bake out a fairly large scene and running into this error. This error stops the bakery rendering. I sent you a message with the log files.

Bakery suggested I run the optimizing utility and I set the recommended default values. But still get this error.

Hope you can help give some suggestions.
Thanks for your help

 

A Universal Additional Light component via UniversalAdditionalLightData.cs must be added to all lights when using URP...but is this still requried when we are using Bakery?

 

• Have you solved it
  

 

Hi all, I'm trying to use bakery volume together with light probes and occlusion probes. I found a problem where light probes baked with bakery are not correctly accepting (or not accepting at all) input from the terrain (consequently bakery volume is not working correctly for me either). Below I have provided screenshots showing the difference between light probes baked with unity and with bakery. Any ideas?

 

Show Stopper Bug: When building a scene for the Meta Quest that has a Bakery light mapped scene, the app crashes on the Quest before I even see the splash screen. Title runs fine in the editor and also runs fine if I remove Bakery and bake with Unity's built in bake tool.

I grabbed these errors from logcat and upon some investigation, I cannot find any clues as to what is going on here.



Here are the two errors captured from the above screenshot:

channel '34a53da com.MetaverseAdventures.IntotheMetaverse.Pilot/com.unity3d.player.UnityPlayerActivity (server)' ~ Channel is unrecoverably broken and will be disposed!

AND

Window handle Window{34a53da u0 com.MetaverseAdventures.IntotheMetaverse.Pilot/com.unity3d.player.UnityPlayerActivity} has no registered input channel

This is a show stopper bug and thus I hoping someone here or Frank has some insights for me as I really need to get past this issue ASAP. It was running fine until this past week, but I have not updated anything so I am scratching my head here. Maybe Meta updated something on the Quest is all I can come up with right now, but I know others whoa re using Bakery who do not have this issue. I also tried several 2020.3.x, 2021, 2022 and even the 2023 Beta and all have the same issue. I am on the very latest Bakery via the built in update.

 

no

----------- update
I noticed that it only fails on my older laptop from 2016. On my newer 2020 laptop I can successfully bake this large scene. Probably a hardware incompatibility issue? Both are running windows 10.

 

Hey. I am still in Bakery before Version 1.9501
but did regulary git updates till end of November.
Is it secure to further update over git or do i have to integrate the new asset store package Version 1.9501.

 

The GitHub version gets updated frequently, whereas the AS version gets updated rather sporadically. If you updated via GitHub or the in-editor patcher so far, you may already have surpassed the AS version by a long shot. No need to download it then.

 

RE Meshless lighting in Bakery.
I brought this up a bit ago in the Bakery Decals thread out of concern for the lightmap quality with decals (which seems to not really be an issue from what I could see) - but I wanted to bring this up here again because I really think its something where Bakery could provide an immense amount of value.
Lightmaps can be very good for creating very high-density detailed lighting - but they can also be a pain to work with. UVs, long baking times, awkwardness with dynamic objects etc etc.
Meshless lighting on the other hand is very well suited to larger, semi-dynamic environments, especially for providing a base layer of good quality GI that can then be further augmented by modern screen-space or raytraced methods. Bakery already has the ability to bake volumes, hence why I think that there is A LOT of potential to extend this functionality into a fully fledged meshless lighting system - requiring no more lightmaps.
@guycalledfrank Is this something you have considered ?
Some interesting research on this topic may be the global illumination system of Quantum Break, which is a bit older but relatively simple and it performs exceptionally well (at least the "large-scale" lighting part that is relevant here) http://wili.cc/research/quantum_break/

 

Weird, weird... are you on the latest version? Did you try patching it? https://geom.io/bakery/wiki/index.php?title=Github_access
If it still fails, can you show me the Inspector screenshot of that area light which caused the error?
Definitely something about this light's mesh or texture.

No, it's not used by Bakery.

Why use both though?

(just hopefully you realize that Volumes don't use any data from light probes and don't require them)

I can see see probes floating in dark void. I don't know what they should pick up the light from.
What is your render pipeline? Are you on the latest version? Did you try patching? What shaders do you use on the terrain? Do you have RTPreview, and if you do, does the terrain look good there?

This screenshot appears to be 400x37...

Anyway, my first guess is just running out of memory (huge lightmaps)?
Can you check if it runs when lightmaps are just veeeery low resolution?


I've no idea what these MetaverseAdventures scripts are, likely unrelated.

Either random luck or newer Bakery version.

Mostly. Some assets, like the new example scenes, only come with the the store version.

It is kinda possible to use Volumes this way right now. You still need to have at least one little valid lightmappable object in the scene, but can mark most of everything with just "Receive GI = Light Probes" or "Scale in lightmap = 0", so it won't receive own lightmaps, but will affect GI in Volumes.
Volumes are of course not much of a "system", they are just uniform raw spherical harmonics 3D textures. The "system" you use to apply them on different objects, to build hierarchies of them, is not in place, and would be very different for different platforms, pipelines and types of games. Unity also doesn't make it easy with lots of hardcoded things and limitations. Options I considered:
- Track objects moving between volumes on the CPU, swap volumes via MaterialPropertyBlocks. It works, but MPBs also disable all types of batching for these objects. But it's the least hacky and the most readable way to do it in stock Unity, that's why I'm using it in the example scene.
- Same, but swap data in materials or swap materials. Then you have a combinatorial explosion of materials (materialCount * volumeCount), and changing the base material won't affect derivative materials, and the high possibility of accidentally serializing your changes and destroying the project...
- In Deferred, draw volumes as boxes and shade pixels inside them. That's totally fine, except it only works in deferred (and Unity has old standard deferred, newer deferred, HDRP deferred...they all work quite differently).
- Sort scene objects into groups affected by different volumes; draw the scene group by group, setting volume data as global. This is how I actually implemented it in my own game, but since it requires a custom SRP, it's a system I can't apply for stock Unity pipelines.
- Some overly complicated tree structure containing all scene voxels of different resolution at once, that can be looked up in any forward/deferred shader. That would likely have a very high cost of lookup. As much as I like the Quantum Break tech, "The current, unoptimised implementation takes more than 3ms to evaluate the precomputed light transport, look up and uncompress the data and perform the seamless hierarchical interpolation per-pixel.". Surely it's likely 0.5 ms on a 4090 with similar resolution now, but I won't be surprised by 50 ms on mobile...

 

Theoretically yes. However, there are a couple issues with this :
1. Baking quality. Volumes often have artefacts that prevent them from being used for a full scene - such as biasing weirdness, sampling issues, and issues with shadowing.
2. It can't invalidate samples inside of geometry.
3. It can't "blend" samples for smoother appearance
4. Its dense, meaning that its not very memory efficient.

As for the Quantum Break method, I understand your concerns for mobile performance. However, you have to consider that mobiles are getting SIGNIFICANTLY faster over time, and that a system like this would however still primarily be used on Desktop, Console and the such. So I think its probably something that may be worth a closer consideration, as it would allow for stable, meshless global illumination with consistency across dynamic and static objects.

 

From reading through this thread we can safely ignore this warning:
"Main Object Name 'LightingData' does not match filename"

But we recently encountered this error:
Unknown error occurred while loading 'Assets/BakeryLightmaps/Cave1_371857150_probes.asset'
That file looks to be corrupted - Unity is not able to place its usual gizmo/icon in front of the filename in the project view and falls back to the default icon (blank white page).

Since it only happens to those members of the team that pulled the file from git (never for the one baking the maps and probes) I assume there's some gitattribute we might need to set. Do you happen to know which one that is?


Edit:
adding a gitattribute file with *.asset binary to the folder with the baked maps and lightprobes helped to solve the issue

 

Is it possible to roll back to the original 1.9 release package after updating?

I was testing and updated to Bakery 1.95, but now need to go back to 1.9... my company doesn't want me using 1.95 yet on current project. I thought it would be a simple process to access previous package, but not finding the option for this.

 

The reason for wanting to revert back to 1.9 is that I'm seeing dark spots generated with 1.95 vs 1.9 (see images for comparison and blue arrows in 1.95 image). I made no changes to the scene, lighting, or Bakery settings. Imported 1.95 into project and generated lightmaps which gave different results. Is there a global setting I need to change to make 1.95 give identical results to 1.9?

 

Some info on scene setup -

• Unity 2020.3.33f1 (also seeing this issue with Unity 2021.3.12f1)
• FBX has imported lightmap UVs instead of Unity/Bakery generated.
• Scene is set up with only two Bakery lights (see image for Bakery and light settings).
• 

 

OK, after some testing, I think I've identified which setting in 1.95 is causing the issue.

If I set Indirect Boost (Hacks) to 0, I don't see the spots. If I crank the setting to 10 then they are very visible.

See attached images showing the comparison between 0, 3 (my scene setting), and 10.

 

Not using a lot of lightmaps. Will sometimes crash when trying to bake a single 4k map. But it is a large surface (1500+ meters) and dense triangle count (8 million). Along with a lot of other polygons casting (but not receiving) shadows. Is it likely that mem allocation/ GI fails due to polygon counts too large? Or a single object's count it too large vs total poly count? Or if a surface is too large in scale?

 

Hi, is there any way to reduce the shadow intensity? I would like to have my shadows less dark but struggling to find an easy way to achieve this?

Thanks

 

Thanks for the reply!!!
I tried turning on the occlusion probes as stated here, item 23, and I tried quite a few different combinations of bake and light settings before writing here and asking for help.
Of course, I understand that the volume doesn't use data from the light probes. But I think when you bake, you call the Lightmapping.Bake method, which will bake the light probes if they are on the scene. Their contribution to lighting won't be used, but I think I can use them to visualize what's baked into the 3d texture (of course I could be wrong, but it correlates with the bake results). I've tried baking both with and without them, and it doesn't make a difference. Objects entering the volume don't get indirected light from terrain.
Sorry, I incompletely formulated the condition, I baked the lighting with the directional light on (screenshot 5), and turned it off for better clarity in the screenshots to show that I don't see that the volume (and light probes, which in this context I would consider a rendering of the volume) is baked with the contribution of reflected light from the terrain.
I'm using HDRP, I've already tried things that have been written about in the wiki, it didn't help. Terrain uses the HDRP/TerrainLit shader. The object shaders on the stage are HDRP/Lit. The test sphere I'm trying to get input from the volume uses the BakeryVolumeSpecGraph shader. Unity version is 2021.3.3f1.
I'll try to patch bakery.
I don't have RTPreview.

 

Hi, I'm try to create my own surface shader, my project baked by "Render Mode: SH". But when I use my shader - shadows a very black. And when use "Better Lit" shader - it's normal.
May I need some modify to my shader?

P.S. Sorry for my bed english)

 

Usually it's enough to offset the UVW in the direction of normal * size of a voxel. Have you tried it?

Do you have any examples of that?

It actually does (unless "Adjust sample positions" is disabled). When a voxel's center is inside some geometry which intersects the voxel, it will actually push it outside, similar to how it's performed for lightmap texels:

If standard trilinear hardware interpolation doesn't cut it, it can be replaced by bicubic in the shader, buuut it's noticeably costlier. I do it in 2D, but decided to avoid it in 3D.

I get your point - I'll consider it.

Oh, interesting. What did you change exactly (for people in the future who might have this problem)?

Asset store doesn't seem to have an option for this...
You can try downloading v1.9 files from github and replacing them:
https://geom.io/bakery/wiki/index.php?title=Github_access
https://github.com/guycalledfrank/bakery-csharp/releases/tag/1.9
https://github.com/guycalledfrank/bakery-compiled/releases/tag/1.9
(or get a copy from your company)

Interesting, can't remember any related changes... can you send me a little test package/project with this lighting? I'll run some tests and locate the cause.

Single object polycount doesn't matter, only total polycount. Physical size of the surface shouldn't be a problem either.
8 mil is bearable... but it possible your other objects have even more polys? You can zip and send me your vbtraceTex.bin and ib32.bin from the temp folder, I can check it.
But if you're 100% sure it happens even when rendering a single 4K map, then indeed it is possible that geometry is taking all this memory...
But also if you have lots of baked LOD levels in different objects, Bakery can internally split the scene into multiple lightmaps that stitch into one later. If that's the case, it will print "bucket count" into Unity console (can also be found in Editor.log), so maybe check if there is a very high bucket value.

Not directly. But you can:
- Increase Skylight (or other fill light) intensity, so it brightens the shadows.
- If you want a shadow to be brighter because it is cast from a translucent object, try using a noisy alpha map: https://geom.io/bakery/wiki/index.php?title=Manual#Opacity
- You can increase Indirect Boost to get more GI: https://geom.io/bakery/wiki/index.php?title=Manual#Indirect_boost (but ideally/correctly that should be done by tweaking tonemapping/exposure).
- As a last resort, you can implement fake ambient like this: https://geom.io/bakery/wiki/index.php?title=How_do_I...#How_do_I_add_fake_ambient_lighting.3F

Ah, it's only used to initialize the probe grid. Colors are replaced.

If probes are baked in L1 mode, then yes, they will look very similar to Volume voxels (as the same algorithm is used).

But anyway, I can reproduce the issue. But I can't get the base map of the terrain in HDRP. There is no way to get the base map directly, and Camera.Render() doesn't work in HDRP.
HDRP was a mistake.
For now I can only suggest using a mesh instead of a terrain (or URP/StandardRP/CustomRP instead of HDRP).

The black version looks normal to me, there is no light to make the undertable area that bright. It is likely that Better Lit is adding some fake ambient on top (?).
What shader are you using when it's not Better Lit though? Are you using one of my graphs?

 

To illustrate the issues with volumes at the moment, have a look at this comparison.
Top : Lightmaps
Bottom : Volume (Resolution 12, no denoise, otherwise default)



I think the issues are pretty visible

 

Hi Frank

The last patch I did was for the bug about:

"light maps being deleted once entering play mode" ..

Should I patch it again?

• If it still fails, can you show me the Inspector screenshot of that area light which caused the error?

Sorry I nuked that project off my laptop. I tried to bake an updated version of the project and still ran into same error. But this time I don't think it was the area light .. I'll do another bake tomorrow and see if I can get a screen capture.

--- UPDATE ---

So I gave up trying to bake that project in one pass. I deleted all the area lights and things seemed to render, until I ran out of memory and Bakery stopped.

Instead I tried to use Bakery Sectors to see if it'll fix the bug. But I ran into several new issues.

1) I might be incorrectly using Bakery Sectors. I was reading this and I put "x" game objects under the one root game object with the Bakery Sector component. But Bakery is rendering everything EXCEPT what is in the bakery sector.
https://geom.io/bakery/wiki/index.php?title=Partial_scene_baking

2) Bakery Sector won't render the light probes for me. It keeps giving me this error.

I sent you a DM with the project files and videos


Hope you can give me some suggestions.

Has anyone else tried using Bakery Sectors? Any tips would be welcome.
Thanks for the help

 

Sad. I'll try to write my solution. Thanks for the reply!

 

Hi, I got a new error while baking.



64-128gb ram. RTX 3070 ti 8gb.

 

Literally just placed a .gitattributes file into the folder with all the baked textures and light probes to override the root folder setup.
With these two lines in there:

# Declare lightmap asset files as binary
*.asset binary

We have a .gitattribute file inside the root of our project with this line for .asset files:
*.asset text eol=lf

When we did not have the override in place the files got corrupted sometimes.

 

Hello,

I'm using dominantDir from volumes for baked specular and custom shadows, but not sure if everyhing works as expected.
Using Bakery shader, forward, 2021.3.8f1, newest pull from git, Volume resolution 1 tex/unit

1. Division by L0 is giving weird results. Withou the division, it works as expected

Code (CSharp):

1. float3 nL1x = L1x / L0;
2. float3 nL1y = L1y / L0;
3. float3 nL1z = L1z / L0;
4. float3 dominantDir = float3(dot(nL1x, lumaConv), dot(nL1y, lumaConv), dot(nL1z, lumaConv));
5. return float4(normalize(dominantDir), 1);

2. There seems to be discrepancy in dominantDir between compressed and uncompressed volumes.


When then sampled from C# - trillinear, at multiple points in grid (red dots), red lines are extension of the returned direction, which should cross at light position. Code is taken vrom Bakery.cginc:
For uncompressed, I get quite correct light position (with texel resolution/2 offset)
For compressed, it gets really messy.


Any ideas? I would like to get the uncompressed quality, because the compressed is unusable for custom shadows (c#).

 

Just ran into an issue I thought was worth reporting. I was trying to script Bakery to bake 8 different sectors in serial. This shouldn't have taken longer than an hour at most. After 12 hours Unity was just outright unresponsive. Here's what the logs showed:

Code (CSharp):

1. Opening scene 'Assets/Bakery/_tempScene.unity'
2. Unloading 0 Unused Serialized files (Serialized files now loaded: 0)
3. Resource ID out of range in GetResource: 1048577 (max is 1048575)
4. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
5.  
6. Resource ID out of range in SetResource: 1048577 (max is 1048575)
7. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
8.  
9. Resource ID out of range in GetResource: 1048577 (max is 1048575)
10. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
11.  
12. Resource ID out of range in GetResource: 1048577 (max is 1048575)
13. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
14.  
15. Resource ID out of range in GetResource: 1048577 (max is 1048575)
16. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
17.  
18. Resource ID out of range in SetResource: 1048577 (max is 1048575)
19. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
20.  
21. Resource ID out of range in GetResource: 1048577 (max is 1048575)
22. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
23.  
24. Resource ID out of range in GetResource: 1048577 (max is 1048575)
25. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
26.  
27. Resource ID out of range in GetResource: 1048579 (max is 1048575)
28. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
29.  
30. Resource ID out of range in SetResource: 1048579 (max is 1048575)
31. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
32.  
33. Resource ID out of range in GetResource: 1048579 (max is 1048575)
34. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
35.  
36. Resource ID out of range in GetResource: 1048579 (max is 1048575)
37. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
38.  
39. Resource ID out of range in GetResource: 1048579 (max is 1048575)
40. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)

It then repeats this for SIX MILLION LINES. After that, it changes slightly to:

Code (CSharp):

1. Resource ID out of range in GetResource: 1539033 (max is 1048575)
2. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
3.  
4. d3d11: failed to create 2D texture shader resource view id=1539033 [D3D error was 8007000e]
5. (Filename: C:\buildslave\unity\build\Runtime/GfxDevice/d3d11/TexturesD3D11.cpp Line: 537)
6.  
7. Resource ID out of range in SetResource: 1539033 (max is 1048575)
8. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
9.  
10. Resource ID out of range in GetResource: 1539033 (max is 1048575)
11. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
12.  
13. Resource ID out of range in GetResource: 1539033 (max is 1048575)
14. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
15.  
16. Resource ID out of range in GetResource: 1539035 (max is 1048575)
17. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
18.  
19. d3d11: failed to create 2D texture shader resource view id=1539035 [D3D error was 8007000e]
20. (Filename: C:\buildslave\unity\build\Runtime/GfxDevice/d3d11/TexturesD3D11.cpp Line: 537)
21.  
22. Resource ID out of range in SetResource: 1539035 (max is 1048575)
23. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
24.  
25. Resource ID out of range in GetResource: 1539035 (max is 1048575)
26. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
27.  
28. Resource ID out of range in GetResource: 1539035 (max is 1048575)
29. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
30.  
31. Resource ID out of range in GetResource: 1539035 (max is 1048575)
32. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
33.  
34. d3d11: failed to create 2D texture shader resource view id=1539035 [D3D error was 8007000e]
35. (Filename: C:\buildslave\unity\build\Runtime/GfxDevice/d3d11/TexturesD3D11.cpp Line: 537)
36.  
37. Resource ID out of range in SetResource: 1539035 (max is 1048575)
38. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
39.  
40. Resource ID out of range in GetResource: 1539035 (max is 1048575)
41. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
42.  
43. Resource ID out of range in GetResource: 1539035 (max is 1048575)
44. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
45.  
46. Resource ID out of range in GetResource: 1539037 (max is 1048575)
47. (Filename: c:\buildslave\unity\build\runtime\gfxdevice\GfxResourceIDMap.h Line: 109)
48.  
49. d3d11: failed to create 2D texture shader resource view id=1539037 [D3D error was 8007000e]
50. (Filename: C:\buildslave\unity\build\Runtime/GfxDevice/d3d11/TexturesD3D11.cpp Line: 537)

This continues for another NINE million lines. At that point I killed Unity.

 

fyi
https://phog.github.io/snerg/

 

Has anyone successfully made a Unity script to bake a bunch of Bakery sectors in sequence? Given the errors above I'm probably doing something wrong so I'd like to see if someone else has already programmed a script to do the same.

 

Weird, where did direct lighting go? Did you bake in Indirect-only and disabled the real-time light?

Here is my test:

Lightmaps (full lighting):



Volume only (132x115x124):



Volume only with sampling position offset a little bit:




There is some brightness mismatch due to lightmaps being baked exactly for given normals unlike the SH, buuut overall it seems pretty close.

Make sure you're on the latest version, BTW.

Tested your project and answered you in DM.

Haven't seen this one before... can you send me your .ftracelog.txt just after this error?

Without the division you'll get RGB-weighted directions.

The code should be different. In the compressed version L1 is already pre-divided by L0 and scaled to the 0;1 range.

I.e.
directionFromUncompressed = normalize(L1 / L0)
directionFromCompressed = normalize(L1*2-1)

Oh... no idea what these resource IDs are. Do you have the script? Maybe I'll test it.

NERFs are cool! I'm keeping an eye on them.

 

I see banding like that in Bakery if I use stretched quads as the mesh for an object, for example this wall is a quad that's been stretched out to cover a back wall (look closely at the shadow in the middle of the first image - second image provided to show the shape of the quad). It has a streaky effect as though the denoising has smeared in the direction the quad is most stretched.





@guycalledfrank I'll message you the script now.

 

Updated version just now.

Same result.

Here are my settings:


The light is always the same, its still on.


And I also have a skylight in the same with the default settings (except tinted slightly blue).
Its all in the global volume.

 

That is what I am using, I've copied the code from Bakery.cginc (although there is no difference between compressed and uncompressed while computing dominantDir.

Spoiler: Bakery.cginc snippet

But even without the division, uncompressed volumes are working as expected - shader prints nice color with visible texels and in c# version it returns correct direction, but compressed does not (with propper code). Is there expected any precision lost, which could cause behaviour like this?

Scene is realy simple - square Plane with red light point light at the center (range = 5), 2 m from the ground. Direct and Indirect light Baked contribution, Shadowmask Render mode and MonoSH Directional mode.

The code I am using in C# version:

Spoiler: Code

Code (CSharp):

1.     public Color sampleTrilinear(Texture3D tex, Vector3 uv)
2.     {
3.         uv.x *= tex.width;
4.         uv.y *= tex.height;
5.         uv.z *= tex.depth;
6.  
7.         Vector3Int uvInt1 = Vector3Int.FloorToInt(uv);
8.         Vector3Int uvInt2 = Vector3Int.CeilToInt(uv);
9.  
10.         Color c000 = tex.GetPixel(uvInt1.x, uvInt1.y, uvInt1.z, 0);
11.         Color c001 = tex.GetPixel(uvInt1.x, uvInt1.y, uvInt2.z, 0);
12.         Color c010 = tex.GetPixel(uvInt1.x, uvInt2.y, uvInt1.z, 0);
13.         Color c011 = tex.GetPixel(uvInt1.x, uvInt2.y, uvInt2.z, 0);
14.         Color c100 = tex.GetPixel(uvInt2.x, uvInt1.y, uvInt1.z, 0);
15.         Color c101 = tex.GetPixel(uvInt2.x, uvInt1.y, uvInt2.z, 0);
16.         Color c110 = tex.GetPixel(uvInt2.x, uvInt2.y, uvInt1.z, 0);
17.         Color c111 = tex.GetPixel(uvInt2.x, uvInt2.y, uvInt2.z, 0);
18.  
19.         Vector4 uvD = new Vector4(uv.x - uvInt1.x, uv.y - uvInt1.y, uv.z - uvInt1.z, 1);
20.  
21.         Color c00 = Color.Lerp(c000, c100, uvD.x);
22.         Color c01 = Color.Lerp(c001, c101, uvD.x);
23.         Color c10 = Color.Lerp(c010, c110, uvD.x);
24.         Color c11 = Color.Lerp(c011, c111, uvD.x);
25.  
26.         Color c0 = Color.Lerp(c00, c10, uvD.y);
27.         Color c1 = Color.Lerp(c01, c11, uvD.y);
28.  
29.         return Color.Lerp(c0, c1, uvD.z);
30.     }
31.  
32.     public Vector3 GetDominantDirection(Vector3 pos)
33.     {
34.         Vector3 L0, L1x, L1y, L1z;
35.  
36.         var b = bounds;
37.         var bmin = b.min;
38.         var bis = new Vector3(1.0f / b.size.x, 1.0f / b.size.y, 1.0f / b.size.z);
39.         //Vector3 lpUV = (pos - (isGlobal ? bmin : _VolumeMin)) * (isGlobal ? bis : _VolumeInvSize);
40.         Vector3 lpUV = Vector3.Scale((pos - bmin), bis);
41.  
42.         Vector4 tex0, tex1, tex2, tex3;
43.         bool compressed = true;
44.         if (compressed)
45.         {
46.             tex0 = sampleTrilinear(bakedTexture0, lpUV);
47.             tex1 = sampleTrilinear(bakedTexture1, lpUV);
48.             tex2 = sampleTrilinear(bakedTexture2, lpUV);
49.             tex3 = sampleTrilinear(bakedTexture3, lpUV);
50.  
51.             tex1 = tex1 * 2 - Vector4.one;
52.             tex2 = tex2 * 2 - Vector4.one;
53.             tex3 = tex3 * 2 - Vector4.one;
54.  
55.             L0 = tex0;
56.             L1x = Vector3.Scale(tex1, L0);
57.             L1y = Vector3.Scale(tex2, L0);
58.             L1z = Vector3.Scale(tex3, L0);
59.         }
60.         else
61.         {
62.             tex0 = sampleTrilinear(bakedTexture0, lpUV);
63.             tex1 = sampleTrilinear(bakedTexture1, lpUV);
64.             tex2 = sampleTrilinear(bakedTexture2, lpUV);
65.  
66.             L1x = tex1;
67.             L1y = tex2;
68.             L1z = new Vector3(tex0.w, tex1.w, tex2.w);
69.         }
70.  
71.         Vector3 brightnessVector = new Vector3(0.2126f, 0.7152f, 0.0722f);
72.         return -Vector3.Normalize(new Vector3(Vector3.Dot(L1x, brightnessVector), Vector3.Dot(L1y, brightnessVector), Vector3.Dot(L1z, brightnessVector)));
73.     }
74.  
75.     void OnDrawGizmos()
76.     {
77.         Gizmos.color = Color.red;
78.         int iterations = 3;
79.         for (int x = -iterations; x < iterations; x++)
80.             for (int y = 1; y < iterations; y++)
81.                 for (int z = -iterations; z < iterations; z++)
82.                 {
83.                     Vector3 dir = bakeryVolume.GetDominantDirection(new Vector3(x, y, z));
84.                     DebugExtension.DebugArrow(new Vector3(x, y, z), dir, new Color(dir.x, dir.y, dir.z)); // Custom
85.                     Gizmos.DrawSphere(new Vector3(x, y, z), 0.05f);
86.                     Gizmos.DrawRay(new Vector3(x, y, z), -dir * 2*Mathf.Max(Mathf.Max(x, y), z));
87.                 }
88.     }
89.  

 

I have a custom surface shader adding stencil masks and a clipping plane functionality, it doesn't use any of the UnityStandardCore cginc stuff to extend the Standard shader, I'm just using a surf (Input IN, inout SurfaceOutputStandard o) etc.

Is there a way I can add support for bakery lightmap specular to a shader like this?

 

hi @guycalledfrank

Been pulling out my hair all day baking and testing and baking over and over.

Would you consider making Youtube tutorials on how to bake very large scenes that need Bakery Sectors? I have a feeling I'm not using Bakery Sectors correctly...

I tried baking using LEGACY in conjunction with Bakery Sectors, as we discussed. Is it normal for the non-static objects to be so dark?

The Quad is the non-static. I set the light probe mode as LEGACY.

The green room is the "Baked Sector" .. but you can see that the light probes are barely lighting the Quad.

Is it because Legacy isn't as good as L1? .. My artist brain couldn't understand the explanation very well.

Code (CSharp):

1.     Legacy: use Render Light Probes button to generate the probes. Point and directional lights are calculated within the lightmapper, while area/sky/indirect lighting is gathered by rendering a cubemap at each probe position. Results are stored as L2 spherical harmonics. The downsides are slow cubemap rendering performance and possible mismatch between lightmaps and probes in cases where shaders in your game do not physically represent lit surfaces or your project is set up for mobile (Unity can clip high intensity values away).
2.     L1: light probes will be rendered together with lightmaps when you click Render. This option provides superior baking performance and will guarantee that probe lighting matches the lightmaps. Results are stored as L1 spherical harmonics (can be still used by regular shaders). Results can be further improved by using Non-Linear Light Probe SH option in Bakery shader.
3.  
4. [B]There seems to be a bug in Unity 2019.3 preventing Legacy light probe colors from being properly saved IF [URL='https://geom.io/bakery/wiki/index.php?title=Manual#Occlusion_probes']occlusion probes[/URL] option is enabled. L1 mode is now default and recommended when using occlusion probes. Legacy mode will be soon deprecated and replaced with a new L2 mode based on L1.[/B]
5.  

Here is another view. You can see I dragged the Quad close to the area light


The light probes

This is the material for the Quad


--------------- UPDATE ----------------
Separate question, how do we remove (or resize) the light probes on bakery lights?






Thanks for your help

 

Don't use legacy, it only ever produces weird results for me. Unity is a bit crap and can't bake light probes in groups so they don't get baked when doing sectors at all. You'll need to set it back to L1 and do a full scene bake to get it to bake the lightprobes.

This has been the bane of my baking life for some time now because it means I have to do one massive bake (to get the probes down) then rebake every sector individually after to get better results.

 

Please help me understand the problem, maybe I'm just stupid, but I can't figure out what I'm doing wrong

For some reason, the script Bakery Point Light bakes the light incorrectly, as you can see in the image, black stripes appear on the wall and uneven shadows on the field.

But the script Bakery Sky Light gives uniform shadows on all surfaces.

I don't use Light Probes and am trying to optimize lighting for a mobile platform.

 

Just replying to myself, so you all know that I'm an idiot
The problem was simple, but I just didn't see it. I had some big objects on scenes, so LOD group slider was all way up to 100% for LOD1. Basically it was overlapping LOD0. So if anyone have problem with shadows casted between lods, make sure you set no more than 99% for LOD1 <palmface>