nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Drone2Map OBJ と SLPK の品質

MarcelVasicek

こんにちは、

D2Mで建物の3Dモデルを作成する際に問題があります。D2Mおよび ArcGIS Pro での .slpk は素晴らしく見えますが、私の主な目的である .obj ファイルを開くと、まったくひどい状態に見えます（下記参照）。City Engine、Meshlab、Blender で開いてみましたが同じ結果だったので、問題はフォーマットか D2M からのエクスポートにあると思われます。.dae も試しましたが、エクスポートされたファイルをどのソフトウェアでも開けず、City Engine でも開けないため品質を確認できません。このような問題に遭遇した方はいらっしゃいますか？

タグ付けされた投稿をもっと見る

Accepted answers

All comments

BenjaminMittler

Thanks Pierre, this helped immensely!

BenjaminMittler

Thanks Mark!

That makes sense, i hadn't checked cloud compare but it shows as expected with global shift applied. I was actually able to view the obj correctly in blender and other software after running the python script @PierreloupDucroix outlined here: https://community.esri.com/t5/arcgis-drone2map-questions/drone2map-obj-and-slpk-quality/m-p/1673193#M1649

PierreloupDucroix

Vote for me : https://community.esri.com/t5/arcgis-drone2map-ideas/offset-obj-mesh-coordinates-to-export-a-file/idi-p/1673191/jump-to/first-unread-message

😉

PierreloupDucroix

I made a script that will shift coordinates of your OBJ file. The result can now be opened in Blender with a normal looking render :

Be careful because the coordinates have now been altered and precision has decreased.

Here is the sample code that you may adapt and test :

input_filename = r'D:\pathTo\Mesh.obj'
output_filename = r'D:\pathTo\Mesh_modified.obj'
# Adapt shift here
x_shif = - 18533500
y_shift = 2538800

with open(input_filename, 'r') as f_in, open(output_filename, 'w') as f_out:
    for line in f_in:
        # Check if the line starts with 'v' followed by a space (to exclude vt, f, ...)
        if line.startswith('v '):
            parts = line.split()
            # parts[0] is 'v', parts[1] is X, parts[2] is Y, parts[3] is Z
            try:
                x = float(parts[1])
                y = float(parts[2])
                z = float(parts[3])

                # Apply the requested shifts
                new_x = x + x_shif
                new_y = y + y_shift
                # Z remains unchanged

                # Write the modified line
                f_out.write(f"v {new_x} {new_y} {z}\n")
            except ValueError:
                # In case of parsing error, write the original line
                f_out.write(line)
        else:
            # Write lines that are not vertices (vt, f, comments, etc.) as is
            f_out.write(line)

print(f"Done. The modified file has been saved as '{output_filename}'.")

MarkBarker1

Hi Everyone,

Thank you for sharing out the datasets and you responses on this behavior. I did some further testing with the 3D viewers that you were mentioning. As @PierreloupDucroix alluded to in his comment above, OBJ files from Drone2Map have vertices that use global coordinate system values with the expectation that the files will be used within GIS software. These values are too large for typical 3D viewer software to accurately convert as these programs don’t typically have coordinate reference system reading built in. Viewers such as MeshLab or Blender are trying to display vertices within a local coordinate system that prioritizes much smaller coordinate values. A global shift is required before the export is made or within a viewing software, such as CloudCompare, where the actual geometry of the vertices is modified to lower precision and can be read within the viewers local coordinate system.

Unfortunately, a lot of these viewers don't have quick and easy ways to apply this global shift. We are going to look into if its possible for us to export the OBJ format with the shift applied. In the meantime, if you would like to log an idea for this on our ideas page you can track any progress we make.
https://community.esri.com/t5/arcgis-drone2map-ideas/idb-p/arcgis-drone2map-ideas

Regards,
Mark

RockRunEnterprises

Appreciate the research and responses!

PierreloupDucroix

We ran tests with Mark, and it seems to be a software issue related to how geographic coordinates are handled.

Apparently, Blender (or the Windows 3D viewer) fails to display OBJ files correctly with certain coordinates.

However, if you open your OBJ file in CloudCompare, the software will offer to convert it to a local system, and the mesh will then display correctly.

If you don't accept this offer, the display will be just as disastrous in CloudCompare as it is in Blender.

I'm still looking for a solution for use in Blender or other software.

BenjaminMittler

@MarkBarker1 Hey Mark, sending you an email now. What the user shared above is exactly what i'm seeing as well.

-Ben

PierreloupDucroix

I'm still encountering the same problem with version 2025.2.0.

The result is always disastrous for the OBJ file, even if the SLPK file is correct.

MarkBarker1

Hi @BenjaminMittler ,

The OBJ should be identical in quality to the SLPK format. If that's not what you are seeing then I would like to get a look at the dataset if possible. Please feel free to email me directly: mbarker@esri.com

I can setup a file share and investigate further.

Regards,

Mark

BenjaminMittler

@CodyBenkelman Was this ever solved? Any idea why this is still happening in 2025?

RockRunEnterprises

I asked about the issue of multiple folders and files a while back in the beta testing. Apparently no way to resolve this yet?

I also wanted FBX files as they are easier and smaller to handle.

PierreloupDucroix

Hello,

I have the same issue, OBJ is looking horrible and is barely usable

and DAE is composed of many small files ordered by level of detail, which I don't know how to use in blender or another 3D software.

Did you find a solution ?

会話に参加する

サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。

クイックリンク

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.