Hey there, been using playcanvas for well over a year now. Have experimented and been fairly successful at various usecases. We recently created an online virtual store solution for big clothing and e commerce brand.
Here is the link to it :
(Playcanvas loads up after selecting one of three zones)
Go ahead and give it a try. We just made it available for public.
However, I noticed that the chunk of performance used by the scene is fairly on the higher side if you ask me. I mean, the scene only contains 360 sphere and with either 4K/8K renders on inner side of it. And there’s a pretty solid backend inventory system which can be used to update any products realtime.
My question is this, if there’s no evident 3D/high-poly models/heavy textures/complex geometry, the GPU and CPU usage in some decent laptops is pretty questionable.
The only thing that may be problematic is 8K texture lookups, some lower end GPUs may not support that big textures. Though I think in that case the texture won’t render at all, instead of rendering at a lower FPS. @mvaligursky any idea?
I tried it on some old cheap laptop, and that feels bit slow on occasions … like loading / swapping scenes seems to create some slowdowns. I guess a profiler is the tool to use, both the one @Leonidas mentioned, but also JS profiler, to see what could be causing it. I captured couple of screens using SpectorJS and rendering seems ok, no problem jumped out at me on the GPU side.
Could be VRAM related? I noticed that the textures aren’t hardware compressed with Basis which would mean VRAM usage could be high? Looking at the app, it’s on 157MB which isn’t that much for desktop
to me this seemed like a CPU issue, not GPU - when the data are loaded, it renders fine. The problem is when UI needs to pop up, when assets for sale are loading and similar. Possibly even some memory leak / unreleased callbacks as it seems to go even slower after few reloads. But I didn’t test it enough to confirm.
I don’t think 8K textures are the problem, coz they will just add up to the project size and stay in memory, use some GPU resources to keep rendering (and yes, if GPU wont support 8K, it would crash or atleast show weirdly rendered textures). I was more of hinting at the core rendering system if I’m missing some vital things, or project settings that I might not know of.
Yes even decent GPU should be fine for whole scene. But I noticed, latest intel HD GPU always maxes out while this scene is active (which is natural) but I have seen few examples particularly with PBR textures, 360 scenes, and 3D geometry or just a regular environment with animated 3D/2D
elements from other sources…They don’t really take a toll on the CPU/GPU at all (even integrated graphics).
The assets that are loading up dynamically get added up to the list of network calls that I make. Once loaded, they’ll just sit in the memory as long as scene is active.
Also, can you suggest how I can test (apart from inbuilt profiler) for memory leaks and advanced stuff like that. I want to make the best out of playcanvas so that we make more and more experiments.
No, I decided to compress them beforehand, before importing. Since basis requires ‘power of 2’ textures, It would be tedious for the designers to specifically carve out every texture like that, wouldn’t have gone hand-in-hand with the flow of pipeline.
But yeah as you said, it could’ve been VRAM too. but the scene hasn’t crashed on any device we tested (even 4-5 year old devices) Gotta give kudos to the compatibility there haha.
So what’s been happening was, the CPU utilization of the scene is unreasonably high on decent devices (like, 2018 Macbook pro). I mean the scene uses lot of CPU chunk for displaying just 360 renders and dynamic images, atleast 25-30%
I anyway use this :
this.app.autoRender = false;
to pause/resume the rendering of whole scene whenever required. This is the only way to drop all the rendering and give it a breather.
Yes, I’m using Device pixel ratio coz it seems to give a significant difference and a boost in overall quality. Have to test out what result it gives after turning off the device pixel ratio.
Yeah that explains it a bit, the MacBook screens tend to be high resolution so rendering a full screen at native does tend to tax the CPU/GPU (integrated) due to pixel fill rates.
You may want to detect if the user has a dedicated GPU and the resolution they are rendering at and adjust the pixel device ratio accordingly.
Or do what you doing now with auto render and perhaps use a lower pixel ratio when the user is moving the camera and switch back to native pixel ratio when they stop.
).
