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

Hi, Am I doing something wrong? or understanding something wrong?

I'm testing shadow mask rendering, the Ball is dynamic, everything else is static.

when the camera is close it works fine... when the camera is far away, the ball gets lit. is that the correct behaviour?

shouldn't it ignore real time lighting and just get dark because of the baked light?

 

Thank you very much, but replace alphabuffergen file still crash, I have try many times, I used v1.2 version

 

Hi, amazing tool you've made. I'm really interested in it but we can't really use it without the directional lightmaps for our project. I'm just curious if you think it will be in the next version releasing? Cheers

 

I just encountered this asset, and my first thought is, "Where has this been all my life?" I'm working on a large sci-fi scene that takes so long to bake that I'm using only realtime lighting right now. There are some places where I really need area lights but can't use those without baking, so I'm simulating with -- ugh! -- cleverly-overlapped point lights. It..works...but is not the look I want. My build system has a 4.5 GHz quad core i7 and a GTX-1080 GPU, but with Enlighten this thing takes so long to bake that I have never had one finish -- it's on the order of 16 to 24 hours, I'm sure. This scene really needs baked lighting -- it's just too complex for realtime, although I've managed to get "okay" performance by being really aggressive with occlusion culling and some other tweaks.

Anyway, I read through the manual -- really nice job on that, by the way. I didn't see offhand how this asset will behave with prefabs containing Unity lights. Can I just add your component to the prefab, disable the Unity light for the ones I want to bake, and use your quick match-the-Unity-light feature to get the settings right, then bake?

The other question I have is, will this work okay with procedural modeling tools? I'm using Archimatix very heavily in this scene, and also have a voxel terrain using Voxeland.

This looks great, and I'm thinking very seriously of jumping in. I know Unity is working on GPU baking, but you've got a working solution now.

 

Shadowmask areas now looks good like with PLM, but again no more than 4 lights.

 

Yes. This is how it works in Unity. Blame them

Your scene doesn't crash for me anymore with this file replaced. Are you sure:
- the file was actually replaced (try replacing when Unity is closed)
- you are testing the same scene

Seems like next release will be about bug fixes and LODs mostly. So maybe wait a bit more for directional.

Yes you can.

Will be fine if they generate lightmapping UVs. Basically if they work with standard lightmappers, then should be OK.

That's the limitation of shadow masking: https://docs.unity3d.com/Manual/LightMode-Mixed-Shadowmask.html

 It stores occlusion information for up to 4 lights per texel, because Textures are limited to up to 4 channels on current GPUs.

There is a difference however if what happens when too many lights overlap in built-in lightmappers and Bakery. As mentioned in Unity's manual:

 if a light does overlap while all 4 channels have already been assigned, that light will fallback to fully baked.

But Bakery just ignores such lights at the moment and bakes them as indirect only. Perhaps I can emulate Unity's behaviour.

 

This should be easily fixable with placing light probes, right?

 

Hi, i get a new problem.

I want use on my scene hi-poly model like this:



Object have generated lightmaps UV by Unity.

But if i try bake scene with this model on "Exporting scene - adjusting UV padding for..." step i get error and my model has been break: "Error exporting scene - see console for details"



After reload unity, project crashed and not opening, until i not deleting this model from project.

Double click on error go on to this line:


I send this model to you PM...

 

Hi,

So we've just given Bakery a try, and we're certainly impressed with the speed, but we have some concerns regarding quality.

Firstly, we're experiencing a crash with a scene containing a Terrain. The bake process fails with the error "Object __ExportTerrain was destroyed mid-export". When we remove the terrain, the bake completes successfully.

Secondly, we're seeing some severe lightmap aliasing and colour banding. The following was rendered at 40 texels per unit, 2 GI bounces, 32 samples. Our project is set to use Gamma colour space because we're targeting mobile devices. Would you recommend switching to Linear colour for mobile, or is there an alternative approach to produce better results in Gamma space? We have also not enabled any of the global shader tweaks.



Finally, it seems as though Bakery doesn't support back-face culling, since lights placed behind walls / surfaces are sometimes not appearing in the baked lightmap. In the following example, a Spot has been embedded into the top of an alcove to create a characteristic down-light onto the shelves, but although this can be seen in the dynamic scene and in the Enlighten bake, it doesn't appear in the Bakery bake.

 

Thanks! Checking it right now.

