[x3d-public] Support for specular maps (and more) in view3dscene, and Blender exporter to CommonSurfaceShader

[Michalis Kamburelis]

 ,2017-04-29 15:27 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
> CommonSurfaceShader is a nice way to get many of the performance and effect
> benefits of shadering without having to learn glsl and the light models'
> matrix math.

I agree, and I would like to see it become part of the X3D standard :)

>Some time ago I made a bump mapped Earth in x3dom and then
> wanted to add a displacement map. However, x3dom only allowed displacement
> in the direction of the displacementAxis field, by default y.  This is now
> changed and displacement is along the normal but only if there is also a
> normal map (I believe).
>
> http://andreasplesch.github.io/x3dom/CommonSurfaceShader/displacement.html
>
> Does parallax bump mapping mean displacement is applied along the local
> normal ? Do you think it would be beneficial to have a displacementAxis
> field ?

Yes, in my implementation, the "displacement" is always applied along
the normal. This is natural when you already have bump mapping working
in the tangent space.

Currently I just ignore the displacementAxis field.

It would be cleaner to be able to say explicitly something like
displacementAxis="NORMAL" .

>
> The main issue I had with using displacement maps is their limited fidelity,
> eg. only increments of 1/255 are possible.
>
> https://github.com/x3dom/x3dom/issues/591
>
> I think webgl2 allows floating point textures. Did you consider taking
> advantage of floating point textures ? I think maybe even phones support
> them.

For parallax bump mapping, I haven't yet encountered the need for
greater precision. The effect is a poor approximation of the actual
displacement anyway, you can easily see artifacts if you look closely
or if you set displacementFactor to something large. So, subtle
details in displacement are not perfectly represented anyway.

But that is just the current case. I can easily imagine that a
different (much more precise) implementation of parallax bump mapping,
or just a different interpretation of the displacement, would indeed
suffer from this problem.

Your solution from https://github.com/x3dom/x3dom/issues/591 seems
nice, and using floating textures for this also seems like a good
idea. I haven't yet tested it yet, though.

Right now, floating-point textures in my engine are only half
supported -- we have a class TRGBFloatImage and you can load it to
OpenGL, but for now no image format is actually loaded through this
out-of-the-box. Our DDS reader for now doesn't handle floating-point
textures. This is all very fixable of course, and once I do, I will be
able to test floating-point textures in all cases, including for
displacement maps:)

Phones support floating point textures, indeed. 32-bit floats or
16-bit half-floats. OpenGLES 2 has extensions (OES_texture_half_float,
OES_texture_float to load, and to interpolate:
OES_texture_half_float_linear, OES_texture_float_linear). OpenGLES 3
mandates support for loading 32-bit and 16-bit floating-point textures
and interpolation of 16-bit one.

>
> Finally, I could not find the displacementTexture field in instant reality :
> http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/
>
> Not sure, if they want to add it (or perhaps already did).
>
> I may try to adopt your examples for x3dom,
>

Indeed, I also saw that the X3DOM specification of CommonSurfaceShader
has a little more fields than the one in Instant Reality.

I have on my TODO list to try this all in X3DOM and InstantReality,
and make sure we're compatible, so I may commit an X3DOM version there
soon:) Please feel free to do it before me, or in general to use these
examples however you see fit. Or the models are authored by me, and
are free to use and redistribute (
https://castle-engine.sourceforge.io/demo_models.php), all the
textures are also on open-source-compatible licenses (the details are
in the AUTHORS.txt files inside).

Thank you for the comments!

Best regards,
Michalis