[x3d-public] What to do about Shaders [was: Flattening Scene Graph]

[Michalis Kamburelis]

2017-04-26 16:56 GMT+02:00 Leonard Daly <Leonard.Daly at realism.com>:
> Instead of providing an interface that allows shaders to be written in the
> X3D environment, should X3D provide a library of possible effects? This
> could be things like sandpaper, fuzzy material, hard shinny steel, etc.
> Because there would be so many different possibilities, I think a library
> would be necessary. This is also important in the commercial realm where
> shader programmers make almost 3X  a 3d artist (see graphcs at
> https://www.indeed.com/q-Shader-Programmer-jobs.html and
> https://www.indeed.com/jobs?q=3d+artist&l=).

1. A material library for X3D is a cool idea.

I don't think it's something for the specification to consider, but it
is something for the community to consider. After all, it's a matter
of setting up a website that collects X3D files with cool materials,
presents them, allows to download them (or reference them, e.g. using
an EXTERNPROTO or IMPORT or both). The files would need to be uploaded
by authors, accepting some permissive open-source license.

Blender community shows how it can be done nicely:

- http://blendermada.com/
- http://www.blendswap.com/terms/category/materials/sort:Blend.downloads/direction:desc

Notice the:
- Easy upload for authors, with a necessity to accept an open-source
license (http://blendermada.com/ simply requires public domain)
- Screenshots showing how it works on a standard test model (so that
materials are compared "fair", without looking at some impressive 3D
geometry, all materials are compared by looking at the same mesh)

2. As far as the X3D specification is concerned, I really think that
the CommonSurfaceShader from InstantReality, X3DOM, and now also
Castle Game Engine (
https://castle-engine.sourceforge.io/x3d_implementation_texturing_extensions.php#section_ext_common_surface_shader
) is something that should be incorporated in the X3D specification.

Maybe with some changes (some fields could be removed from the
official specification, for simplicity), but maybe even verbatim. It's
a neat design, simple and declarative, and it fills a significant part
of the usecase where people right now deal with something advanced
(like custom shader code or multi-texturing).

So, it is some solution to the problem of "it's difficult to write a
shader, and even more difficult to write a portable shader that works
in all renderers". For some usecases, you could just use a declarative
CommonSurfaceShader . The X3DOM already implements it, showing that it
can be done in WebGL too.

Best regards,
Michalis