Product Configurator for Knife Maker Deglon

Hey everyone !

My first project with playcanvas is now online, and has been used this weekend in a french show/exposition, called Made In France.

So far everything seems to work, so I’m satisfied :smiley:

Here you can try it : Knife Configurator for Knife Maker “Deglon”
Basically you can choose a blade/handle/wood type , and add a decor or some text on it.
It’s linked with Prestashop and the configuration is stored in the cart of the visitor.

Still some work to do on this V1 of course, but I learned a lot (thanks everyone who helped in this forum!) and I’m going to stick with Playcanvas for my next projects (2 more configurators incoming :slight_smile: ).

Don’t hesitate to share your thoughts, I’m alone in this so it’s not easy to see everything when you have your nose on the same things all day haha.

3 Likes

Ah, that brand logo on the knife looks good! Well done.

1 Like

Great job, @TonyLGC.

Are you still in a position to update the app? I strongly recommend making some optimizations. Currently, the page loads 256MB of resources:

Of this, 214MB is PNG data. You have several 4096x4096 PNG textures reaching up to 18.9MB each.

This means that the page is taking a very long time to load.

To improve things, I would suggest the following:

  1. Can any of the textures be downsampled without compromising visual quality too much? e.g. 4096x4096 to 2048x2048.
  2. Can you compress any of the textures with Basis? Basis can lower texture quality a bit, but for some textures, it’s reasonable. The savings are massive though. Currently, I suspect this configurator will not work on some mobile devices because the browser tab will run out of memory loading the huge PNGs. Basis fixes that.
  3. Almost all textures are PNG but JPG will compress better (despite being a lossy format). For textures that look bad when Basis compressed, I would recommend JPG over PNG (providing you don’t need to store an alpha channel, which JPG doesn’t support of course).
  4. I believe you are loading everything ‘up-front’. In other words, all assets are preloaded. I suggest disabling preload for any asset that isn’t required for the initial view and then asynchronously loading everything else after that. So, preload the palissandre texture, but do not preload ebene, genevrier, bouleau and olivier. Read more about preloading and streaming here.
  5. Verify that all assets being loaded are actually used by the app. Scan the Network tab for resources you don’t actually need and delete them from your project.

I would estimate that this app could go from loading 256MB of resources to under 10MB if the recommendations above were adopted.

5 Likes

Wow, thanks a lot for the advice!
Yep I’m still going to work on it, this is a first version and I admit that I haven’t optimized anything yet, I only focused on having something that works :sweat_smile: .
These textures are indeed huuuuge, didn’t realize that ! On the expo they used it on an ipad with a good internet connection, but some visitors might indeed have trouble with this.
I’m definitely going to look at your tips, thanks again :wink:
(I’ll update this post updated to show the change when its done)

Cool. :grinning_face_with_smiling_eyes:

By the way, here’s your biggest texture chenevert.png (18.9MB download using 48MB of video memory):

And as a Basis texture (2.4MB download using 22.4MB video memory):

It would be even smaller if it was 2048x2048. Is that texture even used by the app? I couldn’t see it after selecting the various options.

1 Like

Another minor point. Experiment with texture anisotropy.

This is your current app:

This is the difference when you bump the texture anisotropy up from 1 to 4:

(Click an image above and press left/right arrow keys to flip between them to see the difference - especially on the logo!)

1 Like

Haha, indeed, no reason to keep those big files !
This particular texture has been disabled for the expo but will be used again soon. (So another reason to not preload everything :slight_smile: )

edit: Ah yes, that anisotropy change is nice too. Even cooler on a big decor like this one :


(you can try it with this activeConfig.bladeDecoration.recto = 102 )
Does it have an impact on the performance?

1 Like

Good question - yes, there is a cost to the GPU and this increases as you increase the value of anisotropy. However, I suspect that it won’t cause you to start dropping frames. That said, I always recommend having a few old Android/Apple phones around to test on.

Another tip:

Check out the optimization guidelines page in the User Manual. Especially this recommendation:

  • For applications where there is little visual change over a period such as product configurators, there is a specialist property to reduce CPU and GPU usage. pc.Application#autoRender can be set to false so that frames are rendered on demand via pc.Application#renderNextFrame when there is a visual change such as the user moving the camera or adding a part to the product.
1 Like

Hi everyone :slight_smile:
I’ve reduced the handle textures to 2048x2048 a converted them as JPG, that did indeed make a huge change at load time, and no impact on the quality :slight_smile:
Also pushed the anisotropy to 4 on all the decors, it makes a nice change (even if I’m the only one noticing it haha)
the Basis compression made things a bit too blurry, and now that the textures aren’t so big anymore it’s not really usefull I think.


image

Also, I tried too play around with the autorender property but finally I won’t use it in this configurator, I had to add renderNextFrame in too many places in my code haha, it’s too dangerous for this project. (my code quality isn’t really top notch, yet :sweat_smile: )
But I will definitely keep this in mind for my next configurators!

2 Likes