Official Progressive CPU Lightmapper

Excellent! This is looking very good. I spent an evening just enjoying moving lights around, watching the update and doing full bakes that took only 20 minutes.

Only complaint is that it was a bit of a downer going back to work the next day, where we use A Different Engine with a classical lightmapper. Workflow as follows:
1. Adjust light.
2. Wait five minutes for lowest quality bake of the whole scene to get an impression.
3. Adjust light again, because it was still off.
4. Wait again.
5. Adjust again.
6. Wait again.
7. Run out of patience and accept a "almost close enough" solution, other tasks need doing.
8. Wait for day to end to start a two hour production quality bake.

Progressive Lightmapper == Gamechanger.

 

It really does ruin you for other lightmappers. How often do you get an increase in both quality AND speed?

 

Transparency doesn't quite work how I would expect, say a cube intersecting another cube with the one being transparent say with railings texture that is strips of 100% and 0% opaque. It ends up causing either very dark intersection or worse lots of back face culling glitches if the transparent object has exposed back faces

Below with solid cubes


Marking the meshes as transparent in the gi settings makes no difference either.

below with planes with exposed back faces:

 

Ok thanks, setting threshold to 0 on the wall is a work around sure, it only has a slight darkening then ( no AO on either )

0 alpha shows darkening:

 

Gets a bit weird still with shadowed areas:

 

Just all green, just using Unity primitive cubes and planes

The baked lightmap view shows them as opaque also:

 

if I give them matching back faces it makes no difference

And below I made it even more transparent to be more obvious:

Look as if it is opaque to indirect light and only transparent to direct light

 

Looks opaque to this emissive object:

 

Really impresive the new features of the lightmapper. Two question

Could we use real falloff for the lights?
Could we have a different emission power for the GI?

 

Hello,

I was wondering if there was going to be any plans to implement a directional specular-like system into the progessive lightmapper that is fully baked? Are we going to be forced to always have a realtime light in scene in order to get specularity? We are working on a VR game, so naturally we don't want to have realtime lights when they aren't needed. Our team has been happy with the results of directional specular (even with its quirks) and losing all of its functionality going forward is a giant regression in visual quality for us.

I've tested out some of the beta here - but it still lacks the basic functionality of baked directional-specular from 5.4 and earlier. I'm currently stuck now at how to proceed, since my team is being forced to upgrade to Unity 5.5 for other bug fixes needed in that version, but if I have to rebake lighting, I will be unable to. Deprecating directional specular in 5.5 but NOT implementing an alternative solution has really been frustrating and a bit of a blocker for our team.

If anyone has additional information, I'd love to hear. Thanks so much.

tl;dr
have VR game, forward rendering, lightmaps - losing directional specular 5.5 and beyond regresses game visually (no baked in spec highlights), no apparent replacement? Help please! Thank you!

 

Not sure if it's been pointed out but my scene still takes up around 3GB when the scene is baking. When the bake is finished it still remains at about 2.8 GB.

Also Alpha/Transparency baking still doesn't work, it seems the alpha issue and the mem issue still persist. Futher baking tests show that the mem usage is now 5GB.

Also sorry to ask but where did the option to turn lightmaps off temporarily go?

 

Unity and @Jesper-Mortensen -- please can we get a reply on this point? For us VR developers this is a big deal and we need to understand what is happening.

Thanks!

// WildStyle

 

I was talking about to have two GI values, one for the GI and other for the shader emission.

Thanks for the work!!

 

Any word on my post earlier?

 

Any info if this will be fixed before final?

At the moment I can't figure a way how to fix architectural type lights where the actual lights are usually inside the light mesh. With the progressive lightmapper the light stops inside the mesh ignoring the backface type and everything is dark either cause of the mesh or it casts the mesh as a shadow. I was originally thinking unchecking cast shadows would solve the issue if it would be supported. With enlighten everything works as expected which makes it hard to upgrade older projects to use progressive lightmapper.

Simplest test case to this is to add a plane, sphere and put a point light inside sphere.

 

Please don't forget GPU rendering

 

I get one error when baking with progressive

OpenRL reported error code 502: OpenRL error occured: RL_INVALID_OPERATION: Too many output rays emitted from frame program 'ProbeBakeFrameShader'. (rl_OutputRayCount = 1725)

Any idea how I can prevent this?

 

