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

I have the same issue, but I only get "Apply patch?" once after each restart. It does not seem to recognize it is patched.

 

@guycalledfrank I am not sure why I keep running into issues, but I am hitting my 3rd one here and felt it too needed to be put on your radar. I am able to work around all 3 issues, so no show stoppers here, more just time consuming to fix when they happen. This next issue is an odd one that I suspect has something to do with the read/write I enabled on an object so that the Bakery could do the UV adjustments. I hope this documentation of the issue give you the insights to solve going forward.

Issue Details:
I ran a bake and got 12 errors all stating the following:

"Component (MeshRenderer) added to multiple GameObjects! Removing it!"

I have attached the full error. When I click that error it highlights a "Missing Prefab (Dummy)" in a scene which also has a new empty greyed out object at the top of the scene along with 2 new objects that were not there prior to the bake as in the photo below:


I had a backup jsut prior to the bake and the above should have looked like this:


As you can see, there are 2 new objects "Immersive Boi Open Mouth (Missing Prefab)" both with a "Missing Prefab (Dummy)" that were not there before and the "Immersive Boi Open Mouth" which is still there is in the wrong place and scaled way up. I fixed by deleting greyed out object and the 2 new missing prefab parents and then just copied over the transforms from my backup and all was well again. Interestingly, the light bake on "Immersive Boi Open Mouth" looked like it worked for most, but not all when I put it back in the right place. In one case even the medalion object was moved somewhere else and needed to be brought back. This has happened on other objects prior on occasion but I never clued in that it was due to the Bakery baking until this time as there were so many. Seems random especially since these same objects baked just fine over 100 times prior and I have not touched the scene they are in for a very long time.

There was also a "Transform component could not be found on game object. Adding one!" error that when clicked on took me to that greyed out game object. Error is also attached.

I also had a number of "SerializedObject target has been destroyed." Error is also attached.

Any ideas what happened and how it can be avoided going forward?

Thanks for your help
IM

 

hey guys! just came across a bug and I'm not sure if it's been mentioned at all. So when rendering my lightmaps for prefabs I ran into an issue/ found a fix for it. Using URP and baked prefabs I noticed that if I build a scene and render it- then convert to prefab I get the expected results ( exposure wise, and light values from bakery lights are correct)- converting my lightmapped objects into prefabs and then rendering them works well.

However, if I have not rendered a scene and have a prefab already setup to light bake, click render + overwrite the prefab- it blows out the lightmap very badly ( ie the exposure on the lightmap is 20X regular values) . I discovered the issue: A newly generated lightmap from a scene is saved as a lightmap texture ( hdr) , but a newly baked lightmap from a prefab is saved as a default texture in URP 12.

Just wanted to bring this up in case anyone else needs to know how to fix it + so that Mr.F knows it's happening

 

Getting a weird bug, when I bake (2020.3.21 URP) I get weird green hints coming in. Pasted a screengrab of the lighting-only view

 

Actually figured it out, I was using an unlit shader with URP that used a RGB Splat map and it was picking up the splat map as the color as opposed to the final combined color. Once I switched to a Lit shader, it worked fine

 

I tried to do a fake ambient lighting by creating a 6 direction, directional light but for some reason only the light from the forward direction seems to work. On realtime it works fine...

see the image, the zone in the red circle should be lit evenly across all faces but its not.

 

Is there a way for me to copy the lightmap index and scale from one mesh to another? I have a script that does this in the regular Unity lightmapping, but because Bakery stores lightmaps in it's own way and assigns them on Awake, it breaks this functionality. I use this trick to basically lightmap all my LODs for free

 

What setting should I use to remove those random color spots? I'm using 2020.3, Android URP

 

Though I'm still quite the noob to Unity, Bakery, and game dev in general, it looks like lightmap compression artifacts to me. I think there's plenty of help in this thread regarding compression artifacts. Though it's from an older post, here's a quote from some dude people call Frank that may help:

 

Hi. Are there any known issues with BetterLit shader and bakery? 2019.4, built in rp, shadowmask, dominant direction and cannot bake anything normal (no bounces , artifacts, etc.). Thank you.

Edit : tried all possible settings (I think) on shader and bakery and have no bounce of light at all. With Standard shader all good.

 

Really bizarre, when I mark my prefabs with LODs to use the PackAsSignleSquare script, the prefabs no longer cast any shadows on other objects. Any ideas how to resolve this?

 

I really wanted to give this asset a try but dang it caused a project-wide Texture reimport which I couldn't afford Not your fault of course but what an annoyance.

 