If you could send me a unitypackage with this terrain object, it would be extremely helpful. I have a bunch of test scenes with terrains and one user project with a grid of literally 64 terrains, and none of them give any error. From time to time I hear people getting the error you describe, but the only way I can fix it is to reproduce it on my PC first.

I think the problem is not the Gamme mode itself, but the kind of compression Unity applies to lightmaps if your project is set to Android/iOS. Bakery lightmaps are just uncompressed .HDR files, importing/compression and everything else is up to Unity. Maybe try selecting assets and tweaking their compression settings? Was it significantly better with Enlighten? If so, I'll investigate.

That is true, all faces are treated as two-sided, as it's useful for most game scenes (you don't want sun to come into a room through backface).
What are you doing with spot light is basically hacking default spot cone shape to look different (e.g. wider on top). I highly recommend looking into IES light profiles, as they are able to represent very diverse types of light shapes:



Using an appropriate IES light profile will look more realistic AND you wouldn't have to do crazy things like moving lights into geometry.

 

I've uploaded a unitypackage with the terrain object in question to this Google Drive link:
https://drive.google.com/open?id=1Qz5Q5creQ9b5uFzPubjZvq0WEFyz7SkF

Wow, you're quite right. The default texture compression format for Android - ETC - is DREADFUL for compressing lightmaps. Overriding the default texture compression format in the Build Settings to ETC2 or ASTC produces vastly better results, much more comparable to PC.

We'll give IES light profiles a try!

Thanks for the tips!

 

It has Light probes, without them the ball in close, would look weird, the lightprobes give the correct color in close, but at the distance it gets lit.

I was afraid of that, I guess here's were Fog comes to the rescure.

 

One more thing, I've noticed some lights that were marked as 'Baked' are still casting Realtime light after a fresh bake. In the default Enlighten system, Baked lights automatically stop casting realtime light once a bake has successfully finished. Is this a black-box feature of Unity that Bakery can't access? Will I need to hack around this by disabling those lights manually?

EDIT: I think I might be thinking of Unity's 'Subtractive' lighting mode, but for this use case, the question still stands

 

Yes, I know. In this case there's no more than 4 overlapped lights so all of them must be baked as usual. Am I right?

 

I'm afraid so. Check the manual, it was described there.
BTW, I've tested your terrain scene, and couldn't get any error - sent you a PM.

 

Hmmm
- Turns out I sent you the wrong file.
- Also turns out I had sorting order wrong, which was fine on one test scene but not fine on another.



Sending you updated patch.

Another thing that turned out: having more than 4 shadowmasked lights on pre-2017.3 Unity doesn't really work. I̶'̶m̶ ̶n̶o̶t̶ ̶g̶o̶i̶n̶g̶ ̶t̶o̶ ̶f̶i̶x̶ ̶t̶h̶a̶t̶ ̶u̶n̶f̶o̶r̶t̶u̶n̶a̶t̶e̶l̶y̶.̶ ̶2̶0̶1̶7̶.̶3̶ ̶a̶n̶d̶ ̶n̶e̶w̶e̶r̶ ̶h̶a̶v̶e̶ ̶p̶r̶o̶p̶e̶r̶ ̶A̶P̶I̶ ̶t̶o̶ ̶m̶o̶d̶i̶f̶y̶ ̶s̶h̶a̶d̶o̶w̶ ̶m̶a̶s̶k̶s̶ ̶a̶n̶d̶ ̶w̶o̶r̶k̶ ̶f̶i̶n̶e̶.̶ Actually... I will.

 

Good evening!

I took the plunge today and purchased Bakery, and I've been testing it in a sandbox project under Unity 2017.4.10f1 on Windows 10 64-bit, with a GTX 1080 GPU. I started by baking the lightmap in the Roman test scene and found that it works flawlessly. It looks great on my 4K screen. I loaded VoxelFrog's excellent ExplCamera as a nice way to rove around the test scene. I also tested that the lightmaps work correctly in a standalone build, and again no problems.

I have some general comments and suggestions, a couple of specific (but minor) bug reports, and a request for tech support. That being said, so far I think this is going to be a great tool, and I acknowledge that it is in an early release and still somewhat under development. I'm willing to be patient as the asset evolves.

