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

Hello, thanks for the reply.

In my case, I'd triggering ftRenderLightmap.RenderReflectionProbesButton() via a build script (as per the Bakery docs) to trigger a reflection probe bake. OnFinishedProbes is not called - it just looks like an oversight, as OnFinishedProbes is called at the end of RenderLightProbesFunc, but it's not at the end of RenderReflProbesFunc.

(I don't particularly mind if there's one shared callback or two separate callbacks, just as long as *something* fires once RenderReflectionProbesButton finishes).

And thanks for clearing up the other questions.

 

My bad, I misread it as RenderLightProbesButton...
OK, added OnFinishedReflectionProbes event (check github).

 

Thanks!

 

I use Dungen to produce dungeons from prefab rooms and I thought I'd use Bakery volumes with the room prefabs, but when Dungen places the room prefabs it sometimes rotates them and I noticed that Bakery volumes were not rotated. Is there a solution?

 

Hi,

I have a couple of questions. I know you can bake prefabs with light but what about with reflection probe?
I have a scene which i have baked but it has metal and needs reflection probes to look good. Can i also store the baked reflection probe in it?

Also I'm guessing you can't bake a terrain into a prefab?

 

Hi.

The new Hybrid Renderer V2 allows lightmapping now.

https://docs.unity3d.com/Packages/com.unity.rendering.hybrid@0.11/manual/index.html

There is also a Test Lightmaps in the Graphics HDRP Repository under Test Projects
https://github.com/Unity-Technologi...Projects/HDRP_HybridTests/Assets/SampleScenes

• Support for lightmaps in hybrid renderer. You will need to bake with subscenes open, upon closing the lightmaps will be converted into the subscene. (Note: Requires release 10.1.0 of graphics packages).
• Support for lightprobes in hybrid renderer. Entities can dynamically look up the the current ambient probe or probe grid. (Note: Requires release 10.1.0 of graphics packages).

Complete changlog you can find in this package mirror.
https://github.com/needle-mirror/com.unity.rendering.hybrid/blob/master/CHANGELOG.md

Also the code for lightmaps, probes ......
https://github.com/needle-mirror/co...ob/master/Unity.Rendering.Hybrid/LightMaps.cs



Could you have a look if Bakery bakes becomes possible at a given point.

I ported in serveral interations the MegaCity Demo to

Unity 2020.2.3
and
Unity 2021.1.0b3

with Hybrid Renderer V2 and i try to understand how lightmpas would work in such an massive entity streaming environment with HLOD´s.

In this case you you have lots of subscenes with HLOD who get streamed in and out based on camera position.







btw.
In editor you must enable following scripting define symbols:

ENABLE_HYBRID_RENDERER_V2
USE_BATCH_RENDERER_GROUP

 

Hi,

Any suggestions for optimizing the bake quality for a case like this, where a surface has overlaid/intersecting mesh detail?



Point-sampled version, to make the lightmap resolution clear:



There seems to be 3 issues here:

1: Odd black glitches on upper stones
2: Shadows 'leaking' from underneath the lower stones*
3: Directional shadowing of upper decorative mesh is quite hard-edged, may be nicer if it could be softened (although not if it made issue 2 worse...)

The main light affecting this surface is a directional light, set to 64 samples and a shadow spread of 0.05 - which really softens shadows of large objects on the ground, but not if the shadow is close to the occluder. And I'm using shadowmap mode.

I'm using Open Image Denoise with Fix Bright Edges and Fix Seams enabled (the Optix settings added noise around the problem areas, worse than no denoising). The UV unwrap is done by Unity (with the hard angle set to 30degrees, to try and preserve hard edges). I thought the glitches on the top stones might have just been caused by having too much mesh/very small UV islands - but It's baked at a fairly high resolution, and there's quite a few texels involved

With the Unity progressive lightmapper, I'd been using the push-off value to significantly reduce this self-shadowing - which gave a less-detailed but cleaner bake - but there's no push-off setting in Bakery

(*edit: There may just be some questionable geometry - very thin tris - causing this one)

 

I'm having an existential crisis here choosing between an RTX3070 with 8GB and an RTX3090 with 24GB.
I'm coming from a basic RTX2070 8GB, so both would give me twice the render speed I currently have.
The RTX3070's performance is nearly up to par with the 3090 for rendering using Nvidia Optix.
However, the 3090 has triple the amount of VRAM.