PS. Is the OnPreprocessTexture function an essential part of the plugin or is it related to a specific optional feature? In the latter case, I'd like comment it out to avoid the project-wide reimport.

 

Weird stuff! Looks like the red channel is completely omitted. Can you check if happens when denoising is OFF? At first I thought it might be caused by some driver update, but as you're using OpenImageDenoise, it's unlikely.
Another guess is (half)float overflow. Do you have any lights with very high intensity AND indirect intensity values combined?

Hmmm... NaNs/Infs in the emission maybe? But then it wouldn't happen only in SH mode, it would be in any mode. So not sure if it's the same issue.

In case it's some NaN propagation issue...
- How is the light positioned? Is it very close to polygons? Is it close to other lights? Is it close to already bright emissive surfaces?
- If you try it with only 1 bounce, is the "greening" only present around this light for some distance, and not everywhere?

Super sorry about the late reply, BTW. I check the forum once a week, otherwise I get too stressed out and can't finish anything. But for more urgent things don't hesitate to email me directly.

I'm guessing it's when building for platforms not supporting something used by the shader, yeah, I recall that.
Couldn't repro it by building to regular Android target though. Can you please check if the attached file works? It just excludes the GLES renderer, so it shouldn't go to builds.

Yes, the shader is needed during this stage.

So the check for "Apply patch?" is simple, it only happens after you already downloaded it:

        // Was the patch downloaded?

        var cachePath = Directory.GetCurrentDirectory() + "/BakeryPatchCache";

        if (!Directory.Exists(cachePath)) return;

After the patch is applied, the BakeryPatchCache folder is deleted, and the message is no longer shown. Cancelling the window does not delete the folder though, so it'll be shown again after restart, until the patch is applied or the folder is deleted.

When checking for patches, Patcher can compare current version with github version and skip downloading. It creates files named like "bakery-***-cver.txt" and "bakery-***-dver.txt" in the project root folder. "cver" stores current version (last applied update), "dver" stores the last downloaded (but not applied) version. Patcher compares current version to the github one and downloads each repository only if it's different. When applying the patch, downloaded version replaces the current version.

Also "restart to apply patch" is shown even if nothing was downloaded
Fixed that. You can patch the patcher via the patcher and after that it'll show this instead:



"Yes" will act the same as before, "No" will just skip everything. I left "yes" there just for cases like recovering somehow broken installations.

https://geom.io/bakery/wiki/index.php?title=Manual#Notes_on_HDRP.2FURP



OIDN can work as well, just a bit slower.

 

I'm getting these weird grid /lines. Does anyone know whats wrong? The light source is a bunch of light meshes.
Thanks in advance.

 

Hmmm, never seen this before. The only objects Bakery temporarily adds MeshRenderer during export are:
- Generated terrain chunk meshes (not what's on the screenshot)
- Area Lights using Light Meshes. OK, maybe you have objects with both a Light and a Mesh Renderer and a Light Mesh component at the same time? But no Mesh Filter?

WAT

I have no idea what's going on there. Maybe some internal Unity bug with nested prefabs or importing or something. I don't even know how one can create a gameobject without the transform and I've never seen this error before. I'm guessing it also happens on some pretty recent Unity version?
If you can send me any test project/package, I'll check it.

Interesting finding. But I couldn't reproduce it with URP 11, and all Unity versions supporting URP 12 currently simply crash on my machine. This is hopefully going to be resolved soon.
I'm also not sure it has anything to do with the URP itself?
What I tried:
- Created a new project (using 2021.1.7 / URP 11).
- Created a new scene.
- Put some model in the scene (I used cityblock.fbx from the examples), marked as static.
- Put BakeryLightmappedPrefab on it.
- Created a new (original) prefab out of the model.
- Added BakeryDirectLight to the directional light.
- Baked.
Seemed to work:



Maybe there is some bug or behaviour change in those Unity versions I can't test, not sure.

Ah, sounds like the shader didn't have a Meta pass defined, and the splat map was likely in _MainTex, thus it was the best guess of being albedo.

Looks kinda messed up, are you sure that this object has proper lightmapping UVs?

Yes, it's possible, actually I have a script for this purpose. Just uploaded it: https://geom.io/bakery/wiki/index.php?title=Community_extensions#Copy_Lightmap

See this: https://geom.io/bakery/wiki/index.p...id_project.2C_and_lightmaps_don.27t_look_good

Yes.
I'm not sure what to do about it now. Jason is the creator of the asset (and the one to sell it) and he knows how his systems work. But he doesn't understand how Bakery special shader features work. I understand how they work, but I have very bad understanding of his systems. This way neither of us can make it work properly. My part of the code just supplies indirect diffuse/specular GI, but I don't understand how he integrates this data into pipelines.

I'm not sure this configuration can work. PackAsSingleSquare and LODs both dictate different packing rules and don't combine (or at least I never tested it). Do you actually have all your LOD levels in a single atlas, pre-unwrapped outside of Unity? Actually sounds like a good optimization. If that's the case, I can make it work.

As for shadow casting, it works like this: first, all scene object LODs are divided into fine-grained "global LODs", like this:



When baking non-LOD geometry and LOD0, it receives shadows from other non-LODs and LOD0s. LOD1 receives shadows from non-LODs and LOD1s, etc:

Yes, just started getting these complaints recently. Not sure if it happened before? Maybe something did actually change since 2020 in the way Unity decides to force reimports?

It sets parameters on imported textures. Previously I actually didn't have it in OnPreprocessTexture, I loaded the assets, modified TextureImporter values and called SaveAndReimport. But it resulted in 2x texture import times (especially sad when each time it's compressed to something like ASTC). Asset postprocessor was a way to apply desired properties on the first (and last) asset import.

