Progressive is missing areas, has glowing zones, bad coverage and... issues.

I'm working on photogrammetry assets, and its been going well. I'd been using Enlighten, since Progressive hasn't been working right since I first tried it in 2018. Now I've updated to the latest 2019.3.0 and Enlighten is gone. Now I'm wondering whether Unity is even capable of using my assets anymore---

Even in this small test scene, CPU predicts 6 hours and then gives up at some point in the night half way through. GPU is much faster (15 mins) and completes the job... or does it? That rock in the middle of the animated gif above is marked static and is taking lighting in a few blotches, but is otherwise getting skipped entirely. There are spots of missing indirect light everywhere else, especially in darker areas.



1 - shaded 2 - directionality 3 - lightmap 4 - UV islands

I don't know why that seam has a dark edge since the UVs are nice. The directionality sure looks like it has given up long before filling the UV island, and the indirect lightmap sure is blotchy just in general. Its like this everywhere.



Above you can see that the lightmap has plenty of resolution, but Progressive has created big fat squares without even trying to interpolate.



Just look at this-- Its bleeding between well spaced Islands. This is what it considers a completed map... Yikes.



I've boosted and doubled some numbers but nothing changes, really.



I've really cranked some of those sliders now and I don't see any improvement.



Here's a scene rendered with Enlighten. Enlighten worked fine. Whats wrong with Progressive?



Keep in mind this is a fresh, untouched install of 2019.3.0 and I get stuff like this? I have no idea whats going on with these errors-- How should I know what they mean? Google isn't helping much and frankly, how does a guy get errors like this on a fresh install? This is HDRP. I had a working demo scene with a work bench and stuff. Created a new scene. I have reflection probes covering all areas. I have a sky-fog volume, directional light, and a few post FX overrides. Thats it.



Thats a bone stock light.

So someone, please chime in on whats going on here. What sucks most is this I've had this problem for over a year, but this here is a fresh install. I'm not stupid and had Enlighten working great, and this is how Progressive treats me? And now Enlighten is gone. I'm not even going to offer this photogrammetry stuff on Unity if I cant even make a tiny area work. I'd get all kinds of bad reviews. Since it worked in Enlighten, I'd like to think there arent any flaws in my models.

 

Update:



Well. I'm seeing the same errors in the same place in different instances of the models. It doesn't matter whether the model is using UV1 for texture and lighting, or if it has its own UV2 set for lighting only. The UV layout is good. The baked maps are blotchy and it makes me think they're not using the correct UVs somehow. I see the streaks from where you blend edges out, and harsh lines and whatnot, so that makes me think Progressive is getting UV scale or orientation or whatever screwed up. Meshes are exported with Max as fbx. Importing them and inspecting them, they look good and the UV sets are intact. Nothing weird is happening in their import settings, which are at default with texture and animation import turned off. I cant find a pattern otherwise. Lightmap settings have no effect since I'm suspicious that there's a model import error somehow?

 

No double-sided materials, and the texels are valid. When I throw a rock pile (one of the worst offenders) into its own scene and set it up with a directional light, reflection probe, and whatnot, it seems to be working. I notice, though, that Unity stuck a light in the new scene by default that had like 10,000 lux or something. I just get a white screen from the glare so I'm confused as to why the high setting for lux. Normally I set lux to 10ish and get nice, daylight looking results.

I'm researching this-- Although different instances seem to have the same artifacts in that test scene, to me, its otherwise acting like only a few 'dots' of lighting data are being recorded on the texture, and then edge-bleeding outward in streaks. I guess Unity does that the way any baking software does. So you see these blotchy islands of color. See what I mean? Since that rock pile works fine in the new test scene, I'm feeling like it might be a setting somewhere in the light? Perhaps 10 lux is just sending out too few photons...

 

Unity-generated lightmaps throw the same kind of errors but in a different pattern. Pretty much like I'd expect.

Idea: Could Progressive be grabbing the wrong scale of the object somehow? Max and Unity scales don't really match up well. What if Progressive thinks this is a pebble when its a boulder. Here's what I've got:

In max, 30ish generic units import into unity as about 1 unit (meter). This is a good standard working scale I've seen in lots of engines and assets.

In the import, it says "1 in (file) to 0.0254m (unity)"

Is there a problem here? The scale factor on import is 1.

I have one cliff section that really hates getting light as seen in the middle of the screen in the animated gif at the top of this post. I could experiment a bit and see what makes it special. But its not the UV layout itself, apparently. And I'm not surprised since my UVs are quite tidy.

 

Ok so I discovered that I had made a mistake about the nature of this issue. I thought that it looked the same in CPU and GPU, but what happened is the CPU bake choked and died sometime in the night, and I didn't know it would revert back to the previous GPU bake upon failure. I baked it again in CPU overnight and it worked, though took 80x as much time. No settings were touched other than switching between GPU and CPU to make this animated gif. I'm now in doubt that there's anything wrong with my models. To me it looks like the GPU is not shooting enough rays, even though it claims to have shot tens of millions. I think each 'blotch' is where a ray hits and then gets blended out till it hits nearby blotches. Thats why there are zones of solid colors that may be correct for some nearby point.

I've got a watercooled GTX 1080TI, the HDRP Setup Wizard has all green checkboxes, and using driver version 436.48

So I know GPU is still experimental, but yikes. Something's off. Still want a mesh? Or is it more obvious whats going on now that we know its the GPU version of Progressive thats doing this....

 

Oh yes. My meshes have LOD0-3 and a few like the little rocks have an extra one with its own small texture. They're correctly labeled MESH_LOD0, MESH_LOD1, etc. They've got a working LOD Group on the mesh. They work great with CPU but GPU tends to have fewer photons hitting the more distant LODs. They get more black space, essentially, and pop terribly because of that. The LODs do seem to be getting their own spot on the baked sheets, which is nice.

Are you suspecting that the GPU Progressive is looking at the LOD3 and its UVs instead of LOD0 when its working on LOD0's lightmap? And the similarities in errors between instances of the same mesh are because of this, and the fact that there may be whole missing islands in LOD3 vs LOD0? And that the bleed-out may not be reaching into these missing islands, causing the black zones and glowing zones with bad directional data? It fits in some ways. It would explain why the bad maps KINDA work, since most of the time LOD1,2,3 are decimated versions of LOD0

 

Oh. I didn't see a warning on that. There goes a day of debugging! At least it can bake LOD0 and I can get an idea of how the area will look in the end. Thanks for the reply, though.