Official Progressive CPU Lightmapper

haha, of course..Im still stuck in 'enlighten' bake mode

Nice one, thx

 

That grass(!!!) This is outstanding work, truly breathtaking. Please can we get a breakdown of this project from someone, at least the artists names?

 

That was...

Amazing!

I'm guessing it's from the internal team led by Veselin Efremov, right? It looks like it. (please don't give spinoffs to Oats this time )

 

Megascans ftw

 

looks awesome!

 

@Jesper-Mortensen It looks fantastic. What was PLM eventually used for, baked shadows? It's just I see the light update so I assume it's a mixed mode lighting. How long did a typical PLM resolve in?

 

I really can not imagine a Lightmapping to be used in such scenario !
Was it actually !?

I guess it is only custom shaders and post processing may be !?

P.S. or it is not a real time at all !?

P.S. sorry, i missed the post where is says it shows a good use of the Progressive Lightmapper - so Congrats - it's looking so realistic !!!

But is this actually a real time footage or it is pre-baked into a video !?

 

I'm ignorant as to what this is

 

I really doubt this is a real time or the actual 3D area is too wide ! I wonder as well how is this achieved and what the "custom bake feature" is !

 

I'm guessing it's this (from the beta release notes)

(I have no idea how to use it though)

 

Right yeah, I think I'll be having a scoop of that on my plate.

 

I would like to share my concerns about the Progressive Lightmapper's shadowmasks, too. Something is going wrong somewhere in the baking process, and it's breaking things like soft shadows and the baked shadow radius setting.

Here's a comparison between Enlighten and Progressive, both using default settings:


I hope a fix can be provided soon. I understand it's a preview feature and work still needs to be done on it, but the Progressive Lightmapper is already far superior to Enlighten's baking solution, and this shadowmask problem is the final barrier to overcome before we can use it in our projects.

EDIT: Whoops! I tested the project in 2018.1 beta2 and Progressive Lightmapper shadowmakss work flawlessly! Thank you for your hard work. I hope this can be backported to Unity 2017.3 soon.

 

I'm not sure why but I dont get this error anymore.
Sorry, not really helping here but I'm glad the error is gone

 

My pleasure I love the progressive lightmapper so far, so the quicker issues get solved, the better Are you also addressing the bugged seams in the new unwrapper version (some seams are created on smooth areas with low angles)?

 

Hello!
We are using 2017.3.0p2 and Progressive Lightmapper with shadowmasks.

We baked light and got that shadowmask.
Where can these strange red lines in shadowmask of terrains come from?

 

any ETA??? since the last time you said that 5.6.5 has been released and 5.6.5p1 too but none of these versions support Mixed Lighting Mode with PLM

 

so how's the GPU support coming along?

 

Hi, a quick question, is it possible to play around with the sky occlusion experimental API !
If it eventually available in v2018.1 b5 !?

Thanks !

 

i think @robert was planning to create a sample repo for that one

 

Hi.

May be i I will find solution here. I want use mixed lighting - precomputed GI and Progressive lightmapper.

If i bake only precomputed GI, my dynamic objects recived color from light probes:



But if i bake precomputed GI with PLM i have bug: after first play - light probes gives color, after next - only grayscale.
This is first enter to play mode:


And second enter to play mode without rebake or any changes:



Screen with very low resolution for reduced time bake, but with high value - nothing changes.

I am reproduced this in 5.6, 2017.2, 2017.3.

Why after second and other play, indirect color from lightprobes disapears?

It is only using PLM, with Enlighten all ok.

 

Hello,

Unity 2017.3.1 Mixed Lighting, Progressive Lightmapper with Lighting Mode Shadowmask still ugly, not accurate and jagged.
Is it possible to edit the shadowmask file outside Unity and reuse it ?

Thanks!

 

any news of that sky occlusion repo?

 

you can open the image in photoshop or gimp and resave. (in photoshop you need to use 'layer mask > from transparency) for the image to show up.

 

So can someone confirm the jagged shadows are still an issue? Also the filtering seems pretty bad, as you can see in the images, it basically wipes out the shadow lines..it feels like the lowest setting of 1, isnt small enough for lower resolution bakes.

The first image shows the nasty jagged lines without any filtering, and the second with lowest filter setting. ( i can get a nicer result passing a non filtered image through photoshop)



Also i have noticed that as the progressive map iterates, you can see the shadow line appearing, but it disappears in the second pass, as though the samples are being deleted due to some hidden noise threshold or something. (see next images)



This is unity 2017.3.0p4, win 10 on a real beefy xeon machine.

 

I've been working with the Progressive Lightmapper, but I've noticed something in the 2018.1.0b4 beta that I can't quite figure out. Unlike in previous versions of Unity, when I bake my lightmaps using the PLM, I get an additional piece of information in the "debug" area related to "Memory Usage":

(scroll down to the bottom of the pic)



How am I to interpret this? Is the lightmap data taking up 2.0MB or 210 MB? Or is it only taking up that amount of memory when it's calculating the lightmaps? What are some strategies for reducing this, or should I even concern myself with it? Is this related to this issue?

thanks for your guidance on this~!

=g

 

Is the issue of "Progressive lightmapper supports a maximum of 10000 instances" is fixed in new beta?

 

Hi thanks, will stay tuned for this... !

However may i suggest something which will be very useful in PLM. Can we have some control over threads used by PLM or priority etc. because it is somehow hard to navigate through scene when it bakes ( when doing a lot of test baking you decide to copy or move some objects while PLM is working ). if we can have at least one thread available in for editor it would be great because it gets unresponsive very often !

This is just an idea and you may have a better idea on how to free up some resources for flying around or do some edit while baking !

Thanks !

 

Sure GPU lightmapper is the most anticipated thing here. However some users will have to rely on the CPU baker because of the current hardware they use being not high end - like in my case !

Thanks again !

 

Hi, thanks for reply. Yeah the scene is pretty huge, basically the ground is around 220units big...and I'm constricted to a 4k map so for my scene anymore than 10 and it wont fit....I've just been told that the issue is a bug in this Unity 2017.3, however Unity 2018.1.0b8 has had a fix or improvement. I am increasing the samples to around 200 for final bake, however I dont know if im expected to push it higher for such a large surface, as the render times get silly if i do.

Also the direct samples is only needed if you are using soft shadows and baked shadow angle, apparently..i dont know if thats in the docs, but would be good if it was.

 

I'm playing with the experimental api stuff in beta 9 and I'm trying to see what I can do. I'm enjoying the amount of control. But.

Is .innerConeAngle supposed to work? (on spots, obviously)

I'm successfully setting up the delegate and I'm able to change around other stuff (the normal cone, switching falloff types, setting a different indirect color, etc), but innerConeAngle changes absolutely nothing it seems.

 

So I'm having this issue with no idea on how to fix it properly.

Baking my lighting with the Progressive Lightmapper produces these weird dark squares. The strange part is, the more that the lightmapper does it's thing, the more the "artifacts" become visible:




These are the settings used for this bake (with one mixed directional light):


Increasing the resolution to something like 100 makes the squares smaller, but does not eliminate them. Same thing with samples, bumping them up to 60 direct / 1000 indirect / 4 bounces doesn't help.

During the bake, the dark parts sometimes disappear and reappear, but they are always present in the end. The ground is a custom circular mesh about 30 units across (the area visible in the screenshots is around 7-10 units).

The resolution also seems fine:



Switching to Enlighten however, makes the artifacts go away.

Any ideas?

 

Can someone provide a technical explanation for why the curvature of normal maps is destroyed for baked lighting but not realtime lighting?

 

Start a new bake and switch the scene view to the Texel Validity view. Is it full of red? If it is, create new lightmap parameters, and switch the backface tolerance value to 0 and see if that fixes things.