Official Progressive CPU Lightmapper

From what I can tell, the Baked Tag option will still try to atlas UV pages from meshes with the same tag, is that correct? I want no atlasing whatsoever.

So let's say I have two meshes that are atlased on to one UV page (with UV islands mixed together on one page), I want to be able to bake that one page (one lightmap) without Unity trying to re-atlas the UVs for me.

Both meshes will have atlas offset values of [0,0], atlas tiling values of [1,1], and be assigned to lightmap slot 0.

Is this possible?

 

hmm in 2017.2 if we edit lightprobe and trying to rebake the lightprobe it ended up rebake the whole lightmap data. This behaviour will be changed right?

 

5.6.4 arrives and... nothing. Pretty please, this is killing me here. In retrospect, I could have burned the hours away using Enlighten, but I /really/ need Mixed Mode lighting to be able to ship several games now. They're just sitting there, dying for the performance boost.

 

@Jesper-Mortensen i'm getting spammed by this error when baking using Progressive in 2017.2

Code (csharp):

1.  
2. [PathTracer] AddInstanceProperties job with hash: cf9a3334dabff570af4b20a4c39262c1 failed with exit code 5.
3.  

while the baking itself are completed just fine, i'm mostly curious what are those error

 

Can someone tell me how stitch seams work with baking lightmaps?

It seems from a few tests that it is using the albedo UV for stitching as opposed to the lightmap UV2.

Basically, we are getting seams along the colour UV map borders which do not exist in the lightmap uv.


We have double checked the charts in the object maps tab and the mesh is using the correct UV for baking.

Was just wondering if this is intended or if I should bug it.

 

I am really looking forward to the gpu powered progressive lightmapper. Is there any progress on this? What's the status?

 

Yes GPU support would speed things up a lot

 

@kemalakay Is this possible with the Progressive Lightmapper?

 

I don't think you can do it with 2 meshes as there is no guarantee which baked tag your mesh will be put in.

However, you can sort of do it with one mesh if you combine them.

 

I've tried combining into one mesh in the past, but because it still went through the atlasing process, the UVs were scaled just very slightly, and it was enough to ruin the alignment of the lightmap to the UV shells (especially in large scenes). Combining is not an option for us at the moment anyway.

 

Ah ok - If you can combine the meshes...... You can create the lightmap UV2 in an external software, which is packed to the full boundary limit, then set the lightmap parameters in the mesh renderer scale to larger than the object size allows. This normally maximises the UV to a full map/tag

Padding doesn't change in a premade lightmap UV (but to be honest I have never compared texel to texel) - I have just noticed that increased padding in the lightmap settings does not affect a premade uv (unless this is a bug).

but as you said, even if this works, it probably wouldn't help anyway if you can't combine

 

I wonder if i get threadripper 16 core 32 thread will make baking faster. Will progressive lightmapper utilize it at its fullest? Or should i wait for much more needed gpu support?

 

Honestly i would go with the Threadripper and i guess 32 threads would be supported ( 100% utilization ) !

It is pretty easy to utilize any device at 100% in path tracing.

 

You might be right, I haven't checked recently. When I tried that a while ago it would always add a tiny bit of padding (or maybe it was just precision weirdness) around the edge.

But yeah, we can't combine anyway so that option is out. I suppose I could find a way to temporarily combine all meshes in to a new 'bake mesh', do the above process, then apply back to the uncombined meshes, but I'm not going to do that because it's way too faffy.

 

I've just tried 2017.2 and lightmap push/pull dilation seems to have broken for me.

In 5.6.1 my lightmaps look correct (push/pull dilation working), but when I load the same lightmap in 2017.2 there is no push/pull dilation. Which is curious because it seems to do the opposite of what the feature suggests! Any ideas?

5.6.1


2017.2

 

Wow.. I could be wrong, but it's November 2017 and we still don't have support for the shadowmask for progressive lightmapper.

What's the status with this? Any ETA?

I am using 2017.2 and if this is only going to be supported on 2017.3, please let us know.
I just read that filtering on shadow is not working, is it still the case?

 

Hello guys,
About the issue: https://issuetracker.unity3d.com/issues/progressive-lightmapper-ignoring-lights-in-a-larger-scene
KEMALAKAY said that it will be backported to 5.6 a month ago. It still on the roadmap? We should expect that for the next patch release?

 

Hello,
An update on back-porting this fix to 5.6 would be much appreciated. The above issue is slowing down the workflow in our Studio since we use baked emissive materials to light our scenes as a workaround. This unfortunately gives us very noisy bakes that take a lot of samples to resolve.
Thanks!

 

Paging Unity staff, Unity staff to the thread.

 

Mixed light support is coming?
Fast light bakes .. Happy, happy.

Add this after the above:
May goodness this is very good.

 

Don't know if this is asked before.



