The copy function on a number of materials assume that they are copying from the same material type and don't check if a field exists before trying to copy it, resulting in an error.
In this case, the Phong material tries to copy the specular color from the Lambert material, which does not exist.
(new THREE.MeshPhongMaterial()).copy(new THREE.MeshLambertMaterial());
// Throws error on
// https://github.com/mrdoob/three.js/blob/dev/src/materials/MeshPhongMaterial.js#L122
One possible fix would just be to check if a field exists before trying to call copy on it.
Ha, well that looks great. Any idea on why it keeps getting pushed back to the next release?
Probably one of the reasons is I haven't solved the conflicts. I'll fix soon! (Another reason could be we'll introduce node based material soon then he don't wanna update the material code til then.)
Ha, well that looks great. Any idea on why it keeps getting pushed back to the next release?
I think no more work will be done on existing materials, because of the upcoming Node Material.
I've started this project for this reason:
https://github.com/pailhead/three-refactor-chunk-material
If you like how the materials work now, as long as three.js keeps the ShaderMaterial you could use them like this, as 3rd party. It shouldn't be hard to make your own copy function from here.
I think no more work will be done on existing materials, because of the upcoming Node Material.
I don't think that has been suggested. Even if NodeMaterial were merged into src/ immediately, we'd still want to keep a backward-compatible interface for existing materials, and functional .copy() methods should be part of that.
Closing, see https://github.com/mrdoob/three.js/issues/17565#issuecomment-627009414.
Most helpful comment
I don't think that has been suggested. Even if NodeMaterial were merged into
src/immediately, we'd still want to keep a backward-compatible interface for existing materials, and functional.copy()methods should be part of that.