Yes, @lezak has been making that same point.
To which I responded:
In conclusion, was able to make a very simple change to an existing shader, and provided a custom shader for the particular problem, so I could continue to use the materials supplied with the original sample, and get close to a fully working sample.
Going through the process in the code allowed me to grasp the linkages between the .xml material file, the techniques, textures and shaders. Blender use hasn’t yet transferred that knowledge to me (what I have gleaned from blender is I don’t know it well enough to use it effectively yet, and it’s just not yet the right time to begin to fully consume it with my mind, but have been slowly trodding that path, just not with determination, only curiosity)
Apparently, those much more experienced in graphics/3D world tech don’t agree. That’s fine, we all don’t have to agree.
My next steps for this are to write a custom shader by converting the glsl custom shader to an hlsl shader. Then figure out why the NoTextureMultiply sample isn’t working.
While @lezak points out the obvious differences between his AO display and mine, it would seem the edit I did and described above, produces identical results to his when ASSUMING the lighting, the ambient lighting, and material’s settings and zone settings are defined identically.
Because in the custom shader I did, it uses the first UV map as the second. In the custom model he did, he created a second UV map by copying the first.
It would be great if all the samples just worked on all the platforms. But learning blender won’t give me enough (or any) details on how to get the samples running on hololens without code changes. Digging into the code and actually getting the samples running on hololens does. But this code-first implementation is more about the hololens binding implementation than it is about urho3d (shadows not working on hololens). But ultimately, without useful bindings, what good is urho3d?