Collada export Flat shading

[slightHYP]

Dear all,

this is not a 3DCityDB issue, but I would like to check with you how we can solve a problem in our conversion process. We completed and tested our workflow to convert CityGML to BGLTF (automatically starting from the import in 3DCityDB) in order to ingest 3D datasets in CesiumJS and visualize them on the globe. Everything works fine, but we have some problems in the visualization, in particular with 3D objects without textures.

The CityGML model source has no appearance/theme and the export to COLLADA (and then to GLTF) creates flat shaders. It seems that there is no algorithm to calculate the normals of the surfaces (as you can check form the image). Do you have any idea on how to solve this issue?

[clausnagel]

Yes, this is a known limitation. At virtualcitySYSTEMS, we have forked the Importer/Exporter and added code to compute surface normals. You can find the fork at https://github.com/virtualcitySYSTEMS/importer-exporter.

Feel free to test this version. You need to check Generate surface normals under Preferences -> KML/COLLADA -> Rendering -> Building.

We plan to pull this code into the next minor 3.1 release of the Importer/Exporter which will be released soon.

Cheers, Claus

[slightHYP]

Dear Claus,

thank you for sharing the improved version of 3DCityDB...Now I'm trying to solve some strange behaviors from our part of the conversion workflow and at the moment I can't yet visualize the 3d Models.

Anyway I would like to share with you an issue occurred during the export process from 3DCityDB vcs version. I'm working on OSX and during the export it threw the following error:

Exception in thread "main" java.lang.NoSuchMethodError: javax.vecmath.Point3d.getX()

I found that the problem is well known, the version of Java3D installed on OSX is not updated as reported here: http://lists.apple.com/archives/java-dev/2009/Jan/msg00129.html

Replacing the old version with the 1.5 the export works fine.

I'll keep you updated about our building on CesiumJs.

Best, Michele

[slightHYP]

Dear Claus,

we fixed the problem in the conversion process... the problem was in the kml file generated from 3DCityDB.

In some cases the kml for a building is simply written like this:

< Placemark id="COLLADA_UUID_7e52a79b-b5ad-4dfa-a7a4-40a7d789ded8" > < name>UUID_7e52a79b-b5ad-4dfa-a7a4-40a7d789ded8< /name> < Model> < altitudeMode>absolute< /altitudeMode> < Location> < longitude>11.1009319< /longitude> < latitude>46.0338637< /latitude> < altitude>421.088< /altitude> < /Location> < Orientation> < heading>1.5152185< /heading> < /Orientation> < Link> < href>224343/UUID_7e52a79b-b5ad-4dfa-a7a4-40a7d789ded8.dae< /href> < /Link> < /Model> < /Placemark>

in others (we have to discover why) it contains the namespace:

< kml:Placemark id="COLLADA_UUID_e81ec42f-d964-4296-8d61-360ada06defa"> < kml:name>UUID_e81ec42f-d964-4296-8d61-360ada06defa< /kml:name> < kml:Model> < kml:altitudeMode>absolute< /kml:altitudeMode> < kml:Location> < kml:longitude>11.106678< /kml:longitude> < kml:latitude>46.0307296< /kml:latitude> < kml:altitude>292.272< /kml:altitude> < /kml:Location> < kml:Orientation> < kml:heading>1.5191444< /kml:heading> < /kml:Orientation> < kml:Link> < kml:href>224811/UUID_e81ec42f-d964-4296-8d61-360ada06defa.dae< /kml:href> < /kml:Link> < /kml:Model> < /kml:Placemark>

This is the reason why our converter crashed parsing the kml files.

Anyway, now it works! This is our result with the new 3DCityDB vcs version and the computation of the normals.

Thanks for the support, Michele

[clausnagel]

Hi Michele,

Thanks for the update. Your buildings look better now :)

As long as the KML namespace is correctly defined in the file, it should not make a difference whether it is associated with the 'kml' prefix or given as default namespace without a prefix. Your KML parser should be able to deal with both.

However, I can take a look at this. Our priority is currently the 3.1 release though. So if you have any findings on when the file is generated with or without prefix, this piece of information will be helpful :)

Cheers, Claus

[slightHYP]

Hi Claus,

yeah we fixed our parser in order to accept both KML syntax. I checked if there are any differences in the gml files, but I didn't discover anything.

I'll try to go more in deep in your code in my free time and I'll keep you updated if I'll find something.

Best, Michele