• As you point out in the documentation (which is very good, IMO), linear color mode is really important. The skybox in the test scene looked horrid (blazing white) when I started the project, but as soon as I set color mode to linear, it worked perfectly. In other words, to my fellow customers I remind us all to RTFM.
• As a documentation suggestion, I read the section on Bakery lightmap group components. It was clear that I should attach this component to the parent of some visible mesh objects that I want to include in baking, but it was not clear whether or not it is also needed to attach this to light sources, cameras, etc. Please consider adding a little more detail to that section.
• I found a very minor bug with the Bakery rendering dialog. It works perfectly as a floating window, and it docks correctly into Unity. The problem is that if you dock it into Unity in such a way that it is too large to fit its visible docking slot, there are no vertical or horizontal scrollbars. You may need to tweak the window properties to support this. Replication instructions for the bug:
  1. Open any project containing Bakery.
  2. Make the Hierarchy window relatively small.
  3. Open the Bakery rendering dialog as a floating window.
  4. Dock Bakery's window so it is a tab alongside the Hierarchy but within the same screen section.
• After adding the Bakery Skylight object to my scene, when I already had a camera with a Skybox active, I found that the Skylight object's inspector offered me the option to match the skybox to it, but not to match it to the skybox. At some point, both buttons appeared, but I couldn't get this to happen consistently. I think this may be a bug of some sort, where the presence of that second match button depends on...something.
• When I first baked the test scene, there was a long lag after I hit the Render button before the progress bar started to move even to 1%. I realize there was some setup happening, but it would have been easy to mistakenly conclude the program was stalled. I waited, and eventually the progress bar moved and the bake completed, but this is a small user-responsiveness issue. Along the same lines, Unity's own window refresh of the editor dialogs was stalled during that period. I'm not sure this is something you can fix, but I thought it worth mentioning as a UI consideration. If nothing else, it would be good to mention this in the manual so users expect the behavior, if it's unavoidable.
• If there are no static objects in the scene, the error handling wasn't very graceful. Bakery issued notices about being unable to create vertex buffers, etc., when the real problem was that it had nothing to do. Again, a very minor issue, especially since I knew perfectly well what was causing it, but this is one of those edge-cases that you may want to handle with a more friendly error prompt in future versions.

The above are all the reports I have on the standard test scene from the asset. Aside from these very minor issues, it worked great for me, and the full lightmap bake at rather high resolution completed in 336 seconds on my machine.

Now, I have a special use-case for which I would like to request some assistance. Much of the geometry in my project (the real one, not this little sandbox) is generated with Archimatix Pro, from Roaring Tide Productions. These meshes are procedurally generated, and Bakery doesn't "see" them even if they are marked static. Archimatix has an option called "stamping" that makes a copy of the procedural meshes into a set of regular mesh objects. Even after I used that option, and marked the resulting object tree as fully static, Bakery still does not process it. I placed a large static Cube primitive into the scene, to verify that I had a working Bakery setup, and it baked 100% correctly. I think there is something I'm missing with the Archimatix and Bakery interaction.

What I'd like to request is, could you contact the author of Archimatix (a very nice gentleman, by the way) and work with him to understand what Bakery needs in order to accept Archimatix geometry? I would be happy to participate in this discussion if it would help, but I think it probably is more efficient for the two developers to speak directly since each of you understand your own asset better than I do.

I'm sorry this is so long, and I don't mean it to sound negative -- quite the contrary! I think Bakery is already an amazing tool, way ahead of what Unity's own lightmapper can do, and I'm looking forward to continuing to work with it. Thank you for developing this very promising tool.

 

Hi syscrusher, thanks for your feedback!

Seems to only happen in Simple settings mode. Fixed it!

It's probably not a bug. It's just that it can't copy settings from all possible skybox shaders. For example, it can't use the one with 6 2D images, or the generic procedural sky you have in empty scenes. Currently Bakery can only match the skybox if it uses a Skybox/Cubemap material or the native Bakery Skybox shader.

Hmm that shouldn't happen. What you should see in an empty scene is:


Perhaps there were some static objects, but there was something off about them?

Does Archimatrix work correctly with Enlighten/Progressive?
There is a simple list of tests Bakery performs for every object to determine if it should be lightmapped. I wonder if Archimatrix fails any of them:
- Object is active in hierarchy.
- Object is a part of the scene, not a prefab (checked via AssetDatabase.GetAssetPath(obj))
- GameObject.hideFlags doesn't have the HideAndDontSave flag
- Object doesn't have an EditorOnly tag
- There is an enabled MeshRenderer and MeshFilter with a valid non-null mesh
- Lighmapped Static is set
- Scale In Lightmap is not set to 0 on Mesh Renderer

 

