Tsunami of Three.js errors

After a year of doing non-three.js stuff, I returned to three.js, updated the source files and was flooded by lots of error messages for a previously-error-free code:

  1. Why am I getting errors about the three.js library itself?

  2. About the module errors in the beginning, I think I managed to load three.js as a module (which is why I’m not getting an error) but I’m not sure how to do the same with the draco and gltf source files. Any examples?

These are just deprecation warnings, the API changes/improves over time (which seems to be many versions between the one you used to now), in order to not just break your app it will show you warnings you can adapt your code to.

The adaptions are mostly just changes in arguments, the warnings just repeated.

1 Like

I have used the following code on the html that doesn’t seem to work for draco and gltf:

        <script src="three.js"></script>

        <script src="DRACOLoader.js"></script>

        <script src="DDSLoader.js"></script>

        <script src="GLTFLoader.js"></script>

        <script type="module">

            import * as THREE from "./three.module.js";

            import { DRACOLoader } from "./DRACOLoader.js";

            import { DDSLoader } from "./DDSLoader.js";

            import { GLTFLoader } from "./GLTFLoader.js";           


What about the “GL_INVALID_OPERATION: Feedback loop formed between Framebuffer and active Texture” ?

It’s probably related to the renderer warning to use clear instead of force clear. Try updating your code to get rid of the warnings.

I’m not the one who uses ‘forceclear’:

The error line is from three.js source:

The image doesn’t show your renderer.render call, it looks like you’re still passing a render target there plus the 4th forceClear argument. The warning message isn’t an error by THREE, somewhere in your code or possibly an old post-processing plugin there is a render call with 4 arguments.

In the DevTools unfold the warning message to see where the render call has been made.

This code is incorrect since you import global scripts AND the ES6 modules at the same time. Try to use just:

<script type="module">

            import * as THREE from "./three.module.js";

            import { DRACOLoader } from "./DRACOLoader.js";

            import { DDSLoader } from "./DDSLoader.js";

            import { GLTFLoader } from "./GLTFLoader.js";           


BTW: Moving ES6 modules to custom directories is bad practice since modules usually have dependencies to others. If you don’t adjust these paths, the module will break.

If you are new to ES6 modules and not familiar with bundlers, consider to import from a CDN:


1 Like

Thanks, but if I do this I’m getting a “Three is not defined”.

Importing from a CDN is not an option in my case, as I can’t let my app to be dependent on the limited bandwidth and availability of another third party server.

Just as a test, I did that and got these errors:

I guess that might be a security issue, as I’m serving the browser via a local http-server batch file:
http-server -p 8080 -c-1

So, is there a way to “adjust the paths” and make it work at custom directories on my server?

Doing this is always very hacky. One advantage of using modules is to not care about such dependencies anymore. Better to use a bundler like rollup.

Keep in mind that with modules, you can’t access THREE globally anymore. One idea of ES6 modules is to avoid the pollution of the global namespace. Hence, try to move your code from globals.js (and potentially other files) into your <script type="module"> tag.

These links could be interesting here. :slightly_smiling_face:

From my collection * discourse.threejs.hofk.de see: Module usage


Thanks for all the replies, however, the downsides from switching to modular three.js seem far more, than the benefits right now for me -and I bet many other people like me.

For instance:

  1. Modules are supposed to be modular and flexible, yet they require an external, non-three.js “builder” app to be used properly and efficiently - that sounds to me less flexible and less modular than I would expect.

  2. From one of the links:
    "ES6 modules are stored in files. There is exactly one module per file and one file per module."
    So, from my last code of 5000 lines let’s say I create 100 modules, so I’ll have to break that code to 100 files and then build them with some builder.
    That would probably require a month of work or so. And would probably end to larger code overall.

  3. Plus, at least one or two weeks to fully understand the specific concept, for the specific framework (three.js) in practice, via examples and tests, and overcome quirks, bugs, issues of all kinds, plus learn to become efficient in coding with modules.

  4. BTW, where is the three.js e-book about creating modular three.js projects, to take us step-by-step, cover all possible cases for small to big projects, answer all our possible questions and teach us progressively by example?

  5. I would also guess that such standardized modularity might make each peace of code, a piece of cake to be understood and be stolen, vs some custom modularity where a third person won’t have a clue about how the f*** it is organized, thus requiring more time invested and be discouraged.

#2 and #3 are the real obstacles for me. I can’t invest the time needed right now, so I have to continue the traditional way until I have no other choice, while reading now and then about modules.

Without a solid book, specific to three.js about the subject, I think it’s too early for three.js to become modular and demand that huge investment in effort and time -I think the switch should become perfectly synced with the publishing of a good such (e)book.
Forums are of great help, but cannot substitute a well organized, specific (e)book, teaching the user progressively and systematically.

This is not correct. You don’t need a bundler. See, for example, all the official examples which use modules without a bundler.

This is a little bit off. Yes, each file is a module, but a module can have any number of exports. For example, the three.js core has hundreds of exports in a single module.

Well, no one is forcing you to update to the latest version of three.js, or to start writing ES6 JavaScript instead of ES5. All the old stuff still works, so keep using it, if you prefer.

I’m currently writing it. The old version (not using modules) is at discoverthreejs.com, and the new version is here on my staging site:


Well, exactly due to all that contradicting information, official (or responsible, non-BS) training is needed to clear things up. Personally, I’d also want to know which of the alternative ways is more efficient performance-wise and why (not just convenient to code).

Congrats for the live ebook, I always thought that a live ebook would be the next step for ebooks and had a bunch of ideas myself about how it could be made.
I haven’t read yours, but most likely I’ll buy it, so good luck in writing it!

1 Like