Geometry seems off (3D BAG)

[jpvanmuijen]

Hi,

We are trying to create 3D Tiles from the 3D BAG GeoPackage. Converting the gpkg to PostGIS and converting to tiles works perfectly fine, but the geometry seems off in a lot of places.

Cesium JS seems to automatically correct this by making the material 2-sided by default. However, in Cesium for Unity and Unreal, the material is 1-sided by default and all kinds of gaps appear. I checked the geometry in 3ds Max, and it seems like the normals on random places are flipped inside out.

1. CesiumJS, which corrects the normals by making the material double sided (I assume);

3. Cesium for Unity, with the default 1-sided material (same for Unreal);

5. Cesium for Unity, with material switched to 2-sided (same for Unreal);

7. GLTF (converted from b3dm) in Babylon Sandbox, Backface culling switched on;

9. Faces selected in 3ds Max, where the darker ones (specifically the one on the outside of the building) are inside out;

Attached are the files that I used for these screenshots. Not sure if all of these are useful, but just to be thorough. 8_53_103..zip

Could you maybe have a look and provide some guidance as to how we can use the 3D BAG as input for this tool? It could well be that the source geometry is off, in which case we probably should just switch to a 2-sided material for our applications. But that might have an impact on performance, and we'd prefer to not take any shortcuts.

If you need any additional information or testing, please do let me know.

Thanks!

[jpvanmuijen]

Some additional info; I followed the steps as described in README.MD using a single tile in the same area. The result is the same as before; Cesium for Unity showing gaps and CesiumJS apparently correcting this. (Weird side note is the location of the buildings has shifted in both applications)

[bertt]

Hi, I can reproduce the effect of missing polygons in CesiumJS when using DoubleSided = false (you have used https://3dbag.nl/nl/download?tid=9-316-516 ?)

Notes:

• The default value of DoubleSided in glTF is false, in pg2b3dm DoubleSided is set to true in the current version (when not using custom shaders). I suspect the source data, as the triangulation keeps the original polygon normals;

• The horizontal offset I cannot reproduce, maybe this is something related to the used basemap.

So for the moment I would advise to keep the DoubleSided = true

[jpvanmuijen]

Hi,

The offset is something that happened once, so I guess we can ignore that. I used the tile just south of the one you mentioned, https://3dbag.nl/nl/download?tid=9-316-512

Main takeaway is that the triangulation keeps the original normals, so we can rule out any errors during conversion. That's great. So we will try to;

1. Get the source data as clean as possible;
2. Correct any remaining errors with materials/shaders.

Thanks for checking and getting back to me!

[bertt]

ok, I did take a ook into adding an option for DoubleSided (so it's not hardcoded to true), but it was not so trivial to get it working. Probably will add it in a next release.

[bertt]

I've created a new release 1.8.1, can you try? There is a new option double-sided (default true), but I got the impression Cesium for Unity3D does not handle this glTF option correctly.

[jpvanmuijen]

Hi - I just tested with the 1.8.1 version which appears to be working fine :okhand: (the implicit/explicit option somehow didn't work for me in version 1.7.1 but that seems to be fixed)_ Delighted to see that you added support for gLTF and Structured Metadata as well!

We have concluded that there are some incorrect faces in both the 3D BAG and our own data, given that there's still flipped normals in our resulting geometry. Also, I think Unity handles the shading of the 2-sided material a bit wonky. Attached is a side by side comparison of a 1- and 2-sided material. I suppose this could be fixed by tweaking the shader.

The issues seem to apply to the flat roof surfaces in particular. Again, assuming the triangulation keeps the original normals, somehow there are still errors in our source data.

CesiumJS and Unreal seem to do a better job at the 2-sided shader.

All in all, I think we can work with the current setup and output.

Let me know if you need any additional information or testing.

[bertt]

ok great,

I've found a case in 3D bag (NL.IMBAG.Pand.0289100000000381 near Wageningen) where 2 adjacent flat roofs in a multipolygon (polygon 20/21) in 7-624-528.gpkg have different orientation (western part CW, eastern part CCW):

western part:

POLYGON Z ((
172934.328125 441146.65625 21.386999130249023,
172932.515625 441195.90625 21.39299964904785,
172932.84375 441195.90625 21.39299964904785,
172932.75 441198.09375 21.39299964904785,
172932.4375 441198.0625 21.39299964904785,
172932.4375 441198.15625 21.39299964904785,
172907.96875 441197.21875 21.38599967956543,
172910.3125 441136.0625 21.378000259399414,
172935.09375 441137.09375 21.38599967956543,
172934.734375 441146.6875 21.386999130249023,
172934.328125 441146.65625 21.386999130249023))

eastern part:

POLYGON Z ((
172932.515625 441195.90625 18.058000564575195,
172934.328125 441146.65625 18.07200050354004,
172934.734375 441146.6875 18.07200050354004,
172934.625 441149.15625 18.070999145507812,
172935.59375 441149.1875 18.070999145507812,
172935.6875 441146.71875 18.070999145507812,
172947.203125 441147.21875 18.069000244140625,
172945.296875 441196.46875 18.05500030517578,
172933.796875 441196.03125 18.058000564575195,
172933.921875 441192.9375 18.05900001525879,
172932.953125 441192.90625 18.05900001525879,
172932.84375 441195.90625 18.058000564575195,
172932.515625 441195.90625 18.058000564575195))

So maybe we can report it at 3D Bag somewhere?

About Unity3D: I did some experiments, it looks like it ignores the doubleSided = true option somehow.

[bertt]

see also https://github.com/CesiumGS/cesium-unity/issues/370

[bertt]

Did an experiment with reversing the polygon vertices winding order (when order is wrong), but it's not so trivial to get it right for more complex buildings. So the options are getting doubleSided working and/or fix the winding order in the data.

Closing this issue.