# Model is black while the texture is loading

**URL:** <https://discourse.threejs.org/t/model-is-black-while-the-texture-is-loading/39305>\
**Category:** Questions\
**Tags:** textures\
**Created:** [June 16, 2022, 6:29am UTC](https://discourse.threejs.org/t/model-is-black-while-the-texture-is-loading/39305 "2022-06-16T06:29:37Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![tfoller](https://avatars.discourse-cdn.com/v4/letter/t/3e96dc/32.png) [@tfoller](https://discourse.threejs.org/u/tfoller)\
**Post date:** [June 16, 2022, 6:29am UTC](https://discourse.threejs.org/t/model-is-black-while-the-texture-is-loading/39305/1 "2022-06-16T06:29:37Z")

</div>

As far as I understand, the texture loader immediately returns something like one pixel buffer with (0,0,0,0) color to use till the texture is loaded, and that color, multiplied by diffuse color makes the model black.

Is that correct?

If it is, why not to make that color (1, 1, 1, 1) to preserve the diffuse color of the model while loading?

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 16, 2022, 8:05am UTC](https://discourse.threejs.org/t/model-is-black-while-the-texture-is-loading/39305/2 "2022-06-16T08:05:22Z")

</div>

> [@tfoller](#):
>
> As far as I understand, the texture loader immediately returns something like one pixel buffer with (0,0,0,0) color to use till the texture is loaded,

A `WebGLTexture` object is only created when the texture is fully loaded. Up to that point, the renderer just binds `undefined` to the respective texture slot. So it’s not possible to define a different default color since there is not default `WebGLTexture`.

---

<div class="post-metadata">

**Author:** ![tfoller](https://avatars.discourse-cdn.com/v4/letter/t/3e96dc/32.png) [@tfoller](https://discourse.threejs.org/u/tfoller)\
**Post date:** [June 17, 2022, 2:41pm UTC](https://discourse.threejs.org/t/model-is-black-while-the-texture-is-loading/39305/4 "2022-06-17T14:41:00Z")

</div>

OK, I looked at the code, there is **emptyTextures** object there that is used while the texture is being loaded.

It contains zero pixel, that makes the model black, so here is what I changed:

```javascript
function createTexture( type, target, count ) {
  const data = new Uint8Array([255, 255, 255, 255]); //new Uint8Array( 4 ); // 4 is required to match default unpack alignment of 4.
  const texture = gl.createTexture();

```

so now, the material preserves color while texture is loading, if you re-run this fiddle you can see the effect on modified and unmodified code.

> **[Edit fiddle - JSFiddle - Code Playground](https://jsfiddle.net/tfoller/nx5Ldmqz/27/)**
>
> Test your JavaScript, CSS, HTML or CoffeeScript online with JSFiddle code editor.

So back to my original question - why not make this change in the library, so models always show the color and then acquire texture on top when it’s ready?

---

<div class="post-metadata">

**Author:** ![Umbawa\_Sarosong](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/umbawa_sarosong/32/30107_2.png) [@Umbawa\_Sarosong](https://discourse.threejs.org/u/Umbawa_Sarosong)\
**Post date:** [June 17, 2022, 2:45pm UTC](https://discourse.threejs.org/t/model-is-black-while-the-texture-is-loading/39305/5 "2022-06-17T14:45:23Z")

</div>

dont render while the model is loading

---

<div class="post-metadata">

**Author:** ![tfoller](https://avatars.discourse-cdn.com/v4/letter/t/3e96dc/32.png) [@tfoller](https://discourse.threejs.org/u/tfoller)\
**Post date:** [June 17, 2022, 3:54pm UTC](https://discourse.threejs.org/t/model-is-black-while-the-texture-is-loading/39305/6 "2022-06-17T15:54:08Z")

</div>

This way you can give an “average” texture color to your model first and then swap it to white when the texture is ready to deliver a smoother loading experience:

> **[Edit fiddle - JSFiddle - Code Playground](https://jsfiddle.net/tfoller/7dkjcn03/12/)**
>
> Test your JavaScript, CSS, HTML or CoffeeScript online with JSFiddle code editor.

---

<div class="post-metadata">

**Author:** ![Mugen87](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.threejs.org/mugen87/32/5645_2.png) [@Mugen87](https://discourse.threejs.org/u/Mugen87)\
**Post date:** [June 18, 2022, 8:45am UTC](https://discourse.threejs.org/t/model-is-black-while-the-texture-is-loading/39305/7 "2022-06-18T08:45:54Z")

</div>

> [@tfoller](#):
>
> there is **emptyTextures** object there that is used while the texture is being loaded.

I’ve totally missed the code in `WebGLState`. Indeed, `gl.bindTexture()` uses an “empty” instance of `WebGLTexture`. Meaning with no data defined.

> [@tfoller](#):
>
> why not make this change in the library, so models always show the color and then acquire texture on top when it’s ready?

I’m not sure what the reason was for using a black color. However, other engines use an even more distinctive default color like purple so it’s clear for the dev when textures are missing or not loaded.

Normally, you should not render an asset when its resources are not fully loaded. `LoadingManager` is helpful in this context, other loaders like `GLTFLoader` already fire their `onLoad` event when textures are ready.

So yes, using white as the default texture color would be more neutral however a potential error would not be so clear anymore.

---

<div class="post-metadata">

**Author:** ![tfoller](https://avatars.discourse-cdn.com/v4/letter/t/3e96dc/32.png) [@tfoller](https://discourse.threejs.org/u/tfoller)\
**Post date:** [June 18, 2022, 10:23am UTC](https://discourse.threejs.org/t/model-is-black-while-the-texture-is-loading/39305/8 "2022-06-18T10:23:23Z")

</div>

I see, thank you. To me it seemed more natural to render the scene right away with some adequate “flat” colors and then acquire textures as they get downloaded (and rather show an “error” texture if download fails) but I recall now, you’re right, it’s not how other engines work as well.

Luckily, I can fix it in the local copy of the library, so it’s not a problem.