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

Probably bad UV wrapping. Select the model (FBX or whatever) in Unity and make sure Generate Lightmap UVs is enabled.

 

That is now fixed (@DigitalJacksonWork can confirm).

Ah yes. UV scaling is always uniform, so non-uniform scaling still keeps the square UVs, hence the mismatch. But it's not related to the quoted issue.

Same settings, bakes fine... can you send me a little test project/package? I'll check the difference.

Not as dramatic for sure... are you certain that none of your compressed textures are marked as sRGB for some reason? They should be linear. If you don't know, try doing pow(color, 2.2) on your L1 compressed textures and see if that makes them look right.

You can take a look at BakeryDecodeLightmap.hlsl, which is included in URP/HDRP packages. It has this function for specular:

void DirectionalSpecular_float(float2 lightmapUV, float3 normalWorld, float3 viewDir, float smoothness, out float3 color)

{

#ifdef LIGHTMAP_ON

#ifdef DIRLIGHTMAP_COMBINED

    float3 lmColor = DecodeLightmap(unity_Lightmap.Sample(samplerunity_Lightmap, lightmapUV), half4(LIGHTMAP_HDR_MULTIPLIER, LIGHTMAP_HDR_EXPONENT, 0.0h, 0.0h));

    float3 lmDir = unity_LightmapInd.Sample(samplerunity_Lightmap, lightmapUV) * 2 - 1;

    float3 halfDir = normalize(normalize(lmDir) + viewDir);

    float nh = saturate(dot(normalWorld, halfDir));

    float perceptualRoughness = SmoothnessToPerceptualRoughness(smoothness);

    float roughness = BakeryPerceptualRoughnessToRoughness(perceptualRoughness);

    float spec = GGXTerm(nh, roughness);

    color = lmColor * spec * 0.99999;

    return;

#endif

#endif

    color = 0;

}

You can call it in your surface shader and add the result to e.g. emission.
- lightmapUV is uv1 * unity_LightmapST.xy + unity_LightmapST.zw;
- normalWorld is the world normal, and you can use WorldNormalVector to get it: https://docs.unity3d.com/Manual/SL-SurfaceShaders.html
- viewDir is normalize(worldPos - _WorldSpaceCameraPos). Or maybe normalize(_WorldSpaceCameraPos - worldPos). Choose the one that works

Not sure... I was thinking about YT tutorials before, but I would start with the basics, going to more advanced topics gradually, and I wouldn't just record my screen and voice, there should be thorough explanations and illustrations, like in Freya Holmer videos and... and then I realize that I don't have time for it

It's not "worse", but it's slower and potentially less consistent, as it uses Unity camera rendering to gather lighting. In the Legacy mode, what probes "see" is the same as what Unity camera sees, plus point and directional lights.
Are you baking the probes when no sector is selected, after all of their lightmaps are finished? (if not, try it)
Also if you're using Unity area light components + Bakery Light Mesh, can you try using just quad geometry (mesh renderer + mesh filter) + Bakery Light Mesh instead and see if it works? Light Mesh can be synced to both Unity area lights and just any geometry. See if applying a bright emissive material to the Light Mesh quad will reflect in light probes? If that's the case then it's probably because Unity area lights are not visible to camera (and then I can actually fix it and autocreate temporary quads when you bake probes in Legacy).
Using Light Mesh + geometry was actually the original workflow, then I added Unity area light sync later... Legacy light probes might be stuck in these Legacy times a little bit.

??? I don't know what these dots are. Bakery Lights don't carry any light probes. This is probably something coming from your render pipeline UI.

This is not an option if all your Sectors don't fit into your memory. Legacy probes require less VRAM to render.
(And having a Volume per Sector is the best option anyway. Probes are a never-ending source of my frustration).

It looks as if the lightmaps were tiled all over your scene.
It is likely that you don't have any lightmapping UVs? See Quickstart: https://geom.io/bakery/wiki/index.php?title=Manual#Quickstart

Interesting. Can you send me a tiny test package with a scene set up like that? Maybe I can improve workflow so it's not causing any problems.

 

