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

Sat Apr 29 19:29:27 PDT 2017

On Sat, Apr 29, 2017 at 7:24 PM, Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

>  ,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 :)
>

I support this proposal. In addition, or perhaps as an alternative, a
curated, or endorsed library of shader code fragments, which cover the same
functionality, is desirable.

>
> >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" .
>
>
I looked again at the current x3dom implementation here:
https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L355

My understanding now is a little changed. Existing vertices are always
displaced along the normal at the vertex:
https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L444
For the fragment shader the normal texture is used, if there is one.
Otherwise, the normal is calculated from the displacement texture taking
into account the displacementAxis field:
https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L380
and then multiplying with the local normal.
Hm, not sure why this is not done per fragment in the fragment shader
(perhaps too slow):
https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L482
At least, I cannot find use of the displacement map there.

>
> > 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.
>
>
Yes, for my use in an elevation grid. the advantage of using a displacement
texture would boil down to having an efficient way of getting the
elevations into the gpu. All the vertices are still needed.

> 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.
>
>
Is there anything in the x3d standard which somehow makes assumptions about
textures, eg. would conflict with floating point textures ? I do not really
think so.

> >
> > 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).
>
>
If you put an x3dom version on github, it makes it easy to collaborate.

Thanks for all your contributions,

Andreas

-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170429/5329cd73/attachment.html>