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

[Michalis Kamburelis]

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.

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.

Existing mechanisms for X3D, like metadata or EXTERNPROTO, help here.
In practice, it also helps when the implementations do not crash when
they see unrecognized fields, but gracefully warn about it and handle
as much as they can.

Best regards,
Michalis