[x3d-public] Support for specular maps (and more) in view3dscene, and Blender exporter to CommonSurfaceShader

[Andreas Plesch]

One strategy for standardization may be to follow three's Phong Material:

https://github.com/mrdoob/three.js/blob/dev/src/materials/MeshPhongMaterial.js

It defines mostly the same maps, and would have an example shader
implementation for each which perhaps could be used as a reference.

On May 1, 2017 5:57 AM, "Michalis Kamburelis" <michalis.kambi at gmail.com>
wrote:

2017-05-01 5:26 GMT+02:00 Don Brutzman <brutzman at nps.edu>:
> Making shader-oriented code more portable, and better able to support
> related requested capabilities like bump maps and shadows etc. is
certainly
> appealing.  The most frequently declared concern with shaders has always
> been portability and cross-platform support, along with a corresponding
> serious concern about potential security vulnerabilities.


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.


As for security concerns, the WebGL (fortunately) already shown that
an implementation can expose shaders and still be secure. It was not
totally painless for WebGL implementations (e.g. some particularly bad
(and old) GPUs are blacklisted by browsers, as far as I know), but
they showed it can be done. They even expose an OpenGLES-like API,
that allows to do more "dangerous" things than only shaders (e.g.
upload VBO).

I'm not saying that security wasn't a valid concern, I'm only saying
that someone else already attacked this problem and (seemingly) won:)

> On 4/30/2017 10:25 AM, Michalis Kamburelis wrote:
>>
>>    Especially since for now Castle Game Engine expects to find the
>> height map in the alpha channel of normal map, so we ignore the
>> "displacementMap"...
>
>
> Perhaps such configuration information should be in some kind of
enumeration
> field, for portability and reuse?

Hm, possibly. I think we'll see where our (Castle Game Engine and
X3DOM) implementations will go.

- Googling about the displacement support in X3DOM, they admit that
it's something they are still "playing with", and their existing
specification can change to incorporate new possible features.

- It's similar with my "steep parallax bump mapping" --- it's not a
standard technique in renderers yet (unlike the class "bump mapping",
which is now widely implemented), it is only something cool that I'm
playing with :)

>
> Wondering though, there might be more variations possible than make sense
to
> put in a specification.  For those cases, it would also be helpful if we
> might come up with norms for X3D MetadataSet descriptions so that such
> variations in conventions in contained data structures can be compared,
> checked and perhaps adapted by other users and other scripts at run time.

There will always be little features like that, that are not
implemented widely enough to incorporate them into the specification,
but still necessary for some implementations.


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.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170501/a7a46c5b/attachment.html>