Unable to export a single grouped COLLADA file

[yaozhihang]

The KML/COLLADA/glTF-Exporter always creates at least two COLLADA files, regardless how large is the value given in the field "Put objects together in groups of" (preferences -> KML/CLOLLADA/glTF-Export -> Rendering -> Building),

The issue is caused by the current multi-threading implementation of the KML/COLLADA/glTF-Exporter, which creates the group of COLLADA objects within an individual worker thread. As a result, more than one group will be created, if multiple worker threads are instanced during the export process.

[clausnagel]

Additionally, it would make sense to have another option to group all objects on a tile. This would make it very easy to export one file per tile. Currently, you always have to provide the number of objects to be grouped, but this number is not known a priori.

[clausnagel]

@yaozhihang, do you think needs this to be addressed for the planned 4.3 release or could/should be postponed to a later release?

[Flawks]

I am a TUM student and currently working on a project to import CityGML data into Unity game engine via conversion to COLLADA. I am using 3DCityDB Importer/Exporter for this. However, version 4.3.0 is exporting large amount of COLLADA files per tile and it is impossible to assemble them manually. I was wondering will this issue will be fixed soon?

[paleajed]

I am trying to use COLLADA/gltf export for importing CityGML into Blender. It seems the many 3D files that are created are not positioned correctly when loaded into Blender one by one. As far as I can see the relative positioning between parts is encoded in the accompanying kml file. There is no kml import facility for Blender. I could write my own but am not sure about the correct lat/lon/alt to x/y/z conversion formulas, also I am not really a math wizard. It would be really helpful if you could add a means of only using one worker thread (I don't care if it is slow) so only a single correct COLLADA file is created, ready for Blender import. Or maybe there is some means of creating correctly relative positioned collada files already, if so please let me know how to get this done. Thank you alreaady.

[clausnagel]

Thanks for your post, @paleajed. We are currently focusing on the next major version 5.0 of the 3DCityDB with support for CityGML 3.0. So, this issue is on hold at the moment.

Have you tried to export the data as CityJSON instead? There is a Blender plugin to load CityJSON files: https://github.com/cityjson/Up3date. I haven't tested it myself but maybe it helps you to solve the issue.

[paleajed]

I can export CityJSON without textures and it imports into Blender nicely. When choosing to include appearance though, the exporter detects millions and millions of textures (I've been running for an hour, given up now), while when exporting COLLADA it only detects 7069 textures which takes a few seconds. Something must be wrong here...

[clausnagel]

Yes, sounds strange. Do you have a similar number of textures when exporting to CityGML? Can you share (an excerpt of) your dataset so that we can try and reproduce the problem? You can also send it by email if you don't want to upload/link it here.

[paleajed]

My dataset does have errors in it concerning duplicated ids. Its a public dataset. I link to it below.

https://download.data.public.lu/resources/base-de-donnees-nationale-des-batiments-3d/20230921-102008/act2020-bati3d-differdange.zip

[clausnagel]

I checked the data. Yes, the id issues should be fixed. The dataset uses one global appearance to assign textures to all buildings. This is where the data is not super smart and I would always recommend using local appearances. CityJSON does not support global appearances, and that's why the exporter must convert them to local ones on the fly during export. And this is where the current exporter implementation is not super smart, and should be improved.

So, here is what you could do:

1. We will address the issue of the Importer/Exporter and provide a new version. However, this might take some time. You can just wait until the bugfix is available.
2. Alternatively, you could convert the global appearances to local ones using citygml-tools. Check the to-local-apps command for this purpose. Afterwards, import the adapted dataset into the 3DCityDB and export to CityJSON. Should be really fast then.
3. Alternatively, and after having converted the global appearances with citygml-tools as in 2.), you could also directly use the to-cityjson command of citygml-tools to convert the adapted dataset to CityJSON. No database needed in this scenario.
4. Alternatively, you could give the 3DCityDB 5.0 beta a try which does not have the issue. Download the current beta version of citydb-tool from its releases page. After unzipping, use the database scripts in the "3dcitydb" subfolder to setup a 3DCityDB 5.0 instance (do not connect to your current database instance - it will not work). Afterwards, run the citydb command on the command line to import your CityGML dataset and export it as CityJSON. Note that the citydb-tool does not offer a GUI.

[paleajed]

Thank you very much. You are masterful in following up issues quickly en thoroughly.

[paleajed]

All the good information can't help when in the end it seems the CityJSON importer for Blender doesn't support textures... I will have to wait for you to implement global COLLADA support. Thanks anyway.

[paleajed]

Adding my own constructive snippet: there's a fork of the CityJSON importer mentioned above named CityJSONEditor. It supports textures, but I can't get it to work with my dataset... yet. I am trying some changes to the Python code to get it to work. Since my problems are most probably dataset related, I am mentioning the addon here so it could serve others on their quests.

[paleajed]

I got it to work. BUT. CitJSONEditor is incredibly slow (hours and hours..., didn't get it to finish yet) on bigger datasets (thousands of buildings). It imports every building as a separate Blender object; as the Blender object count grows, the importer grinds to a halt. I tried using tiles: this works kind of, but after importing some tiles, textured viewport performance grinds to a halt and ultimately Blender crashes. So, I come to the conclusion there is still a big need for global COLLADA support (COLLADA is fast: both at importing, and at visualisation with textures in Blender). If I understand correctly a setting for number of worker threads (like there is for Export) would solve this when set to 1? Must be relatively simple to implement then? Still, I am a programmer myself and many unknown (to me) factors could exist. Just hoping this fix will come along sooner rather than later!

[clausnagel]

Hi @paleajed, thanks for your tests and insights regarding CityJSON tools and Blender.

The geo-reference of the exported COLLADA models is indeed written to a separate KML file. But you can let the exporter put the COLLADA model and the KML file into a single KMZ package. I am not a Blender user, but according to this tutorial loading KMZ with Blender is possible: https://blenderartists.org/t/importing-google-earth-kmz-files-into-blender/470213. To export as KMZ, tick the "Write to compressed KMZ archive" option in "Preferences -> VIS export -> General -> General options". You will find the KMZ file in the "Tiles/../.." subfolder(s) of your export directory.

@Son-HNguyen, @yaozhihang, do you have more ideas?

[paleajed]

Hello @clausnagel,
I had already checked that tutorial; all it does is tell you to unzip the .kmz and then open the supplied COLLADA file. Not an implementation of true .kml/.kmz