So I decided to check which Unity versions actually reimport the entire project worth of textures when you simply create a script with OnPreprocessTexture:

5.6: nope.
2017.4: nope.
2018.3.3: nope.
2019.3.4: nope.
2020.1.2: nope.
2020.1.14: nope.
2020.2.2: yes.
2020.2.7: yes.
2020.3.2: yes.
2021.1.7: yes.

So it looks like a Unity bug/regression that was added somewhere between > 2020.1.14 and <= 2020.2.2.
Copied it to the bug thread.

Sorry, not sure what to look at. The dark lines on the floor? The aliased white line on the ceiling? Can you isolate it to a simpler scene? Are you sure that your objects have lightmapping UVs?

 

about BetterLit. Yes, been in contact with him as well same time. So kind of stale mate situation. What I do is I bake with standard shaders and switch to BetterLit after bake

 

I tried to make it a bit more clear (the shadows generated). Same scene but without textures and with irrelevant parts cut out. I also raised/lowered 2 meshes.

What do I need to do for lightmapping UVs? Are the settings I attached enough?

Thank you!

 

Hey, I'd like to switch Bakery completely off during runtime, as I'd like to offer different quality level, where one would use Bakery lightmaps + Volume, and another only SSGI (using HDRP).
Is this possible, if yes, how?

 

So, what I do when I prep my models is that I ensure that each LOD has matching lightmap UV positions so I can force each LOD to read from the same location on the lightmap as LOD0, thus I save a bunch of lightmap space and my LOD transitions are impossible to notice because the lighting is exactly the same across all LODs
I made a tool to do the lightmap position transferring for me a while back, but since Bakery overwrites everything from it's own storage, I eventually just changed my tool to check if it is contained in the bakedRenderers, and if not, add the LOD duplicates and their target values so that they get assigned at runtime along with the other Bakery settings, and it works like a charm!

 

I am wondering though, since I am using your Lighting Volumes on the Oculus Quest, and the volumes output 3 3D textures, am I able to leave out some of those textures to lighten the shader load for the Quest? It currently does run, though I am always looking for corners to cut for optimizing hahaha

 

The UV is automatically created by realtime CSG so I guess its good plus every point lights works just fine. Also I can make the ambient lights works fine by rendering over and over, sometimes it randomly works like one out of ten times but breaks if I render again...

I'll keep you informed if I have more details

 

Has anyone had this kind of a issue before?

Some of my meshes appear completely black. Here is a example of two meshes that are exactly the same in every aspect but one of them is black and the other one is rendered fine. Any idea why this would happen?

 

Hi @guycalledfrank , I'm unsure of how to achieve a combination of the following:
- HDRP
- LPPV/Bakery Volumes "everywhere" or moving with larger objects since many objects can be moved almost anywhere in our game
- Sight sensors for a stealth game (being lit runtime by direct point sources detection is easy with raycasts, but indirect lighting and mesh light sources and emissions are a different story... maybe with something like 'LightProbes.GetInterpolatedProbe' for baked could work, but runtime area (or mesh) light sources like this I have no idea how to properly detect). Also if we use Bakery Volumes, I can only detect amount of light at specific position by doing async GPU readback, right?
- Lights that can be turned on/off. This is achievable with some kind of lightmap switching, yes. However players can turn off every single light in our game.
When there are two lights partially lighting same space in the same room, is it possible to bake them separately so that each has its own lightmap group and doesn't influence lightmaps of the other light? Will these blend properly when both lights are turned on at the same time?

