Official Progressive CPU Lightmapper

Jagged shadows with the new Progressive Lightmapper - Unity 2017.3, Shadowmask mode is set to Shadowmask. Enlighten(2017.2) vs Progressive(2017.3) (image_1, image_2). How can I make them soft like Enlighten?



I've played around with Filtering - Direct Filter, if its set to max, the shadows are softer, but not accurate, if its set to min, the shadows are more accurate but jagged (image_3, image_4). Any advice?



Thanks!

 

Hi Jesper,

You replied this comment to me back in the beginning of April this year in regards to deprecating Directional Specular, and while I tried utilizing your advise here (and in previous comments as well), unfortunately we're finding that having a realtime light JUST for specular highlight purposes is not a viable solution, especially on performance. I understand that directional specular in previous releases was also expensive, hard to manage, and had lots of artifacts, but at least it processed all baked lighting into just one draw call and without additional shaded passes. The additional cost incurred with the new system isn't worth it for our purposes, and it's really frustrating losing visual quality that we had previously in 5.4 and before. Mixed lights don't solve this problem. Reflection probes aren't enough. And SSR is deferred only - not an option for forward rendering VR.

I have seen other posts also struggling with VR and Directional Specular being deprecated, but absolutely no response or indication of what's coming down the pipeline for VR. Is there still a plan for cheaper alternative specular? I don't see anything on the Unity roadmap to indicate this. None of the new lighting modes provide the same visual quality we had before in 5.4, and all the new lighting modes incur a bigger cost once a realtime light is added. This just isn't an option for many VR developers.

What are we in VR to do? Feeling very left behind by Unity here.

Thanks for your time.

 

I've always assumed that Unity Technologies developers were aware of the feature set inside other prominent game engines (e.g. UE4, CryEngine, Source, Godot, etc.) and used that knowledge to keep Unity competitive with respect to the larger ecosystem(?) UE4 has an excellent lightmapping solution (Lightmass) that resolves the GI equation using photon mapping, resulting in bakes that contain very detailed lighting. Currently, the best solution to achieve accurate reflections for a statically lit scene in Unity is to use a combination of reflection probes, SSR, and mixed lighting - this is not entirely cumbersome, but much more complicated than simply dragging a reflection capture actor into a scene and baking out a lightmap. This is not meant to be snarky, or a dig at Unity, but there is a reason why professional archviz projects are developed in UE4: it's not because of the shader model, or auto-LOD's, or UV stitching, or w/e - it's because of the lightmapping options and the level of fidelity that can be achieved. I feel like Unity has just recently met parity with Lightmass by way of the Progressive Lightmapper, but reflections are still an issue.

This is a WIP hallway for a VR project using PLM with several box projected reflection probes (forward, MSAA, HDR; no SSR). The scene is lit entirely with area lights and realtime emissive materials to produce ground reflections. Although the following comment is unrelated to what I've posted above, I cannot determine why the reflections fade as the camera completes it's trajectory(?) I would assume that if a reflection probe were present - and it is - then reflections should also be present. Instead, you can see the walls and ground become completely flat.

 

(we're getting slightly off-topic, but doesn't Unreal more or less use a similar system for reflections? (by which I mean, reflection probes + SSR))

 

Right, I have no interest in commenting on Unreal beyond what I've already mentioned, but yes, Unreal does use reflection capture actors (box or sphere) and SSR; same as Unity. Scenes often look just fine without SSR, sometimes better due to temporal dithering artifacts. Again, my comment was not meant to be inflammatory despite its tone, and I do not mean to instigate another UE4 vs. Unity tangent.

EDIT: I thought it was important to note in light of the Directional Specular comments above, which are obviously related to lightmapping.

 

I just wanted some clarification. So let's leave unreal out of this.

What is missing from Unity's reflection systems? I think probes+SSR generally works quite well (of course it has limitations inherent to the methods, but that's the methods) and is generally a quite popular method with other engines as well.

By the way, I saw your video. I'm not 100% sure I understand the issue, but my best guess is that you'd like to see the doors at the end get reflected as well as the camera gets closer to end of the hallway?

I think it's because the reflection probe is quite stretched, and I'm guessing the center of it is somewhere near the middle, so the probe doesn't really see those doors that well. Plus since it's stretched, there isn't enough resolution either (since the middle is pretty far from the end of the corridor).

 

@Jesper-Mortensen

These look interesting :
https://docs.unity3d.com/ScriptReference/Rendering.GraphicsSettings-lightsUseLinearIntensity.html
https://docs.unity3d.com/ScriptReference/Rendering.GraphicsSettings-lightsUseColorTemperature.html

May I ask why they are never on by default? I mean I get it for upgraded projects and 2D, but why are they still false for new projects?

 

Thank you for showing this, very excited about the GPU lightmapper!

 

I think its just because of freshnel effect.

 

While the techniques may be similar, the implementation is clearly different, leading to visually distinct outcomes.

Regarding the reflections, I would've assumed the same, but actually the hallway is lined with a series of adjacent box projected reflection probes that are all regular in shape (cuboid). I'm not actually looking for a solution here, merely pointing out a non-obvious issue that arises for me.

 

Did you check, what's wrong with the PLM. I've updated to 2017.3.0p1, but its the same.

 

Very interesting! Where can I follow this up ? Any threads?

 

When could we expect Skinned Mesh Renderers to be supported for baking? A few months ago I was assured that 2017.2 or 2017.3 would support them, but I've just updated to 2017.3, and it doesn't

 