And thank YOU for the quick reply. I will have further time to test later today, so your timing is perfect (and unexpectedly fast, on a weekend).

Well, I can't ask much more than that.

Ah, thanks for clarifying. If that is in the manual, I overlooked it.

Would it be possible in those cases to extract the color from the other skybox? Even the Unity procedural one does have a color selector in its inspector. That would be a good partial workaround.

In any case, thanks for the extra info.

That is almost certainly true. Those messages came up when I had marked the Archimatix models as static but had not yet "stamped" them out to traditional meshes. I may have been unclear in my feedback -- I was not expecting that Bakery should be able to handle those objects, only that it might be more user-friendly to silently treat them as non-static, perhaps with a single message in the log rather than a bunch of popups. The error was expected; I'm just suggesting more graceful handling.

Last time I tested, yes, but I have not tried it with this specific version of Unity, so I will retest that.

THANK YOU! That is an excellent level of detail. I will have some additional time to test later today, and thanks to this reply, you've given me very specific and useful guidance of what to investigate. I will report back after I have done my next round of testing.

 

I did quite a bit more testing tonight, and I have some progress to report but still am not quite able to get it working. On the other hand, things are a lot better than before, so I feel we're close to success.

First, I rechecked my settings on the Archimatix model, and found that I had not specifically enabled it to generate lightmap-compatible procedural meshes. This has been "already done" in my production project for so long that I forgot it was a manual one-time step for a new model. Here is the relevant documentation from Archimatix, in case others are working through this also: http://www.archimatix.com/manual/lightmapping-with-archimatix

Once I fixed that problem (including telling AX that it needs to generate the UV2 maps), I got rid of almost all the errors from the Render process under Bakery. Unfortunately, Bakery is still not creating meaningful lightmaps for the Archimatix model.

As a test, I put a couple of cubes into the scene that are above the AX model's roof and casting shadows down onto it from the scene's one Directional Light (which also has a Bakery Direct Light component attached, and I used the buttons to match the parameters). The Directional Light is marked fully static as are the AX models and both cubes.

What I find is that Bakery walks through the motions and says it's mapping the AX models and the cubes. When I look at the resulting lightmaps, it appears to me that the Skylight is mapping onto all geometry, but the Direct Light seems to map only onto the cubes.

I also found that if I put a Bakery Lightmap Group component onto the parent cube but not on its child, then what happens is that both cubes share the same lightmap even though they are not lit the same (one is above the other). When you talk about a LMGroup applying to its own component and all its children, is it intended that this means the lightmaps are the same for each of the objects? If so, then I simply misread the documentation.

In an unrelated issue, I am able to fairly reliably reproduce a hung process in Bakery Render, if I select an object in the Hierarchy and press "Render Selected" in the Bakery dialog. I get this message in the console log:

ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
System.Collections.Generic.List`1[System.Boolean].get_Item (Int32 index) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:635)
ftRenderLightmap+<RenderLightmapFunc>c__Iterator2.MoveNext () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:3040)
ftRenderLightmap.RenderLightmapUpdate () (at Assets/Editor/x64/Bakery/scripts/ftRenderLightmap.cs:1923)
UnityEditor.EditorApplication.Internal_CallUpdateFunctions () (at C:/buildslave/unity/build/Editor/Mono/EditorApplication.cs:127)
​

The render then stalls indefinitely. Fortunately, I'm able to close Unity itself in a graceful way, and when I restart Unity and reopen the project, all is well. I do not see this problem if I render the entire scene in Bakery, just if I try to do a selected part of the Hierarchy.

Getting back to the Archimatix baking, I tried doing their Stamp operation again to create conventional meshes. This has the same result in Bakery; again, lightmaps get created but are missing the Direct Light.

If I tell Archimatix to combine all its output into a single large mesh (it has the option to do that), then render it in Bakery, I get a map that is a "hot mess" of glitchy shadows. I don't think this is a Bakery or Archimatix issue, but simply that this one gigantic mesh is too big for even a 4Kx4K lightmap to process sensibly, so I don't put a lot of weight on this test.

I also tried using Advanced mode in Bakery, and telling it to validate the UVs. There were no reported errors.

Any suggestions on what I should try next? I could ship you a copy of this project via Dropbox, but that isn't legal because it contains the Archimatix script code.

 

I forgot to mention: I tried using Enlighten to bake the same scene, and it works correctly once I turned on the lightmap enablement options in Archimatix. Apologies for forgetting to mention that.

 

It would be very helpful if you could bake an Archimatrix model into a mesh and send it to me as unitypackage - I'll check what's missing.

It's intended behaviour (which I'm going to change though, as many people don't expect that).
Check this post (#294), there are some pics: https://forum.unity.com/threads/bakery-gpu-lightmapper-v1-2-released.536008/page-6#post-3598369
I should add them to the docs. In the next release you won't have to apply Pack Atlas components to every child, and it will be more intuitive (already done that).

Ah yeah, this one seems broken in 1.2, and generally also doesn't work the way most people expect. Gonna do something about it. Three things to know about Render Selected at the moment (technical details):

1. It doesn't only rebakes selected objects, but it rebakes the whole Lightmap Group they belong to. Lightmap Groups are either defined explicitly by you, or Bakery auto-splits the scene into them. LMGroup is just a collection of objects belonging to 1 lightmap. So if e.g. Bakery generated 5 lightmaps and you selected 1 object and hit Render Selected, it will only rebake the 1 lightmap object belongs to - but also with other objects being in the same lightmap.

2. Different Lightmap Groups can illuminate each other with bounced and emissive lighting without any problem. However, because each group needs to calculate its own lighting prior to GI propagation, Render Selected may not pick up up-to-date lighting information from other groups during GI. Simply put, if you have an unlit scene and render 1 group in isolation, it will only get bounced light from itself, not from objects belonging to other (not yet baked) groups. Shadow casting/sky occlusion will work as expected though.

3. Render Selected currently seems to throw errors if no baked data from other Lightmap Groups is found. This is a bug - expect it to be fixed in the next release.

I'm planning to release 1.3 this week.

 

I've updated teh GPU instancing script to support lightmapped objects.
https://forum.unity.com/threads/instanced-gpu-rendering-doesnt-work-reliably.419063/#post-3658753

This will instantiate the same prefab this is attached to, and keep the lightmaps of the original prefab that is destroyed right after. This way the prefabs will gpu instance (if material is set to gpu instantiate)

For this to work you need to alsocreate a lightmap group(s) so all the prefabs of an specific instance fall within same lightmap.

For instance I've harbour cranes harbour containers etc... you can do one lm group for cranes and another one for containers, depending if the size of the lm (up to 8k) can host all the lightmapping for all the geometries. or you can do a different group fore each, lets say containers and cranes so each will bake in a different lightmap to witch you can control the size of the lightmap.

TBH the lightmap groups are easy enough to understand once you understand them, so rather than modifying the code you may whant to modify a bit the documentation with a practical example.

My cranes are loded so look like crap so eagerly waiting for next update.

 

What I'm changing for v1.3 is the fact you needed to have the component on every child for Pack Atlas mode to actually pack them as separate objects.

The way Pack Atlas currently works:
- All objects with the same group use single atlas
- Only objects with the component are considered to be packable rectangles, containing their children (assuming they don't overlap)

The way it's going to work in 1.3:
- All objects with the same group use single atlas.
- All objects with the component AND their children are considered to be separate packable rectangles. So now the default assumption is that children overlap and should be packed.
- But it also performs a UV overlap test for each model. If it realizes your model has multiple objects with no overlapping UVs, the whole model will be packed as single rectangle.

This is similar to how auto-atlasing (without the component) works at the moment, and I think it's a more useful behaviour for manual Pack Atlas groups too.

 

I'm having issues getting this asset to work properly. Whenever I update light probes, dynamic items turn red?



https://gyazo.com/21ca794402f8a93653412aa6329f53a0

 

The current behavior matches what I surmised from what happened in my scene, and the planned behavior in 1.3 accurately expresses what I expected to happen from reading the documentation.

@TooManySugar may disagree with me (no offense taken if so), but to me at least the plan you have for 1.3 sounds more intuitive.

That being said, is it worth having a checkbox option in the LMG's asset file inspector, to choose one behavior or the other? The current behavior could actually be useful if a person wanted to have a bunch of identical objects all mapped the same way because it was known in advance that their non-local lighting would be the same (or, perhaps, the only light that isn't very close to each object is the scene's directional light, and maybe that is realtime to allow weather changes or day/night cycle). You already have the existing code, so it seems a shame to throw it away.

 

I can certainly do that, because the AX scripts won't be part of it. I considered that last night but wasn't sure if it would be useful. Again, thanks for being so responsive on this. I really think we will get this solved.

 

No ofesene for sure . I will adapt myself to whatever it comes, That said , clarify that my objects do not use identical lighting, just the same ligthmap file.

 

Which version of Unity are you on? Can you try pressing "Update Skybox Probe" after that?

You still can do that using Simple mode - it doesn't perform any packing whatsoever. The UVs used will be exactly as they were in modeling package.

 

I'm on Unity 2017.3.1f.

Update skybox probe did fix it a little bit, but dynamic objects still remain red (apparently the walls weren't dynamic which I first thought):


All I do to produce this:

1. Duplicate "example_shadowmask"
2. Open duplicated scene
3. Click render lighting buttons in Bakery

I managed to get Bakery working in a fresh scene so this is weird!

I noticed this as well. It seems like light probes don't work well with shadow mask mode. Shadows are ignored for the probes:



Compare with enlighten shadowmask light probe behaviour:

 

Getting 2017.3 now... can't reproduce on 2017.4 and 5.6 so far (or maybe has to do something with your project settings).

If you disable the light, you'll see probes looking more similar to enlighten. It's like Unity treats my probes as dynamic objects themselves and applies direct lighting on top of the lightprobe data - I'm not sure why. It's not baked in the probes.

 

OK, I can't reproduce it really:




Can it be something about your project settings? Or other third-party plugins?

 

@guycalledfrank, is there a way to disable the usage of certain reflection probes? When I bake my scene that has a ton of probes it takes forever to bake and for that scene the probe doesn't really affect anything. If I forget to disable them and start the bake, I come back an hour later rather disappointed, lol.

 

As long if you have any LightingDataAsset plugged in Unity's Lighting settings, you can always just select relfection probes and hit Bake on them.

 

I understand that, but I mean that the bakes take longer when there are active reflection probes in the scene, like it is taking them into account somehow. So if you have a scene with no probes and hit bake, it takes little to no time. If you add 10 probes, now it takes 10 times as long or more. My solution is simply to disable the probes before baking, but I have forgotten a few times and come back to it still baking the first light, lol.

 

Wait, what? Reflection probes affecting lightmap render? That's impossible - I don't use reflection probes for anything. I don't even bake them, I just call engine method to do that (they have nothing to do with lightmapping, so the button is just for convenience). Maybe Unity tries to update them every frame? Have you tried the "unload scenes before render" checkbox?

 

I've seen proves destory lightmaping ONLY when you click the bake from the prove itself not from Bakery menu. That button is like a boobytrap, waiting for catch you unaware.

 

It's a fresh project with no other assets but yours.

What setting exactly could cause this behaviour?

It seems like if I start removing items, it gets a little bit better each time.

 

Aha, could reproduce it with forward instead of deferred. Seems to only happen on 2017.3, not 2017.4 or 2017.2.
Further debugging made me realize the default sky probe color before render in this version has a very weird value, instead of just being zeros.
Try replacing these two files: https://drive.google.com/open?id=10_QT0rXOGYg0yTlMdeIX2jeVj2SddMmg

 

Works great, thanks!

 

@guycalledfrank
Is there a way to make Bakery work with a procedural skybox? (Such as the default skybox material.)

 

Currently not. But you can hack it by creating a baked reflection probe in an empty scene, baking it and then using the resulting cubemap asset in Bakery's Sky Light.

 

Hi again. In last time i get error "seamfix error" when bake scene with high resolution. Can you give some advice to find the cause?

 

Was it because of large terrains? If so, I fixed it - can send you the patch.

 

No, terrain not using in scene... but may be it's related.

 

Hmm is it caused by a specific complex object? If you can send me a unitypackage with the mesh causing it, I'll debug.
Shouldn't be caused by resolution - only by certain geometry.

 

Scene very big (more 2gb) with many objects. I can manually disable it step by step, but for this need a lot of time. It`s happens on resolution more 100...

 

Something you can try:
- Disable all lights
- Set GI bounces to 0
- Remove the Denoise checkbox
- Render and see if it crashes. It won't render anything, but will just go straight from scene export to seam fixer.
- If it does, disable 50% of all objects
- Repeat steps above until the bug-causing object is found.

 

Ok, i will try this...

 

After disable all lights i not get this error. Any idea?