Create Integrated Mesh Scene Layer Package Tool

[gauthierverlin]

Hello,

I'm trying to use this tool but I can't make it works. I was wondering if this tool works with OpenScenGraph 3d model made with Photoscan.

I have checked all the possible solution to resolve error 999999 but it still won't work.

If you have any idea how this tool works with 3d OSGB model made with Photoscan, I'll be glad to hear about it.

Best regards

Gauthier

[Andrew--Johnson]

Hi,

How are the OSGB files structured in the folder that you input? Was that how Photoscan output the files or did you move everything into one folder? 

thanks,

Andrew

[gauthierverlin]

Hello,

I kept it the way Photoscan exported it. Here is the file I try to import :

It's all group into one folder I named "OpenScenGraph" as you can see in the input section of my first question.

[Andrew--Johnson]

Thanks for providing that information. Typically OSGB data should be output into a hierarchy where each tile root node will have its own folder so you would have  Tile001, Tile002, Tile003, etc. Our importer expects the data to be structured in a certain way so that the tree hierarchy can be properly constructed. Without being able to take a look at this data its difficult to investigate this further. We have seen issues where the children nodes are not declared in the parent nodes or the data is all lumped into one folder structure and the imported is not able to differentiate the tile nodes when building the tree hierarchy. Are you able to provide the OSGB data so we can take a look on this end to determine the specific cause of the failure?

thanks,

Andrew

[gauthierverlin]

If I export the model from Photoscan in .slpk and I import it in a scene, the model look like this :

Of course it's an example to test if this method works before using it on larger model as we work with model of bridge or dam for example.

My goal, by using the Create Integrated Mesh Scene Layer Package Tool is to give an Anchor point to my 3d model.

When exporting a 3d model from Photscan in .slpk format, the coordinate system of the model will always be transformed in WGS84 + VCS EGM2008 Geoid. As we are trying to work in Local system or just different system than WGS84, exporting model into .osgb format from Photoscan provide us the possibility to export it in local coordinate system.

That's why this tool look promising as I could use a .osgb 3d model in a local coordinate system and transform it into a .slpk using the tool from Arcgis Pro and giving it an Anchor Point to place it where I want on the map.

Here is the link to my OSGB data : https://drive.google.com/open?id=17wljvtmkL3_GzLSmuxH-y6mjMvcOfAv8 

Thank you for all the answers and the interest you give to my problem

Best regards

Gauthier

[Andrew--Johnson]

Thanks for this information and for sharing the data. One more follow up question, when you say local coordinate system do you mean custom coordinate system or just a local projected coordinate system?

thanks,

Andrew

[gauthierverlin]

Our Local coordinate are different for every structure we work for. We usually take some points on the structure and some points around it with the origin of the coordinate system (0,0,0) not far. We usually took something like X = 2000 m, Y = 4000 m and Z = 100m.

It's more like no coordinate system if we want to find a equivalent. For example, when we import our orthophotos in Arcgis Pro, we don't reference coordinate system and this kind of "no coordinate system" are detected as "Unknow" which is fine for us.

On this capture, you can see that our coordinate are around X = 100 m, Y = 300 m and the coordinate system of the .tiff is "Unknown".

But we can't do this with 3d model (.slpk) as they are automaticly referenced in GCS WGS84 and VCS EGM2008 Geoid.

Althought, we would like to be able to reference our map and coordinate systems with this "Unknow" system but it isn't possible.

Hope my answer helps you.

Thank you again

Gauthier

[Andrew--Johnson]

Yes that does help! Please note none of our scene layer tools support creating scene layers with a custom coordinate system. We require a well known id (WKID) but we do have it in our backlog to support custom coordinate systems. We are planning on getting this work done either in 2.4 or 2.5. Regardless, this isn't the cause of the problem as I can reproduce this problem on my end using an anchor point with a projected coordinate system. Our developer has a utility that can interrogate the binary file to determine whether or not its written out properly by Photoscan. We recently discovered an issue where ContextCapture was not writing out the child nodes properly in the root nodes leading to failures in our tool so in these situations it is difficult to know the exact cause until the osgb file can be interrogated. Our developer is traveling this week so there may be a delay in getting back to you but i'll reach out as soon as I have more information.

thanks,

Andrew

[gauthierverlin]

Hello Andrew,

I just wanted to know if you if you had more information on the problem.

Best regards

Gauthier

[Andrew--Johnson]

Hi Thanks for your patience on this. Our developer was traveling so he just had a chance to look at this yesterday.  It looks like there are variety of issues at play here

1) It doesn’t conform to the well-known naming convention we use (such as the ones context capture generates as below)
 Tile_+010_+023.osgb == > naming here doesn’t matter but child osgb files need to indicate the Level they are (L_15, L_16, if they don’t have ‘L_’ they will be presumed root)

Tile_+010_+023_L15_0.osgb

Tile_+010_+023_L16_00.osgb

Tile_+010_+023_L17_000.osgb

Tile_+010_+023_L18_0000t4.osgb

Tile_+010_+023_L19_00000t3.osgb

Tile_+010_+023_L19_00010t3.osgb

2) We expect children of osg.Node to be osg.PagedLOD ; in this case the root node (Rame.osgb) has a nested osg child node
3) Normals need to be recomputed
4) Some of the faces seem to be inverted

Moving forward we are implementing some fixes in ArcGIS Pro 2.4 to handle these unexpected cases. We will also work with Agisoft directly to ensure the correct information is being output to the OSGB files.

Here's a screenshot of a SLPK that we created and once we do some additional testing with the fixes I can provide this SLPK to you.