Very crude compatibility with Three.js r110+ and ES6

[oliver408i]

Adds compatibility for up-to-date THREE.js and ES6 web standards (Javascript modules mostly).

Big disclaimer: this is a really stupid way to get compatibility without editing the code much, and it requires additional setup before you can use it!

Note: I only edited the output file (the non-min one), not any src files

See #38 for details on what was changed.

If you are going to use this, two changes are necessary:

1. Before loading in this lib, you must assign window.THREE to THREE (imported from an es6 module). See example below
2. Defer loading of this lib file and any other scripts that depend on this lib
3. Instead of THREE.Terrain, use window.THREETerrain

initThree.js

import * as THREE from 'three';

// Push THREE into the global scope for THREETerrain to use
window.THREE = THREE;

HTML
Make sure you have an import map set up first

<script type="importmap">
  {
    "imports": {
      "three": "https://cdn.jsdelivr.net/npm/[email protected]/build/three.module.js",
      "three/addons/": "https://cdn.jsdelivr.net/npm/[email protected]/examples/jsm/",
    }
  }
</script>

Then load your scripts

<script type="module" src="./initThree.js"></script>
<script src="path/to/THREETerrain.js" defer></script>
<script type="module" src="main.js" defer></script>

For a demo on how to use this, please see my game, https://github.com/oliver408i/missilesim

Additional technical notes: THREE.Math functions were changed to their identical THREE.MathUtils ones

[arcanis]

You edited the build folder - I believe you need to edit the src one instead. The change should also be to add import * as THREE from 'three'; at the top of every file rather than rely on window.THREE (and to export const THREETerrain = ... rather than assign it to window.THREETerrain).

[isaac-meaningfulgigs]

Sorry for the delayed review, and thanks for this effort.

arcanis is correct - for this PR to merge, the files in the src folder need to be changed. The build files are auto-generated, so any changes to them would get overwritten in the next build.

Beyond that, I agree that it would be preferable to convert this library to ESM style rather than add to the window global, but I'm okay with window as a workaround for now. However, ideally we should be able to get rid of the need to load a separate initThree.js script first.

[oliver408i]

I will do that (the files are just concat together one by one right? I don't normally use this kind of javascript build system). I did attempt to convert this into an ESM style model but I haven't been successful by doing basic modifications (I didn't want to change too much of the original code, but it seems like that is necessary to fully convert the module). I will continue to experiment with that. Thanks for your review

[oliver408i]

Update: I managed to get a working ESM style module going, but I don't think it is possible to split it up into that many different files (Terrain is now a class).

[IceCreamYou]

Yeah, the build process concats files and then minifies them. I haven't touched how that works since 2015. In this case, the only symbol that would get exported is the Terrain constructor, and everything else gets added as a property on that constructor. So if all the other files get concatenated after core.js, and an export line is added at the end, that would probably work.

[oliver408i]

I have added the code to the .mjs files in src. I'm not sure how to compile them, so I'll leave that to you (or you can let me know what to put in the config). Order is: Core.mjs + CoreNoise.mjs + Terrain.mjs + Export.mjs. I also updated README to include slightly different usages for this module. Note that I included THREE.Terrain.Module.mjs in the build folder for reference for the complete module file. I know it will get overwritten, its not meant to be permanent.