Importing OBJ-Preserving Textures in 3rd party software.

[Jonesy82]

I have been experimenting using the Apple Iphone 15 pro LIDAR capabilities to map historic mine workings. My current workflow is:
1. Scan the mine workings in sections (usually no more than 20 metres at a time. The mine workings are tied to a DGPS coordinate reference point.
2. Stitch together each scan using Cloud Compare. Register the scans to the DGPS coordinate points to achieve the correct X, Y, Z.
3. Export the completed scans as an OBJ file. I export each scan separately as a merged file.
4. I import the OBJ files into a 3rd party geological software called Maptek-Vulcan. Vulcan will import the OBJ file and automatically apply the linked texture images to the mesh (triangulation).

I have successfully imported OBJ files into Vulcan before. Not remembering how I done it previously, I am seeking advice on what I could be doing wrong. I am finding the mesh is importing perfectly, but the draped linked textures are not. They are working in parts of the mesh, but are looking like a camouflaged layer in the 3rd party software, whereas they look perfect in Cloud Compare.

Attached:
Fig 1- Resultant importing mesh with 'camo' patchy texture draped
Fig 2- Correct texture as seen in Cloud Compare
Fig 3- I export as an OBJ the greyed out mesh as seen in the explorer tree (CC).

Advice needed:
- What could be the cause of the imported mesh and patchy 'camo' texture in the 3rd party software?
- Am I exporting all the neccessary files correctly (OBJ) as shown in fig 3 from Cloudcompare? Do I need to export the other unchecked meshes?

Thanks.

[daniel]

No, you are right, only the 'mesh' object at the top (well, just below the main 'file') is sufficient to properly export the mesh.

If you reload the mesh later in CloudCompare, is the texture still ok?

And by the way, are the original files coming out of the iPhone OBJ files? If yes are you able to import them directly in Vulcan?

[Jonesy82]

Hi Daniel,

I have tried your suggestions;
- Reloading the exported OBJ back into Cloud Compare, the textures load correctly to the mesh.
- You can load the iPhone exported OBJ files directly into Vulcan program, however they are not georeferenced. The textures also do not load correctly.

I have been trying multiple ways today, still haven't found a solution as yet. I have had it work in the past, just didn't write down the instructions or the resolve of this glitch.

What is happening is the wireframe mesh is loading correctly and some of the overlaying textures are too, but 70% of the textures seem to load jumbled acrossed the wireframe.

[daniel]

At least, it seems that the issue come from Vulcan? Have you tried to contact them?

I guess they fail to load correctly the texture (u,v) coordinates or something like that...

[Jonesy82]

I have made contact and they are looking into the issue.
When you open up the .mtl file you can see each material (texture-image) link to what mesh. I believe Vulcan will only import each mesh and cannot handle multiple linked images.

Is there a way to export each individual mesh component separately? (as highlighted in the DB tree image)

Only other possible option could be to manually edit each .mtl file to only contain one material/image per mesh in a text editor?
Thankyou

[daniel]

I am not sure... Have you tried to maybe clone only one child mesh? Don't hesitate to share a sample file with me also (to admin@cloudcompare.org)

[Jonesy82]

Hi Daniel,
I have returned to this issue and now have resolved it.
The 3rd party software can only import a single image (material) and link to a single triangulation. By exporting as a merged file, the 3rd party software does not recognise the individual materials and triangulations. I have just experimented and found a way around:

If you expand the tree of the layer, you can see there are 4 individual meshes. If I highlight each mesh, I can export them as individual OBJ files. The 3rd party software will then recognise 1 mesh linked to 1 material image when importing each individual file. It will create a lot of files, but this is the current way around this.

Solution_1.jpg (136.53 KiB) Viewed 6140 times