No announcement yet.

Overlapping lightmap UVs for frond

  • Filter
  • Time
  • Show
Clear All
new posts

  • Overlapping lightmap UVs for frond


    Anyone has idea about why the lightmap UVs overlap? v7.0.6, the light blue parts (Frond with Count > 1) are overlapped UVs in either image:

    Click image for larger version

Name:	Flip_Mapping.GIF
Views:	1
Size:	29.6 KB
ID:	3299Click image for larger version

Name:	Flip_None.GIF
Views:	1
Size:	28.7 KB
ID:	3300

    Last edited by macrod; 04-29-2015, 11:20 PM.

  • #2

    What exactly are you showing there? And what is different in the tree that is causing the difference in the map? Is the selected part some geometry with a custom leaf mesh?

    BTW, there are updates to the Modeler that include fixes to lightmapping. Be sure to update to the latest version, if just so we're both on the same page.


    • #3
      Thanks for replying, Greg.

      The difference is not important, 1 is Flip > Mapping, 1 is Flip > None, but both have overlapping UVs shown in light blue.

      Not custom, it's basic frond.


      • #4
        7.1.1 is still like this.


        • #5
          If you could, send us your tree so we can take a look. Use "save as with assets" from the file menu into an empty directory, zip up the whole directory, and send it to [email protected]. That ensures we get all the assets used in that tree.


          • #6
            Tree > Trunk > Level 1 (Branch).

            Level 1:
            Geometry Types: Frond
            Count: 3 (interpenetrating leaves)

            Render > Lightmap density


            • #7
              I believe you have uncovered a problem with lightmapping on fronds. It's currently not taking into account the "Frond:Count" property correctly. All 3 of the planes of each frond node in your tree are getting stacked up in the lightmap uvs.

              So set count to 1 to work around it. You can still get the same tree by copy/pasting the Level 1 generator so you have 3 of them. Then adjust the Frond:Roll in each generator to be 0, 0.3333, and 0.6666. The resulting tree will be the same as the original, but it will work correctly for lightmapping.

              I'll log to fix that bug.


              • #8
                Thanks for the solution!

                The model I sent has another problem:
                Level 1 > Frond > Count = 1, Duplicate Level 1, the duplicate one does not look the same as the original, maybe there're some random numbers?


                • #9
                  If there is variance on anything, then yeah they can compute slightly differently. Rolling the original branch is going to end up slightly differently, even if you account for variances and random seeds.

                  Or.. don't try to fix it. Variance in trees is good ;-) Is there a problem with the resulting tree?


                  • #10
                    Then "3 fronds each with Count 1" is different than "1 frond with Count 3", the trick is not really usable.

                    Copying something results in the same thing will make sense, we use pseudo randomness, right?

                    Please let me know if a new version fixes the overlapping UVs issue, thanks!

                    Looks we'll have to use mesh fronds and waste some diffuse textures.
                    Last edited by macrod; 05-20-2015, 11:42 PM.


                    • #11
                      UE 4.8 can unwrap non-overlapping lightmap UVs.


                      • #12
                        The automatic lightmapping in UE4, while a quick solution, usually makes sub-par lightmaps for trees. It weights triangles by surface area, so leaves are given the most space in the lightmap. You really want the trunk and large branches to have the most space in the lightmap. We can also remove the twist from branches to get them to light up right on texels. You have a lot more control over this using SpeedTree's lightmapping controls.

                        That being said, requiring unwrapped meshes for mesh assets in the Modeler is a little cumbersome, and we are looking into solutions for unwrapping arbitrary meshes to not require that step.