Uh, I'm sure you would, but I paid a minor fortune for several users for Unity 5.x - are you telling me, with this post, that 5.6 is being abandoned with a half-finished progressive light mapper?

 

latest stable can also mean 5.6 latest patch.

 

Is baking light cookies coming at some point? I don't see it on the roadmap.

 

baking light cookies should be standard for a lightmapper.

 

@Jesper-Mortensen Is there a development roadmap for the GPU accelerated PLM that we can follow?

 

Hey @danix,
to improve the quality of the shadows while keeping the details (accuracy) you can generally increase the "Anti-aliasing Samples" option in Lightmap Parameters. You can assign a new Lightmap Parameters asset just to the surfaces receiving shadows where you care about increased quality or set it for the entire scene, but please note that this increases the memory usage of the lightmapper during the bake (but of course doesn't affect the runtime).

Since this value translates to a supersampling multiplier in the lightmapper, only values 1, 4 and 16 give distinct results (1x, 2x and 4x supersampling respectively), the other ones simply clamp to one of those.

I can see in your screenshots that you've used the value 16 already, but currently there is a regression in hashing Lightmap Parameters, so to make sure you see the results of your changes you will unfortunately need to save your scene, open a new scene (CTRL+N) and then switch back to your original scene. This issue has been fixed and the fix will land in all the affected versions.

Also please note that currently to match Enlighten's default "Blur Radius" of 2 (from Lightmap Parameters) in the Progressive Lightmapper you'd need to set the "Direct Filter" to Gaussian with Radius of 1 in compositing settings in the Lighting window.

 

Hey,
Thanks for your advice and help. Waiting for the next updates and fixes!

 

@Kuba in the video for radeon reys PLM, it goes black between each change which is quite distracting and disturbing to view so I would suggest:

• not clearing existing texture
• consider loading it by smallest mip first if possible

To reduce visual disruption, which I find really unsettling to look at, iteratively.

 

Yes I also found the black frame on refresh distracting, but i was so excited to see the GPU lightmapper in action that i did not want to say anything about it
Would be good if its smooth like in other interactive lightmappers

 

Will multiple GPU's be supported? ( at the same time )

 

Love it, all my concerns - vanished. Great work you and the team, thank you So when do we get our new tools?

 

how about releasing the version from the video right now on github so we don't need to wait a year to start experimenting with it?

 

Ok... so DOES it mean 5.6?

 

Hi,

Q1. For large scenes / environments etc, will we still need to split up geo to speed up the baking, as required with enlighten?

Q2. Are there any improvements with the UV placements with lightbaking? i.e will it pack them more efficiently?

thanks

 

A couple of my personal findings

Q1. The Progressive Lightmapper deals with large objects perfectly, no issues there.

Q2. Not sure about placement, but I noticed that the unwrapper creates UV seams where they shouldn't be. E. g. in the import settings I set the hard angle to be ~80 degrees, but it still creates a UV seam at some places with, say, 45 degree edges (where a UV seam is actually not necessary at all). I had to export some models with secondary UVs just to eliminate that.

There is, however, an option to fix the seams (the lightmapper then attemps to smooth out the pixel values on the "broken" seams), but that doesn't fully help with lower resolution lightmaps. And on one of the models it actually introduced very strange artifacts in shadowed areas – super saturated random colors around the seams.

 

Baking terrain tree shadows still seems to be extremely erratic with 2017.3. Since Enlighten just ignores terrain trees, you have to use the new PLM if you want trees to cast shadows.

First of all, it seems that you have to limit the number of trees to 10,000 for PLM to work at all.
Second, I found out through trial-and-error that for tree shadows to work, I had to mark the tree prefabs "lightmap static" (even though they get instanced / billboarded by the terrain system), and then set their scale in lightmap to 0:


Now, can anyone explain this behaviour?
This is the resulting terrain lightmap. Huge square dark areas -- it looks like the PLM just stops at some point, without further subdividing.

Changing the shadow mask mode, or the number of samples, bounces, filtering, etc. does not change anything. Neither does using directional vs. non-directional lightmaps.

 

I've been waiting for working mixed-mode support since about... Feb 2015 I think?

 

Hello,

Unity 2017.3.0p2, PLM shadows are still not accurate and jagged, Anti-aliasing Samples not working. Saving the scene and creating new one and switching back to the original one doesn't fix the regression in hashing Lightmap Parameters. It was mentioned above, that the bug is fixed, is the fix not included in the new 2017.3.0p2 version?

Thanks!

 

Hey,

I was adding some lightprobes and did a re-bake and I get these errors everytime I bake the scene


I'm on 2017.2.0p4
Can't really see anything wrong with the baking in general, should I be worried?

 

Will this cover use-cases like textured emissive surfaces? I often get into situations where I waste a lot of texels on emissive materials, not because I want detailed lightmapping on them, but because I want certain details on the textures to be taken account for lightmapping (for example an emissive material with a grid texture, if the texels are not enough, lines from the grid will be lost).

Ideally I should be able to set how they are represented when lightmapping and how they are actually lightmapped separately.

 

Thanks for reply..

But because the unwrapping doesnt recognise UV spaces inside objects (such as an oval racetrack) it wont pack anything into that space, so to avoid large wastage of UV space its still best to split certain types of geo. Is that correct? And if so is that something the improvements with take into account?

 

Or you could make your own uv channels that don’t have holes in them.