And why is the resulting texture coverage so unoptimised?

There is a lot of empty space, any way I can optimise this with settings?

 

Using 5.6f1, Terrain trees don't seem to be casting shadows into the terrain lightmap, and the billboard trees are very bright, switching to very dark when converting into a mesh tree.

Are these things going to be fixed?

 

Crashes for me when I press bake. Here's the call stack:
> mono.dll!get_hazardous_pointer(void * volatile * pp, MonoThreadHazardPointers * hp, int hazard_index) Line 293 C
mono.dll!mono_jit_info_table_find(_MonoDomain * domain, char * addr) Line 396 C
mono.dll!mono_sigfpe_signal_handler(int _dummy, _EXCEPTION_POINTERS * info, void * context) Line 4952 C
mono.dll!seh_vectored_exception_handler(_EXCEPTION_POINTERS * ep) Line 214 C
[External Code]

EDIT:

I set the lightmap resolution to 4 texels per unit instead of 5 and it stopped crashing. I don't know why it was set to 5.

EDIT2:
Not only do the results look much better, it has also reduced my bake times (for a test bake) from over an hour to only a minute. Great job guys!

 

Hi Jesper,

Thanks so much for taking the time to answer. I still do have a couple questions/concerns though - while yes of course we are utilizing reflection probes, SSR is not an option at this time for VR, nor is it forward rendering compatible. I understand too you guys are working on those tools - I do hope you're keeping VR in mind, as many trick normally used in a non-VR game just aren't an option in VR (realtime lights with realtime shadows, SSR, SSAO, most camera/post-processing effects in general...).

Is Unity taking strides for VR optimized content like that? For many of us working in VR, what would be a proper workflow? Of course VR still being a new technology so nothing is standardized yet, but what with all the developers using Unity as their engine for VR creation, I would hope there's some desire on Unity's part to help improve these areas. And while I don't doubt Unity is making strides for VR, it's sometimes difficult to know from an outsider's development perspective.

Thanks again. Looking forward to all the improvements.

 

If this is the case what about when your poly count exceeds the maximum and gets split into multiple meshes? I'm still using 5.5 but I literally had to chop my mesh into almost 10 parts, because if I didn't it would do it anyways except be all over in random places.

I would also like to say I want to thank you and the rest of the Unity team for all your hard work. i've seen too many people here tell staff "Well maybe you should hire more people", and "Really? More releases with an untested bug?", and just plain rude things like that. It infuriates me to hear their arrogant self-entitled orders. They need to realize how much work there really is to make an engine, and that its hard to test everything corner of it. The only real possible way to find some bugs is put it out there for the community to find. Hah sorry, and thanks again! </endRant>

 

Create a new lightmap parameters and set Backface Tolerance to 0.4 or 0. It should solves black holes problem

 

Is Mixed Lighting Mode supported yet for the Progressive Lightmapper?

I'm using Mixed mode in my scene, but no realtime lighting or or shadows on my realtime objects.

 

Can you post your lightmapping settings? Mixed mode works for me.

 

Mixed mode is not working for me either in 5.6.0f2. I don't know if it's not enabled, it's broken or I'm doing something wrong.

 

I believe Mixed Mode still not available in f2 using the Progressive Lightmapper. But judging by the release notes:

• GI: Progressive Lightmapper (Preview): Lighting Modes are not supported (coming soon).

Should be available post 5.6...

 

With the progresssive lightmapper? Mixed mode works fine for me with the Enlighten lightmapper. But if I rebake with Progressive, it doens't work.

 

Yes, with the progressive lightmapper. The wooden tiles are dynamic, the rest is all statically baked with the progressive lightmapper.

 

Can you clarify this a bit? In realtime mesh formats, a vertex can't hold more than one normal and more than one same-channel UV coord. By "watertight welded meshes", did you mean ensuring that meshes don't have gaps in surfaces (with seams made up by exactly identical vertex positions being fine), or did you mean ensuring that meshes don't use any seams at all? Welding usually refers to merging any similarly positioned or position-matching vertices. If it's the latter, that would mean that lightmapper is unable to work with hard edges (split vertices with duplicate positions but different normals) and UV edges (split vertices with duplicate positions but different UVs), so I'm probably misunderstanding what you meant by "welding". Archviz and environment art typically involves using enormous number of hard edges and UV seams, hence my interest.