Allow .obj & .gLTF material overwrite, or componentize envMap & sphericalEnvMap ?

Adding an envMap to a gLTF in aframe is currently counterintuitive and involved, which is a blow to PBR workflows. Currently, one can't use the material component to overwrite attributes of materials imported from gLTF, or .obj with .mtl files.

I've been teaching with a-frame a lot, and this is becoming a common point of confusion with my students (they wonder why their low-roughness materials don't reflect anything, then learn about envMaps and try to add one by setting the attribute with materials, and are confused why it doesn't work)

Some ways this could be approached, not mutually exclusive:

1) Allow gLTF & obj+mtl material overwrites from the material component
This seems most intuitive to me, is what I tried the first time, and is what some of my students have told me they tried. One would just selectively overwrite attributes (like envMap) using the material component. Curious to understand why this currently isn't allowed. Many circumstances where one might want to overwrite attributes of a material on a gLTF. I can see how it is unintuitive when a gltf gets used to store a whole scene.. but for envMap, a very common use is to apply the same envMap to all scene objects

2) Ship a-frame with an env-map component (w/sphericalEnvMap support) and have the material component continue to ignore attribute changes on gltf & obj+mtl
This makes sense in some ways — the logic being that any attributes not imported via gLTF files can can then be set via aframe components. Is maybe premature given talk of this possible extension.

3) Leave as is. Expect users to write a component, traverse the three object graph, and modify materials, and/or let community components fill the need and hope users know (where) to look

gLTF-part is one partial answer, but this is still trouble when:
a) using a .glb where it is harder to know the (sometimes auto-generated) keynames that correspond to gltf pieces
b) a gltf contains a single highpoly object that is broken into tons of sub meshes (Unbound's export currently does this.. tho likely something of an edge case).

The problem is solved for me: I've made a simple component that can be attached to gLTFs to inject envMaps and spericalEnvMaps, and I'm thinking about making it work with all entities (to be attached to a scene and propagate to all models that have materials, for example)... I'll publish this shortly, but I wanted to bring it into discussion more broadly as I've seen several newcomers bump into it with the core library.

ps: <3 <3 <3 a-frame, one of the most important projects going right now

Start by reading A-Frame’s material component behavior for imported glTF and OBJ+MTL assets, then compare it with the existing gltf-part component mentioned in the issue. The proposed alternatives need maintainer agreement first; done should mean a defined, documented behavior for applying envMap or sphericalEnvMap to imported materials.