Now the question is:
Will I ever encounter a situation were 8GB is not enough to render with Bakery without turning down quality?
I mean having "out of memory" issues that don't let me render the scene no matter what at that quality.
Or could I just make the render tiles smaller and it will consume less VRAM preserving the same quality settings? (even if it takes longer to render)

I usually go for the best VGA I can buy, but triple the cost for 10% performance boost when rendering is plain stupid.
Only the amount of memory seems to justify it, and I'm not really sure I would actually NEED it.

Thanks

 

If I may ask, how can I exclude an object from being lightmapped, but it still affects other lightmapped objects with GI & shadows? I didn't found anything in the documentation. It could also be that I missed it. Do I still need to change the "scale in lightmap" value to zero, that activates as option if you tick ON unity's light baker? Because it's off, since I bought and use bakery xD. Just asking before I bake my whole scene again, which is complicated, because then I have to import all closed objects again (switching between two mesh variants, where deleted backface-versions will be replaced after baking, to avoid unnecessary poly overhead). That's why I don't wanna "just try to see" xD

thanks in advance =)

 

Honestly? In my opinion the shadow map is simply to small. Idk what is more important to you, size or look. but whatever you want to achieve. it sure makes such artifacts, if you scale down the lightmap to such a minimum. Often, rising the resolution of the lightmap, makes the difference. I always render at highest resolution, then I go to the project folder and manually scale each lightmap as I need it down, by looking at the changes in the viewport. And as always, those strong artifacts vanishi, if you rise/adapat the resolution manually for each object/object-group. Because higher resolutions halve the pixel matrix, so that such strong pixels can vanish behind the stone. I don't want to be smart about it, rather I hope that it helps. =)

 

Does bakery support 4k or 8k lightmaps? Can a laptop RTX 2060 bake with Bakery's RTX mode? Any known issues witha mobile RTX 3070? Thanks

 

Atm only 4k. I am sure that 8k is considered to be coming, one day. But hey, you don't wanna deal with the original light mapper! Believe me! If you see that thing running the 1st time, you'll know why! Every cent of it worth! To cheap in my opinion. This is done by a total pro. There are so many plugin-code-butchers out there!, like the ones who wrote the unity build in light mapper, for example ....however, not that one!

 

Hello! I need some help with Bakery and version control.

We started have a strange issue when it comes to baking and pushing. Im certain that we are all using the same version of Unity (2019.2.21) and the same version of Bakery (1.71)

None the less, when we push bakes, the new ones always get this message on Lighting Settings:



Any idea on what we may be doing wrong? Thanks in advanced!!

 

Hi, I have a question regarding shader graph shaders and Bakery. I created a simple shader graph shader that uses a mask to cut out holes in a rusty corrugated metal ceiling by using a _Cutoff property as an alpha clipping threshold. Of course, when in normal scene view the directional light can travel through the cutout holes and light appears on the ground. But when baking light, no light is able to move through these parts of the object. In the real-time preview these cutout parts are just ignored.
My question would be if there is a way to get shader graph shaders with alpha cutout to work with bakery? Or what do I have to do to make this work? I read in the documentation in "Opacity" that the right rendertype tag could help but afaik its not possible to assign tags in shader graph shaders (correct me if I'm wrong,my shader knowledge is very basic).

would be amazing if someone could help!

Cheers!

The corrugated metal roof with the cutout hole



The Material properties

 

Hello @guycalledfrank

We started an update of our project from Unity 2019.4 to 2020.1, our environment scene with baked ligthmaps are in a Unity Package built with 2019.4. When I open a project with 2020.1 that uses this environment package, the mesh scale in the lightmap is wrong for most of the objects in the scene.

Here are two screenshots to illustrate the problem:

Unity 2019.4:


Unity 2020.1:


Do you have any idea what's happening in here, or are you aware of some changes in how the lightmaps are handled in 2020.1?

Thanks for the time you take on the support

 

Why is xatlas so slow at adjusting UV padding?

Like each time it needs to update UV's it takes like an hour or two.

Edit: or maybe its light map groups that's the problem? I just removed all light map groups and there was no long packing phase. But adding them back brought back the packing.

 

i unwrapped my models with unity automatic "Generate light map uvs" and thus i have no overlapping light map uvs.When switching to the "experimental settings" i am confused about the "Asset uv Processing" Settings.Which settings should i choose between 1: don't change 2:Adjust uv padding 3:Remove UV adjustments. Which setting will give me best result among these settings. read the manual but still little bit confused.If the author shed some light on this will be very helpful for me thnx

 

... yeah, currently volumes are fixed AABBs, not rotated (like the reflection probes). If you baked them unrotated and later rotate the object it is possible to get away only with a little shader modification. What render pipeline are you on?

BakeryVolume.cs sets the global volume for all objects, any other scripts (BakeryVolumeTrigger.cs in my examples) can set different per-object volumes.
You can send volume rotation to the shader, e.g. add this to BakeryVolume.cs:

Shader.SetGlobalVector("_GlobalVolumeRotation", Matrix4x4.Rotate(transform.rotation));

and similar for the non-global matrix, if you need it.

In the shader (Bakery.cginc for standard pipeline, BakeryDecodeLightmap.hlsl for URP or HDRP) you can declare these matrices:

float3x3 _GlobalVolumeRotation;

float3x3 _VolumeRotation;

There is a line for volume UV calculation that looks like this:

float3 lpUV = (s.posWorld - (isGlobal ? _GlobalVolumeMin : _VolumeMin)) * (isGlobal ? _GlobalVolumeInvSize : _VolumeInvSize);

You can replace it with something like this instead:

float3 vmin = isGlobal ? _GlobalVolumeMin : _VolumeMin;

float3 vinvsize = isGlobal ? _GlobalVolumeInvSize : _VolumeInvSize;

float3x3 vrotation = isGlobal ? _GlobalVolumeRotation : _VolumeRotation;



float3 vcenter = vmin + 0.5f / vinvsize; // can be precomputed and sent to shader in advance.



float3 lpUV = mul(s.posWorld - vcenter, vrotation) + vcenter; // order of multiplication may be different

lpUV = (lpUV - vmin) * vinvsize;

The only difference is that you rotate world position around volume center. Should it be a feature included by default? Maybe. I guess it can be an option on the shader/volume.

Reflection probes are fully managed by Unity, there is no extra code for them. If you can do it without Bakery, it works, if not, then it's not supported (but can be possibly hacked around).

This should be possible.

I think Hybrid Renderer is still a bit too early to look into right now.

Can be caused by weird UV or just very low resolution of the object.

Yeah, that's my thought... can you show the checker? Problem 3 looks as if texels were larger than UV islands. If it's not the resolution, then I don't know. Can you send me this mesh to test?
Make sure to use Bakery's own checker preview, not "baked lightmap" view in Unity.

That should be autofixed if "Adjust sample positions" is enabled, hmmm... are you sure you didn't disable it and the stones are not double-sided?

If you are not planning to build a HUGE, like H-U-G-E world with ridiculous detail... then 8 GB is the way. But 24 GB sounds sexy (personally I'm still within 6 GB limit with a pretty big world...).

It is there though: https://geom.io/bakery/wiki/index.p....2FGI_without_having_a_lightmap_on_its_own.3F

Yes. Main UI doesn't allow to select 8k though, because it's a bit too much performance-wise (or was... when I tested it 2 years ago). But it's just a UI limit, you can remove it. Manually created lightmap groups also allow choosing 8k.

It should. Why would they call it RTX if it didn't have RT cores?...

Don't know about the mobile one. Heard some very weird reports about 3070 randomly crashing when you least expect it (watching youtube, having a Unity scene open without doing anything), but I'm thinking it's likely related to some hardware problem in a minor share of these GPUs.

The message itself is fine, you can ignore it. Lighting data asset is only used to store light probes (at least when using Bakery), lightmap data is stored separately. If you can see light probes working, then it's OK.

It's tricky, because Unity doesn't have a proper way to transfer opacity information to the lightmappers (including built-in). All standard shaders and graphs implement a "meta pass" which renders albedo and emission to use for lightmapping, but doesn't support custom alpha: https://docs.unity3d.com/Manual/MetaPass.html
Both Bakery and built-in lightmappers just take some opacity map with the standard name (i.e. _MainTex, _BaseMap, _BaseColorMap, depending on your pipeline), standard UV0 and standard alpha threshold and use them.

I recently added a way to supply custom alpha to the lightmapper though, but it requires a fully custom (not surface, not graph) shader. The updated version is on github: https://geom.io/bakery/wiki/index.php?title=Github_access

It works by allowing you to declare your own extended meta pass in the shader, with alpha support:




I'm not sure yet how this feature can be used with graphs. Shadergraphs still don't allow you to create new passes, right?...
https://forum.unity.com/threads/how-can-i-add-an-extra-pass-to-a-shader-graph.796503/

You also can't define a vertex shader in the graph (which is needed). Graphs in their current state are extremely limited.

By Unity Package do you mean .unitypackage files? These should work, and I didn't notice anything different in 2020.1.
Lightmap atlas tiling/offset is stored on the invisible !ftraceLightmaps object in the scene and applied when the scene is open. Maybe it wasn't copied or the script is not present/linked/failed to compile? Can you try:
- Importing my debug tools: https://geom.io/bakery/wiki/index.php?title=Community_extensions#Debug_Tools
- Bakery -> Debug select storage
- Clicking "Show debug info"
Anything wrong in the process? E.g. unreferenced script on the selected object? If you close Bakery window, delete the object and click "Debug select storage" again, will it select another object? Maybe there are somehow many of them in the scene?

Depends on mesh complexity, if "hole filling" is enabled. If you disable hole filling, it will make xatlas pack bounding rectangles, which is much faster. But when it's on, it has to pack very complex shapes and can get annoyingly slow.
Also, you can change the atlaser per-group.

 

Imagine you have a UV layout:



It's a pretty decent layout on its own. And you can see some padding between the islands, so the color from one island won't interfere with another:



But... we decided to bake a very low resolution lightmap to it:



Oh no! Everything is now a mess and the padding is gone:



When you enable "Adjust UV padding" Bakery will re-unwrap automatically-unwrapped meshes right after the lightmap resolution is computed.

The padding is now larger and suitable for low resolution:



Note that it is only performed for the assets with "Generate lightmap UVs" checkbox enabled. Custom UVs are unchanged.

However, the problem with this approach is that Unity doesn't bake the new UV layout into the original asset, and the unwrapping process is re-executed every time every machine imports the asset. Bakery stores additional unwrapping info in the .meta file of the model and has a model post-processing script. These try to make sure every time the model is reimported, it will respect these adjusted settings. Sometimes it fails when syncing the project across many PCs, e.g. if the script was imported after the models: https://geom.io/bakery/wiki/index.p...2Fother_version_control_system_with_Bakery.3F

It can also take some time to adjust UVs before the bake (but it only happens if lightmap size became different on the object).

"Don't change" doesn't do anything.

"Remove adjustments" removes this additional info from .meta files and reimports the model with default unwrapping settings.

 

Well, I finally pulled the trigger on the RTX3090 since I managed to get it at MSRP
That and 32GB of RAM extra for my rig, so now I have 64GB of ram and 24GB of VRAM
Now if I could actually finish my game, that would be great.

 

thnx for clearing thnx man

 

Actually i think i figured out the main source of the issue is enabling the Xatlas unwrapper. Without it, it takes longer but not near as long as otherwise.

But now i'm encountering another problem with the atlaser without it.

Objects are being overlayed in the UV. Maybe I'm missing a setting?


part of the uvs


And other issues where objects are dominating the map despite the scale being correct. For instance this TV stand appears large for no clear reason, and it seems like random objects just dominate the map.

 

So it seems the cause is Hole filling?

 

Alright, thanks for clearing that up!

 

Ah yeah, using it as unwrapper is much slower than just for atlas packing. Even using it to unwrap sponza is quite slow. Standard Unity unwrap + xatlas atlas packing with hole filling gives very good results and much faster. But if it's slow even this way, then try disabling hole filling.

 

Is it with the default unwrapper + xatlas packer + hole filling on (off?)
Using any lightmap groups (with which packing mode?)

Some sides of the object look correct. I guess the unwrapper just decided to make front faces smaller than other faces for some reason? If it's a single mesh, then no matter how it's scaled in the atlas, front/up face texel ratio will remain the same.

 

Hey @guycalledfrank ,
Thanks for your answer:

I'm talking about Unity Packages handled by the Unity Package Manager, we built a scene that is hosted on our private package repository (a scene we use across multiple projects).
So the scene assets/baked lightmaps are not in the root Assets/ folder but in Packages/com.company.packagename


I tried the debug tool and the !ftTraceLightmap is there, I removed it and tried to select it again and it didn't select anything else. So it is not duplicated

I didn't spot any missing scripts, or anything.

I don't know if it will be useful but I will open the scene where we used that package in 2019.4 without problems and compare the !ftTraceLightmap object with the one we have in the 2020.1 scene.

Thanks for your help

 

Hi @guycalledfrank !

I'm testing Bakery Volume in URP 10.2. I'm using Shadow mask and everything related to bakery lightmaps works fine, but I can't seem to make Bakery Volume take into account shaded areas (adaptive resolution with 2 texels x unit). It just seems to grab baked lights and the mixed dir light, but is not reading from any shadowmask lightmap o volume. Is Bakery Volume + URP Shadowmask supported.. or is there any workaround?

 

sometimes my baked light maps are too bright any workaround to solve this problem.This usually happen on last "LOD" level that i have created for my models for lod 1 and lod 2 the light is baked perfectly but on lod 3 this thing happens

 

Do all LODs use the same UV2 for lightmapping?

 

It seems hole filling was the issue in both cases and yes I'm using light map groups. I have not had the issues since turning hole filling off.

These are my settings (besides hole filling being on causing the issue.)

 

yep same uv2 for lightmapping

 

Hey,

I have some questions to volumes. First, is there a description on how to implement volumes in custom hdrp shaders or even modify the core lighting shaders to always use volume gi?
Second, is there a way to remove terrace-effect from volumes by e.g. blur them out in pixel shader or clip texel directly beneath terrain?
Mabe one could implement a function to not illuminate backfaces by checking normal direction of surface to voxel center.
Mabe move every 2nd zell half cell size, so its not obvious square.



Is there a way to blend between two Volumes?
Optix Denoiser makes everything black and broken.
And last, is there a way to apply them to fog, particles etc.?

Best,
Andre

 

Another question... is there any way to bake the Bakery Volume but don't bake any lightmap? I noticed that it's feasible to light the full scenario only using a Bakery Volume and it looks nice for a stylized artstyle withouth having to worry about lightmap textures / sizes / quality.

Also, is there any way to place multiple Bakery Volumes without having to apply the volumes manually to each renderer? Like, can objects automatically detect the volume they are inside, or can we merge multiple volumes?

 

As far as I know, Bakery Volumes use 3D textures, so you should really worry about size in memory.
Somebody correct me if I'm wrong.

 

Well, yeah.
But let's say that I can use multiple volumes to only envelope gameplay areas and evade "empty space".
Let's say that I could compress the 3D textures to use them on low end devices.

Going full bakery volume means:

• No lightmaps (so more free gpu memory).
• I don't have to deal with authoring lightmap UVs
• I don't have to deal with the mess that is separating stuff between lightmapped vs lit by light probes.
• No need for LPPV (that doesn't exist on URP anyway).

Of course I'd lose directionality and detail, but for open levels or stylized visuals you don't really care.

 

I managed it by creating one volume each terrain and load seperate scenes with volume additive. Then i only load and bake one volume scene a time, as it else would kill my gpu ram. I set volumes to global and everything inside it with a volume modified shader recieves gi. I guess hard drive space is required. I saw that there is ongoing work on texture compression that will reduce size and makes sampling faster. I will use a texture streaming solution to stream in 512*512 volume tiles. I would also like to blend between volumes to create a time of day effect. This is what they did in horizon zero dawn and it obviousely worked and looked well. For mobile it will be a ram problem i guess.



I modified the volume shader to take more sampling points, but still some lines are visble.But why only horizontal and not also vertical lines? Mabe in 3d textures, there is interpolation when sampling the horizontal texture, but no interpolation between different texture layers?



This is how it looks, when I set texture filtering to point. So is a 3dtexture just an 2dtexturearray without filtering in y axis? Texturefiltering also in y axis would solve this. Mabe it has to do with Texture3D format?

 

Hi I have one development machine running IOS platform, and another running Android platform, I baked the lighting on ios platform machine, and copy all data over to the android machine, and the lighting looks wrong on android machine, the UV location changed, any idea why this would happen?

 

Because the UV are calculated on import of the 3d models.
Right-click on the 3D models folder and force a reimport on the new machine and it will get fixed.

 

Ah, hmm... I never tried that. I have no information on how packages behave.

That'll help!

In Subtractive mode, full lighting is baked into the volumes (at least in the latest patch). I can't apply shadowing to direct lights via a shader graph (or maybe I can try by... darkening the albedo? But it would be very hacky). You can use Layers to exclude dynamic objects from being lit by the light, making them only use the volume. Problem is, they will also stop casting dynamic shadows... but you can have a copy of the object with Cast Shadows = Shadows Only. Ugh. Unity (URP/HDRP specifically) doesn't make it easy to integrate stuff into it. But this solution should work.

Maybe it's just too tiny in the atlas? Try:
- Increasing Scale In Lightmap on this LOD.
- Using this advice: https://geom.io/bakery/wiki/index.p...oduces_bright_edges_around_geometry.2Fshadows

There are shader graphs included in the package (Bakery_ShaderGraphHDRP), you can check how the volume graphs are made. I post updates to graph packages to Discord (see #announcements) from time to time between store releases.
The graphs are not very complicated as there is a "Override baked GI" input in them where you can write custom GI color without any hacks.
My volume sampling node basically just calls BakeryVolume_float() (or BakeryVolumeSpec_float()) from BakeryDecodeLightmap.hlsl.

Modifying core lighting shaders is possible but risky. Originally Bakery shaders for HDRP were made like this, there was a whole clone of the Lit shader with additional customizations. However, HDRP changes too often. Variables, defines and everything else change names, order and structure. Modifying core stuff can easily break in a newer version

Oh, you want to shade static objects with it. It might be not the best idea, but you can get away from this effect, not by blurring, but by moving the sample position away a bit (~1 voxel diagonal) by normal. I.e. use my volume graphs, just add (pos += normal * voxelSize) before feeding the pos to the volume sampling node.

During the bake, voxel centers are moved outside, so they are never under the surface (behind any backface). However, with smooth slopes and using the volume to illuminate static objects, it will still give some "terracing" between these centers. The problem is very similar to shadowmap acne and the solution is similar to shadowmap biasing.

Not recommended. Would require too many texture reads. That's exactly what I wanted to show in the example_volumes_advanced scene: you can avoid blending by overlapping the volumes instead. Then a single switch is enough.

Ah, well. Yes, in this case I don't have better ideas, blending is needed. Well, you can modify BakeryDecodeLightmap.hlsl like this:
- Declare Texture3D _Volume0B, _Volume1B, _Volume2B;
- Create a copy of BakeryVolume_float function. Same code, but replace _Volume0 with _Volume0B, etc.
Then:
- Supply these additional textures from scripts to the shaders (you can see how original volume textures are assigned from BakeryVolume.cs and example trigger scripts).
- Modify the volume graph: just copy my custom function node and use a different function name on it (your copy).
- Mix the results of these two custom function nodes.

Everything?
For low res volumes OpenImageDenoise is more reliable though.

Applying them to fog is a whole separate system (volumetric lighting) I am going to implement. Not trivial, but not impossible.
Particles: yes, if you can use a shader graph on particles, just do the same thing as in my volume graphs.

If you really just want to have a volume-only scene, you can. It will complain that there is no static geometry though; but just create some tiny quad somewhere, it should work.
If you want static objects to affect the volume but NOT get any lightmaps, mark them static, but also set Scale In Lightmap to 0: https://geom.io/bakery/wiki/index.p....2FGI_without_having_a_lightmap_on_its_own.3F
If you want to rebake the volume in a complex scene, without re-rendering the lightmaps: not possible at the moment, but I'll add it soon.

Objects can't if you don't script them That's why there are triggers and trigger/receiver script in the example.
Alternatively volumes could be applied like deferred lights, as a postprocess. But this requires writing a very specific code for a very specific rendering pipeline; and I don't think it is possible at all on e.g. URP. It would also add some noticeable overdraw, if there are many large volumes, so performance-wise I'm also sceptical about it.

Why merge though? Do you mean at runtime?

Correct. But:



Prepare for some compression
It's already on github. Current version is hardcoded for PC formats (BC6H/BC7). I'll add some mobile compression soon.
Sad thing is that it only works on Unity 2020.1+. Older versions simply disallow creating compressed 3D textures (which is weird, because even in native DX9 you could create them without a problem).

Is there a solution for this already? Can Unity stream volume textures?

3D textures have the same filtering for all 3 axis.

Tried this? https://geom.io/bakery/wiki/index.p...2Fother_version_control_system_with_Bakery.3F

 

reimport worked

 

. @guycalledfrank After studying the example scenes a bit more I think I understand the different limitations.

So that you understand my use case... We've got pretty big open environments with thousands of models. 1 mixed directional light, a few realtime lights, and dozens of baked lights.

I'm baking a shadowmask lightmap (around quality 5) to get shadows outside of the realtime shadows range. Big / important props are static gi, while most others are lit by light probes. There's no LPPV in URP, so trees and other large props are quite ugly, as they are tinted by the closest probes. Working with modular props also means that there's no gradient of light when placing 2 props next to each other, as they usually grab different light probe trios.



So my approach was to use a Lightmap for architecture / floors + Bakery Volume for small props. That way I can get rid of light probes. Since levels have lots of verticality and twists, using a single bakery volume means that the AABB box needs to encompass everything, usually having 2/3 of empty space. That's why I was enquiring about using multiple volumes.

The Volume Receiver approach is not practical, as Unity won't play nice if I try to add a script to thousands of meshes. Start times would spike up.

 

Can anyone help me out?
My bakery updated, and now when I bake my lightmaps are completely black.
Does anyone why this is?

 

Found out one of my many copied objects with a black material causes my scene to become all black, now i just have to find the culprit.

 

Hi. A couple of questions from a Bakery Noob :

Process and data
Is there some docs that outline the baking process, and what data is created and where. I'm not taking about the map texs themselves - more like the meta data. EG I gather there's an invisible gameObject created in the scene (?) and what does ftGlobalStorage.asset store/do?

Running procs on GPU
My current settings spawn many many small jobs in serial to run on the GPU. To me this appears suboptimal. The process of launching these procs and collating the data seems to spend more time on sys & i/o than it does on the actual GPU processing. I might rather expect to see a few large pushes of data across to GPU. Perhaps I've set things up naively?

Bonus Q
What's the 'ft' prefix refering to ?

Thanks!

 

Has anyone got Bakery to work with HDRP? I've been trying, but I just can't figure out what is going wrong. I am able to bake, and the scene tab Baked Lightmap setting shows the correctly lightmap, but in the normal view:
- If I have a realtime light: the lightmap is basically completely invisible, seemingly hidden by the light
- If I don't have a realtime light: the whole scene shows as sort of reflective grey, maybe as if there was zero lighting (not even from lightmap) and it is just showing the sky light on the objects?

For instance, these are the bakery example scenes, baked, and viewed in shaded (i.e. normal) view mode. They are both full lighting baked, so there are no realtime lights in the scene




Here is an example of having a directional light on. It completely hides the lightmap.


And here I have a mixed light, and baking with full lighting (much like the sponza or train demo scenes above, and gives the same result. This scene was created by clicking File > New Scene > Outdoor template. It is basically the default scene and global volume. I also haven't changed anything in the project itself, just a new test project.
I've tried on 2020.2.0f1, 2020.2.2f1, and 2019.4.20 just in case.
Although my mixed directional light is set to 130,000 intensity, I have the bakery light turned down to a reasonable value as mentioned in the docs



For what it's worth, here is the exact scene above, baked with the Unity progressive lightmapper set to Shadowmask, nothing else changed. This is the scene tab, shaded view.


I'm clearly doing something really dumb, but I can't figure out what

 

Rotating volumes seems super important to me. I recall the amount of people falling foul to Unity's axis locked probe volumes until HDRP fixed that. Even 45 degree turns for better fitting a level would be useful if it doesn't kill perf on mobile or Quest 2...

I'm on URP though.

 

Using Unity's SRP, that's the issue.

 

I'm using built-in pipeline. Thanks for your help but I'm afraid those shader things are way above my head for now
I decided to go back to baked lighting with prefabs.

 

Do Backery support baking lightmap textures into 2DArray? If not Do it plan to support and when?