Edge, Safari, and Firefox mobile display my threejs/webgl FBX loader fine. For a few days, Firefox Desktop did as well. However, now Firefox Desktop displays a black screen. Anyone know how I might fix this?
No errors in the console. I checked webgl is enabled. Tried with Hardware acceleration both on and off.
Thanks!
This example : FBXLoader - JSFiddle - Code Playground works for me in Firefox 111.0.1 (desktop)
Thanks. Appears to be related to my exports from Substance Painter. The way its encoding FBX and GLTF seems Firefox doesn’t like. Though it could also have to do with hosting it in a Linux system. Either way seems Firefox suddenly started to hate my files
This is hosted on Linux and works in Firefox. (Ubuntu 20.04 & Nginx)
FBX Animations : https://sbcode.net/threejs/fbx-animation/
So you can rule out those.
1 Like
After a bunch of testing I think it’s an issue on my host side (godaddy with wordpress)
It seems to be blocking the threejs examples that load gltf/FBX files. Even attempting to download them didn’t work until I manually added the mime types. Now I can download the fbx files directly, but their system is still blocking the examples from loading FBX/Gltf files such a pain.
It might be something very unique/specific to my browser, maybe antirvirus. Would you mind seeing if you can view this? I doubt that’s the case since I can see examples on the three JS site just fine.
Test Page
The test pages looks empty in my Firefox. I switched on XHR
and Requests
in the console to see what resources are being downloaded. The HDR file is marked red:
When I try to manually access the HDR file, I get this content encoding error:
In Chrome there is no problem. The background image is shown and after it the 3D model is shown. Accessing the HDR file directly just downloads it.
1 Like
Thank you! Glad I’m not nuts. I started to feel that way as I’d swear I’d have it working then suddenly it would quit and I’m not doing anything difficult at all I started from scratch and got rid of the HDR using the basic light-probe example. It works fine–for now. Not as pretty but showing up is better
1 Like
I suppose that also eliminates it being a host issue, which would have been obvious if I thought through it, and that it works in other browsers. Or maybe not. Because the threejs samples work fine in firefox. So something is interfering but only happening between the host and firefox–strange it would be isolated to a specific browser
It could be a combination of hosting issue and FireFox attitude towards this issue. I’m not that experienced in this area. Sometimes when a site (or host) is misbehaving, browsers react differently. Some try to work it out, while others are too strict and refuse.
1 Like
Makes sense. Any idea who threejs uses to host their own content?
Could you try the following with your FireFox:
- go to [
about:config
]
- search for [
network.http.accept-encoding.secure
]
- if it says [
gzip, deflate, br
] edit it and remove [br
]
When I do this, the site shows in FireFox (after 2 seconds delay for loading):
Wo - you’re amazing It works! Any idea if that can be coded around? ChatGPT mentions editing htaccess to revise it (something about compression) so might give that a go.
I have absolutely no idea. I found this br
by looking at this:
The browser request says it likes gzip, deflate and br compressed files
The server has sent br compressed file
I don’t know what does this mean:
- FireFox cannot uncompress this br file
- the server cannot produce correct br file
- FireFox and the server use different (incompatible) versions of br
Maybe other browsers work fine by not requesting br files at all? In any case, changing the flag is not an option, as it is rude to ask users to change their FireFox settings. If you find a work-around, please, post it in the thread.
1 Like
Maybe there is some server-side configuration setting that makes the server ignore request for br compression?
Think so, just need to find the right trigger Thank you for everything so far! Super impressed btw!
I tried adding this to htacess but nothing:
For now I emailed godaddy to see if they could provide a simple solution on their end
1 Like
Circumventing Godaddy’s servers worked. They mentioned it’s their policy to not help with web design so it seemed my best path forward for now. Changing the path to reference the HDR from github:
new RGBELoader()
.setPath('https://raw.githubusercontent.com/mrdoob/three.js/b6503a4dc285879556d4e3ea360c93de33529c94/examples/textures/equirectangular/')
.load('royal_esplanade_1k.hdr?v=' + Date.now(), function (texture) {
1 Like