Thank you for the PR. The only part that I think might be an issue is the "magic values"; although I acknowledge that getting good results in KiCAD is an important goal, I think it is also important to not have hardcoded values that favor one specific workflow to detriment of other ones.

Have you compared the rendering results in SolveSpace and KiCAD? If you use SS.ambientIntensity do they match? If they do, then it sounds like for your workflow, you should set SS.ambientIntensity to match KiCAD in the first place.

Actually, now that I look closer, I'm not sure if it makes sense to use ambientIntensity since in SolveSpace it is combined with the user-defined light sources, and in VRML this isn't applied (and can't be). It's not quite clear what's the best path forward here.

According to this, diffuseColor should be ignored with colored textures; what about colored triangles? Does it come into play here at all?

Hmm, when I update ambientIntensity = 0.3; // no setting for that yet to be 1, instead, the model looks, well, uniformly fully lit, as expected (and haven't found a setting in KiCad).

But, I played around with the material a bit more, and reduced it to pretty much just diffuseColor making or breaking the rendering (ambientIntensity being present or not does change the render, but to a very small degree in this case). So I searched for "diffuse" in the source and came across GL calls in rendergl1.cpp, so I plugged in SS.ambientIntensity in there, too, and it looked equivalently good.

Which, as I understand it (that is: poorly), and correct me if I'm wrong, is to be expected: the exported model specifies how it is supposed to look/behave, or under which conditions it looks "neutral" with its material spec, right? So, if we specify the material that we use within SolveSpace, in this case lighting conditions, was created and looks neutral under [our set of conditions], the renderer that uses the export knows to apply those instead of or on top of its defaults/environment?

Anyway, this is the material I arrived at, and a screenshot demonstrating it:

diffuseColor 0.3 0.3 0.3
ambientIntensity 0.3
transparency 0.0

The same but without ambientIntensity:

Without diffuseColor:

With neither:

The colour of this package's body is set to 0.07 across the board in SolveSpace, so that's not a great colour

Granted, diffuseColor might be slightly different de iure (like idk, depend on the other two lights), but I know absolute fuck-all about 3D, so I used a value that I had on hand (and which turned out to look good). I'd be happy to test with other software, but I neither have nor, really, know of any

Merged as 837628e.

I was also gonna add proper transparency handling since you didn't have anything against my caching scheme, but I guess I'll open a second PR?

Yep, that works!