The green box is exported with one smoothing group + normal map, and the blue box has split smoothing groups.
There isn't any problem for the green box when baking with enlighten.
It seems to me progressive only uses vertex normals for path tracing. or at least with my setup.


The green box looks fine with enlighten.

Dont' know if i am doing anything wrong, please help.

 

+1 waiting for the fix of the following bug to be backported to 5.6.4!
https://issuetracker.unity3d.com/issues/progressive-lightmapper-ignoring-lights-in-a-larger-scene

It's really slowing us down, we just aren't able to ship updates with new lightmaps without it. Any news or estimates for that?

 

Just upgraded to 2017.2.0f3, had some issues with Enlighten so moved to Progressive.

Is it meant to eat through 20gb of RAM like candy? My system ends up completely unusable during a bake and for some time after it (as Unity still has a hold on that RAM after the bake is long done). Is there a patch out that fixes the memory leak?

 

I'm using the Progressive Lightmapper in 2017.3 beta. Everything is working well but wondering about a feature.

I have several object that are marked as not casting shadows. However they still seem to block indirect light in the bake causing dark areas under them.

Lightmap parameters for transparent appear to only work for real time GI. Is it possible to have objects not block GI rays, either through a shader or other setup on the meshrenderer?

Thanks

 

+1

 

Patch 5.6.4p4
Released: 7 December 2017

No mention of the progressive lightmapper here. For god's sake, how do you get an actual unity dev to pay attention to the other part of their job? It's not just 'programming', it's also 'keeping your customers informed as to what's going on'

 

https://issuetracker.unity3d.com/issues/progressive-lightmapper-ignoring-lights-in-a-larger-scene
Annoyingly, the issue has been 'fixed' since early October. But it is only available in a BETA version of Unity 2017.3...

In such situation I find it difficult to understand why it's flagged as 'fixed' on the Issue Tracker, especially since it has not yet been ported to any stable Unity version.

Many patch releases were deployed since the 'fix' so it unfortunately looks like the backport of it has been neglected.

 

Yes yes yes yes yes. Honestly, I do wish that GPU support had been top priority from the start - I don't think anyone would be saying "Gee I sure wish I could bake this lightmap at a 10th of the speed on my CPU!" if GPU baking had been the only thing supported by Progressive.

But hey, it's on the way, and that's what matters. I look forward to not waiting 2 hours for a bake.

 

Can you explain Unity's level of prioritization of the Progressive Lightmapper in light of the evolving(?) OTOY integration? It seems these two options, while different, would both converge on a GPU-based lightmapper, but with different levels of integration within Unity and quality. In essence, which is the most future-proof option for Unity developers?

 

I have a Nvidia 1080 ti with 11 GB memory on the GPU,
love to see a beta version with GPU support

I have it running with Nvidia webdrivers, on a MacBook Pro 2016 video card external via e-gpu thunderbolt 3.

Any one with a serious need for lightmapping is more than likely to invest a GPU that is up to speed and has the memory.

Please don't forget the Mac even if it's only 2 percent of unity users, thanks
( Otoy did say that a Mac version will be made only after they made the pc version )

 

Damn, I need a new graphics card

 

Has that really made in 2017.3? Is it in the current betas/RCs? The release notes for the RC don't mention it.

 

Hello everybody,

I've made a thread about artifacts with Enlighten, but nobody replied there.

The problem is, when I try to bake my shadows with Enlighten, I get artifacts, where objects are intersecting, AO is disabled (image_1 and image_2). There're no artifacts using Progressive Lightmapper (image_3 and image_4), but I need Mixed Lighting, which doesn't work with PLM. It looks like Enlighten doesn't blur the shadows, or lightmap anti-aliasing is not working. I have tried everything in the lightmap settings. I've played around with the Lightmap Parameters, still nothing. This is a test scene, with default cube primitives. Using Unity 2017.2.0 (updated to 2017.2.1f1 - same artifacts). Do you have any advice, how this can be fixed?

Thanks!

 

So enlighten won't be fixed, and progressive lightmapper is the future, right?

 

Cool!

I think you should make sure your fixes are in the release notes. I also noticed that the packing improved (yay!) in 2017.3 and again there's nothing in the release notes. There were also similar issues in the past (in fact I think when the progressive lightmapper first got into a public Unity beta release the release notes again, mentioned nothing).

I sometimes find workarounds (for example, I was having glass surfaces as not lm static, since indirect transparency wasn't handled correctly) and I may not notice when a fix for something is in. I do read the release notes quite diligently, so I think it's super important that all your fixes are in there.

 

Is it eventually feasible to use the Enlighten realtime GI with the progressive lightmapper?

 

that is what light modes support(?)

 

@Jesper-Mortensen
Is it possible to acces the A-Trous filter via api?

Or will you be able to create ipa acces to the filter?

Thanks

 

To able to use the filter for a custom lightmapper, to filter / cleanup the results of the render on a texture.
So yes switching to the A-Trous filter via script.