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

[Leonard Daly]

I have another discussion topic. This time it is shaders. I have 
included Michalis's response to another post because it is a good place 
to start.

There are two places in the X3D specification that are not declarative 
-- Script and Shaders. I wish to discuss shaders in this thread.

At the time the Shader node was developed, there were two primary shader 
languages - GLSL and HLSL (Wikipedia lists 8 real-time languages 
https://en.wikipedia.org/wiki/Shading_language). X3D uses those two plus 
nVidia's CG. Note that Wikipedia states that Cg is deprecated. Use of 
the Shader node requires some rather detailed knowledge about the 
hardware that is available on the target system. If the target system is 
unknown, then X3D's Shader node allows multiple versions to be included 
to support all common hardware.

This is rather deep and certainly not declarative knowledge needed for 
someone to use. In the case of display in a web browser (meaning 
integrated DOM), then the target language is reduced to GLSL. However, 
it still requires someone to know how to write a shader.

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=).


Leonard Daly




On 4/25/2017 10:51 PM, Michalis Kamburelis wrote:
> 2017-04-26 7:31 GMT+02:00 Michalis Kamburelis <michalis.kambi at gmail.com>:
>> E.g. I will definitely defend cube maps, 3D textures and
>> generated texture coordinates
> Although, while I will defend cube maps and 3D textures, I will not
> defend (as much) the current MultiTexture or
> ComposedTexture3D or ComposedCubeMapTexture.
>
> - If we add CommonSurfaceShader to the spec, it can fill many usecases
> where right now people use (with varying success) MultiTexture. I can
> easily see that the MultiTexture component gets removed at that point.
>
> - ComposedTexture3D and ComposedCubeMapTexture could be in principle
> removed. The existing ImageTexture3D and ImageCubeMapTexture could
> perform all their roles (but we should recommend there some formats
> with a good and open specification, like Khronos KTX; the existing
> prose for ImageCubeMapTexture recommends only Microsoft DDS). So the
> cube maps could be specified as "generated" or "url(xxx.ktx)", and
> that's it.
>
> - Some of the TextureProperties information can be derived from other
> information, or implementation-dependent (e.g. whether to use texture
> compression). But not all (e.g. anisotropicDegree really needs to be
> specified per-texture by a graphic artist, there is no escape from
> that, with existing technology).
>
> IOW, I do see various ways in how the current specification could be
> simplified, to have less nodes (and thus, enable more concise
> description of some features). I do think that the optimum may be
> somewhere between the current specification and your flat Mesh
> proposal.
>
> Best regards,
> Michalis
>

-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170426/d097972c/attachment.html>