Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add remark about differing size units between glTF/glb and USDZ #559

Closed
PixelPartner opened this issue May 20, 2019 · 12 comments · Fixed by #1180
Closed

Please add remark about differing size units between glTF/glb and USDZ #559

PixelPartner opened this issue May 20, 2019 · 12 comments · Fixed by #1180
Assignees
Labels
arc: ar arc: compatibility flag: documentation flag: partner Issues or PRs opened by an integrating partner, or affecting one in an important way

Comments

@PixelPartner
Copy link

The README recommends to use meter as unit size. Note about units and model size in AR. Please add a note that USDZ exports should be in centimeter instead and may need scaling, or iOS users will see models 100 times smaller.

@cdata
Copy link
Contributor

cdata commented May 20, 2019

@PixelPartner thanks for the feedback. I have it on good authority that 1 unit is treated as 1 meter by AR Quick Look, but I cannot find any definitive documentation on the subject. Can you share a link to documentation from Apple or Pixar on this subject? Or perhaps a reproducible demo that confirms what you are claiming?

@PixelPartner
Copy link
Author

PixelPartner commented May 21, 2019 via email

@cdata
Copy link
Contributor

cdata commented May 21, 2019

This may be true, but that does not mean that Quick Look does not specify a metersPerUnit for its UsdStage.

Other engineers who are subject mater experts in this area have confirmed for me that Quick Look treats 1 unit as 1 meter.

If you can you give me the steps to reproduce what you saw Quick Look doing, I can review that with the other engineers. Perhaps we will learn something interesting :)

Sadly, Apple's documentation on this topic doesn't seem to exist. If you can't give me repro steps, I have to trust the guidance of the other engineers who have more expertise in this area.

@PixelPartner
Copy link
Author

PixelPartner commented May 21, 2019 via email

@cdata
Copy link
Contributor

cdata commented May 21, 2019

@PixelPartner ultimately we are not in control of what a user decides to set as their metersPerUnit. I will propose that we change our documentation to remind users that while we recommend metersPerUnit should be set to 1, ultimately they must decide for themselves what the value should be.

@PixelPartner
Copy link
Author

PixelPartner commented May 21, 2019 via email

@PixelPartner
Copy link
Author

PixelPartner commented May 21, 2019 via email

@PixelPartner
Copy link
Author

PixelPartner commented May 21, 2019 via email

@PixelPartner
Copy link
Author

But the discussion also mentioned that metersPerUnit is a very new property.
Too new to be supported by Apple's usdz_converter and some other tools.
The old standard was centimeters, and that's why the fallback for the new property is 0.01[m].
I'm still not sure about a helpful wording.

@pushmatrix
Copy link
Contributor

FYI metersPerUnit is now working in iOS13. It also supports channel packing, so it will use the same ORM texture from the glb in the usdz.

The problem is that this will only work on iOS13. It will be ignored on iOS12 resulting in the model being way too big.

How we got around it at Shopify is to only show the AR badge on iOS13 and above.

@cdata cdata added the flag: partner Issues or PRs opened by an integrating partner, or affecting one in an important way label Oct 10, 2019
@cdata cdata modified the milestones: v1.0.0, v0.9.0 Feb 3, 2020
@cdata cdata modified the milestones: v0.9.0, v1.0.0 Feb 11, 2020
@smalls smalls self-assigned this Apr 27, 2020
@smalls
Copy link
Contributor

smalls commented Apr 29, 2020

I've proposed a small change to mention size units as part of general verification of converted output. In general there might be more recommendations we can give but I'm not sure how we'll keep them up to date. We've had a long-standing interest in tooling here (#278) which seems like potentially a better answer than a guide.

@rianlukog
Copy link

Facing some issues regarding size scaling, wondering what is the best way to go about it. My 3d model looks good in the 3d view port but upon opening the AR port the model is so tiny that it is barely visible and is often off-centered to the right

Explanation video and post: #2526 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arc: ar arc: compatibility flag: documentation flag: partner Issues or PRs opened by an integrating partner, or affecting one in an important way
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants