After initialization it runs perfectly smoothly for me, constant frame rate, no drops.
I’ve tested it on many devices with many browsers with hardware acceleration turned off, and it’s the same story.
The only issue is initialization time, I managed to reduce the shader compile time significantly but it’s still a bit slow on Firefox for slower devices.
However my friend gave it a go on his mid-range PC and the results were very different:
When the cursor icon grabs he is clicking and dragging the Orbit Control camera. It’s hard to tell there is any responsive input because the lag is so unbelievably bad. It’s less than 1fps.
It was the same with every browser he tried on this particular device.
He’s not the most technically minded so all I could get from him was the PC had an i5 processor and it’s a touch screen.
Perhaps someone could shed some light as to why this device is struggling so much? Is there anything I can do to fix it? Are there some features I’m using (like PCFSoftShadows) that incur a huge cost in certain environments?
Apologies for the lack of technical details but the app is now live if you want to see for yourself.
Excellent work! This is an example of using technology to actually increase usability, WOW factor, and salability of the products, instead of “torturing the user” like in most cases.
My low-range old PC + a relatively recent low-mid range graphics card (GTX1650) runs it fine.
Apparently your friend might not have a graphics card at all - it might be embedded In the motherboard using the CPU display features or something.
What are his/her PC specs?
About the 3D load time, on my 50Mbit line it took 14 seconds on Edge.
Then I disabled cache, waited for the main page to load, and after hitting “preview” it took 22 seconds. There is obviously room for optimizations here, as in an older ~10Mbit line it might take 5 times longer.
That said, loading time might be affected by my weak CPU.
I’ve just pushed a small update that includes 2 improvements:
Loader now has 3 stages - “Loading 3D interface” (THREE.js + app JS), Loading 3D Model (GLTF download) and Initializing (finishes when the first frame of the scene is rendered after all shaders are compiled)
Using a library called detect-gpu that does some sniffing for GPU capabilities. It returns a value of 0,1,2 or 3 depending on the quality of your gear. I’ve set it to now to reduce resolution and shadow quality depending on this number.
The app script is 813.36 KB but gzipped to 221.40 KB. Each scene is a 3D model GLTF draco compressed to between 1.5-2 MB. There’s also the additional draco decompression script but that’s another 350KB
At 50Mbps and delivered via a CDN it should take very little time to download.
Your long load time suggests you’re also experiencing long initialization times compiling those shaders. I don’t understand why my particular app has this problem so bad. I’ve managed to reduce the number of shaders drastically but it’s clearly still an issue.
I would be grateful if you could test it again and tell me at what stage of loading it hangs for 14 - 22 seconds.
I tried twice with Edge and counted 16-17 seconds of 3D scene loading.
On ‘Firefox for Developers’ at one time it took about 17 secs the second time about 24-25.
I profiled it on FF for Dev twice, and FF allows to upload it to their servers.
So here are the two links (those who have the links can see it), to download and see it exactly as I did (interactively).
From the series of screenshots at the upper row you can easily see how long it took for the main page, the preview button and the 3D scene to load.
The Edge profiler adds way too much overhead on my PC and it appears to be more focused on analyzing the first few seconds.
EDIT:
I did one more profiling on a powerful PC with 100Mbps line and Quad9 DNS (I’m using CloudFlare) and everything loaded very fast! I didn’t expect such difference myself!
Thank you for that. Very discouraging though to see it’s not your network at fault but the app initialization.
I have no idea why it’s taking so long, unfortunately all of the data recorded in the call tree / flame graph does not appear to relate to the app itself. Is it possible you’ve recorded the performance of the debugger itself?
In particular the parent process in the first recording is almost empty while it’s saying ‘Loading 3D models 100%’, I would expect to find lots of calls relating to shader compilation.
@dllb
I updated the app earlier with some improvements.
I was originally using SVGLoader and processing an SVG on the client-end to produce the wall decal mesh. Not only did this result in a lot of unnecessary work for the user’s machine, but due to the complexity of some of the SVGs and the lack of any mesh simplification it was resulting in a huge amount of tris. One model in particular was producing a mesh of 246,000 tris.
So now I’ve pre-processed all the stickers to reduce the number of vertices/tris and uploaded them as compressed GLB models.
The sticker geometry is around 1/10th of what it was without any noticeable change visually, and almost no processing required to load using GLTFLoader to parse and draco decompression.
Would be curious to know how it performs on your old machine now.
Thanks for all your help.
It’s faster, but obviously the main bottleneck is something else.
BTW It’s not only the CPU slow, it’s the motherboard too. It’s a cheapo one ( GA-G41M-Combo) I had bought after a very expensive (and awesome) Asus one died (hundreds of euros)- and I immediately noticed a huge drop in speed on everything. So don’t take it very seriously, it’s just a motivation to keep optimizing the code…
Thanks for that additional profiler recording. Unfortunately the call tree still isn’t recording the app but I’m pretty sure I can make sense of it now.
The only timespan I’m interested in is between 100% download completion and the first frame rendering. If I compare the last profiler recording and the first one you sent me, they both took almost exactly 10 seconds in this respect.
Originally I thought the loader’s text was an issue, as it continued saying ‘Loading 3D Models 100%’ for so long, but after checking my code I realised it was working correctly. Which suggests the bottleneck for you is the draco decompression algorithm working.
Was thinking about this and thought maybe I could serve both compressed/uncompressed models to users based on a guesstimate as to which will load faster… But without knowing the user’s network speed it’s a bit of a coin toss.
Thanks again for your help and further clarification on your setup.