Just for my own benefit: Volumes aren't usable in a scenario like VRChat where I can't control the shaders being used by other dynamic objects, are they? (as I cannot control what shaders people's avatars are using, and thus there's an almost zero chance it'll be a Bakery Volumes compatible shader - as per "To sample the volume, a special shader is needed, and these are included in Bakery.".

 

I think you can easily reproduce it by yourself. Make for example a big cube as lod0 and big sphere as lod1, then set lod1 to 100%. You should see baked shadows casted on each other. I was using Shadowmask

 

Here, this is my test scene and its settings.

 

@guycalledfrank I randomly discovered these bakery-compatible SH baked specular URP shaders from Not-Lonely, and they give me fantastic results: https://not-lonely.com/blog/tutorials/amplify-shaders-for-bakery-urp/

comparatively, the URP shadergraphs provided with Bakery all give sub par results, even when compared to the packaged shaders for the built-in pipeline. Here's a comparison between Not-Lonely's shader and the URP SH Spec graph that comes with bakery:



the ShaderGraph's are all pixelly and don't look nearly as good. Is there something wrong with them?

 

Is "Bake Light Probes" supposed to be usable? It only works if you switch to Legacy probes, but at that point, Bakery just produces nonsense. The lightprobes produced by Bakery in a Legacy "Bake Lightprobes" run appear to be complete nonsense as though it's not bothered rendering most of the lights (or maybe emissions?) thus rendering the functionality useless.

Doing a normal bake in L1 mode produces accurate probes.

Are there some catches to doing a Legacy Probe bake that are likely to be causing this result?

 

Have you since came up with ways to make this happen?

Regardless, excellent work on the asset and the support alike.

 

Hi, I'm having issue when bake result. The scene in build (Android) look darker than what in the Editor and Editor game view. Like wrong color space or gamma or something. Any idea what might cause this? Is it something to do with my device?

Some infos:
- URP on Unity 2021.3.16f1.
- I'm not sure which Bakery version but it should be the latest (timestamp in doc pdf is 12/11/22 9:44 PM)
- Linear color space, ASTC texture compression, and high quality lightmap encoding
- Camera has post-processing enable with global volume. The in-used effect are: Bloom, Color adjustments and Vignette
- AA is enabled in the URP asset and in the Camera inspector.
- Scene has Bakery SkyLight but the intensity and color of the light does not match skybox material (on purpose).
- Bake setting is attached. (Yeah, I know, 500 texel/unit is kinda crazy haha. I'm trying to make it as realistic as possible)
- Android 10, Mali-G76 GPU. Problem persist both on Vulkan and OpenGLES 3.0.
- It used to happen on another project with different Unity version and rendering pipeline before. However, a build from both project were running on the same device.


Any info appreciated. Thanks!

 

I had to pull Bakery out of my project for now sadly as it is conflicting with the Meta Avatar shaders (being fixed by Meta), but even after removing it, I am still getting BAKERY_INCLUDED under script compilation. I can delete it here on the GUI or in the backend project setting files,but it always comes back. I am at a loss as to where it is coming from and am hoping you can provide some insights on how to permanently remove for now. Thank you

 

Why Bakery Volume (BakeryURPVolumeSpecGraph) so bright compared to static lighting (BakeryURPSHSpecGraph)? Is it normal situation? I am testing it on example scene (Unity 2020.3.38f1).



More real example with BakeryURPVolumeGraph(left) and BakeryURPVolumeSpecGraph(right):

 

Yes, in this case you can't use them

Ah... so the problem is not related to the volume itself. The reason why volumes can't be baked separately without also baking the lightmaps, is because volumes (as well as L1 probes) just gather lighting from the lightmapped scene. I.e. every voxel shoots rays in all directions, which then hit the scene, but instead of evaluating every GI bounce for every ray hit for every voxel, it just reuses the cached data already computed for lightmaps. However, when your geometry is set to "Receive GI = Light Probes" and/or "Scale in Lightmap = 0", Bakery assumes no UV data and... caches lighting in vertices instead, which is fairly okay when it's a separate object in a static environment, not environment itself, or if it has more vertices than... a cube. In your case what Bakery is doing is basically computing very crude per-vertex lighting for cubes and then re-gathering it into volume voxels. When I did my tests, I actually only had one copy of the cubes. Both the lightmaps and the volume were baked once, but then I switched my materials to volume-only. If I do it in your scene, it works well too.
So to sum it up, to generate high-quality volumes, you need to bake with lightmaps of comparable quality; but then you can throw these lightmaps away and use just the volume.

Yeah, Not_Lonely added a bunch of his own features, like some specular anti-aliasing and fresnel softening. It does look better indeed, but it's a bit out of scope of the basic SH-supporting shader
You can check Not_Lonely's graphs for the source of these additional features.

It is supposed to be usable for Legacy light probe mode.
Are these Unity area lights by any chance? Or points/directionals? Example scenes seem to work.

Not yet, but thanks!

Might have something to do with a different texture (de)compression implementation (Unity software decompression VS actual hardware), I'm not sure. Is there any issue if you try building on PC (to separate build issues from hardware-difference issues)? Also what happens if you use the built-in lightmapper, is there any brightness difference too?

Hmm I wonder what parts cause the conflict? Maybe I can do something on my part.

Oh. So yeah, the define is never actually removed (and I don't know how to run any keyword-removing code right before all the code gets deleted from the project, especially if it's deleted simply via Windows explorer).
The script adding the keyword is ftDefine.cs. If the keyword reappears somehow, then this script must be still somewhere in your project.

There is some difference due to low precision currently (and lightmaps knowing their surface normal in advance, unlike probes/voxels). You can try reducing GI intensity in the volume graph a bit to match it.
But yeah, it's annoying and I should take another look, maybe there is a way to make it more matching out of the box.

 

All lights in the scene have a corresponding Bakery component (and the Unity component disabled). It's entirely possible the problem areas are ones where that part of the scene is only lit via area lights (with corresponding bakery mesh light component) or emissions. Is there some issue when using legacy probes with either of those specifically?

 

Does anyone know why Bakery isn't baking LOD 0? I have an issue where it looks great in editor, but when it's built for Android, it doesn't bake the tree lighting on LOD 0.

 

Also,what do these errors mean? The don't seem to make my scene not play, but might be related to my LOD 0 issue.

 

Short version:
I fixed it. The problem is in Scriptable Render Pipeline. I have one Renderer asset that has SSAO and screen space shadow added but they're "not enabled" (checkbox unchecked). Removing both features fixes the problem.

Long version:
After some testing. I think it's something to do with the project. No matter what I did in my current project it all resulted in darker scene in build. Bakery lighting, Unity lighting, Android build, PC build, all of them are darker in build.

I then create a new project and a new scene and everything is fine. Bakery/Unity lighting, PC/Android build. I then export that new scene into my current project, bake using Bakery, then build to Android and yep, it went darker again.

I compared the 2 projects and the Scriptable Render Pipeline asset stood out. I randomly remove 2 rendering features (SSAO, and screen space shadow) in the Renderer asset and the problem went away. I no longer use those 2 features and left unchecked but apparently it still has effect.

I have no idea where those assets came from and why it's setup in Graphics Setting as I never created it. Might have came from any of the asset package that I imported. I did import post processing stack V2 from package manager thou. I already removed it using package manager long earlier. This is the first time I'm using URP, so this Scriptable Render Pipeline thing is new to me.

 

As someone who started using Beast back in the day and even made a video about it, this is WELCOME. And for projects they don't use Time of Day, the quality is astounding.

 

Best plugin for Unity EVER and outstanding support and updates for 5 years now!
Rock on Frank !

Spoiler

 

I think it'd be better if Bakery lightmapped prefabs would clean up LightmapSettings.lightProbes after being destroyed. Trying to have indoor areas with light probes in our game, but outdoor areas with dynamic weather, the issue is that the probes stick around after the prefabs are unloaded, and the way unity implements light probes, they have an effect even if infinitely far from the nearest mesh.

 

Is it possible to make (as idea) volume to use MonoSH instead of full SH to make it cheaper?
Also, it would be very cool to add the ability to use compressed volumes to the URP.

 

I know his shaders have extra features, I think there's something truly wrong with the baked specular in the URP shadergraphs though. They are unusably pixellated, and even if I use the same textures with built-in, and use the standard bakery shader in a non-URP project with SH enabled and bake specular, the quality is entire different. See below, the top image is the URP SH spec shadergraph, bottom is baked in unity 2020 with the built-in pipeline and the standard bakery shader with SH enabled.

 

That looks more like texture compression artifacts than lack of resolution. Try setting the lightmap textures as "uncompressed" to check if it's related to that.

 

I wish that were true but I they're currently uncompressed. I tried tweaking every setting imaginable. Do you get usable results from any of the baked specular methods with the URP shadergraphs?

 

I don't use SRPs, only built-in, but I've seen this kind of behavior with compressed directional lightmaps (that I use for specular). Have you looked at the actually generated lightmap textures? (not the global settings or Bakery's settings, but selecting the actual generated textures and setting them to "uncompressed")
Sometimes Unity doesn't honor the global settings for additional lightmaps (like SH or directional).

 

Yeah, i've checked both. they're uncompressed in the inspector in the bakerylightmaps folder.

 

Yeah unfortunately the idea that a Light Mesh can be used together with an Area Light is newer than Legacy light probes
Originally it was supposed (and it still works) that you put a Light Mesh on, well, a mesh (e.g. a quad or anything), which is then treated as a light source. Unity area light matching was added later and I forgot to make it work with Legacy probes.

OK, I've just fixed that. Legacy light probes should now "see" Light Mesh + Area Light:



Please try updating via the patcher or github.

That's probably not related to LODs, but a common build problem, e.g.:
https://geom.io/bakery/wiki/index.p...iated_at_runtime_in_a_build_have_no_lightmaps

- Shader Stripping killing off some required shaders?
- Optimize Mesh Data removing UV1 from the mesh?
- Async loading? Try calling ftLightmaps.RefreshFull() after the scene is fully loaded.

If it's something else, can you share some screenshots (editor vs play mode)?

Hmmm that seems to be coming somewhere from Unity internals. As Bakery calls Unity baking just to prepare the light probe grid, it starts complaining about some textures being Crunch-compressed. But since Bakery doesn't need any textures from this process, it's unlikely to cause any problems.

Wild guess, but SSAO and screen-space shadows can sometimes exhibit erroneous self-shadowing if the bias is too low; and since both effects depend on screen resolution... is your resolution different in editor vs build? Might have something to do with it. Usually adding some kind of bias fixes it.

But Lightmapped Prefabs can't contain probes... so removing something that it didn't previously add sounds like unexpected behaviour to me.

I tried, but it didn't look great. It's not as critical when used for normal maps, but when whole objects don't have color variation from different directions, it's just too meh...

(To be continued soon)

 

OK, just added!
URP Volume graphs should now work with volume compression. No need to change anything in the materials (they branch by the global BAKERY_COMPRESSED_VOLUME keyword):
https://drive.google.com/file/d/1s7DnYVrNsJ5aY4hcqjSUYaBiuG4nqtcK/view?usp=share_link
Link updated on the Wiki page too: https://geom.io/bakery/wiki/

(You might need to update Bakery through the patcher, as I recently added a small fix to the compressed volume encoding)

---

Bonus script:
Ever wanted to get average lighting directions from volumes to your C# scripts?
Bakery now has a new OnPreVolumesCompress event which you can hook into to get raw volume values before encoding/compression, and I made a little script to visualize lighting directions captured via this event:



The script is attached.
Usage: just put it on literally any GameObject. It will hook to the event and after the bake is done, it'll put an instance of the same component to all BakeryVolume objects. Then read the voxelDirection array.

---

I wonder if the specular function and the smoothness mapping is just different... is it any better if you reduce the smoothness? Also I don't have a texture with such noticeable artifacts, so if you can send these (at least normal + gloss/roughness) to me, I'll test it.

 

Thanks! I DM'd you a link to a zip file. Tweaking smoothness doesn't really change anything. I tried tons of different textures but it always happens, here's another example:



The top image is Unity 2020 LTS using the built in render pipeline and the bakery standard shader with baked specular in SH mode... the bottom is Unity 2021 LTS with the baked SH specular shadergraph and baked in SH mode.

 

Reasonably new to Bakery but love the results that it produces.
Looking for some help in understanding some console errors (see attached screenshot below).
We were doing some project cleanup and subsequently updating the respective cleanup with commits into Git. We also ended up moving baked maps around (inside the Unity Project - not from explorer) when we were doing some project folder re-org. Regardless, we may have inadvertently moved/deleted something we shouldn't have.

I'm curious if anyone might have an idea of where to start looking with error notifications of this sort as it looks like we moved or deleted a key component in error?
Thanks in advance!

 

Just reinstall Bakery from the Unity asset store and then update it using the built-in updater in the Bakery menu.

 

Hi, @guycalledfrank

I rendered a scene in Project A (which includes the bakery plugin), and then exported the scene file, lighting data image, and art resources to scene1.unitypackage (which does not include the bakery plugin). From project B, I imported scene1. unitypackage, but the lighting data of the scene was not displayed correctly.There is no lightmap in the baked lightmaps of the lighting.

Recent test results: From Project A, I have tested that when I export scene1.unitypackage (which include the bakery plugin) and import it from Project B, the lighting map is normal. But I don't want to export the bakery plugin to another project now, what should I do? thank you!

 

@trojant You will need to include a few scripts. See this page for details:

• https://geom.io/bakery/wiki/index.p..._who_doesn.E2.80.99t_have_Bakery_installed.3F

 

hi @guycalledfrank

i am using Bakery with Unity 2019.4.20f1. it has been a great tool so far but i've run into complications.
when i try to bake the lighting in my scene, i get a "memory allocation failed" error even though my texels per unit is set to as low as 5. and a lot of the objects in my scene even have their "scale in lightmap" set to 0.1.

my computer is a relatively powerful one with a graphic card RTX 3070Ti and my scene isn't all too large or complex. i've also noticed that this error occurs when certain objects are in the scene and when i disable these objects, it works. not sure what is special about these objects that is suddenly stopping the scene from baking. Will love help and if you need me to provide extra information, just ask.

PS: I tried setting Force VRAM optimisation to true but that crashes my Unity anytime i try to bake.

 

In the meantime, check this section of the wiki: https://geom.io/bakery/wiki/index.p..._get_an_.E2.80.9COut_of_memory.E2.80.9D_error

 

yeah, i've gone through that entire page before. i don't have any terrains. and i close all other applications. my texels per unit have also been set to very very low. even at 1 texel per unit, it still fails.

 

Hi, I just upgraded from Unity 2021.2 to 2022.2.14. I'm using URP and Shader Graph, and I'm receiving the following error when compiling shaders from BakeryDecodeLighmap.hlsl.

 

Not sure if this was just a random bug, but after the bake completed, Unity was running incredibly slow and my heirarchy now had a load of Bakery lights added to it at the top level with the same name.

 

Thanks! That seems to be solved now (I hope):
https://github.com/guycalledfrank/bakery-csharp/issues/41

New URP graphs are downloadable from the main Wiki page, as usual:
https://geom.io/bakery/wiki/index.php?title=Bakery_-_GPU_Lightmapper

I've put them under "rev 2.0", since the fixed DirSpec graph has somewhat dimmer specular intensity (it now matches Bakery Shader in Standard RP) in case your project already relies on the previous behaviour. Note that this issue didn't affect SH/MonoSH graphs, these were OK.

Either you don't have ftLightmapsStorage.cs (goes to Assets/Bakery by default) or you used Assembly Definitions in some way that prevents two groups of scripts (Editor and runtime) seeing each other.

Hmmm... is it a CPU or GPU one? Can you show how it looks?

(To be continued tomorrow)

 

Hello, once again Frank thanks for creating such an insanely cool asset. Possibly one of the greatest ever.

Is there any way to use Bakery Standard features, in URP? I have successfully imported URP shaders, and I want to utilize MonoSH, so I'm utilizing the BakeryURPMonoSHGraph example included. However, the default shader doesn't include basic stuff like tiling, nor the ability to enable double-sided rendering. Likewise, I'd like to use it for my plants with alpha clipping, etc.

In short, is there a BakeryStandardURP floating around anywhere? Thanks in advance for any info!

 

I understand - however, generating lightmaps purely to then generate volumes and also having to manually switch between them is quite tedious and inefficient - do you think its possible to make some changes or adding options here somewhere to make this volume-based workflow more efficient ? Potentially skipping lightmaps alltogether ? Since a big part of the reason I am so interested in volumes is their meshless nature - no worrying about faulty UVs or other mesh issues and inconsistencies between objects.

 

heyo, attached are two images. the first one is from the memory check which shows my bake should require around 200MB of video memory.

the second one is a screenshot of the error gotten, and the baking process it develops this error. let me know if you need any more information!

 

I tested this version a bit and ran into some wild ShaderGraph UI errors, so for now I'll won't touch it (maybe Unity will fix something on their own).
But a quick fix for this particular error seems to be just replacing "sampler_MainLightShadowmapTexture" with "sampler_LinearClampCompare" in the hlsl file.

Weird... they're autodeleted right after scene export/light probe competition normally. Maybe you were still in the middle of probe rendering? And does it happen... randomly? Not on every bake?

Thanks!
You can easily change the built-in graph, they are pretty simple. I just didn't put all possible features there so they're easy to decipher and combine with your own custom graphs (it's also a pain to maintain one super-graph as SRPs like to update with some breaking changes...)

Tiling example:



Double-sided is just one-dropdown in the SG editor:



For alpha clipping you can just use one Split node to e.g. get base map's alpha channel:

I can technically make a completely separate volume renderer that uses RTPreview-like path-tracing, but I'm not sure if it's really worth it (given the amount of work I need to put into it).

It can't estimate the size of geometry, only textures. So it's possible that you have a huge amount of triangles there. Terrains? Painted terrain trees? Just lots of high-poly objects?

 

hm, i don't have any terrains or trees in the scene.and i don't think i have particularly high poly objects in the scene. and not a lot of those. can you give me a ballpark of the total number of triangles in a scene that you'd expect to use more more than 8gb? this will help be certify if indeed my scene is too complex, or there is some other bug.

 

I mean, I may be biased, but I personally do believe that it would be worth it. A lot of the issues lightmaps face are due to their texture-based nature, and not that of being precomputed. Especially when it comes to lighting environments that include both lots of static AND dynamic objects, this kind of texture-based solution just is not sufficiently scalable. Meshless lighting, whether via probes or volumes, can be very efficient especially for more low frequency lighting. On platforms where a bit more performance is available, it can allow for considerably greater visual quality with A LOT less artist overhead from creating lightmap UVs, tweaking values for correct size and texel density... With meshless lighting, things are more consistent, faster to author and can potentially gain performance. I would very much urge you to consider this as it would be an incredibly powerful tool for many lighting pipelines, and something that would truly put Bakery in a league of its own.

 

I have a problem with specular in monosh, I tried both v2 and old packages. In both cases, the specular appears as if it wasn't there
Unity 2021.3

 

Hey guys! Love your work and Bakery looks like an amazing tool. A bit of a noob question. I got it recently and was trying to use it for my outdoors scene following the getting started guide. In my scene I have one main Directional Light that pretty much is being the sun, plus I was using Environment Lighting from Unity's Lighting tab to soften some shadows and fill it with more light. I'm also trying to keep the Directional Light as "Mixed" in order to cast shadows from my character and some of the trees.

After baking it with Bakery, this is how the scene looks like, compared to what I get with Unity's native baking. Baked shadows seem to be too dark and not blending well. Any ideas what may be the problem? Much appreciate your help!

 

Greetings all!

I've recently purchased Bakery, int he hope that it makes my life easier with lightbaking in unity, but...I have to admit unfortunately it made things worse, for now at least, which baffles me because I've seen very good reviews on this system so I have to think I'm doing something wrong.
I've been testing for two days straight , tried three different unity versions (2018, 2019, 2022), until I finally narrowed it down to emissive surfaces (using light meshes)...

I've attached three screenshots:
In the first one the light source is a ring shaped mesh with a bakery "light mesh" component on it and using the bakery light shader. You can see that the UV seams are very visible and glitchy. I also usually find all sorts of weird dark spotty areas and other artifacts wherever emissive surfaces provide the light. Now I do make use of emissive surfaces, and unity's own lightmapper has no trouble with them, so I wonder what's going on here?


In the second one I'm using an area light , comparable intensity, with a bakery "light mesh" component on it. No seam issues here.


And finally the third image where I'm using a simple point light (again the appropriate bakery point light component added), no artifacts.


Here are the settings I've used for the above bakes, but I've gone through probably most of the possible combination of these settings, especially pertaining to UV adjustment (fix UV seams and asset UV processing),and they didn't make any difference. The mesh has "Generate lightmap UVs" turned on in unity, which before bakery, worked totally fine with unity's built in lightmapper, without causing such seam issues.


On a sidenote I've also had a weird issue where if I have Bakery detect optimal settings and then apply them, it tells me that RT doesn't support terrains. Which is fine, but then why is the "Terrain optimization" and "RTX mode" settings ticked simultaneously by default when I apply the optimal settings? Also in the basic view, you can't even see those options, so you are left wondering what's happening (if you manually try to tick them both they mutually untick one another so again, why do they both get ticked when applying default (previously detected) settings?). I've had this issue in both 2018 and 2022.
I have an RTX 3090 by the way, if that is a useful piece of information.

Thank you!

Cheers,

Adam

 

Hello again!

I just wanted to report that I'm now getting very good results. I have no idea how it got resolved though, all I did was go into bakery's project settings, and flip from TGA to PNG for the texture format. But when I flipped it back to TGA, just to see if I get the bad seams again, they were still fine... I don't know why this fixed the seams, but now they are perfectly fine, same settings as before!

Update:
Apparently somehow if "Dominant direction" is left on when I bake in indirect mode, the seams come back.

Cheers,

Adam

 

Unity 2021.3.13f1 and URP pipeline:

 

It's hard to predict geometry size in VRAM due to the size of the BVH tree (its complexity can't be known in advance). If we consider a super inefficient mesh where every triangle has its own non-shared vertices, then you'd need 79 millions of such triangles to get past 8 GB, perhaps 1/3 less if we also count a pretty fat variant of BVH. With real geometry where you have many triangles sharing edge vertices, this limit is higher (>100 mil).
So I'm really not sure what's going on there unless you have such polycounts.
Can you try baking it, get the error and then send me your ib32.bin and vbtraceTex.bin (they're in Bakery's temp folder)? That's basically final geometry vertex/index buffer, so I can check their size and if there is something weird taking too much space.

It is possible, but with a uniform (non-sparse) volume representation, volumes can quickly get way more memory-hungrier than lightmaps, especially if you want decent (at least HL2-ish) resolution on static stuff (especially if used for direct lighting and high-contrast shadows). In my game I'm using both lightmaps (detailed, high-frequency) and volumes (2x2x2 voxels per square meter) as a tradeoff. Volumes are used on characters/vehicles/other dynamic objects as well as foliage (too complex geometry - too expensive to bake lightmaps or even per-vertex data), they also give me a pretty good lighting estimate when I start adding new static objects into the scene before baking them. But using volumes on static objects would not look great... think of narrow contact indirect shadows, for example:



that would need waaaay too many voxels... otherwise you'll have to combine them with some near-field screen-space semi-GI (and then use heavy TAA to smear it?), and here we're going into a very complex solution for high-end-only platforms...
OR you can come up with some really-really sparse representation that has lightmap-like resolution near static objects, but gets immediately coarser one voxel away from them?

It's the reflection probe, they're handled a bit differently.
The problem with them and my URP SH graphs is that, unlike the built-in shaders and even HDRP, I can't just replace Unity's GI with my own, so instead I hack it by setting AO to 0 (which kills built-in indirect diffuse) and add my own with emission:



Problem is, AO also affects reflection probes, darkening them to zero as well. HDRP graphs avoid it by having a specific GI input, but here I can't do it.

If you use a MonoSHSpec graph, I won't recommend combining it with reflection probes anyway, as it defeats the point: SH specular has per-pixel occlusion, while reflection probes just shine from every crevice.
For highly glossy surfaces I recommend using refprobes only, while for more diffuse objects SH specular can give better results.
Ideally you should be able to combine SH diffuse with refprobe specular (in the non-Spec shader), but I'm not sure that it's worth it.

A somewhat hacky solution that samples a new reflection probe can look like this:



(I'm attaching this graph for you to experiment)

Just replace you environment lighting with a Skylight
https://geom.io/bakery/wiki/index.php?title=Manual#Bakery_Sky_Light

Here is also a useful little guide: https://geom.io/bakery/wiki/index.p...I_quickly_port_my_existing_scene_to_Bakery.3F

Interesting... can you show me your Light Mesh settings? As well as its Mesh Renderer & GameObject settings, just in case.

Also see if:
- Disabling "self-shadow" gives cleaner results.
- If self-shadow is enabled, object also has "cast shadows" enabled as well
- if self-shadow is enabled, the object is not marked with the EditorOnly tag

Weird! I don't think it can affect quality this way, so it was likely something else.

Yes, it's using Bakery shader which is for the built-in RP. You'll need to swap this material to a URP-compatible one. I have a little guide just about that https://geom.io/bakery/wiki/index.php?title=Manual#Viewing_example_scenes_on_URP