Are we not able to serve a USDZ file on Wix Studio?
I just want to have it as a download link. Which on Apple devices means it’ll launch into QuickLook and an AR experience.
But, the file manager says USDZ is not allowed.
The file share system says USDZ are not allowed.
Seriously? Am I missing something?
Are you able to share where you’re seeing the difference in ability?
In the meantime, I found someone who created a walkthrough on how to add USDZ to Wix - USDZ on Wix.com for free (on Mac) | by Marcin Kulwicki | Medium
Oooooo - @christopher-derrell is our resident AR/3D expert.
Any insights here?
That’s a nice workaround. I also know that we can npm Google’s model viewer, but in both of these scenarios the actual usdz file is being hosted elsewhere.
So, it appears it’s not a supported file format inside the media manager. If you upload, it gives you an error saying so.
So, I thought, well, maybe the file share app has more capabilities, but it does not even let you choose a usdz file to upload. I can zip the usdz, of course, but that defeats the purpose of serving usdz files for view on Apple devices which automatically prompts QuickLook for an AR experience.
For example: Quick Look Gallery - Augmented Reality - Apple Developer
Yep! That would defeat the purpose especially since the Z in USDZ means its already zipped, as I’m sure you know.
My suggestion would depend on your model’s functionality. If you don’t have animations baked into it, Model Viewer will actually convert a GLB file to USDZ on the fly, so that you can use QuickLook. I’ll see if I can spin up an example for you.
If it does have animations, you’ll likely need a separate hosting provider and another library as Model Viewer doesn’t support USDZ.
My recommendation would be to convert it to a GLB (using an online converter or Blender if it’s just one model) and host this instead.
haha yes, we want to stay away from the zip inception…
I did not know that about the ModelViewer. In some, very few, cases this may be somewhat, sort of, kind of, okay-ish? But, for the most part it is desired to have the on device AR experience with more complex and animated objects. Are you saying that Wix Studio will host GLB but not USDZ?
Does Wix Studio intend on supporting the USDZ/USDA file format in the future?
I’m actually wanting to build something around that entire experience, soooo I might have tears in my eyes atm. It’d be nice to not have to spin up a host somewhere else.
Yep, Wix will handle the GLB file, complete with its animations. It will still give the on device AR you’re looking for across Android and iOS although it won’t be as crisp as the QuickLook.
Here’s an example of how it looks, some of these models have animations - https://derrellchristopher.wixstudio.com/lix-demo/ar
(Apologies about the mobile header , this is a site we experiment on and is being replaced by a newer one)
This isn’t bad though.
There’s something weird happening with the scaling. Seemed like most times it loaded in with the camera central object, one time it didn’t. I wonder if that’s controllable?
But, as far as quality and performance, it’s not bad for viewing a basic model. Looked as good as anything else.
I did try it on an old Galaxy S9, and that was not a good experience. I assume the new Android devices perform better? (might run up to BestBuy to test haha)
Alright, so are you using https://modelviewer.dev/ package for this?
And maybe, we can also ask the file format gods to grant us usdz/usda in the future?
Edit: digging through the docs on ModelViewer. I hadn’t really spent much time looking at it before. Seems solid and the goto choice for web view. Looks like they plan to support animation in the future with their on-the-fly usdz.
Here’s the thing. I had considered using Wix Headless to drive auth and data on an iOS app that would serve USDZs. 
Hmm… I set it up real quick, but I am only get a blank element.
npm, google modelviewer
public file: model-viewer.js
import ‘@google/model-viewer’;
set all the attributes
url’s correct, didn’t work
uploaded spaceman into media and copied local url
still didn’t display
source code shows element with all the right stuff, but also a lot of extra style written in?
<model-viewer src="https://modelviewer.dev/shared-assets/models/NeilArmstrong.glb" shadow-intensity="1" poster="https://modelviewer.dev/shared-assets/models/NeilArmstrong.webp" ar="true" environment-image="https://modelviewer.dev/shared-assets/environments/moon_1k.hdr" camera-controls="true" touch-action="pan-y" style="width: 100%; --wst-color-fill-background-primary: rgb(20, 17, 20); --wst-color-fill-background-secondary: rgb(32, 31, 35); --wst-color-text-primary: rgb(217, 216, 221); --wst-color-text-secondary: rgb(60, 60, 66); --wst-color-action: rgb(130, 130, 133); --wst-color-disabled: rgb(33, 32, 38); --wst-color-title: rgb(217, 216, 221); --wst-color-subtitle: rgb(60, 60, 66); --wst-color-line: rgb(217, 216, 221); --wst-button-color-fill-primary: rgb(130, 130, 133); --wst-button-color-border-primary: rgb(130, 130, 133); --wst-button-color-text-primary: rgb(20, 17, 20); --wst-button-color-fill-primary-hover: rgb(130, 130, 133); --wst-button-color-border-primary-hover: rgb(130, 130, 133); --wst-button-color-text-primary-hover: rgb(20, 17, 20); --wst-button-color-fill-primary-disabled: rgb(33, 32, 38); --wst-button-color-border-primary-disabled: rgb(33, 32, 38); --wst-button-color-text-primary-disabled: rgb(20, 17, 20); --wst-button-color-fill-secondary: rgb(20, 17, 20); --wst-button-color-border-secondary: rgb(130, 130, 133); --wst-button-color-text-secondary: rgb(130, 130, 133); --wst-button-color-fill-secondary-hover: rgb(20, 17, 20); --wst-button-color-border-secondary-hover: rgb(130, 130, 133); --wst-button-color-text-secondary-hover: rgb(130, 130, 133); --wst-button-color-fill-secondary-disabled: rgb(20, 17, 20); --wst-button-color-border-secondary-disabled: rgb(33, 32, 38); --wst-button-color-text-secondary-disabled: rgb(33, 32, 38); --wst-color-fill-base-1: rgb(20, 17, 20); --wst-color-fill-base-2: rgb(217, 216, 221); --wst-color-fill-base-shade-1: rgb(32, 31, 35); --wst-color-fill-base-shade-2: rgb(33, 32, 38); --wst-color-fill-base-shade-3: rgb(60, 60, 66); --wst-color-fill-accent-1: rgb(130, 130, 133); --wst-color-fill-accent-2: rgb(130, 130, 133); --wst-color-fill-accent-3: rgb(130, 130, 133); --wst-color-fill-accent-4: rgb(130, 130, 133); --wst-color-custom-1: rgb(33, 32, 38); --wst-color-custom-2: rgb(217, 216, 221); --wst-color-custom-3: rgb(174, 173, 177); --wst-color-custom-4: rgb(87, 86, 88); --wst-color-custom-5: rgb(43, 43, 44); --wst-color-custom-6: rgb(243, 248, 240); --wst-color-custom-7: rgb(210, 228, 199); --wst-color-custom-8: rgb(146, 176, 121); --wst-color-custom-9: rgb(97, 135, 65); --wst-color-custom-10: rgb(57, 100, 29); --wst-color-custom-11: rgb(242, 234, 231); --wst-color-custom-12: rgb(229, 206, 192); --wst-color-custom-13: rgb(169, 128, 111); --wst-color-custom-14: rgb(139, 97, 79); --wst-color-custom-15: rgb(99, 60, 43); --wst-color-custom-16: rgb(255, 233, 223); --wst-color-custom-17: rgb(255, 191, 161); --wst-color-custom-18: rgb(250, 133, 79); --wst-color-custom-19: rgb(234, 96, 32); --wst-color-custom-20: rgb(201, 64, 1); --wst-font-style-h2: normal normal normal calc(42 * var(--theme-spx-ratio))/1.3em madefor-display-bold,helveticaneuew01-65medi,helveticaneuew02-65medi,helveticaneuew10-65medi,sans-serif; --wst-font-style-h3: normal normal normal calc(38 * var(--theme-spx-ratio))/1.3em madefor-display-bold,helveticaneuew01-65medi,helveticaneuew02-65medi,helveticaneuew10-65medi,sans-serif; --wst-font-style-h4: normal normal normal calc(34 * var(--theme-spx-ratio))/1.3em madefor-display-bold,helveticaneuew01-65medi,helveticaneuew02-65medi,helveticaneuew10-65medi,sans-serif; --wst-font-style-h5: normal normal normal calc(28 * var(--theme-spx-ratio))/1.3em madefor-display-bold,helveticaneuew01-65medi,helveticaneuew02-65medi,helveticaneuew10-65medi,sans-serif; --wst-font-style-h6: normal normal normal calc(22 * var(--theme-spx-ratio))/1.4em madefor-display-bold,helveticaneuew01-65medi,helveticaneuew02-65medi,helveticaneuew10-65medi,sans-serif; --wst-font-style-body-large: normal normal normal calc(18 * var(--theme-spx-ratio))/1.6em madefor-text,helveticaneuew01-45ligh,helveticaneuew02-45ligh,helveticaneuew10-45ligh,sans-serif; --wst-font-style-body-medium: normal normal normal calc(16 * var(--theme-spx-ratio))/1.6em madefor-text,helveticaneuew01-45ligh,helveticaneuew02-45ligh,helveticaneuew10-45ligh,sans-serif; --wst-font-style-body-small: normal normal normal calc(14 * var(--theme-spx-ratio))/1.6em madefor-text,helveticaneuew01-45ligh,helveticaneuew02-45ligh,helveticaneuew10-45ligh,sans-serif; --wst-font-style-body-x-small: normal normal normal 12px/1.4em din-next-w01-light,sans-serif; --one-unit: 1vw; --theme-spx-ratio: 1px;"></model-viewer>
Ahh, you’ll need to do a bit more work to get it working! It’s better to import it like you did through NPM, but you’ll need to wrap it in a custom element. Here’s a tutorial video I had done a while back (it should still work) https://www.youtube.com/watch?v=y-p-M8SGHik&t=12s
If you’re looking for a really quick implementation of it to just make sure it works, you could also use my (shameless plug) Wix App - LixAR | Wix App Market | Wix.com. That’ll do all the setup for you.
Interesting, I did exactly that. npm, .js in custom-elements folder, import @, custom element, named model-viewer, put in all the attributes, checked that the url’s were correct, it prints in the source, but it’s just a blank element.
Hmm, super strange. I just tested your code out and it loads right. This is a non-Wix environment, but it should work the same.
Try setting the actual Custom Element tag through the Wix UI to model-viewer
Ah! I remember now. It’s likely thea Three JS dependency issue. You’ll have to go to a version before they bundled in Three JS. A safe version I use is 2.1.1
Ah, okay. Spaceman has landed! That was it.
Any idea on when we might be able to implement the latest version?
I can’t seem to get the size of the model-viewer window to respond to anything. It’s quite small, and doesn’t respond to the custom component size. Tried attributes. Tried some CSS, not working. How do you actually target it?
It’s picking this up from somewhere, and I can’t seem to override it…
:host {
display: block;
position: relative;
contain: strict;
width: 300px;
height: 150px;
}
Soooooo, looks like the Wix Studio team might be making adjustments to this situation on the back end. We now have a situation where it scales to it’s parent object. I thought I had solved it, but my CSS wasn’t actually showing up. There’s actually new CSS from the backend driving the change. So, if that’s the case, then that’s awesome!
I do think this is a good solution to model viewing in page. However, my one gripe atm is that ModelViewer is compressing the heck out of the textures when converting to USDZ on the fly. It comes out with so much noise, maybe version 4 is better quality?
I have also noticed when I import and export the existing USDZ from Blender and open that with a gltf viewer, the lighting is weird, much darker. Looks fine in page.
I guess it’s just one of those things where we’ll have to have separate files for each device type for a while, but right now the ModelViewer severely cripples Apple’s QuickLook experience. So, I would still very much still like to see the USDZ file format supported.
Absolutely. Unfortunately some of these bugs with the colours of the element were actually corrected in the later versions (with the decoupled shaders). Using 2.1.1 you’re at least one major version behind the main version. Yep you’re very right, version 4 is supposed to be better with shading, which corrects some of the colour issues. It would just be to handle the external Three JS dependency and you’d be good to.
As it is, you can also correct some of that weird lighting & appearance now, with your environment settings in Model Viewer, and controlling the metallic/roughness nature of the model itself before upload.
It did also come to mind today that if you have a USDZ file hosted elsewhere, you can still set it as the ios-src to trigger that as the QuickLook version (with lighting and everything) when the visitor puts their device into AR mode. It’s just that this model will not be used to render the model on the website.
yeah, I did see that. Obviously, I would love to just be able to upload a USDZ like I can the GLB on Wix Studio 
Also, curious, have you tried using the latest version through script embeds rather than npm? I was thinking about giving it a shot…