Somewhat related - some time ago you mentioned the following on Discord:
"there is one problem though, as Light Meshes currently don't support mixed lighting, that is, you can't mix real-time HDRP area light specular/dynamic shadows with baked area light shadows/GI; they must be fully baked. this will be improved."
Is that feature implemented?

Thanks for lighting our Christmas trees <3

 

Hey @guycalledfrank I have a kinda strange request. I am generating dynamic meshes at runtime that are a subset of a statically baked mesh. Basically, I'll bake using a static proxy:



And then at runtime. build a subset of that mesh, generate a renderer, etc. I manually assign the baked ones lightmapIndex and lightmapScaleOffset when it's generated. As long as it has the right UVs, it all works out (this is Bakery + indirect + dominant dir):



Now that works great for the builtin lightmapper, and for Bakery with just default settings. However, for SH lightmaps, it breaks as soon as I change the renderer.

My guess is I need to change something in ftLightmapsStorage somewhere. I do see the

List<Renderer> bakedRenderers

in the ftLightmapsStorage class and could maybe figure out a way to replace that when the scene loads, but would that actually work?

Thanks so much for any help you - or anyone else - could provide.

(EDIT: I know I need special shaders for SH; I have added those. It works fine with the original mesh, just not the retargeted one)

 

Hello! I'm using lordenfel: castles vegetation assets in my scene and have a bad shadow result. In the shadow side the ivy and grass shadow is too dark, in the light said the ivy and grass shadow looks normal. I alardy set backface GI to 1, it doesn't work, How i fix?

 

Hi there, I am consistently having issues with Bakery & source control (GitHub). I have followed the Wiki instructions for what to ignore/commit (.gitignore: https://gist.github.com/Vixxd/5a00247204b3ea56f551aea363b0665d).

To clarify, I am ignoring:

• Bakery folders (meaning Assets/Bakery and Assets/Editor/x64/Bakery or wherever they were moved).
• As per: https://geom.io/bakery/wiki/index.p...2Fother_version_control_system_with_Bakery.3F

And as Bakery installations do not persist, I am force-including the following in order to avoid issues in scenes across devices/branches,:

• Bakery/ftLightmaps.cs
• Bakery/ftLightmapsStorage.cs
• Bakery/ftLocalStorage.cs
• Bakery/ftGlobalStorage.cs
• Bakery/BakeryProjectSettings.cs (on v1.9+)
• Editor/x64/Bakery/scripts/ftModelPostProcessor.cs
• Editor/x64/Bakery/scripts/ftSavedPadding2.cs (on v1.7+)
• As per: https://geom.io/bakery/wiki/index.p..._who_doesn.E2.80.99t_have_Bakery_installed.3F

Here are two common scenarios which cause widespread issues:

Issue 1, installation:

• Bakery installed on Computer 1 in Branch A
• Branch A pushed from Computer 1
• Branch A pulled on Computer 2
• No indication Bakery has been installed
• Bakery must be manually re-imported through unity package manager to be used (lights in scenes throw errors otherwise and cannot proceed with any work)

Issue 2, updating:

• Bakery updated on Computer 1 manually via menu (with GitHub/invoice details) in Branch A
• Branch A pushed from Computer 1
• Branch A pulled on Computer 2
• Even if Bakery has been installed previously, it is now out of date and so many cascading errors occur (e.g. other packages like 'cinemachine' do not appear until fixed) that it must be:
  • re-imported through UPM
  • then manually updated via menu on Computer 2.

Expected behaviour: Bakery is in packages-manifest and recognised as a dependency. Files & folders related to the asset are pulled in by unity

I cannot find any indication of Bakery install versions in package-manifest/packages-lock even if installed initially through Unity Package Manager. This is causing us huge worfklow headaches and I hope it's just a case of overlooking something simple - any help would be appreciated.

EDIT: I have tried to search the thread high and low and this is the only other similar post I can find:

 

Settings look OK. Still not sure what's going on there. Maybe you have some real-time lights using texture cookies that set to Repeat? If you can send any small unitypackage/project to test, I'll check it.

Hmmm.... as this answer says, it's tricky to completely omit lightmap loading, but it's possible to disable the lightmaps after the scene is loaded.
Here is a decent solution, just make sure to run it after Start() (probably in the first Update()), because Bakery applies the lightmaps in both Awake()/Start().

Or you can just directly modify ftLightmapsStorage.cs Awake and Start functions. Add your quality settings check there and return from functions if the lightmaps are not needed.

Clever!
It always inspires me to read about such tricks.

Not much to remove. although if your lighting is more or less grayscale, you can leave just two textures, one being the colored L0 coefficient (tex0.rgb), another being the grayscale directionality (dot(tex1.rgb,luminance), dot(tex2.rgb,luminance), dot(float3(tex0.a, tex1.a, tex2.a),luminance).
Code remains the same, just reads 2 volumes instead of 3 and gets the same data.
But it would make it lose some contrast and it won't be possible to do proper multi-colored lighting at each fragment.
Alternatively, there is texture compression, but I couldn't encode the data nicely in ETC/ASTC, so it currently BC-only (aka desktop-only). I should look into it again, I guess, it should be possible to use.

Not sure about the validity of this guess - it may generate good UV0 for regular texturing, but no non-overlapping UV1. What tool do you use for CSG?

Same question - do you have proper lightmapping UVs on this model? Did you use any mesh combiner or procgen asset thay may not generate the UV1?

But you're not moving... walls? Volumes should have lighting baked from something that doesn't move. Or is it like you have movable rooms and everything inside them should be lit by the movable volume?
Generally moving volumes is possible, and it works even in HDRP, if you check my example_volumes_advanced scene (just replace standard pipeline shaders with compatible shader graphs from the package). If you want lighting from multiple movable volumes in random combination overlap/blend on a single object, that would be much trickier (can't just set one volume and its position on an object). In HDRP I'd probably go with some deferred approach, e.g. draw a box, box shader reads the GBuffer, adds volume lighting to pixels.

In this case I would create a CPU-side copy of the first volume texture (bakeryVolume.bakedTexture0). Do some GetPixels() on it, and you actually don't need color info, so take Mathf.Max or r/g/b and create a simple float array. First texture of the volume is the L0 coefficient, it stores average light from all directions, so it's what you need.
Then check point lightness by doing something like:

var volPos = (worldPos - volCenter) / volSize + Vector3.one * 0.5; // move from world space to 0...1 inside the volume

// UV -> voxel ID

int x = Math.Min(Math.Max(int)(volPos.x * volumeWidth), 0), volumeWidth-1);

int y = Math.Min(Math.Max((int)(volPos.y * volumeHeight), 0), volumeHeight-1);

int z = Math.Min(Math.Max((int)(volPos.z * volumeDepth), 0), volumeDepth-1);

// Lookup

float lightness = volumeLightness[z*(volumeWidth*volumeHeight)+y*volumeWidth+x];

You can also add some voxel interpolation by reading 9 samples, but if the voxels are less than a meter, I'd probably leave it like that, you can still do time-based interpolation.

GPU readback is also possible, but it will introduce some latency, or (worse) make the whole engine/driver stall, waiting for the transfer, so fully CPU-side solution is safer IMHO.

In which case you can't bake GI from these lights. The only GI you can have is from Skylight/Directional, everything toggleable should have its Indirect Intensity set to 0, otherwise it would look off.
Baked lights should be all in Shadowmask mode (to get any benefits from lightmapping, skipping most real-time shadows from these lights). This is actually the way HL:Alyx does blinking lights (masked, with no GI).

Ah yes, it was implemented some months ago You can totally use mixed HDRP area lights with Bakery now, the shadowmasks will be baked.

Also, possibly interesting to you (just added today): https://twitter.com/guycalledfrank/status/1472588446187335687
I'm using it to save performance on some smaller lights, as you can omit not only shadows, but attenuation as well (which is actually quite complicated for area lights).

<3

SH objects also receive a MaterialPropertyBlock with additional maps, as I can't provide them via the regular lightmap system. You can see how it's initialized in ftLightmaps.cs:

UVs look good, and it should be better with backface GI, so perhaps the leaf shader is non-standard and doesn't provide alpha or albedo for the lightmappers? As it looks as if they were black/opaque for the lightmapper. Does it work if you use some standard lit shader?
Oh, also, is the leaf geometry double-sided? That is, not double-sided shader, but double-sided triangles? For backface GI such geometry will be still like 2 front faces.

"Don't commit Bakery files" advice assumed that both machines already have it installed. It's only to prevent overwriting it.

Currently yeah, every PC should update individually.

I never published Bakery as a "package" (as in Package Manager). I just submit the files to the asset store. Patcher also just downloads the files and puts them to the asset folder. I'm not sure how this whole thing connects to the Package Manager, and I'm not a big fan of it, as it creates layers of complexity over simply having the files without any magical updating/locking/etc.

 

Hey Mr.F, @guycalledfrank
I need your help with shadow mask for HDRP, I'm trying to reproduce simple volume shadow mask example scene. Looks like using HDRP the volume are not baking or it is not overriding the baked lights properly. I'm using unity 2019lts. Is it works mb with the latest version of HDRP? (I'm using verified with 2019, HDRP version 7.6) or it has some trick how to do it?

 

Awesome; thanks so much! Merry Christmas!\

EDIT: Oh yeah; it's working great! Combined with lightmapping, it really makes interiors look dramatic.

 

Hello. Bakery does not correctly handle holes in the built-in terrain (paint holes tool). Whatever the shape of the hole or the mesh that I use to describe the cave, there is always an artifact in the form of a shadow, the shape of which depends on the shape of the hole on the terrain.

 

Hi @guycalledfrank

I bought Bakery a while ago and just testing it out now. I'm running into this weird bug where things go black once I press play.

Thanks for the help !

1. Render doesn't work for me. Once I press "render light probles" I get a black result when playing. But in the editor the bake works. Please see the .GIF
2. As a result of this I am trying Bakery Volume. However, I am running into another problem. The volume is moving the FBX object. I think the volume is spawning at the FBX's object's pivot point. Is there a way we can move the volume without moving the FBX object? Please see GIF

Is it normal for the lightmap to be deleted during runtime? Pls watch GIF to the end where u see the lightmaps disappear

This is the version I have installed from the asset store. I PM'ed you my transaction ID as well.


I can see the Bakery Light Probes reacting to non-static objects just fine ..

 

Hello! Whenever I make my lightmap, it looks really bad. This is after it was working just fine and I had changed no settings. I thought it might have to do with how I was using only a light mesh in my scene, but when I tested it with a point light, I realized that my texels were not changing at all. The problems were nowhere near as evident with the point light, but the texels still did not modify the result. The bake would always take around 8 seconds, regardless of how many I used. I put 1, 20, and even 1000000, all with the same result.

Bakery's real-time preview seems to work just fine, and I've tried deleting and reinstalling all of my Bakery files to no avail. Thank you for taking your time to read this, I am a massive fan of this asset.

 

Merry Christmas!

Yes, I couldn't make volume shadowmasks work with HDRP. There is no reasonable injection point to affect HDRP lighting from the shader graph. When JBooth worked on BetterShaders, he also couldn't find a way to do it. So unless you're OK with using a custom rewritten branch of HDRP that won't receive official updates, it's not possible - just use real-time shadows (HDRP does not seem to be designed for performance anyway).

Interesting, actually I did write a special hole-handling code.
Tested it now: so it works properly if the Terrain Optimization is OFF. In fact, it was never supported when it's ON, because when it's on, there is a separate heightfield ray-tracer with no alpha support. It's already not performant enough, so I'm not sure it's a good idea to add alpha there. Try disabling Terrain Optimization?
BTW are you on any SRP?



But it should definitely at least warn about it instead of just baking without holes.
... but it seems like there is no way to tell if the terrain has any holes without reading every pixel of the hole map, so I'm not sure how to do it.
Updated the docs at least: https://geom.io/bakery/wiki/index.php?title=Manual#Terrain_optimization

You DMd me - was it also related to the MLP plugin? I don't remember it happening to anyone else before, so if you can send me any test project, I'll check it. But it feels like some odd combo of third-party plugins causing this.

When you resize the volume by the corners, both its position and scale changes. Because its position is at its center. Just don't parent anything to the volume? It doesn't need object hierarchy.

What is "bad"? Do you have any screenshots?

It is possible if you have one super huge object. Unity only supports 1 lightmap per mesh renderer, meaning if a single object hits maximum resolution, it can't go above that.
Also, if you're using a Lightmap Group, its resolution overrides global texels per unit setting.

 

Here's a screenshot of what it outputs and one of what it looks like in the real-time preview for comparison.

 

Hello!
This has happened twice now but thankfully I backup our project frequently.
Curious if this is a bug or just something to do with the FBX. Bakery works fine when it is disabled.
Do you have any idea what we can do to fix it without using backups if it is a problem with the fbx?
We are using unity 2019.4.31f1
Here is what happens when I click Render

Here is an example of the hierarchy

 

Hi Frank

Yea it's some weird combination of 3rd party apps.. because if I start a completely new project and just use cubes, Bakery works just fine with MLP. I gave up for now .. will just stick with Unity's light mapping tool.

The object was the root parent. .. maybe my project is just cursed

 

Seems with generate lightmap UV's turned off in the import settings of the fbx the error does not happen.
But the lighting does not bake properly with this off.

 

Have you tried providing your own lightmap UVs with the FBX? Unwrap in Maya/Blender/Max to a secondary UV channel?

 

Sorry for the late reply, my csg tool name is Realtime CSG

 

EDITED: Solved.

As I knew, I'm such a fool. The reason because the other scenes were working, and not this one, is because, and not this one, at least in HDRP, the materials need Masks to be part of the baking party. Materials were on construction and I wasn't aware of that fact at all, but well, I solved a lot of things in the meantime. Also make some test using Bakery shaders.

I'll take the chance I was writting here to make two questions:

- Does the Detail Maps from the default Hdrp shaders work well with Bakery? They're the only part that I'm getting weird results for now.
-I understand there is some command to select what GPU to use exclusively with Unity but I don't have any idea how to make that... I'm quite a noob understanding some technical parts... Also btw... is there a known good way to force the Unity Editor to only use some specific GPU for all his proccesses? Windows 10 and Nvidia Panel are not very friendly lately to allow run software on specific GPUs, I only achieved to run my Work GPU (the good one) on the Unity Lightmapper, and I see Bakery uses it too, but I think by default Bakery is using both GPUS.

Thanks for any answer,

And as I was saying in the unedited post, Amazing asset, lots of thanks! (btw: also cheap)

 

Hello, I have this strange bug with the LightProbes, anyone here knows why?

 

Does anyone know why this object is being so heavily lighted at LOD1 but not base LOD?

There are 2 spotlights being emitted from the nearby lamps but I was expecting it to look more like the base LOD. I'm not sure why LOD1 looks so crazy with the lighting.

2021.2 URP

 

What's the realm of possibility with using Bakery outside of the editor.. i.e. pass mesh and light data to software, receive lightmaps?

 

I seem to be running into the same issue on Windows. Did you solve this?

 

Having problems with Directional light in Single Pass Instanced mode when using the Bakery > Standard shaders. Is it supported? There is a weird shadow projection issue happening in one eye only. Looks fine in the editor. I'm running Unity 2020.3.25f1.

I can send more details and video if helpful. Great asset otherwise, the lightmapping quality is so good!

Update:
- I also have Better Shaders and if I create a stacked shader that uses the `Stackable_Bakery` shader that works fine in Single Pass Instanced mode. So it's only the Bakery > Standard shaders that are having the weird shadow projection issue.

- Also getting this error in Unity on Windows related to the Bakery shaders, I have to keep manually reimporting the shader to fix it.

"Shader error in 'Bakery/Standard': Fragment program 'bakeryFragForwardBase': Unrecognized sampler 'samplerunity_lightmap' - does not match any texture and is not a recognized inline name (should contain filter and wrap modes).
at line 90 (on d3d11)"

- And with Better shaders I cannot enable the 'Use volumes' option as that creates a similar error.

 

Hey!
Are normals not supported in the SH mode or am I missing something?

 

Happy new year, folks!

I see. So when "self-shadow" is enabled. light mesh computation is split into 2 different techniques for near-field and far-field lighting. It looks like the "near" one doesn't work for some reason in your case. Can you check that:
- "Samples Near" is > 0
- If it's a mesh, "Cast Shadows" is enabled and there is no EditorOnly tag?
- ...light mesh is a part of some prefab or lightmap group? Possibly something weird there.

Hi, what is your Bakery version? Doesn't seem to correspond to my copy of the original v1.9 or the latest patch.
Can you please try the patch? https://geom.io/bakery/wiki/index.php?title=Github_access

It definitely must NOT be off.

So according to https://realtimecsg.com/manual.html

When the model’s “Lightmap Static” flag is set, the lightmap UVs are automatically updated about a second after you’ve stopped modifying the model.

If it works, UVs should be good. Just in case, I'd still check them with my UV1 visualizing shader: https://geom.io/bakery/wiki/index.php?title=Community_extensions#UV_Debug_Shader

Maybe there is something different, but I can't see it clearly from the screenshot. Is it possible to convert this geometry to a regular mesh asset? Can you send this mesh to me? I'll check how it's affected by lighting.

It should work as albedo, when computing GI. What problems do you have with it?

There is, I didn't document it though. Not sure how often it's needed, but:
- Open .ftracelog.txt (by default it's in Assets/Editor/x64/Bakery/, not visible in the editor)
- Look for "Device". You'll see lines of text like this:

Device 0: GeForce GTX 1060 6GB (ON)

Device 1: ... (ON)

- Open ftRenderLightmap.cs and look for:

const uint deviceMask = 0xFFFFFFFF;

This mask tells Bakery which GPUs to use.
0xFFFFFFFF = all available/compatible GPUs.
1 = Device 0.
2 = Device 1.
4 = Device 2.
8 = Device 3.
...
Or for any device number (0-31) you can calculate the number as (1 << deviceNumber).

- Change it to the value of the desired device and save.

As for Unity editor in general, I don't know
But lightmapping tasks are separate.

Thanks

Ah yes, mentioned here: https://geom.io/bakery/wiki/index.php?title=Manual#Bakery_shaders
So L1 light probes are faster to bake and they're more consistent with lightmaps (not relying on Unity renderer), but due to the reduced amount of coefficients, they can produce this negative color effect in high-contrast areas, unless you also use a modified shader lookup ("Non-linear light probe SH" option in Bakery shaders).
Or you can set light probe mode to Legacy, and it should provide better results for regular shaders, but may take a little longer; it also "sees" light meshes and skies the way Unity sees them, not the lightmapper, so there might be some discrepancy in case your real-time area textures and skyboxes differ from the ones you bake.

Weird, did you try the latest patch?

It is possible to implement, but pretty hard, and there is limited use:
- Players must have compatible GPUs, enough VRAM and disk space.
- Asset pipeline is unavailable at runtime, there must be a separate texture importing pipeline.
- StaticEditorFlags, SerializedProperty, etc are unavailable at runtime, filtering scene objects and deciding their scale in lightmap must work differently.
- Static-batched geometry is combined at runtime, you can't work with original objects anymore.
- Literally everything that Bakery supports in editor-time, must be implemented differently for the runtime version, and maintained.

I didn't test it with instancing TBH. Something to investigate. Do you use Bakery shader for some specific feature?
Bakery shader is based on the standard shader circa 5.6, so there must've been some changes in the instancing behaviour.

Weird, probably newer Unity versions undefine the texture sometimes where it previously didn't. But there is actually a very good way to avoid it on newer versions by using inline samples, I just didn't do it for the sake of compatibility.

I updated Bakery.cginc to use an inline sampler instead of samplerunity_lightmap. Attached the file. Can you check it?
Where did you enable the Single Pass Instanced, btw? Looks like it was removed from newer version's player settings, and when it was there, it was in "preview".

Thanks!

Of course, the point of using SH lightmaps is to get normal maps work with baked lighting. Or did you mean something else? Just make sure that your shaders have SH lightmap support: https://geom.io/bakery/wiki/index.php?title=Manual#Feature_support_across_shaders

 

Hi @guycalledfrank ,
I'm using this code for stealing lightmaps from LOD0 to other lods

Code (CSharp):

1.  
2.  var storageGO = GameObject.Find("!ftraceLightmaps");
3.  
4.         if (storageGO == null)
5.         {
6.             storageGO = new GameObject();
7.             storageGO.name = "!ftraceLightmaps";
8.             storageGO.hideFlags = HideFlags.HideInHierarchy;
9.         }
10.         var storage = storageGO.GetComponent<ftLightmapsStorage>();
11.         if (storage == null)
12.         {
13.             storage = storageGO.AddComponent<ftLightmapsStorage>();
14.         }
15.  
16. dstR.lightmapIndex = srcR.lightmapIndex;
17. dstR.lightmapScaleOffset = srcR.lightmapScaleOffset;
18.  
19. storage.bakedRenderers.Add(dstR);
20. storage.bakedIDs.Add(dstR.lightmapIndex);
21. storage.bakedScaleOffset.Add(dstR.lightmapScaleOffset);
22. storage.bakedVertexOffset.Add(-1);
23. storage.bakedVertexColorMesh.Add(null);
24.  
25.  
26. EditorUtility.SetDirty(storage);
27. EditorSceneManager.MarkAllScenesDirty();
28.  

it looks ok in scene, coz of those lines I belive

Code (CSharp):

1. dstR.lightmapIndex = srcR.lightmapIndex;
2. dstR.lightmapScaleOffset = srcR.lightmapScaleOffset;
3.  

But when I'm reloading scene every LOD but LOD0 has lightmap Index 1, so I guess storage switched this param.
What should I do to prevent this?

 

Yup, I've extended my own shaders and tried yours (for HDRP). Now, the SH diffuse/spec works great, but I have an issue with the baking process.

What I mean here is that the normals are ignored during it, which is troubling because I have a lot of low poly meshes that have normals baked into the maps and at this stage it's not feasible to introduce high poly variants.

Thanks either way, the seam fixes are amazing