Official Progressive CPU Lightmapper

@Jesper-Mortensen I think I found the culprit. If I bake my scene using the Bake Prefab Lightmap script, and play the scene, not only does the scene become overexposed, but I can no longer see my baked GI visualisations like Directionality and Baked Lightmaps.

I am waiting for my project to be sent over... in your tests, bake with Bake Prefab Lightmaps, and the scene will become overexposed. Seems to happen in my projects

 

Good morning. This overexposure only happens if use that script to bake (I'm using an asset that unfortunately requires prefabs) and I will sometimes lose my lightmaps in standalone builds. The case number is 924826. Just sent an update. Not sure if this is happening to anyone else but it is happening in my project.

With non directional lightmaps using the script, the lightmaps will sometimes vanish

 

Is this a Unity bug (getting hundreds in the console)? 2017.1.0 Beta 9

Code (CSharp):

1. Assertion failed: Assertion failed on expression: 'Thread::EqualsCurrentThreadIDForAssert(Thread::mainThreadId)'

Scene contains quite a few point and spot lights, but certainly less than what was introducing the errors reported several posts above. Precomputed realtime works fine, but baking completely corrupts the lightmaps.

EDIT: Moved to release candidate version, error no longer appears

 

It's been confirmed... if you use the Bake Prefab Lightmap script with Directional Lightmaps once you play the game, you will get the overexposure... I did this in Non Directional and no overexposure


Also in builds, I lose ALL of my lighting

 

Are there any plans to address the high memory usage of the progressive lightmapper? Its results are great and I really love it but initial RAM usage makes it nearly impossible to render large scenes at high resolution. Even if I would be willing to wait for the process to complete... Unity just crashes

 

I have also been dealing with this issue lately

 

Afaik from the Unite Europe: Yes, they know about it. Yes, they will address that problem in future. No, it's not the most urgent issue they are working on, as the system is not complete yet and they want to focus on that, before doing optimizations to the system.

 

And I hope you guys figure out ways to store lightmaps on prefabs. The current workflow is PAINFUL

 

Unfortunately 2017.1.0f1 produces other fatal errors for me, including the following (see attached). Submitted a bug report yesterday.

 

In the future, will PLM be able to cache results from previous bakes to reduce iterative bake cycles? I'm not sure the feasibility of something like this for a path tracer, but submitting multiple 8hr bakes just to tweak color / intensity parameters on a light is extremely grueling.

Also, will PLM support Shadowmask and Distance Shadowmask in the official release of 2017.1?

 

Wondering when the Progressive Lightmapper will be getting another update?

You guys have been kinda silent about its progress after 5.6 shipped. And I see no details about it in the next 2017.2 beta.

 

(Case 926910) Unity 2017.1.0f1 Fatal Error

 

And I hope in the patch updates, the overexposure of lightmaps can be fixed and we somehow get the ability to bake light maps to prefabs

 

For that matter, is Octane going to produce lightmaps as well, and if so, is Progressive going to be dropped or is there a reason to maintain both?

 

The memory usage thing it the upmost deal breaker for me. I really want to see what the lightmapper can do to my scene but I cant set the resolution to anything higher than 5 (indirect and direct) before windows force closes unity.

Other question: Will it be possible to save multiple lightmaps (Day/Night e.g.) and load them while the game is running? Would be fine if its a slow process to swap lightmaps. I could live with some kind of loading screen or hiding it behind a cutscene

 

This was trivial in Unity 4, using the lock atlas -option to generate different sets of lightmap textures. Unfortunately for 5 they removed the lock atlas support and changing lightmaps is considerably more difficult (have to update every renderer to reflect the proper position in lightmap).

 

So the progressive lightmapper does not do the stitching while its rendering and it also does not do the filtering any more.

Is that going to stay that way? Is A-trous that much more intensive that doing it every update slows things down? Is it the same for the stitching?

I'm hoping it's not going to stay this way, but if it does, at the very least we need a better workflow for finding good filtering values and see if stitching improves things.

Right now, you need to force stop, see the filtering and the stitching, change values, start the bake again, then force stop again. We at the very least, need a way to keep the filtering updates interactive while we tweak the values, and see the stitching happen on the fly. (maybe a special, edit filtering button?)

With all that said, I'm hoping this is a temporary thing and that there's no point to my post

 

Also...

Does the stitching happen before or after the filtering?

It feels like the filtering happens after the stitching and it brings back some of the discontinuities. If I have filtering off, stitching works great. With filtering the results get a bit worse.

Also, is it me, or does A-trous make things lighter overall?

 

Does this one mean proper transparency support for indirect light?

 

Is there somewhere that the official planned stuff on Octane is listed? If not, any ETA on when that will start becoming public? There was speculation that it would work in the following thread from a couple of months ago (although the latest posts from today seem to say not). It would be great to have somewhere to reality check what's actually coming down the pike.

"In the previous video Jules Urbach did mention running the progressive lightmapper with octane. He also mentioned it was roughly 10 times faster." from https://forum.unity3d.com/threads/additional-otoy-octane-details.463964/

I haven't actually watched the video mentioned to find the comment ... I just took it at face value.

 

No problem. Just understanding that helps. Thanks!

Also, GPU support will definitely be huge ... I already have a few hefty GPUs for Octane rendering, so that will go hand-in-hand with light baking if it can use all (or at least the best) of them. Very glad to hear that!

 

Hey there,

I am trying to bake a scene with the Progressive Lightmapper and have a few questions. My scene is a university like building with a hedge and a few trees around it, it has to two floors so it is a more huge scene with about a million tris. It is needed to be for VR.
It takes pretty long to bake, i gues 30 hours (image with adjustments atached). I have 32 GB of RAM. I can`t bake the Lightmap Resolution bigger than 256 or it will crash. I would need bigger lightmap resolution cause i have some seams on objects, but dont really want to unwrap them for lightmap porpuse, because it is too time consuming. I dont use pointlights in the building only emissive Materials inside the Lamps and a directional Light as a Sun.
I think i figured out that Emissive Light Sources need to have a certain sice to bake their light. Unfortunatly it seems that not all Lights are contributing light. So maybe there is a Limitation of emissive meshes as well.
Another thing is that i have Noisy lighting in the inside of the building, i thought it comes from a low value in the "Indirect Sample" column but a value of 3200 doesnt help. Outside everything looks nice.
So my Questions would be:
Is there a minimum and maximum in size and count of emissive Objects and can i change that somewhere?
Why is my Lighting inside the building noisy?
Why does it take so long and it is possible to make the "Lighmap Resolution" bigger?
Is it at all the right approach to bake a scene like this?

 

Sounds like excellent work so far, very happy with Unity's work on progressive! btw was an ETA mentioned for the GPU acceleration on progressive? It's a bit slow to be honest, or more accurately, I torture it so.

 

Why is my Lighting inside the building noisy?
You have 2 options:
1. You can use spot lights and point lights as indirect light sources to reduce noises and bake time
2. Increase indirect samples to 10.000 to get clean look indirect lights

https://www.youtube.com/playlist?list=PLVXvfvDWvto2r9NYSx7PfZG1fHU3rVe4_

Spoiler: Videos

https://www.youtube.com/playlist?list=PLVXvfvDWvto2r9NYSx7PfZG1fHU3rVe4_

Why does it take so long and it is possible to make the "Lighmap Resolution" bigger?
Always use a low resolution in lighting settings window and increase Lightmap Scale (in MeshRenderer) for special objects to fix unwarp issues
Or simply use lightprobes for these type of the objects (set them as no-static)
Watch above videos for how to setup

Is there a minimum and maximum in size and count of emissive Objects and can i change that somewhere?
No limit

Is it at all the right approach to bake a scene like this?
Yes. the watch videos. You can bake your scene using Spot lights similar to Unreal Engine demos to archives better indirect shadows and very shorter bake time (3-4 hours => 30 min )

 

thak you aliyeredon! I will watch the Videos.

 

Reduce bake time from 3-4 hours to 30 min
Kill indirect lights noises
Increase indirect light shadows quality

 

I bake my environment with the Progressive Lightmapper and it lightmaps the environment, light no longer affects the environment (it's baked), but when my racing kart spawns in it doesn't receive any real time light from that same Directional Light I just baked from. The light is set to "Mixed" so it should be casting real time lighting on my racing kart. Why is this happening?

I don't care about real time shadows or anything...I just need lighting on my kart materials to show up.

 

PLM (preview version) does not support mixed mode feature . You need to bake using Enlighten or use light probes for dynamic objects

 

It is planned feature for 2017.3 . See post #275 in this page...

 

If you don't care about mixed shadows, you can still bake with Mixed mode using Progressive. Realtime lighting data should still work.

 

No it sure doesn't. Has to be related to the Progressive Lightmapper, because when I baked lightmaps with Enlighten it kept the real time lighting on my karts and the environment was properly baked. Using the Progressive Lightmapper it would bake the static environment. When baking was done I lost all real time lighting on the "Mixed" Directional Light. I found that deleting it and adding a new Directional Light to the baked scene brought back real time lighting on my spawned karts, it also multiplied over top of the lightmaps (affecting them with real time lighting).

 

Progressive UVcharts are calculated by shels UV0, why?
This gives a lot of artifacts, on complex models.
Can have a solution? Thanks!
sorry for my english

 

Ah okay well that explains it. I don't see how this wasn't a higher priority thing (kind of a big deal). The ability to have any real time lighting lost after baking a scene with the Progressive Lightmapper. Does it behave this same way in 2017?

 

hi, kemalakay thanks for your help
Albedo and lightmap UVs are located correctly,
I tried to make more examples,
unity 2017.1
Thanks)

 

Try generating lightmap uv inside modeling software . Some models that are made using Booleans is not works correctly with unity Generate Lightmap UV option.

 

The Progressive Lightmapper has now become unusable for me. For some reason (and this just started), it now consumes almost all of my CPU, locks up my machine entirely and I have to use the power button to turn it off. I have no idea what the heck happened? Just trying to lightmap a 15k triangle mobile environment. Turned all of the resolution settings way down to iterate over bake times faster. Now it hangs my entire computer up. So much so I can't even launch the Task Manager. When I switch over to Enlighten this does not happen at all. However the Enlighten bake times are ridiculous for a mobile optimized environment.

 

Check Ram usage during bake time. PLM needs lots of memory to start baking. I have 32gb for simple terrain baking
It's usable but with +32gb memory for large environments

 

This is a small mobile phone game environment...less than 15k triangles. I have 16GB of ram, but that's always been plenty.