I’m interested in being able to export a single georeferenced .OBJ file from a project. Currently when I try to export an .OBJ model it creates multiple .OBJ files and each one seems to have been converted to a local coordinate system rather than the established georeferencing from that model. I have seen the offset text file that’s generated with the export which helps identify the local offset from the georeferenced locations, but this offset limits the usability of those .OBJ files.
I’m hoping this is a feature that already exists that someone can point me to, otherwise I would be interested in understanding the process for potentially incorporating this in the future.
As you noted, the OBJs are using an offset file. The reason being that the Waveform OBJ file specification doesn’t have a spec for georeferencing, so we use the offset to align more with how other software treats them.
What software or workflow are you using that this setup isn’t working for?
We’re using a custom-developed piece of software to read and manipulate .DXF & .OBJ models and I personally am not familiar with the workflow on how the .OBJ parsing logic was implemented. We’ve had success imported georeferenced .OBJ files from Agisoft Metashape Pro.
We have influence over the development of our custom-developed software so if there’s a standard that you can point me to in order to automatically apply these offsets when importing these WebODM generated models I could get that information in front of the right people to see if that can be incorporated.
We’ve also struggled with our exports generating multiple OBJ files. Is there a means to export as a single file rather than multiple chunks of the same model?
I’m not sure how Agisoft is doing what they do since their product is closed-source, but again, without the OBJ specfiication having an official spec for georeferencing…
Could you not, since you have control of your software, use the offset files as we generate them?
How do you mean? Each Task should generate a single OBJ with an associated MTL file, though there may be numerous texture atlas files.
I will use one of the offset files to see if we can incorporate that to the model imports. I wanted to see if there was something I was missing before we went down that path of manipulating the file-import process. We are relatively new to WebODM and are hopeful it could be a valuable resource for us.
I’ll have to get more context from some of the other users who have been trying WebODM who have told me they are seeing multiple .OBJ exports from a single model. I’ll be sure to reach back out if I can clarify.