<p dir="auto"><strong>Is your feature request related to a problem? Please describe.</strong></p>
<p dir="auto">I believe it is good library hygiene to support both module and classic static file imports.This keeps the library accessible to a wider group of developers and allows developers to use their preferred style.</p>
<p dir="auto">Personally I really try to avoid using modules in general, I like projects that are static files with classic simple JS file includes. Maybe I'm just a weirdo but I really hate how far frameworks unnecessarily abstract you from things and how much they re-invent wheels or otherwise black-box you. I know you can use modules without any frameworks, however module includes are less intuitive then traditional JS includes, they often have failed me when trying to use them within a static file setup.</p>
<p dir="auto">Using ES6 Modules are not ideal for every deployment, though they are certainly a welcome addition. I teach many new programmers threejs because I love the library and IMO it is a great and satisfying way to get into programming. It is a lot easier to teach people basic vanilla CSS/JS/HTML without also shoving the entire node/npm + framework stack down their throat at the same time. Static libraries are simpler to use/understand and keep the barrier to entry low here.</p>
<p dir="auto">Stylistically, I also prefer overloading THREE with additional functionality instead of adding new named functions that float around freely. Though this is obviously preference.</p>
<p dir="auto"><strong>Describe the solution you'd like</strong></p>
<p dir="auto">Perhaps I can better answer this after getting a bit more information about why the decision was made to transition to modules only, but I'll take a stab at it.</p>
<p dir="auto">The documentation addresses that ES6 modules may not work in every situation and for those situations it suggests using a  bundler such as browserify/rollup/webpack/parcel etc....</p>
<p dir="auto">My solution would be have an automatic ES6 bundler script go through the modules in <strong>/examples/jsm</strong> to generate <strong>/examples/js</strong> non module versions. This way developers no longer need to worry about making changes in two places and can continue to enjoy using the JS non module versions and global var import style if they like.</p>
<p dir="auto">This automatic generation of JS non module files could be done as part of the build process or be a command in the package.json someone could run manually. Though I'd opt for automatic generation.</p>
<p dir="auto">Creating this automation or otherwise maintaining the JS non module versions of this library is something I can donate my time for. If the reasoning behind jumping to ES6 only is not just removing the need to update two parallel version of the same thing manually, I'd love to discuss other solutions to address those concerns as well.</p>
<p dir="auto"><strong>Describe alternatives you've considered</strong></p>
<p dir="auto">The obvious other consideration would be to leave things as is and continue maintaining JS and JSM versions of all libraries. Though considering the announcement these are being deprecated, I find this somewhat unlikely. But I'd be happy to take on responsibility for making sure JS libraries stay up to date with their JSM counterparts manually if we decide to go this route.</p>
<p dir="auto"><strong>Additional context</strong></p>
<p dir="auto">Much love to this library and everyone that contributes either in code or by reporting/discussing issues.</p>
<p dir="auto">Hi,</p>
<p dir="auto">We have noticed that on computers using Intel HD Graphics chips 620 (or 520), the rendering was completely wrong.<br>
Here are screenshots illustrating the issue, taken from the following link using three.js: <a href="https://sayduck.com/3d/jhqw?starting-variant=0od32t8kalqa" rel="nofollow">https://sayduck.com/3d/jhqw?starting-variant=0od32t8kalqa</a></p>
<p dir="auto">On a computer with an Intel HD Graphics 620, the rendering is completely wrong.<br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://user-images.githubusercontent.com/16535933/28261579-25ac43b6-6ae0-11e7-9385-e96d6cf540d6.jpg"><img src="https://user-images.githubusercontent.com/16535933/28261579-25ac43b6-6ae0-11e7-9385-e96d6cf540d6.jpg" alt="rendering_issue" style="max-width: 100%;"></a></p>
<p dir="auto">And here is the same page on another computer, rendering as it should.<br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://user-images.githubusercontent.com/16535933/28261613-39865cd2-6ae0-11e7-8097-20c7912548ce.jpg"><img src="https://user-images.githubusercontent.com/16535933/28261613-39865cd2-6ae0-11e7-8097-20c7912548ce.jpg" alt="rendering_correct" style="max-width: 100%;"></a></p>
<p dir="auto">This has been observed on all major browsers (but only on windows 10). Turning off hardware-acceleration for rendering solved the issue, pointing the fault on the GPU chip. The GPU drivers have been updated to the latest version without any impact.<br>
Finally, no errors are present in the browsers' console, and support should be fine for both webGL and webGL2 on the computer (see webGL report files):<br>
<a href="https://github.com/mrdoob/three.js/files/1152049/WebGL.Report.pdf">WebGL Report.pdf</a><br>
<a href="https://github.com/mrdoob/three.js/files/1152050/WebGL2.Report.pdf">WebGL2 Report.pdf</a></p>
<p dir="auto">Also, the Graphics Feature Status of chrome://gpu has all elements green and "Hardware accelerated" (except for Native GpuMemoryBuffers which is not supported on Windows).</p>
<p dir="auto">I have filed a report on Intel's community forum too, but thought this might be worth reporting here as well.</p>
<p dir="auto">Thanks a lot in advance.</p>
<hr>
<p dir="auto">Three.js version r86<br>
All major browsers<br>
Tested only on Windows 10</p>