Unlit Materials

[joseph-kaile]

[cesium-concierge]

Thanks for the pull request @joseph-kaile!

• ❌ Missing CLA.
  • Please send in a Contributor License Agreement (CLA) and comment back here to let us know to check this!
  • Maintainers, here's how to check for a submitted CLA.

Reviewers, don't forget to make sure that:

• Cesium for Unreal Samples works.

[kring]

Incorrect comment.

[kring]

I think maybe using +Z as the normal isn't quite right. It's fine when the tileset is located near the georeference origin. But what if the origin is on one side of the globe, and the tileset is on the other? Then the tileset would only be lit when the sun is below the horizon, which is likely to surprise users.

So I think instead of +Z, the normal at each point should be set to the ellipsoid surface normal at that point, transformed to the mesh's coordinate system.

Basically you need to get each vertex position, transform it to ECEF using the transform passed into this method, and then call Ellipsoid::WGS84.geodeticSurfaceNormal to get the surface normal at that point. Then that surface normal has to be transformed from ECEF back to Unreal coordinates using the inverse of that passed-in transform (don't forget to construct the vector to transform as glm::dvec4(ecefNormal, 0.0) before multiplying it with the inverse of the transform, because it's a direction not a position).

[joseph-kaile]

OK, I believe I implemented the above in code. I'm not sure how to visualize the normals. However the code is straightforward enough. If I invert the normals the buildings get dark. Also, I disabled the dynamic shadows:

[kring]

Please mention the extension name here.

[nithinp7]

@joseph-kaile Sorry if I'm missing context, but a couple of comments:

• Smooth normals fix the weird triangl-ey lighting issues in photogrammetry and they seem like a more elegant solution than fake normals right?
  • Technically that is against gltf spec when normals are missing - spec dictates clients should generate flat normals when normals are missing, but imo smooth normals look better than flat normals for photogrammetry.
  • The only times flat normals need be generated are when tangents are needed and missing e.g., to apply a normal map. When tangents are missing normal maps are relative to MikkTSpace tangents, which requires flat normals. All that being said though, normal maps are never used for unlit photogrammetry (currently).
  • So for example, we could potentially just generate smooth normals if the unlit extension is present, if this is the route to go down.
• But alternatively, why don't we just use an actually unlit material shading model instead of faking normals when the unlit extension is present? I don't necessarily love this option, as it would look even more unrealistic - but it seems to be how photogrammetry was intended to be rendered. Plus that's what we do in Cesium for Unity and CesiumJS.

[kring]

I don't think the unrealToOrFromCesium here and below are needed. I tested by using Buffer Visualization -> World Normal and comparing the color of Melbourne with Cesium World Terrain. Cesium World Terrain will have some undulations in its normals, while Melbourne will be a solid color, but the overall color of them should be the same because the normals should point in basically up in both cases. With the unrealToOrFromCesium in place, they were quite different, but once I removed it they were the same. This makes sense because there's no need to use the Unreal coordinate system at all. The Origin is expressed in model coordinates, then we transform to ECEF, compute the normal, and transform the ECEF normal back to model coordinates.

There seems to be something weird with normals in Cesium for Unreal in general, though. Everything is good near the georeference origin, but on the back side of the globe something is wonky. For example, in this screenshot, both CWT and Melbourne are dark even though the sun is high in the sky:

This doesn't necessarily need to be fixed as part of this PR, but maybe you have an idea what's wrong? I'm at a bit of a loss at the moment.

[joseph-kaile]

That makes sense, I assumed that there was code I couldn't find that automatically transformed the coordinates in the position view accessor.

I did see something like that. I think when the georeference was so far away everything was sky blue. I just thought that this was from floating point precision cause its too far away from the origin it gets messed up.

[kring]

Could be precision related, but in theory the directional light should just be a direction, so the large coordinate values shouldn't matter too much. But who knows. I'll write an issue.

[kring]

Oh! I think it's just this issue again:
#527
And there's a workaround listed in there.

[kring]

Thanks @joseph-kaile!