VCityTeam / py3dtilers

Tilers accepting various input formats (OBJ, 3DCity databases, GeoJson, IFC) and producing 3DTiles tilesets.
Other
191 stars 51 forks source link

[CityTiler] 3D Tiles with textures are almost always bigger than the input CityGML #66

Open jailln opened 2 years ago

jailln commented 2 years ago

I've observed that in most cases, the 3D Tiles created is bigger than the input CityGML by a factor of 2 of 3 (only happens for conversions with textures). It seems odd since the CityGML is based on XML and not optimized while 3D Tiles is mainly binary and a bit of json and is meant to be optimized. Sometimes though, the 3D Tiles produced is smaller than the input CityGML but I have not been able to find out why yet. I think this issue may be related to #65 ? but it needs to be investigated more thoroughly.

clementcolin commented 2 years ago

Quick question: do you compare 3D Tiles created with the CityGML and the textures associated, or only the CityGML files?

If it is the former, I agree that's an odd behavior and results and needs to be investigated more thoroughly.

jailln commented 2 years ago

Yes I compare the 3D Tiles and the textures with the CityGML and the textures :slightly_smiling_face:

clementcolin commented 2 years ago

I think that this happens because, when we are grouping the textures in atlas, it is hard to find the proper size of the resulting atlas given a set of textures, we approximate it but not perfectly, thus we create non-necessary information (the black pixels) that are not in the original textures.

Do you have, by any chance, a clue to find the optimized size of an atlas, given a set of textures ? We follow this algorithm to create the atlas, yet, it does not talk about this problem.

jailln commented 2 years ago

I think that this happens because, when we are grouping the textures in atlas, it is hard to find the proper size of the resulting atlas given a set of textures, we approximate it but not perfectly, thus we create non-necessary information (the black pixels) that are not in the original textures.

This seems like a good lead indeed!

Do you have, by any chance, a clue to find the optimized size of an atlas, given a set of textures ? We follow this algorithm to create the atlas, yet, it does not talk about this problem.

No I don't and by looking over the internet it seems that it depends on the algorithm you use. It also seems that many algorithms start with a fixed height and unlimited width, try to place the textures, then update the width and height and place the textures again, and so on, until finding the best width/height combination. The author of the blog post you used left his e-mail at the end of the page for questions and comments though, maybe it's worth contacting him ?

An other solution would be to find the name of this algorithm (guillotine texture packing algorithm ? shelf texture packing algorithm ? etc.) and then to find out how to deal with the atlas size for this algorithm ?

Some interesting resources that I came across:

LorenzoMarnat commented 2 years ago

See comment about greedypacker.