Super thanks!

From my understanding, those changes are needed for aframe 1.4.2 (r147) with colorManagement:true (and I have this combination in my project), but not needed for aframe master (r152), right?
It may be good to still merge this and include it in a new release.

From my understanding, those changes are needed for aframe 1.4.2 (r147) with colorManagement:true (and I have this combination in my project), but not needed for aframe master (r152), right?

In aframe master it's no longer needed to call rendererSystem.applyColorCorrection on colours, but it's still very much needed for textures, as there is no way for Three.js to infer which colour space they are in. This means that this PR is still needed for the groundTexture and gridTexture. Nevertheless it's probably best to merge this PR with the applyColorCorrection on colours as well, since that way it will work on both 1.4.2 and master. On master those will effectively become no-ops.

Seems that on master some more changes will be needed, investigating it

Added a commit that fixes it for aframe-master. With the newer Three.js all Color instances were automatically converted, but the code does use instances of THREE.Color for drawing on a canvas for the ground and grid textures. I've made sure that these are now correctly performed in "NoColorSpace" and only converted to the working color space when needed.

It's done in such a way that it works for both 1.4.2 and master. With colorManagment: false the results should still be identical, and with colorManagement: true they are very close (obviously small differences due to lighting taking places in linearSRGBColorSpace in the shader). Biggest difference is still as noted in #83 when an emissiveMap is used. Sadly there is nothing that can be done about it without changing the shader.

Thank you very much!