Search Unity

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

Discussion in 'Global Illumination' started by Automoda, Oct 7, 2019.

  1. Automoda

    Automoda

    Joined:
    Apr 27, 2017
    Posts:
    125


    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.
     
  2. Automoda

    Automoda

    Joined:
    Apr 27, 2017
    Posts:
    125
    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?
     
  3. kristijonas_unity

    kristijonas_unity

    Unity Technologies

    Joined:
    Feb 8, 2018
    Posts:
    367
    Do you have any geometry that uses one-sided materials within the scene? If so, make sure that Double Sided flag is enabled for those materials.

    These artifacts seem to be caused by invalid texels. I would suggest rebaking the scene and using Texel Validity scene debug view to verify whether this issue is caused by invalid texels (they will show up as red in the debug view). Keep in mind that the bespoke debug view only works with CPU lightmapper for now.
     
  4. Automoda

    Automoda

    Joined:
    Apr 27, 2017
    Posts:
    125
    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...
     
  5. kristijonas_unity

    kristijonas_unity

    Unity Technologies

    Joined:
    Feb 8, 2018
    Posts:
    367
    In order to determine whether this is an issue with lightmap UVs or not, you could try generating lightmap UVs within Unity. Click on Generate Lightmap UVs in the mesh inspector, rebake, and see if that helps.
     
  6. Automoda

    Automoda

    Joined:
    Apr 27, 2017
    Posts:
    125
    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.
     
  7. kristijonas_unity

    kristijonas_unity

    Unity Technologies

    Joined:
    Feb 8, 2018
    Posts:
    367
    I highly doubt that this is a scale issue. You could reset xform for you mesh in max, but I don't think it's going to make a difference.

    Could you please attach this mesh or send a small repro project so that we could investigate on our end? Thanks.
     
  8. Automoda

    Automoda

    Joined:
    Apr 27, 2017
    Posts:
    125


    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....
     
  9. uy3d

    uy3d

    Unity Technologies

    Joined:
    Aug 16, 2016
    Posts:
    98
    Are there any LoDs on those models?
     
  10. Automoda

    Automoda

    Joined:
    Apr 27, 2017
    Posts:
    125
    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
     
    Last edited: Oct 10, 2019
  11. uy3d

    uy3d

    Unity Technologies

    Joined:
    Aug 16, 2016
    Posts:
    98
    LoD support for the GPU lightmapper is still work in progress, so currently unsupported. Disabling all LoDs but level 0 should allow you to verify that the artifacts are caused by the lods.
     
  12. Automoda

    Automoda

    Joined:
    Apr 27, 2017
    Posts:
    125
    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.