Three.js: Example files that still need to be converted to modules

Since the node materials files are already modules, they should probably be moved out of the js/ folder and into the jsm/ folder. Then we just need to create typescript files for them.

files in the lib/ folder

I looking for a way to provide inflate as a module. I'm afraid issues like #16602 will frequently pop up with certain loaders like FBXLoader. Unfortunately, it seems there is no module version of zlib.js. Could we maybe use another library?

Yes, I was thinking we'd have to do that, unfortunately. It's just a standard zip inflate function I think so that shouldn't be too hard.

EDIT: Perhaps this one? https://github.com/zprodev/zlib.es

Someone mentioned that they got it working with the FBXLoader. However, that means that the js FBXLoader and jsm FBXLoader will have different dependencies. How can we handle that?

We can define inflate as an external dependency of FBXLoader in modularize.js. So the script automatically creates the import statement to the respective module in jsm/libs/.

Edit: Of course this does only work that easy if the interface of the module version of the lib is similar to the normal version^^.

I will try to start converting js files. The ones I authored will be easier for me (ConvexObjectBreaker, GPUComputationRenderer, LightningStrike, LightningStorm, LDrawLoader) I can do more later.

So I'll start by moving ConvexObjectBreaker and GPUComputationRenderer to js/misc (as stated in other comment) and converting them, if you agree.

https://github.com/mrdoob/three.js/pull/16054 is in progress for nodes/, added a note to the OP.

@yomboprime Sounds great!^^

I'm working on Cloth.js and it's a huge mess of global variables. I can convert it to extend Mesh and put in the the objects/ directory. But, before I do that - do we really need two cloth examples?

https://threejs.org/examples/webgl_animation_cloth.html
https://threejs.org/examples/webgl_physics_cloth.html

Should we convert the deprecated files, or not?

-- loaders/deprecated/

• LegacyGLTFLoader.js
• LegacyJSONLoader.js

-- vr/deprecated/

• DaydreamController.js
• GearVRController.js

Should we convert the deprecated files, or not?

I would convert them at the end when everything else is done.

But, before I do that - do we really need two cloth examples?

Let's keep the example since it demonstrates cloth animation without a physics engine.

ConvexObjectBreaker and GPUComputationRenderer are done already, I have marked them.

I assign to myself the geometries/LightningStrike.js and objects/LightningStorm.js

Edit: I did those two and marked them in the list. Next is LDrawLoader.

/ping @sunag would you be able to convert the SEA3D loader and related files?

@looeee of course. I will do this with NodeMaterialLoader too.

BTW: We can remove EquirectangularToCubeGenerator from the list since @WestLangley recently introduced WebGLRenderTargetCube.fromEquirectangularTexture() (see #16671). That means EquirectangularToCubeGenerator will be obsolete after the example code uses the new interface.

We can remove EquirectangularToCubeGenerator

Not yet please. There are a lot of encoding and decoding possibilities and multiple workflows to support. This is not trivial. The new method is not yet documented.

I've just meant to remove it from the todo list, not the file^^

Since the amount of open tasks gets smaller and smaller, I think it's better if you assign your name to a file if you want to convert it. In this way, we avoid that two more devs work at the same thing.

@looeee I've added you to the CTMLoader files since it seems you are already working on it.

I've added you to the CTMLoader files since it seems you are already working on it

I actually won't have time in the next couple of days, so it's fine if someone else does that. I'll take my name off for now.

We can remove the worker scripts from the list since these files are not imported in user applications like the other classes. Besides, they do not export a class or a namespace so modularize.js can't process them anyway.

Removing the Draco and Basis libs from the list for now, see https://github.com/mrdoob/three.js/pull/16754#issuecomment-500494943

I've converted most of the HTML examples in the last days. The following list shows the open tasks:

• [x] webgl_materials_compile (NodeMaterial)
• [x] webgl_materials_nodes (NodeMaterial)
• [x] webgl_mirror_nodes (NodeMaterial)
• [x] webgl_performance_nodes (NodeMaterial)
• [x] webgl_postprocessing_nodes_pass (NodeMaterial)
• [x] webgl_postprocessing_nodes (NodeMaterial)
• [x] webgl_sprites_nodes (NodeMaterial)

The node material examples can be solved as soon as #16054 is ready

https://github.com/mrdoob/three.js/pull/16834

@Mugen87 I will open a PR until Sunday that brings back OBJLoader2 + Worker (jsm and standard workers supported). MeshSpray and Parallels example will not be ready then as the required code has not been ported/re-written. Is it ok to let those two example stay on old code until R107 or do you want to remove and re-introduce those two examples?

TBH, I think two examples for OBJLoader2 are totally sufficient. One that demonstrates the basic usage and another one in context of a worker scenario. After the migration, the non-module version of OBJ2Loader in the js directory can be removed.

Ok, the non-module OBJLoader2 and LoaderSupport can then disappear. A new multi-asset loading example could then be proposed once the new code is ready.

Here are a few remaining files to add to the list. Some of these may not necessarily make sense as es6 modules per se but once we make the move to convert all /jsm files to /js I think it will make sense to keep all of the maintained, editable versions of the examples in one directory (/jsm):

/vr

• HelioWebXRPolyfill.js
• WebVR.js

/offscreen

• jank.js
• offscreen.js
• scene.js

/loaders

• ctm/CTMWorker.js

/renderers

• rendering/RayTracingWorking.js

see https://github.com/mrdoob/three.js/issues/16688#issuecomment-501618684. The worker files can just moved to the jsm directory.

I would not change the other two VR files for now. Like the name implies, HelioWebXRPolyfill is just a polyfill for the WebXR API. WebVR.js is similar WebGL.js not in the THREE namespace and I'm not sure @mrdoob wants to change this.

WebVR.js probably doesn't even need a non-module version. Will work on it this cycle.

I'm tempted of removing the CTM loader. Seems too complicated to deal with and I'm not sure there is enough files out there that makes it worth it? Also, at the time it was a good option, but GLTF should be used instead now.

@Mugen87 I agree that a lot of the files don't need to be "module-ified" but they should at least all be moved (eventually) into the same folder if only for consistency. I think it will be a bit confusing to have a mix of modules that are generated and hand-edited in the same folders. It's also still valid to load a script using import even if it doesn't export anything, as would be the case with the polyfill:

import './examples/jsm/vr/HelioWebXRPolyfill.js';

Regarding the namespace for files like WebGL.js it would be possible with Rollup to exclude this file (or set of files) from being added to the THREE namespace and be added to something like window instead. My changes in #16920 could be easily modified to support that.

The conversion is now mainly done. We can now move the remaining, non-module files (see https://github.com/mrdoob/three.js/issues/16688#issuecomment-506108218) to the JSM directory. I would also do this for the remaining external libs (see https://github.com/mrdoob/three.js/issues/16688#issue-452345634).

Changed my mind. I think it's better to have only modules in the JSM directory. The remaining libs and worker files can stay in examples/js. If we eventually generate UMDs via #16920, a comment will highlight that these files are generated. So this will make it easier to see whether a file is manually maintained or not.

I think the issue can be closed. It's not necessary to convert all libs and worker scripts to modules now. We can change this over time e.g. when a lib vendor provides an ES6 version.

We should now focus on the UMD generation so the modules become the canonical code base.