Back to the Shapespark home page

PNG or JPG - best performance vs quality?


I usually use PNG files for objects with transparency and JPG for standard textures. If I use PNG for standard materials, is this a difference in size/performance later?
Will PNG files be compressed during the export by Shapespark?

There won’t be a difference in size/performance. Input textures are converted into GPU compressed formats (DXT for desktops, PVRTC for ios and ETC1 for Androids). A handful of devices do not support any of these three formats, but for such devices PNG textures without transparency are converted to JPGs.

For quality using PNG textures as inputs may in some cases be slightly better, because it avoids double compression to lossy format (first to JPG, then to DXT/PVRTC/ETC1).

Okay. Thank you for your detailed explanation, @jan .

I have additional questions about the textures:

  • Are the image sizes identical in the folders img/large/dxt/ ***.ktx with img/small/std/ ***.jpg? Excuse me, I can’t open ktx files.

  • Whether the texture will be in the atlas or not, of which depends? Textures in the atlas are nearly last loaded.

  • Non-atlas textures change their dimensions by what rules? Examples: 1066x532px -> 1024x1024px and 1062x700px -> 1024x512px. Is it a recommendation that we adjust the texture ourselves to these dimensions?

  • I want the textures in the first scene to be loaded before the other textures in other rooms. How can I achieve this?

  • Textures in img/large are at most 2048x2048 and in img/small/ 1024x1024
  • Textures that do not repeat in the scene are in atlas, repeating textures are not do to technical limitations of WebGL. Atlases loading priority is the same as other base color textures, atlases usually finish loading last because they are the biggest.
  • Textures that repeat must have power of two dimensions (WebGL requirement), but the size is converted internally by the pipeline, so it is not required to use power of two sizes in input textures.
  • It is not possible to control texture load priority. You can completely disable progressive loader in the Viewer tab to ensure all assets are available before the user can start navigating the scene.

Thank you @jan
This is my load order, it seems like there is some rule in the order, or this is a lone case.

It is very important for me to extract one image from the opening scene from the last atlas that is being loaded, but I do not know how.

Can you give me some advice, please?

Could you describe your use case. do you need to extract the image to use it via JavaScript API?

Shapespark doesn’t keep and expose textures as images that could for example be used in HTML. One of the reason is that GPU compressed formats are supported only by WebGL, it is not possible to for example populate an HTML <img> with DXT, ETC1 or PVRTC compressed texture.

I’m thinking of changing the name to textures that are in the atlas. The atlas included all my images whose name begins with the letter. Pictures not covered by Atlas are mostly numbered.
The load order from the internet has a descending sequence by numbers, right?
So what I need first to load from textures should start with number 9.
It looks naive but maybe it works?
Certainly, thank you for your time.

Is disabling progressive loader not acceptable solution for you? This would be the easiest thing to do.

You could also put the important texture in some additional hidden place in the scene and make it repeat. This way the texture won’t be in atlas.

Jan, I’m doing a gallery for one artist. Pictures that are not in the atlas are certainly not repeated, and there are still black spots in the atlases.

There may be another reason why they are not in atlases. And I actually want one from the atlases not to be there (it would load faster). I’m trying to understand this.

You gave me good advice @jan . Progressive loader is not necessary in this situation. The presentation was commissioned to show artists paintings, not architecture.
I can tell you that the artist is extremely pleased with Shapespark’s capabilities.
Thank you!

great to hear that :slight_smile: