I have a fully working renderer that will render a scene with a perspective camera, then clearDepth, then render a scene on an ortho camera. Runs fine on all of my machines and devices, except any browser on OSX… It’s as if OSX doesn’t support it or something, yet it’s a Mac Pro with Dual AMD FirePro’s, plenty of ram, … I’m baffled.
Can you please demonstrate the issue with a live example. I’m also working on OSX so I can easily check if I have the same problem.
BTW: Do you see any errors/warnings in the browser console?
Well, I’m not running raw js… I’ve developed it all in React.JS, so I dunno if that makes any difference. I can’t really replicate it in a fiddle.
But here’s a direct link to the application hosted on a dev AWS bucket…
http://nhc-dev-hosting-nhc.s3-website-ap-southeast-2.amazonaws.com/
The centre of the screen should display ‘NEW HYPOTHETICAL CONTINENTS’ … it’s a textured sprite in ortho view.
I’ve tested on my iMac with Chrome, FF and Safari and I can’t see the sprite. It does also not work with my Pixel (Android 9) and Chrome. Can you please host your application with un-obfuscated/un-minified code? Otherwise it will be hard to debug the issue.
BTW: Are you aware that Chrome does not allow automatic audio playback without a user gesture? Adding a loading screen and a “Start” button can solve this issue.
1 Like
FF and Chrome not showing the sprite for me. I’m on GNU/Linux.
I’ll grab the files and push them up in the morning.
I’m actually using a react library built on soundmanager2 to start and stop the sound, I haven’t had any issues with chrome yet, it seems to completely bypass all of chromes restrictions.
Well, it did not work on my systems where I’ve tested with Chrome. If you want to reproduce this, you should open the URL in an incognito tab in order to ensure no cached resources/settings. Related information:
Interesting… it did not play straight away in an incognito session. I knew of Google’s new Autoplay policy but didn’t think this was affected because it appeared to work fine. 
Here’s a link to my React.JS implementation of a Three.JS project.
https://paste.ofcode.org/sXvC9ReU2XYnkmun32wtLV
Very odd that it works 100% fine on my Windows 10 machine at home, but at work it’s dead. It appears that i’ve got a reply on here that also states that it fails on Linux.
I believe I’m running the same latest version of Chrome across all devices.
Does it make any difference if you don’t inline the PNG but load it from a server? Something like:
new THREE.TextureLoader().load( './path/to/my/texture.png' );
It is from a server right now, but react can’t load a URL directly from itself it has to be webpack loaded so it works but doesn’t. If I load from a http://etc… will work. If I load from a direct source in reacts webpack loader it will work, on my windows 10 machine but nothing else, the alternative was convert to base64 and inline it. Like I did with the other two textures on the page. I didn’t think of that though, that should be my next step…, I should just base64 it and see if it makes a difference.
Hmm. Still the same issue when loading base64 data. It works perfectly on my mobile devices, but not any browser on Mac or Linux. The texture appears to be loading, because I can see it resize to a standard GL size, in the logs. I can preview the texture loaded up in the Network as well… so I know it’s giving the texture loader a real texture. It just won’t display.