A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Now in Beta! Get 1:1 live lessons on any Unity topic or help troubleshooting your project – Connect with an expert on Unity Live Help
Discussion in 'Assets and Asset Store' started by guycalledfrank, Jun 14, 2018.
Gamma mode shouldn't affect the baking process.
I forgot... I'll take note next time this happens, which I hope not.
Are you sure it's without overclocking now?
In any case - try replacing this file (in Assets/Editor/x64/Bakery) and see if it helps: https://drive.google.com/open?id=1iT-lwnpGUeP68B2YPeSBKOtnzRWrXzee
It still happens. by the way my screen flickers right before this error happens. Also this is the last log:
The only other thing I can think if that changed since yesterday is that I changed the project from gles 3.0 to 2.0 which re-imported all assets. Just for the sake of being thorough. I'll revert to gles 3.0.
I'm out of ideas then - you will need to find specific objects/materials/lights/settings causing the crash.
Any problems baking example scenes, e.g. Sponza? I wonder if you did something weird to your video driver during overclocking.
hm... I did uninstall and re-install it last night, but it's the same version. I'll play around and see.
My other test scenes that used to work, still work. So it must be something I changed. I'll try to find out. Thx
I found the issue. In the samples field it usually says 16, but I must have somehow added a 0 and it became 160 in there and only half the zero was showing so I didn't notice it! Anyways, what a time thing...
should I revert this file now that I found the real issue? What's the side effect of this updated file?
Glad you figured this out I should add some limits to sample values.
You don't have to revert the file, it just has a fix for another problem.
Hey guycalledfrank, your work here looks great, thank you! I'm considering buying it if it constitutes a solution to a brutal Unity bug. I was wondering if you could confirm or deny?
there's a rather annoying bug in Unity where when loading a scene additive, the previous scenes light probes get blown away and only the most recent scene's probes exist. This obviously is a problem for open world games that are comprised of several scenes. The only way around this currently is to load all your scenes and bake 'em together, which is somewhat of a problem if you want multiple or unrealistic lighting setups.
Does Bakery fall victim to this bug as well, or have you gotten passed it somehow?
It's support asset bundle?
Thanks in advance.
Most likely it's susceptible to this bug as well, because it's just filling the values for native Unity light probe system.
I have so much pain with probes due to their limitations and lack of API, I'm considering writing my own independent probe system.
I still haven't tested it
I have no experience using bundles. Maybe someone in the thread used them and can tell more?
If you provide a demo for your tool so I can test & provide you feedback.
I tried a build with vertex lightmapped objects, using just the included shader example, and all of the vertex lightmapped objects are invisible in the build. Looks great in editor. Nothing in the output.log. Am I missing something?
OK FINALLY I found it. this is a shadow casting camera
Prior to 1.3 I was testing if baking a all in FULL lighting and having a shadow caster could do the job. The issue with the provided link is that the shadows when reaching the limi of the camera bounds they cause a very rare glitch, if the shadows could be sofly dissapear with like an overlay to the camera this could be a great alternative I believe.
Also, while I was writing this I Came across an idea: You bake all in indirect and the directional light is set in realtime to lit only specific layers where dynamic objects will be, this way they receive ligthing and cast shadows and you can control the shwadow distance to be sortest possible in quality settings, sort of shadowmasking but with les cpu overhead, as someone pointed it has some.
I noticed something similar once, related to batching. Seems like a Unity bug to me, as it comes from using additionalVertexStreams together with static batching. Try disabling batching on these objects.
This is way late and a version behind, but with the latest update in Unity 2017.3.1f1 I'm getting a UV error. I'm not sure if this is what was causing the failed terrain export or not. I don't remember the exact error, but I do remember "UV(0.9xxx, 1.1xxx)" being in the error or something similar. I can edit this or post the error tonight when I get home from school.
There are no Lightmap Group componts, heightmap resolution is 2049, and we are using CTS terrain shader, however, standard shader fails too. I can bake other terrains in different scenes, but I can't use the terrain data that fails in the main scene.
I can upload an assetpackage with just the terrain later if it's not a simple fix.
I assume it was "Mesh has incorrect UVs"? If so, it shouldn't cause problems with terrain anyway. In fact it might be harmless, if UVs are still relatively sane, but just out of 0-1 bounds.
Does it help to lower the resolution?
Would be immensely helpful, yes.
Hi frank I remember somebody has posted this but not finding.
After v1.3, it became this way.
How can I pack them together as tight as possible? I don't want to group them, just using default setting.
Make sure minimum lightmap size is small (preferrably the lowest value possible), so large atlases are not allocated for no reason.
This is the scenario: one big scene full of speedtrees and currently only getting light from procedural Unity Skybox.(I know speedtrees are not supported and I am assuming that is way my baking crash)
I wonder if it is possible instead of crash just avoid speedtrees, or even better, support it in the future? they are currently Static but lightmap scale on 0. (getting light from lightprobes)
and I wonder if it is on the roadmap to being able to use unity procedural skylight as well as bitmaps? I guess I can render the sky as a hdri cubebox as an alternative, but still, I'm lazy.
Doesn´t unchecking "lightmap static" on the tress do the job? or are they part of a terrain?
OK, we've just tested it with a friend, and it seems to work
Except for light probes, but it's a general Unity problem, not Bakery's.
I'm not sure if it's because of speedtrees. Did you try disabling them and baking again?
Yeah, you can do it via a reflection probe. I can make a built-in thing that would do just that automatically, but currently it's a low priority task - I have to finish more important stuff first.
I assume they want trees to still cast shadows.
Still, can't figure out why. Maybe LOD?
We get some "ftrace error" after builds occasionally fail... log simply says "Error: [number]" 500599 & 8008, what are those numbers? Sorry it won't be possible to share the scenes we're working on - so if you knew what those errors meant it might help troubleshoot our side. Thanks!
Seems like it can't do better. And yes, objects from different LOD levels get into different atlases. I can try improving it in the future, but the best thing you can do now is either live with that or unwrap everything properly in a modeling package, so packing won't be necessary.
What is the size of the first (top) texture though?
Thanks for telling me these error codes! These are known, I just didn't implement proper error printing, but if you'd look into ftracelog.txt, you would see their explanations: "Can't open ao.bin" and "Can't read direct lighting".
Why do they happen? There can be multiple explanations. My first thought is you are going out of disk space, and so it fails to read random files. If that's not the case, please check if it disappears if you disable AO?
Yes, actually, the disk was running out of space.... cleaned it up! I'll do some more tests with the AO option off/on as well, see if it continues. Thanks!
I can understand way you are working hard implementing directional, because when it's finished, it will crash by far unity lighting system. For now I just enjoy watching the development process and experimenting but not really able to apply bakery in real projects just yet.
Some other feature request not as important as Directional:
- Shadowmask viewport draw mode.
- Transparency / shadow support when Tiling is other than 1 / 1
- Any sort of visual reference of the baking process, whether is a noise progression, bake per object, ugly preview, anything that helps to cancel the job if you can see something unusual before it has finished. this is very handy in big scenes.
- Procedural Unity Sky support.
- Speedtree support (shadowmask).
- Any sort of network / distribution baking / SLI, etc. would be super, I know it is hard but way not to ask.
May be you did read al ready but there is a trick already for
"- Procedural Unity Sky support.
Its posted not too ong ago, I recall it was something like baking into a prove and use the prove for IBL
Unity should do it actually. I'm pretty sure it does on some versions (newer?), but appears to ignore custom shadowmasks on other (older?). What is your Unity version?
This one should be easy to do, if you are just using the tiling property on the material. Noted.
Bakery draws lights one by one and then proceeds with GI bounces similarly. Not the whole image at once. Would it be useful to see such progression?
Since it's so often requested, will try to cram it into 1.4 release.
Should work already!
Tried on 2018.1.0f2
If I understand you correctly, what you describe is actually pretty handy to observe. Some of our scenes are really really big, designed only to run in 1080ti or above. It is a pain to find nasty surprises at the end of 3 days of baking with enlighten. Bakery would take a few hours instead of days, but still would be nice to see the progress as it goes and take early actions if it is need it.
Another problem with dynamic preview is it will have to take a significant piece of RAM and VRAM. I have an "unload scenes" checkbox for a reason: to free up all memory for rendering. Having preview would mean having all your scenes in memory AND having uncompressed preview lightmaps (128mb per 4096x4096 map). This is only practical for small scenes, but they are already quick to bake, so I'm not sure if such preview would be practical.
Hey there @guycalledfrank - Your Lightmapper looks ever more appealing to me lately (also since the first Unity GPU Lightmapper Beta is rather broken). Do you currently support directional lightmaps?
Working on it! Next version will have them
And not just standard directional, but also RNM (HL2-style approach) and spherical harmonics lightmaps (the way they did it in Battlefront).
Sounds most excellent! Might have to buy your solution after all... hmm....
You should join the beta test instead, you have much more value there as both an artist + moderator
Well he has no less value using Bakery as well.
Not sure why Unity is taking so long over their version. I noticed they have problems with memory and fall back to CPU baking. They also do not have vertex baking.
Despite the total lack of features, the deal breaker for me is asking "what happens when we have no more VRAM". Does your solution save the current progress, clear and resume? Can it handle unexpected workloads without crashing? Thanks
In Bakery? What features exactly do you need apart from directional lightmaps (which are coming)?
Bakery is designed with low VRAM in mind:
If will cache stuff on hard drive to prevent going out of RAM/VRAM, and this specific optimization allows it to only store a very limited dataset in memory (stuff in lightmap being processed + compressed stuff that is visible from it).
If you have GTX1060 or better - good luck hitting the VRAM limit
can Bakery support nvidia shared memory [i mean virtual vray memory from ram] to baking large scene?
and what about HDRP?
Not really, but Bakery manages memory anyway, trying to unload the stuff it doesn't need at any given moment.
No, in Unity's own GPU baker! that is why I am interested in your baker because it does not lack features.
And from what I see... is reliable without fallback to CPU. So I only need say, a 980 card and it'll just bake even if it runs out of memory?
Unlike Unity's baker which will bake until it runs out of memory then stop and fallback to CPU which will be slow. It also has different results between cpu and gpu baking (according to Unity staff) so when it falls back, you can expect your lightmaps to look different in the same scene.
I don't see any competition for Bakery to be honest.
Another question: what about Unity's light probes and Unity's occlusion probes? Naturally I would prefer to remain with the native probes because they're properly supported in HDRP.
Well it will do what it can to NOT ever go out of memory. If it somehow does it will show an "out of memory" error and bake nothing. Editor shouldn't crash, as baking runs in its own executable. If it happens, it may help to set GI VRAM auto optimization to "force on" manually, as auto-prediction is a bit approximate. In general, you should leave it to "auto" though, as using the optimization performs some extra steps.
Bakery supplies colors for standard Unity probes. Occlusion probes are a bit tricky - there is no API in Unity to access their values, therefore they have to be baked by built-in bakers. Bakery has a checkbox to fill occlusion probe values, but under the hood I'm just setting all static renderers lightmap scale to 0 and call standard Bake() function to trick Unity into rendering probes, but not lightmaps. It works, but of course it's a terrible hack, and I see 2 ways to improve the situation:
a) Wait for Unity to provide occlusion probe APIs.
b) Create a completely separate probe system.
If option A doesn't happen after I release 1.4, I'll look into option B. There are actually many interesting things I'd like to do with probes, like making them modular, moving them together with objects, auto-populating volumes, etc.
Definitely. This dev came from nowhere and in record time has taken by storm the baked lighting area with such a solid product that tbh I really dont care too much what unity delivers by 2019. Im using it already in production and the directional lightmaps will be the cherry on top of the cake. To me memory wise system memory is more a concern than the vram. I managed to crash due to mem peaking when texel and samples where "high". I wish if not already when this happening the temp disk to be used for virtual mem. This is anyways a 5/5 product already. Future wishlist for 1.5+ add easy way to bake different lighting conditions and switching among. May be also if changes are made in scene and you what to bake batch bake whole light modes so this can be left overnight. Also batch baking adding scenes would be nice for final cranked up values to be left overnigh overweekend.
Hi I'm not an expert at this stuff so I'm confused when you say you are working on directional lightmap. Currently I'm already using a directional light in the scene and it works. So I guess my question is what's the difference b/t directional lightmap and my using directional light in the scene and baking it?
Directional lightmaps have nothing to do with directional lights
They are called so because they contain information about directions the light is coming from, allowing them to interact with normal mapping, specular, etc: https://docs.unity3d.com/540/Documentation/Manual/LightmappingDirectional.html
Not 'directional' the light source, but 'directional' meaning the map takes the direction of the light into account for calculations moreso than it does without using the mapping.
I bought a 1080ti just for baking because of Bakery! And now it bakes my city in less than an hour! This city is made up of over 3000 sector scenes(for streaming the open world), with LOD for each building!
This is a far away view, the game is a 3rd person perspective game so you actually see each building up close with details and you can even enter each and any building.
Without Bakery this would take days and I'd have to use a 100gig ssd drive as ram drive to finish baking. So yeah Thx Frank!