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

[yottzumm at gmail.com]

Leonard, I use X3DOM’s subdivision with Sphere and a vertex shader to achieve a flower-like geometry.  This could and probably should be done with IFS, but I have chosen Spheres, because I don’t have to lay out the coordIndexes for the IFS (I have done it the latter way first).  I would like to wrap the IFS into a sphere IFS, but haven’t worked on that yet.

Example shown here:

http://coderextreme.net/X3DJSONLD/flowers.xhtml

John
Sent from Mail for Windows 10

From: Leonard Daly
Sent: Wednesday, April 26, 2017 10:57 AM
To: X3D Public
Subject: [x3d-public] What to do about Shaders [was: Flattening Scene Graph]

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/779de0d3/attachment.html>