Need some help rendering a very large jpeg to a scene

Questions
1

I have a scene that is made up of a grid of 10 x 2 unique jpeg textures. Each texture is large at 1000 x 1000px as the image is an intricate hand-drawn artwork that recreates a real-world 10m x 2m piece.

When I first started on the scene, I thought to load the image as one large texture. This seemed to work on desktop and it kept the file relatively small (4-5 MB) but was overly compressed and resized on mobile.

The second idea I had was to divide the image into the 10 x 2 grid which got around the compression and resizing on mobile but now have the problem of 20 HTTP requests being made for images that are circa 500kb each (or 10 MB in total) and is very slow to load.

eg.

const materials = [ new THREE.MeshBasicMaterial({map: textureLoader.load(tile_01)}), new THREE.MeshBasicMaterial({map: textureLoader.load(tile_02)}) ...

Is there a way I can import the entire image and split it/position it in Three without the mobile version resizing it and leaving it pixelated? I have read a bit about THREE.Sprite, texture.repeat, texture.offset, and using THREE.Group and positioning the sprite in the group however I feel I need a steer in the right direction.

Thanks!

2

  1. That is not a large texture. As a rule of thumb anything below 2048px is “small”, 2048 can be considered standard resolution, above 2048 is “big”. Even large amount of 1000px textures shouldn’t significantly affect performance on mobile or desktop.

  2. The problem with using one big texture that keeps multiple texture (ie. a “texture atlas”) is that, unless it’s a collection of minecraft 32x32 sprites, you may quite quickly hit WebGL texture size limits (around 16000px x 16000px atm of writing.) Using texture atlas may speed up shaders compilation a bit (since you upload image to GPU only once), but not sure if it’d have a useful influence on compression.

  3. Pixelation may be caused by the fact that 1000x1000 images are quite small - viewed up-close may just not look good, unless you increase that resolution.

  4. If you have 20 images - having 20 HTTP requests is to be expected. I wouldn’t overthink that part - that’s how resources are delivered in the browser :sweat_smile: (if you’d really like to avoid it, you can zip the images and unzip them on the client - example on donmccurdy/simple-dropzone.)

  5. Loading time is and will be there. Even if you compress your images 100x times, users at 3G will still experience the loading as slow. The best thing you can do is a) preload images before you start rendering, and just show a loader; b) load small (ex. 128px x 128px) blurry versions of all images first, to render something at all, then in the background load HD versions - that way user can interact will your app while you fetch heavy images (you can see a good example of that on Sketchfab.com.)

3

…for a model that spans the entire screen, yes. for something smol that renders at ~300 pixels max you probably dont want to go above 512px

4

load smaller versions first, and then continue loading high-res versions after presenting the scene to the user?