Texture as a Promise
See original GitHub issueDescription of the problem
Loading textures with TextureLoader.load
is great for as long as someone stays strictly within ThreeJS env (since needsUpdate
does all the work.)
When trying to go “outside” of three, for example “change this icon, when texture is loaded” it becomes a bit … dated.
Loader allows only for onLoad
callbacks, which are ok only for as long as you care about a single texture.
When you want to “change this icon, when these 3 textures are loaded”, there are two options:
- chain
onLoad
callbacks (bad) - wrap each
load
in a Promise manually, and.all(...)
them (better)
Would be very nice to have this Promise functionality out of the box (this also makes async / await, which improves readability significantly.)
I can see 1 or 2 nice improvements that could help there:
- (1) Add
.promise(url)
method toTextureLoader
, that instead of Texture returns a Promise (not ideal, but already better, if you care more about loading.)
const textureLoader = new Three.TextureLoader();
Promise.all([
textureLoader.promise(url1), // new Promise instead of new Texture
textureLoader.promise(url2),
textureLoader.promise(url3)
])
.then((textures) => {
// ...
});
Obvious con here is that .promise()
can’t nicely return both texture and a promise… unless!
- (2) Add
PromisedTexture
wrapper extendingTexture
, that would add Promise proto functionality (similarly as CanvasTexture does with canvas.) Promised texture would resolve/reject after initially loading, allowing for handling the async process manually outside of ThreeJS.
const textureLoader = new Three.TextureLoader();
const texture1 = textureLoader.promise(url1); // new PromiseTexture
const texture2 = textureLoader.promise(url2);
const texture3 = textureLoader.promise(url3);
Promise.all([ texture1, texture2, texture3 ])
.then((textures) => {
// ...
});
Three.js version
Latest
Browser
N/A
OS
N/A
Hardware Requirements (graphics card, VR Device, …)
N/A
Issue Analytics
- State:
- Created 3 years ago
- Comments:12 (7 by maintainers)
Top GitHub Comments
How about
Loader.prototype.loadAsync
?If we did this we would have to change all the loaders in the lib. I think it may be easier to make an abstraction in your project.