Official Progressive CPU Lightmapper

I am not sure what you mean exactly, any images? Wild guess: Even with directional lightmaps, the directionality is at lightmap res, so it's presumably far less detailed than what your real normal maps are.

 

Is the artifact still appear even when the lightmapping process finished? when i said finished like it totally finished by itself, not manually stopped/canceled?

 

I suppose it's actually specularity and not curvature. I can post images in a bit, just for reference.

 

Well, specularity only happens when actual lights hit your meshes, so it's normal that it's gone with lightmapping, if you're baking the direct light as well.

 

That fixed it, you're a genius!

So to confirm, if I understand correctly, if a texel produces a lot of (indirect) rays that go throught backfaces (so through the back side of a single-sided mesh) that texel gets rejected and it won't have any lighting applied to it?

We have a lot of leaves that has backface culling turned off, so that's probably the issue...

Do the lightmap parameters have to be applied scene-wide in this case? And are there any performance implications or other "hidden" changes that will affect the scene later?

Thanks!!!

 

Exactly. The logic behind it, is that if it's seeing backfaces it's probably intersecting geometry so in order to avoid making everything black (which might be an issue, for texels that are partially visible) it rejects them. There is another way to handle this, you can mark the materials to be double sided only for GI purposes (it's the last checkbox on the material), but that only works with the progressive lightmapper.

No, you can create multiple lightmap parameters and set them on mesh renderers that override the global one.

No performance implications. You might get dark texels in corners near intersecting geometry, but that's it.

 

Awesome, thanks for the explanation!

I'm having one more issue though, if you could shed some light on it (bad pun intended).

Using a single baked light gets me these results:


Looks good but it requires me to have another realtime light for dynamic shadows which somewhat messes up my baked shadows.
So I want to try using a mixed light. I changed my main light to mixed and baked the lighting. However, I can't get direct lighting to look good, no matter what i tweak. I get really jagged edges and they're not going away.

This is without any filtering (one mixed light with shadowmask):

Note that Auto looks more or less the same as no filtering.

Turning on filtering to advanced and bumping up direct radius (gaussian) just looks weird:

I tried all values from 0-5 but none of them look even remotely like the first screenshot where i used only a baked light.

Moving on from that, using A-Trous doesn't seem to have any affect whatsoever. Sigma 0 and 2 look exactly the same to me. Maybe that's a bug or I'm just using it wrong...

Any idea how I could make my mixed lighting setup look more like the baked-only setup? Thanks!

 

The filtering doesn't happen until the rendering is finished (or you click force stop), so while it's baking you won't see the result.

That third screenshot looks kinda weird, not sure what's going on there.

Which mixed mode are you using? Have you tried subtractive? (also, is this a mobile game or desktop?)

 

I did wait for it to finish but still A-Trous had no effect with any sigma value i used (as opposed to Gaussian).

I'm using Shadowmask (not distance shadowmask) and developing for mobile (more high-end iOS devices).

Just tried Subtractive and it looks good! More or less the same as when only using baked lights but with realtime shadows for my dynamic objects

This is with the default auto filtering. Though getting the realtime shadow to look good will require some tweaking of it's color.

However, I'm still confused as to why the shadows in Shadowmask mode looked the way they did, and why Auto filtering wasn't able to correctly blur the edges...

 

Because then the static shadows come from the Shadowmask and not the lightmap. And the filterting only affects the lightmap Now why it looked so bad, I'm not sure.

In any case, for mobile, subtractive is the way to go, and it works for you, so... cool!

Just a note, I often find "Auto" filtering to be too aggressive, I generally use lower filtering settings.

 

@AcidArrow is there *any* way to retain the specular information from realtime / mixed mode lightmap in baked only, that you know of?

 

That used to be the directional specular mode, but it was kinda crappy and removed (I thought it was the correct choice).

I think the logic now is, that if you want speculars you may as well pay the cost for the light (directional specular was kind of expensive as well), so if you really want speculars I'm afraid you'll have to go with the mixed mode.

Personally, since I usually don't have moving lights, I tend to use a lot of static emissive materials to light my scenes, so I also have something bright in the actual environment, so that when I use reflection probes I get something that somewhat resembles speculars (although very inaccurate) from reflections probes.

(although, emissive materials are right now really hard to get clean bakes out of, so I'm hesitant to suggest them).

 

Right, I had a feeling I was circling back to the directional specular conversation. Yes both of the issues you pointed out regarding emissive materials and reflection probes have been an obstacle for me as well. Thanks for your advice though.

 

It's a bug. For some reason the progressive lightmapper isn't baking/filtering shadowmasks properly in 2017.3. I've made a post about it here more than a month ago: https://forum.unity.com/threads/progressive-lightmapper.454362/page-11#post-3356880

Jesper-Mortensen has said a fix was being done by someone named Kuba, though I'm not sure when this will happen.

 

i was told its been improved in 2018.1.0b8, havent tried yet.

 

Hey progressive lightmapper devs. Once you are done with the important stuff and GPU baking so things are fast enough, could you maybe look into a couple of pet features I want?

1. Implementing SSS/Transmission baking? I mean we have it in realtime with the HD render loop, so if the realtime lights can do it, why can't our baked lights do it?

2. Can you make it so bounced light takes into account the material smoothness? If I am not mistaken, now it treats everything like it is as rough as it gets. It could be nice if it could take smoothness into account so that the bounced rays get spread less if the material is smooth. This way, with enough rays, reflection caustics will be produced from smooth surfaces, which will be cool It will probably need a lot of rays, but if GPU baking is coming that shouldn't be a problem, right?

 

is there a wish list thread, if not that would be pretty good...kept to bullet points etc

 

Hi, i would like to suggest a small feature related to PLM !
In some stand alone renderers there is an option to set a max render time .
If we could get one when using PLM would be really nice.

Thanks!

 

Hi,
Don't know if this is a bug or what, but after baking a scene in 2017.2, the reflection probes turned out very blotchy. It looks like they where rendered before the filtering or the lightmap compress pass where done, so I had to re-bake the reflections probes.

Please tell me if I should report it.

 

@Jesper-Mortensen When Lightmap resolution value are higher than lightmap size. the resulting lightmap are darker.
i encounter this twice in 2018 b10 with LWRP. is this known issues?

 

Hi, i have a question. Is there any change in how PLM bakes objects in 2018.1 !?
It looks to me that all the objects are now baked one by one and the whole process is somehow slower !

 

If i'm not mistaken, i read the response about this somewhere. They change the PLM baking queueing per tile now rather than tracing the entire lightmap at the same time now, the reason is to reduce memory usage since tracing all lightmap at once for large scene required high amount of memory.

 

Thanks for the info !

Unity, we need a toggle for that ( sorry if there is one but i cant see it ). Baking a small scene now has to wait to iterate all objects instead of wait like to bake a few samples and force stop it !!!!!!!!!!!!!!!!!

 

Hi ,
i have a question, any chance of exposing the "LightingDataAsset" so if we write a custom lightmaping tool then we can use it !?

 

Another useful option would be to be able to bake only selected objects within a scene. So if i have a big level bake, and change a single building object, i could rebake that single object as opposed to the whole scene again.

 

I̶s̶ ̶P̶L̶M̶ ̶w̶o̶r̶k̶i̶n̶g̶ ̶w̶i̶t̶h̶ ̶s̶h̶a̶d̶o̶w̶m̶a̶s̶k̶ ̶i̶n̶ ̶2̶0̶1̶8̶?̶ Yes

EDIT: so ready for the GPU PLM

 

What is the status of the sky occlusion implementation, e.g. is it available in 2018.1 beta? Obviously it is present in the Book of the Dead demo and appears in the GDC presentations.

 

it's already there since b1, we just need an example on how to use it.
@Jesper-Mortensen and @robert any news about the sky occlusion samples?

 

Is there an option in quality settings or lighting window to enable this feature? If so, I've completely missed it.

 

Sadly not, i think it only available via script, and you also need to adjust your shaders to use the sky occlusion data.

 

Is anyone else having the issue that baking is stuck at the very beginning for forever with 4k resolution lightmaps? I let it run overnight, 0 progress. I can bake in under 10 min with resolution set to 2048, but at 4096 it just seems to be stuck. I see no change whatsoever in the scene view after hours.

The strange thing is this only started happening recently, I think. I could've sworn that I made 4k bakes of this scene before. Not sure what I changed.

Edit: Well this is strange. I took out "Prioritize View" and I'm suddenly seeing progress and an ETA. Case closed I guess.

 

I tested PLM on a small scene and after 2 minutes using mostly default settings I got nice results.

Question: Why did it run out of memory on my second attempt at baking it?

Can't wait for instant baking in Unity 2018 but we need it to actually work with proper memory management like enlighten or beast because quality or render times are not really issues anymore and me needs more than a 1 shot wonder.

 

I've just experienced this out of memory issue too. I don't see how that's possible with 16GB of ram. Should be more than enough memory for a texture bake. I've been experimenting and it seems it might be related to the lightmap resolution.

 

I was digging into the LWRP files and out of curiosity I took a look at how the GI Meta pass is defined in LWRP. ( https://github.com/Unity-Technologi...e/LWRP/ShaderLibrary/LightweightPassMeta.hlsl )

And I saw that the LWRP has a specular color output.

Which is curious. Does this do anything for the progressive lightmapper at the moment?

 

I found a potential few problems which I can't believe are actually a thing as they are what I would consider category 5 issues.

- I cannot manually enter the scale in lightmap.
- All default 3d objects have MASSIVE uv texel resolutions and this is what seemed to be causing
extremely long bake times for me and like 40 lightmaps even on just a few peices of geometry and a floor.
- the UV chart view is showing my objects as transparent and this is not practical.

So basically for me the default texel size for my objects is 1.0 but this is about 50 times larger than a decent texel resolution for the lightmapper....how can this be that the default 3d meshes in 2017 are not optimized for baking?

Here are some images to showcase my examples.

 

Why not?

Are those screens from the lightmap view? Start a bake to see them update and not be transparent.

 

I'm having a similar 'bug" or issue. I can adjust the scale in lightmap for geometry pieces, but the lightmap parameter's settings for "baked tag" and "system tag" are not working. I assign a specific tag value for a group of geometry pieces I want to put on the same lightmap atlas, but it doesn't work. They stay on their own atlases with a ton of wasted space around them on the texture atlas. We're talking lightmap textures with 75% empty texture space occupied by my UVs in a small corner. These are UVs I've hand authored in UV2 from 3ds Max too, so they should all sit nicely on the same atlas if I give them all the same tag in the lightmap parameters.

 

It just wont let me type in there.
I need them to be solid shaded so I can visualize texel density before baking and I did bake then clear the maps. It wasn't transparent in Unity 5.

 

After some good testing and consideration I have realized the progressive lightmapper has become much worse than it's original 5.6 introduction. At this time I have decided to deem it unworthy and I will avoid using any of the lightmap features within Unity and stick to real time lights until some major changes occur within Unity.

I currently have some really good settings with real time and see no reason to go into baked lightmapping anyway. This is why I have been quiet on this topic for a year.

With the introduction of the new render pipeline and the medium, close fit, no cascades shadow trick I am able to get lighting fast fps. I can share these details if anyone needs them.

So good luck to you lightmapping fans as I have decided to leave this front until further notice.

 

You obviously have a strong opinion on this matter. Could you elaborate on what, specifically, has led you to this conclusion?

 

I was one of those beast lightmapper fans and never had any issues with it. That lightmapper was fast, optimized and gave amazing results. Then one day Unity decided to remove beast when Unity 5 came out and as hesitant as I was I trusted them and began to use it for production cases with a team I had back then who by the way were unreal fanboys.

I had convinced them that Unity was better but when it finally came to using this new Enlighten feature It was so unpolished and rigid that it literally broke the team apart after many arguments and the community having the same issues and deeming them unsolvable.

The answer that Unity gave was "our bad, please wait for next update" and that is when the waiting game began for them to work on a usable system for lightmapping and in the end it never came with enlighten as enlighten was too rigid to work with anything but super realistic lighting and still has its own set of issues even right now.

Some years later Unity 5.6 came out with PowerVR or now known as the experimental light mapper. I beta tested this and was fairly pleased with it's initial abilities which were a good blend between enlighten and beast. It had some limitations like no transparent baking and after half an hour of use it ran out of memory but it was a good sign overall of what was to come. So I waited again for another 2 years and now the result as mentioned in my recent comments above we have is barely any better than that of 2 years ago and now is totally unusable for me since it runs out of memory on basic cubes and primitives in my scene now!

So basically my issue here is I am constantly "waiting" for the team at Unity to fix everything and get it into a usable state but this waiting time is time I am losing money on being unable to use key features or paying for things in the asset store that only partly fit the bill or flat out just don't work as an alternative. That's a LOT of time and money lost.

So seeing as it's been like 5 years since Unity 4.6 you can imagine how I might feel my trust in the lightmapping side has gone sour. The good news is that in that time they have come out with many other features not related that seem quite useful and I have found some very good real time settings that I found through lots of testing and they give the perfect blend between quality and performance that render the need for lightmapping no longer necessary.

So that's my summarized story for you. If the lightmapping system works for you then use it but if you are like me and constantly encountering issues that stop production and put you into a state where you gotta delay and delay for those features to work then maybe don't put your money on this feature. It is after all the longest preview feature spanning like 2 years and it's not being given priority by Unity to finish it which tells you their goal does not sit here but elsewhere and real time lighting appears to be where it is with such major focus on it recently by them.

 

Although I do like where the progressive lightmapper is going, I do share SilverStorm's opinion with how all of this was managed. Lightmapping has been a nightmare since the beginning of Unity 5.x's release cycle, and it should never have been this way.

When Unity 5 was first released, Enlighten's implementation was obviously incomplete and had issues, and Unity needed more time and feedback to get it working properly. Users also needed time to adapt to Enlighten's system, and documentation was limited. This is expected with new/experimental features, and that was fine. But the problem was the complete disregard for contingency. Instead of keeping Beast as a legacy feature/fallback for baked GI, it was completely thrown out, and users were required to make do with what they had, assuming they could even get it to work or understand it. Upgrading to Enlighten should have been a transition, not a switch.

And there was the pace in which Enlighten issues were fixed. I recall it taking three major releases of Unity 5 (almost a year) before light probes finally worked with baked GI. As for mixed lighting: Directional Specular mode was the precursor to this, but it never worked properly, and it seemed like Unity struggled to figure it out. It was swept under the rug when mixed light modes was finally released after two years. I understand it takes time and hard work to develop software, but a lot of this tells me there was some poor planning involved.

Enlighten's baked GI is much better today, and I use it in many projects now, but it still has its flaws (no gamma support, light cookies aren't supported, and LODs depend on light probes for baked GI, which is a silly concept, and enabling final gather breaks it anyway).

I can only guess Beast was removed because it wasn't compatible, cost too much to maintain, or there was some conflict of interest when using Enlighten and Beast together. In an ideal world, it should've been kept until the end of 5.x release cycle, or once Enlighten's baked GI had reached parity and stability.

 

I'm going agree with these statements. I think the Beast removal was some kind of situation with the licensing with Autodesk. I did find this very interesting: https://en.wikipedia.org/wiki/Autodesk_Gameware

Especially this line in the wiki: "The Beast API is a programming interface designed to make it as easy as possible to create a Beast integration with any game engine."

So if that is true and they've discontinued it, is it possible someone can pick this system up and integrate a version of it in Unity today?

 

Beast sucks too. I remember testing it for something I saw in this thread, and it wasn't bouncing the light properly.

 

I didn't mean to instigate any mudslinging on the Unity Lighting team, I was legitimately interested in difficult features or bug-related issues. That said, PLM - and Enlighten for that matter - are leagues of ahead of earlier versions, which is something Unity can be proud of.

I still don't understand, however, what is the difference in the shader model or light gathering operations in Unity that results in such qualitatively different results from Unreal, in terms of baked reflections; a la Directional Specular.

 

A bit off topic but just for clarification !

Do you mean that you do not really like how the reflection probes ( no matter real time or baked ) contribute to the material surface and final pixel color !?
If so, i guess this shouldn't be having anything to do with the light mappers but is more of about how the colors sampled form reflection probes are added to the final color which describes the surface !

Not sure if you are meaning this but if so, i found it weird as well, like reflection probes make a surface looking like it is coated with some transparent layer of white jelly especially in the Standard (Metallic) workflow. You can not simply create a surface to look like a metal in unreal.

However i find the new Metal/Roughness workflow in 2017.2 MUCH MUCH nicer. It reacts on reflections much nicer and surfaces look much closer to how they look in unreal ! I would recommend yo any one how haven't to try them.
I am not using anymore metal/smoothness sharedrs !

 

Hello,

My team has recently moved from Unity 2017.2 to 2017.4.1f1, and lightmapping has since become extremely slow. Both Enlighten and Progressive have drastically increased their times, and Progressive in particular gives me very low-res images, regardless of what I do. I've been the whole week trying different configurations, and it's... stressing, to be honest.

Everytime we update to a new release, I do some tests with lighting, so I have an approximate idea of how much time it usually takes. I'm working on a relatively simple scene right now, so with Progressive on low resolution (around 2 texels on everything), it usually takes no more than five minutes. That hasn't changed much... but when I increase the texel resolution now (around 20-30), it ends up taking an hour or two, while giving the exact same pixelated and jaggy result.

Two hours to make some sharp and nice lightmaps? Yeah, I'd take that. But, using that time to make exactly the same? I'm lost. I've tried many things, and nothing seems to work. Well, there's one thing in particular I can't try: going above 1024px. If I do that, it'll just run out of memory and get stuck in a loop, skipping jobs forever.

After three days doing tests on Progressive without any good result, I decided to go back to Enlighten, and the experience is being even worse. At this moment, Unity has been for two days baking lightmaps in a scene that usually takes less than a couple of hours, and I doubt it'll finish today. Right now, it's on "7/11 Light Transport 64", but clustering took several hours yesterday. Also, it's using 2 texels on both indirect and direct, because I always bake first with low values in Auto mode, and start increasing them once the colors and lights are as I wish. It's quite strange to me that it's taking so long now.

Is anyone else experiencing this? Am I missing something important, or is just broken?

Thank you.

 

Likely most of the users !
I will tell you what am i doing and i find it ok while i learned to not be targeting high quality lighting using Unity !
In some previous version the team has changed the way the lightmaps are getting queued for better memory management. What i find as a good saving feature is the "filter" - denoiser. I am currently having directional samples set to 4-8 and indirectional around 32 using automatic filtering. This way you iterate much faster through objects and rely on the denoiser to clean up the lightmaps. I am getting good results - well still very often "out of memory" errors but it is not useful to me in other way !

Having proper UVs and scaling is crucial for acceptable lightmaps - at least in my opinion !

 

Thank you for your answer, although the Auto filter seems even more broken for me, because the result is very very noisy. I have to use Advanced and pump the values up to 5 with the Gaussian filter. The result is still kinda noisy, but it's blurry noise (sigh).

On the other hand, having good UVs is not exactly what I was hoping for. We're doing a flat-poly game, and this style was chosen precisely to avoid most of UV and texture related work, since I'm doing 99% of the art by myself. What I do in my models for the scenery is dividing them into different meshes taking into account where the camera will be able to look. Then, I just have to use a proper scale value for the lightmap parameters on each mesh (lower for backgrounds, higher for close props, etc), and let Unity do the rest.

I've already done over 70% of the game's content, but the lightmaps were not final yet on any level. If I have to unwrap the entire game now, I'm going to need some medication.