Inverted 3D models after using

[AriemX]

Hello,

I work in a public lab in wich we create accurate 3D capture of historical and cultural heritage related sites.

I've been playing for a while with the VTS backend and encountered an issue :

Our datasets are in the slpk format. When I load it in my local vts environement I end up with a "mirrored" version of my data :
normals seems to be inverted, the model itself is inverted on the Y axis and the latitude and longitude of the default camera inverted in the url (//localhost:3060/dpn/tilesets/test_v17.slpk/?pos=obj,47.895247,-3.407835,fix,-33.02,0.00,-90.00,0.00,74.85,45.00).

We tried to load this same dataset in the melown cloud plateform and their is no sign of these isues (//www.melown.com/cloud/link/ZLlnO3RgGLV4k89n835j?pos=obj,-3.407941,47.895019,fix,86.35,-57.63,-56.62,0.00,72.50,45.00).

We import the data using :

• slpk2vts --input <dataset> --output /var/vts/store/resources/tilesets/<dataset> --referenceFrame melown2015 --tilesetId <dataset>
• and then vts dpn --add --tileset /var/vts/store/resources/tilesets/<dataset>/ --top

Do you have any idea why we have this behaviour ? Maybe we are missing something. Do you pre-process the files before importing in your cloud service ?

[vaclavblazek]

Hi, it looks like a problem with normals. The input dataset is not preprocessed but the software running in the cloud is way older than the current git HEAD.
Would it be possible to provide me with your SLPK dataset so I can debug the problem?

[AriemX]

Thanks for your quick response.

Of course ! Can I send it to you via email ? I'd rather not to provide dl links on public chanel (You can find mine in my profile, you don't seem to have a public mail on yours).

[vaclavblazek]

Sorry for not replying, I've got distracted by other stuff. Downloaded and your message with the link deleted.
Will investigate.

[AriemX]

No problem. Thank you.

[vaclavblazek]

I was unable to replicate your problem. However, there was a problem in the 1.89 version of vts-tools in our package repository that was fixed few weeks ago. What OS (vendor, version) and what version of vts-tools do you use?
There's a package 1.93 available for Ubuntu 18.04 (bionic) in our package repo. Otherwise current HEAD of master works OK.

[vaclavblazek]

I've noticed that due to "uneven bottom" of your dataset (i.e. not all data are represented at the deepest level 13) the slpk2vts tool computes VTS LOD assignment at level 6 where the dataset resolution does not quite reflect the dataset quality -- the resolution is computed too low and this places the bottom of your dataset (13) at LOD 30 with insanely tiny tile (like 34x34 mm).

The workaround to move the dataset to lower LOD in the VTS tile tree is to use --tweak.optimalTextureSize 1024x1024 on the command line; normally, the optimal texture size is 256x256 so this uses 4x larger texture that leads to move the data 2 LODs up which seems like what the data at the bottom level in your dataset match. This also leads to ~86k tiles -- instead of original ~1.38M tiles.

However, I've hit a bug in the code, the is fix in the master branch. No package built yet.

[AriemX]

Thank you for your feed back. I use a custom docker image based on ubuntu 20.04, building directly vts-tools, vtsd, mapproxy and registry from the master branch. I'll try updating my image to incorporate your bug fix. I'll also update my loading process using the workaroud you proposed. I'll keep in touch with you once I've done that.

Thanks again.

[AriemX]

Hi,

I have updated docker image using the latests masters and used the workaround you proposed. Unfortunatly it does not seems to correct my isue :
the 3d model and the relation between latitude and longitude are still inverted.

We also tried to load the data as LodTree and got the same result.

Where you able to load the data correctly on your environment ?

[vaclavblazek]

Yes, I converted it OK. However, now I noticed you are running it on focal. Lemme test it on focal as there may be some hidden problems with newer libraries.

[AriemX]

That's what I thought too. I'll wait for your feedback then.

Thanks again.

[vaclavblazek]

Got the same result! Will investigate.

[vaclavblazek]

OK, got it. Fixed in master.
As expected, it was a change in dependency: GDAL 3 (present on focal) started honoring axis order in CSR by default. So, for latlon it interprets arguments as (Y, X, Z) by default. I had to tell it to use "traditional GIS order", i.e. (X,Y, Z) regardles of the CSR. This x/y axis swap 1) flipped triangle front faces and 2) moved the model in completely different place in the world.

Just currious how much code did this change break...

[AriemX]

Thanks a lot !

We will use the new version and give you feedbacks on any isues. Let's hope nothing has broke ;).

[vaclavblazek]

I forgot to mention that the change is in submodule, you have to updated recursively.