google-ar / sceneform-android-sdk

Sceneform SDK for Android
https://developers.google.com/sceneform/develop/
Apache License 2.0
1.23k stars 604 forks source link

Wrong encoding on .obj conversion #226

Closed ManuelTS closed 6 years ago

ManuelTS commented 6 years ago

Originating from this issue, when I use the Import Sceneform Asset Wizard in:

Android Studio 3.1.3
Build #AI-173.4819257, built on June 4, 2018
JRE: 1.8.0_152-release-1024-b01 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.15.0-29-generic

with the dependencies:

api 'com.google.ar:core:1.3.0'
api 'com.google.ar.sceneform:core:1.3.0'
api 'com.google.ar.sceneform.ux:sceneform-ux:1.3.0'

and the 1.3.0 Sceneform Plugin for Android Studio, an import from any object inside download number 9 from the link: https://dbarchive.biosciencedbc.jp/en/bodyparts3d/download.html causes Android Studio to give me a

File was loaded in the wrong encoding: 'UTF-8'

error message which is not resolved by reloading the file in UTF-8. It also happens when I use the extracted converter from the sceneform gradle plugin jar file in the google-ar-asset-converter repo of @necrostylery linked in issue #217.

/Edit: I'm on Ubuntu 18.04.1 LTS.

gstanlo commented 6 years ago

I'm having difficulty reproducing this. To clarify, I unzipped a folder isa_BP3D_4.0_obj_99 with 1000+ obj files in it. The first, FJ1252.obj, starts like:

# The license for this database is specified in the Creative Commons Attribution-Share Alike 2.1 Japan. If you use data from this database, please be sure attribute this database as follows: "BodyParts3D, (c)  The Database Center for Life Science licensed under CC Attribution-Share Alike 2.1 Japan".
# http://dbarchive.biosciencedbc.jp/en/bodyparts3d/lic.html
#
#
# Compatibility version : 4.0
# File ID : FJ1252
# Representation ID : BP5633
# Build-up logic : FMA 3.0 is_a
# Concept ID : FMA59763
# English name : Gingiva of upper jaw
# Bounds(mm): (-35.461100,-181.682000,1461.347400)-(34.135000,-127.714200,1479.842700)
# Volume(cm3): 21.758500
#
...

Is this correct?

ManuelTS commented 6 years ago

1.4.0 Came out and it works now. However, #217 persists.