<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 29, 2017 at 7:24 PM, Michalis Kamburelis <span dir="ltr"><<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ,2017-04-29 15:27 GMT+02:00 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>>:<br>
> CommonSurfaceShader is a nice way to get many of the performance and effect<br>
> benefits of shadering without having to learn glsl and the light models'<br>
> matrix math.<br>
<br>
I agree, and I would like to see it become part of the X3D standard :)<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>Some time ago I made a bump mapped Earth in x3dom and then<br>
> wanted to add a displacement map. However, x3dom only allowed displacement<br>
> in the direction of the displacementAxis field, by default y.  This is now<br>
> changed and displacement is along the normal but only if there is also a<br>
> normal map (I believe).<br>
><br>
> <a href="http://andreasplesch.github.io/x3dom/CommonSurfaceShader/displacement.html" rel="noreferrer" target="_blank">http://andreasplesch.github.<wbr>io/x3dom/CommonSurfaceShader/<wbr>displacement.html</a><br>
><br>
> Does parallax bump mapping mean displacement is applied along the local<br>
> normal ? Do you think it would be beneficial to have a displacementAxis<br>
> field ?<br>
<br>
Yes, in my implementation, the "displacement" is always applied along<br>
the normal. This is natural when you already have bump mapping working<br>
in the tangent space.<br>
<br>
Currently I just ignore the displacementAxis field.<br>
<br>
It would be cleaner to be able to say explicitly something like<br>
displacementAxis="NORMAL" .<br>
<br></blockquote><div><br></div><div>I looked again at the current x3dom implementation here:</div><div><a href="https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L355">https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L355</a><br></div><div><br></div><div>My understanding now is a little changed. Existing vertices are always displaced along the normal at the vertex:</div><div><a href="https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L444">https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L444</a><br></div><div>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:</div><div><a href="https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L380">https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L380</a><br></div><div>and then multiplying with the local normal.</div><div>Hm, not sure why this is not done per fragment in the fragment shader (perhaps too slow):</div><div><a href="https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L482">https://github.com/x3dom/x3dom/blob/master/src/shader/ShaderDynamic.js#L482</a><br></div><div>At least, I cannot find use of the displacement map there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> The main issue I had with using displacement maps is their limited fidelity,<br>
> eg. only increments of 1/255 are possible.<br>
><br>
> <a href="https://github.com/x3dom/x3dom/issues/591" rel="noreferrer" target="_blank">https://github.com/x3dom/<wbr>x3dom/issues/591</a><br>
><br>
> I think webgl2 allows floating point textures. Did you consider taking<br>
> advantage of floating point textures ? I think maybe even phones support<br>
> them.<br>
<br>
For parallax bump mapping, I haven't yet encountered the need for<br>
greater precision. The effect is a poor approximation of the actual<br>
displacement anyway, you can easily see artifacts if you look closely<br>
or if you set displacementFactor to something large. So, subtle<br>
details in displacement are not perfectly represented anyway.<br>
<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But that is just the current case. I can easily imagine that a<br>
different (much more precise) implementation of parallax bump mapping,<br>
or just a different interpretation of the displacement, would indeed<br>
suffer from this problem.<br>
<br>
Your solution from <a href="https://github.com/x3dom/x3dom/issues/591" rel="noreferrer" target="_blank">https://github.com/x3dom/<wbr>x3dom/issues/591</a> seems<br>
nice, and using floating textures for this also seems like a good<br>
idea. I haven't yet tested it yet, though.<br>
<br>
Right now, floating-point textures in my engine are only half<br>
supported -- we have a class TRGBFloatImage and you can load it to<br>
OpenGL, but for now no image format is actually loaded through this<br>
out-of-the-box. Our DDS reader for now doesn't handle floating-point<br>
textures. This is all very fixable of course, and once I do, I will be<br>
able to test floating-point textures in all cases, including for<br>
displacement maps:)<br>
<br>
Phones support floating point textures, indeed. 32-bit floats or<br>
16-bit half-floats. OpenGLES 2 has extensions (OES_texture_half_float,<br>
OES_texture_float to load, and to interpolate:<br>
OES_texture_half_float_linear, OES_texture_float_linear). OpenGLES 3<br>
mandates support for loading 32-bit and 16-bit floating-point textures<br>
and interpolation of 16-bit one.<br>
<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> Finally, I could not find the displacementTexture field in instant reality :<br>
> <a href="http://doc.instantreality.org/documentation/nodetype/CommonSurfaceShader/" rel="noreferrer" target="_blank">http://doc.instantreality.org/<wbr>documentation/nodetype/<wbr>CommonSurfaceShader/</a><br>
><br>
> Not sure, if they want to add it (or perhaps already did).<br>
><br>
> I may try to adopt your examples for x3dom,<br>
><br>
<br>
Indeed, I also saw that the X3DOM specification of CommonSurfaceShader<br>
has a little more fields than the one in Instant Reality.<br>
<br>
I have on my TODO list to try this all in X3DOM and InstantReality,<br>
and make sure we're compatible, so I may commit an X3DOM version there<br>
soon:) Please feel free to do it before me, or in general to use these<br>
examples however you see fit. Or the models are authored by me, and<br>
are free to use and redistribute (<br>
<a href="https://castle-engine.sourceforge.io/demo_models.php" rel="noreferrer" target="_blank">https://castle-engine.<wbr>sourceforge.io/demo_models.php</a><wbr>), all the<br>
textures are also on open-source-compatible licenses (the details are<br>
in the AUTHORS.txt files inside).<br>
<br></blockquote><div><br></div><div>If you put an x3dom version on github, it makes it easy to collaborate.</div><div><br></div><div>Thanks for all your contributions,</div><div><br></div></div>Andreas<br clear="all"><div><br></div>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>