Generic mesh provision via web worker

[kaisalmen]

Update: 2017-09-08:
This is a copy of the text of three.js PR 12048:

The evolution of OBJLoader2 has now reached a point where your feedback is required (mrdoob, jbaicoianu, fernandojsg, jonnenauha, mikearmstrong001 and please ping anyone interested or of help).

Let me sum up why this all happend:
I started some prototyping on a branch in my WWOBJLoader repo, because I wanted to separate the asynchronous mesh provision of the worker fromWWOBJLoader2. Almost in parallel fernandojsg started #11746. During the discussion mrdoob brought up the idea to have a common approach for executing the Parser part of any Loader in a worker and passing raw results that to a common mesh builder function. With this approach Parsers could be defined without any reference to three.js code allowing quick worker creation.

This PR realizes this with an a new version of OBJLoader2 that fuses OBJLoader2 and WWOBJLoader2 into one, plus the proof of concept MeshSpray example which is not a loader, but it uses all actors and provides a worker executable parser function.
I have extracted LoaderSupport classes (independent of OBJ parsing functionality) that serve as support tools and utilities. Some of the classes make building other worker based loaders a lot easier and are considered required. Some things may be identified as superfluous, but we will see. All extracted code now resides under namespace THREE.LoaderSupport to make it independent from OBJLoader2:

• Validator: Tools for null/undefined checks and default value assignment
• Commons (optional): Possible base class for loaders. It bundles common functions and parameters
• WorkerSupport + WorkerRunnerRefImpl: WorkerSuppport provides helper function to create workers from existing Parser code and it handles the communication with the Worker. WorkerRunnerRefImpl realizes the communication with the front-end, creates, configures and executes the parser inside the worker.
• Builder: It builds one or many THREE.Mesh from one raw set of Arraybuffers, materialGroup descriptions and further parameters. Supports vertex, vertexColor, normal, uv and index buffers.
• PrepData + ResourceDescriptor: Description used for automation (fed to run method, see OBJLoader2 description below) and for a unified description resource description in examples
• WorkerDirector: Creates parsers via reflection and utilizes WorkerSupport to automate loaders via queued run/PrepData instructions with configurable amount of workers. Used to fully automate loaders (MeshSpray and Parallels examples)
• Callbacks (onProgress, onMeshAlter, onLoad) + LoadedMeshUserOverride (helpful): Used mainly for automation with PrepData. LoadedMeshUserOverride is returned onMeshAlter (see Normal-Helper addition to vive-controller in examples obj2_options)

OBJLoader2 POIs (example obj2_options features six methods how to use it):

• parse allows synchronous loading of arraybuffer or string data
• parseAsync allows asynchronous loading of arraybuffer or string data
• load Allows both synchronous and asynchronous loading of a OBJ file (additional async flag in function)
• run Allows automated loading of MTL and OBJ files according instructions (sync/async, mesh-streaming, callbacks, etc.)
• loadMtl makes MTL loading via MTLLoader and provision of materials to OBJLoader2easy
• Internal Parser is fully serialized, configured and run by generic WorkerSupport
• Functions initand validate are no longer needed. OBJLoader2 should be re-instantiated when it shall be used again. run has an optional parameter that allows to provide an external WorkerSupport with the cached parser worker (no need for re-build). LoaderDirector uses this mechanism in run_director example
• UPDATE 2017-09-03: OBJLoader2 now supports setUseIndices which loads data into indexed BufferedGeometry. Loading is roughly a third slower, but up to three quaster less vertices/uvs/normals are created.

Please let me know what you think of all of this and please review the code. This whole approach imposes heavy changes on existing loaders when decided to be ported, but no force to do so is imposed by all of this. We just gain useful options to build asynchronous loaders.

Examples:
obj Indexed
obj2_options
obj2_run_director
ww_meshspray
Bigger OBJ files stage (External) Indexed

TODO for me:

• Enhance Builder with code for handling serialized materials. In case of OBJ materials are loaded from MTL files and are just assigned to Builder (not handled by buildMeshes, yet).
• Update the documentation
• Transform another fairly simply loader like PCDLoader to this generic approach. I am open for suggestions here
• Done: Polish the examples

[kaisalmen]

For discission follow: three.js #12048.
Text has been added above for convenience,

[kaisalmen]

Closed along with three.js PT 12048.