[x3d-public] battle of the composed shaders. X3DOM wins until you teach me how towrite better shaders.

[Michalis Kamburelis]

2017-05-04 11:04 GMT+02:00  <yottzumm at gmail.com>:
> http://coderextreme.net/X3DJSONLD/ball.xhtml  (inlines and URLs, links to
> shaders)
>
> http://coderextreme.net/X3DJSONLD/ball.x3d (actual file to modify)
>
> http://coderextreme.net/X3DJSONLD/x3dom.vs (working vertex shader in X3DOM)
>
> http://coderextreme.net/X3DJSONLD/common.fs (working fragment shader in
> X3DOM)
>
>
>
> Has a sphere in a scene shown with ComposedShaders.  My challenge for
> everyone except for X3DOM is to provide better shading programs or shaders
> to me that will make your viewers look superb like X3DOM.  I suspect that it
> has something to do with the shaders, but I have only a clue how to write
> OpenGL ES shaders, and I don’t know how to write portable shaders, it
> appears.  So I’m hoping you will help.

The vertex shader version that works with view3dscene is attached,
with a screenshot as a proof :) Nothing else needed to be changed in
your files.

You are depending on 2 uniforms, and 3 attributes, which are only
defined by X3DOM (
https://doc.x3dom.org/tutorials/lighting/customShader/ ). It's not
that X3DOM is doing something better here than the other browsers.
It's just that every browser has it's own conventions for these
uniform/attribute names, and your files happen to follow X3DOM
conventions.

I agree that this is unfortunate. I'm not defending the current
situation, I'm only explaining it, and describing where do I see
solutions :)

This has similar answers as mentioned in the thread "does someone have
a solution to multiple vertex shader files":

1. We could standardize these names (uniforms and attributes, in this
case). Seems like a simple solution, but standardizing here too much
would limit possible optimizations on the implementation side.

2. Or we could write shaders using Effect nodes from my "compositing
shaders" extensions.

The case of 2 uniforms (modelViewProjectionMatrix and modelViewMatrix)
also has an additional possible solution, which I mentioned in the
thread "Extensions from Castle Game Engine that could be generally
useful in the X3D standard":

3. We could make a ViewpointSensor node that allows to generate
various matrices as X3D events. These events could be ROUTEd then to
your shader. Like
https://castle-engine.sourceforge.io/x3d_implementation_navigation_extensions.php#section_ext_viewpoint_camera_matrix
. This solution is only partial (it only solves the issue with 2
uniforms). But it's clean: it's not specific to any shader language.
ViewpointSensor would be a generally-useful node, that allows to pass
this information to many places -- like shaders.

Best regards,
Michalis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ball_0.jpg
Type: image/jpeg
Size: 73003 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170504/fdcd31ed/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x3dom-converted-to-view3dscene.vs
Type: application/octet-stream
Size: 2136 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170504/fdcd31ed/attachment-0001.obj>