[x3d-public] Shader extensions and shadows in a ray / path tracing renderer.

[doug sanden]

Agreed - same issues with programmable shaders. I think effect nodes will have more uptake / be more useful to scene designers since usually you dont want to do the whole shader from scratch / replace the whole shader.
Ps freewrl has a configuration using angleproject lib to convert gl es 2 calls -and shaders- to directx, and the Effect node tests worked there as well as desktop gl and android gl es 2, except no geometry shaders in es2.
-Doug

________________________________________
From: x3d-public [x3d-public-bounces at web3d.org] on behalf of Michalis Kamburelis [michalis.kambi at gmail.com]
Sent: April 12, 2017 12:29 PM
To: Roy Walmsley
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] Shader extensions and shadows in a ray / path tracing renderer.

2017-04-12 19:29 GMT+02:00 Roy Walmsley <roy.walmsley at ntlworld.com>:
> One question I have just thought about relates to your proposed shader and
> shadow extensions. It is this:
>
>
>
> Currently your extensions are designed around an OpenGL rendering
> environment. X3D actually makes no assumptions about the rendering
> environment, so the standard should be equally applicable to, for example, a
> path or ray tracing renderer. Would your extensions still be valid in such
> environments?
>

The same question applies to the standard X3D "Programmable shaders"
component ( http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/shaders.html
), with the same answer:

1. On one hand, we try to make a specification incorporate various
possible shading languages - GLSL, HLSL, Cg.

  That's why we have the "language" field at the shader nodes.

  Also some shader languages require a little different organization
(e.g. for GLSL you use ComposedShader + ShaderPart. For HLSL, you use
ProgramShader + ShaderProgram). The specification encompasses them
all.

  My Effect extensions should also work with all shading languages. I
kept that in mind when designing them (see
https://castle-engine.sourceforge.io/compositing_shaders_doc/html/chapter.implementation.html
). If I failed, I'm sure it can be easily fixed, by drawing
inspiration from already-working standard "Programmable shaders"
component:)

2. We don't require the implementation to handle any particular
shading language. That's why "shaders" field is MFNode, so the browser
can choose any option it can. Or the browser can simply ignore the
"shaders" field, when none match (e.g. browser uses Direct3D (HLSL)
and user provides only GLSL shader code).

So, any renderer, real-time or not, could

- Make it's shading language (like RenderMan Shading Language,
https://en.wikipedia.org/wiki/RenderMan_Shading_Language ) available
through X3D shaders.

- Or just ignore the shaders, if not applicable.

Best regards,
Michalis

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org