<div dir="auto"><div><div dir="auto">One strategy for standardization may be to follow three's Phong Material:</div><div dir="auto"><br></div><a href="https://github.com/mrdoob/three.js/blob/dev/src/materials/MeshPhongMaterial.js">https://github.com/mrdoob/three.js/blob/dev/src/materials/MeshPhongMaterial.js</a><div dir="auto"><br></div><div dir="auto">It defines mostly the same maps, and would have an example shader implementation for each which perhaps could be used as a reference.</div><div class="gmail_extra"><br><div class="gmail_quote">On May 1, 2017 5:57 AM, "Michalis Kamburelis" <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">2017-05-01 5:26 GMT+02:00 Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>>:<br>
> Making shader-oriented code more portable, and better able to support<br>
> related requested capabilities like bump maps and shadows etc. is certainly<br>
> appealing.  The most frequently declared concern with shaders has always<br>
> been portability and cross-platform support, along with a corresponding<br>
> serious concern about potential security vulnerabilities.<br>
</div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Being declarative, CommonSurfaceShader should not be affected by vulnerabilities introduced by allowing arbitrary shader code. In fact, it addresses such concerns with the existing shader component.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text"><br>
</div>As for security concerns, the WebGL (fortunately) already shown that<br>
an implementation can expose shaders and still be secure. It was not<br>
totally painless for WebGL implementations (e.g. some particularly bad<br>
(and old) GPUs are blacklisted by browsers, as far as I know), but<br>
they showed it can be done. They even expose an OpenGLES-like API,<br>
that allows to do more "dangerous" things than only shaders (e.g.<br>
upload VBO).<br>
<br>
I'm not saying that security wasn't a valid concern, I'm only saying<br>
that someone else already attacked this problem and (seemingly) won:)<br>
<div class="quoted-text"><br>
> On 4/30/2017 10:25 AM, Michalis Kamburelis wrote:<br>
>><br>
>>    Especially since for now Castle Game Engine expects to find the<br>
>> height map in the alpha channel of normal map, so we ignore the<br>
>> "displacementMap"...<br>
><br>
><br>
> Perhaps such configuration information should be in some kind of enumeration<br>
> field, for portability and reuse?<br>
<br>
</div>Hm, possibly. I think we'll see where our (Castle Game Engine and<br>
X3DOM) implementations will go.<br>
<br>
- Googling about the displacement support in X3DOM, they admit that<br>
it's something they are still "playing with", and their existing<br>
specification can change to incorporate new possible features.<br>
<br>
- It's similar with my "steep parallax bump mapping" --- it's not a<br>
standard technique in renderers yet (unlike the class "bump mapping",<br>
which is now widely implemented), it is only something cool that I'm<br>
playing with :)<br>
<div class="quoted-text"><br>
><br>
> Wondering though, there might be more variations possible than make sense to<br>
> put in a specification.  For those cases, it would also be helpful if we<br>
> might come up with norms for X3D MetadataSet descriptions so that such<br>
> variations in conventions in contained data structures can be compared,<br>
> checked and perhaps adapted by other users and other scripts at run time.<br>
<br>
</div>There will always be little features like that, that are not<br>
implemented widely enough to incorporate them into the specification,<br>
but still necessary for some implementations.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">This is a valid concern, and a reason why three.js is successful. It allows any degree of tweaking which often becomes a requirement for serious applications.</div><div dir="auto"><br></div><div dir="auto">Andreas</div></div>