Official Progressive CPU Lightmapper

I'm assuming that includes any light with baked soft shadows, right? (because those are kinda noisy too and they never resolve)

 

Very cool feature, long time awaited !

A bug on negative scaled objects has been submitted : Case 877021 (posted screenshot on another post, Progressive vs Enlighten)

One suggestion : Indirect Resolution should be greyed out when using pure static baking with Progressive, since it has (if i'm correct) no influence at all in the new Progressive Lightmapper !

Keep up the good work !
Thanks

 

Also, it seems like the preview for the progressive lightmapper is clamped. I mean some overbright areas in the lightmap seem clamped while it's baking, but once it's done it seems they appear properly.

Is it a bug, or is it done for performance reasons?

 

Clamped means... clamped High brightness values are clamped. return clamp(color, 0, 2);

Example:

I have a VERY bright point light next to a wall.

Here is how it looks while it's baking:



Here is how it looks after it's finished:

 

I don't have any reflection probes no.

And it's not just baked direct, it's any light, it could be indirect if you somehow manage to get it really bright.

Baked Lightmap view looks "correct", since all the materials are white. It mostly happens when using dark materials.

To reproduce you need a really bright light source (more than "2"), and a dark material (darker than 128,128,128).

(I can make a repro, but it'll have to wait until tomorrow)

 

Wow... this progressive lightmapper is freaking sweet... and in my Sanctuary level, the lighting looks even...

 

Exciting stuff, I'm really looking forward to this. One issue so far: the light attenuation between dynamic and baked lights don't seem to match in the progressive lightmapper, baked lights always seem to be a bit brighter than dynamic lights, even when using linear colour space. When using Enlighten backend they are almost a perfect match (but only in linear colour space). This could become a problem because there will be visual discrepancies between static and dynamic lights, and I can see some users struggling to maintain consistent lighting in their scenes if they use mixed lighting modes. I've attached some screenshots for comparison:


It would be great if you could bring back the "Show Lightmap Resolution" toggle, for some reason it has disappeared in the 5.6 beta. It would be nice to turn off the checkerboard pattern so we can see the quality of our lightmap bakes.

 

I am truly liking that I can see my scene lighting in one spot before it is finished... but sometimes when you build a level, not everything is built in one whole piece. Is there a way I can implement a blocker mesh to keep the light from spilling through? Example, that harsh light on the roof? In reality, that would never happen like this...

 

I've just downloaded the Beta to try it for myself a little. Just with a probuilder test so far. But before I try to find the time to dig deeper into this I have to say:
So far the most useful thing about the progressive lightmapper has to be the ETA of the bake!
It's so great to actually see (and not only guess) how much a setting will influence the bake time. This makes prototyping so much easier and better, throughout. Can't wait for this feature to progress into a stable work version.

 

+1. And the fact that I can focus on ONE AREA where the camera is facing and bake that... the one thing I do ask is if we can try to revert to the pre-Enlighten behaviour of baking lightmaps to prefab... thus is extremely important especially for prefab heavy assets like UFE

 

I must to tell that the new progressive lightmapper is impressive. I have used the system in old scenes that was impossible to obtain a good solution with enlighten and now i see perfect all the assets. Really good work.

 

So far the progressive lightmapper is nothing short of impressive.

There is still one issue I would like to see addressed that made Enlighted completely unusable for my projects - the lack of lightmap dilution/padding. There is no reason to have any non-padded pixels on a lightmap.

The progressive lightmapper seems to generate some padding, but it is not nearly enough to avoid black lines when looking at surfaces from far away.

I hope this issue will be addressed.

 

I wish i'd found this forum earlier, spent ages trying to fix the negative scaling problem. So far i like the new lightbaker, gives you a much faster idea of what it's going to look like.

 

Kinda. When I do a standalone build for my game, all of the lighting is lost. In UFE, the levels are actually prefabs of your scene... when a standalone build is done you lose ALL of your lightmaps.

And I've used a similar script and that stuff doesn't work correctly

 

I'll test the scene and do a standalone build to see what happens

 

So it looks like it works in the standalone build...but only if I hit play. THANK YOU!! I've been trying to get this to work in 5.5 and it is very flaky. Hopefully, I will be able to use this with UFE once they update their toolset to work with this... And it is easy to set up... would it be possible to add an option to this for the Progressive Lightmapper?

 

is this the real life? is this just fantasy?

can we bake a scene in this beta and somehow use this bake info in the same identical scene in version 5.5

 

Is the 3000 object limit is a memory restriction at the moment?
Going forward will additional LOD's be considered part of the object limit if they are included in the bake data?

Many thanks for all your work on this guys, its a fantastic feature!

 

Does anyone know how to use blocker meshes with this? Trying to figure out how to stop the photons from leaking through? Thanks

 

No photons. This is a brute force method. So leaking is something else.

Try disabling filtering and see if that helps. If it doesn't, post an image, since I can't think of anything else without seeing the scene.

 

Taking a little more time with the progressive lightmapper, and I am still seeing the same issues I ran into before when using this... and I notice that light probed objects will stick out like a sore thumb...

Even with LPVs.




I may as well just stick to just using straight up light maps, just to keep the look consistent... Most of my levels will be small so it is not an issue. Will there be a way to fix this so that I will be able to use light probes on moving objects and it will look consistent?

 

It is probably because of the way I modelled my dojo level... in pieces... and sorry, I am used to using mentalray so photons always slip out lol...

Here is an image of what I am dealing with. Unless this is the actual behaviour of this, it is probably something I am doing.

I also don't have textures on my model since they are part of another scene in 5.5 and I don't feel like bloating my hard drive on the beta...

See that bright light on this corner? Unless this is intended behaviour, I shouldn't worry too much... my favourite part of this lightmapper... I can see how much time it will take... and the results are always consistent...

 

Hmmm, I can't really tell what is going on.

Do you use high multipliers for indirect? It kinda looks like it's bounced light from the floor outside?

 

My light intensity is 1.5 for the sunlight. In 5.5, I have Shoji screens covering the windows with a transmission shader... and I have no textures in this test

 

I set that indirect intensity to 4. Though I should dial that down in the final test, mainly because the room gets very dark unless I tone map.

And unfortunately, when I modeled the dojo, I approached it architecturally and have it in pieces.

 

I used that feature, and I saw a few bits of red that didn't bother me much... and also too my goal for this level is to simulate light coming from outside... it's an old dojo, like the scene from The Matrix, when Morpheus was fighting Neo... In Unity 5.5, the light is dialed down considerably and in its place, I am using tone mapping...

 

I gave it a shot today and we can't use it, as long as we don't have support for transparencies (which is on the roadmap, as I've read above).

What I noticed is, that most of our shaders need at least a recompile (change shader file, undo, save) in order to work.
Some didn't work at all ... the meshes just were invisible. Don't have anymore time left right now to try to fix them.

@Kuba You state, that the lightmapper will be flagged as experimental on release.
What does this mean in terms of enlighten lightmapping?
Will this remain in the build for the whole 5.6 life cycle?

With our current game project, we will be stuck with 5.6 for at least the next 1.5 years (due to the drop of Win 8 support after 5.6) and we need a 100% working lightmapping solution (which enlight right now would be).

 

Enlighten isn't going anywhere. You can pick which lightmapper to use.

 

One question about features.... which features we will see in the first release 5.6?

 

Does the system ignore the "cast shadow" property of a mesh?

 

great stuff! and while looking at shadows, perhaps you also can smooth filter the realtime shadows, as they are blocky.

 

This is amazing! The speed of iterating lighting is unbelievable. Good work!

I was searching around a bit and looking for one option, baking direct lighting into light probes? Is it currently supported?

 

Is it a known bug or by design that the progressive lightmapper completely ignores the cast shadows property of a mesh renderer? It works with Enlighten.