<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:windowtext;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Leonard, I use X3DOM’s subdivision with Sphere and a vertex shader to achieve a flower-like geometry. This could and probably should be done with IFS, but I have chosen Spheres, because I don’t have to lay out the coordIndexes for the IFS (I have done it the latter way first). I would like to wrap the IFS into a sphere IFS, but haven’t worked on that yet.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Example shown here:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><a href="http://coderextreme.net/X3DJSONLD/flowers.xhtml">http://coderextreme.net/X3DJSONLD/flowers.xhtml</a></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:Leonard.Daly@realism.com">Leonard Daly</a><br><b>Sent: </b>Wednesday, April 26, 2017 10:57 AM<br><b>To: </b><a href="mailto:x3d-public@web3d.org">X3D Public</a><br><b>Subject: </b>[x3d-public] What to do about Shaders [was: Flattening Scene Graph]</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I have another discussion topic. This time it is shaders. I have included Michalis's response to another post because it is a good place to start.<br><br>There are two places in the X3D specification that are not declarative -- Script and Shaders. I wish to discuss shaders in this thread.<br><br>At the time the Shader node was developed, there were two primary shader languages - GLSL and HLSL (Wikipedia lists 8 real-time languages <a href="https://en.wikipedia.org/wiki/Shading_language">https://en.wikipedia.org/wiki/Shading_language</a>). X3D uses those two plus nVidia's CG. Note that Wikipedia states that Cg is deprecated. Use of the Shader node requires some rather detailed knowledge about the hardware that is available on the target system. If the target system is unknown, then X3D's Shader node allows multiple versions to be included to support all common hardware. <br><br>This is rather deep and certainly not declarative knowledge needed for someone to use. In the case of display in a web browser (meaning integrated DOM), then the target language is reduced to GLSL. However, it still requires someone to know how to write a shader.<br><br>Instead of providing an interface that allows shaders to be written in the X3D environment, should X3D provide a library of possible effects? This could be things like sandpaper, fuzzy material, hard shinny steel, etc. Because there would be so many different possibilities, I think a library would be necessary. This is also important in the commercial realm where shader programmers make almost 3X a 3d artist (see graphcs at <a href="https://www.indeed.com/q-Shader-Programmer-jobs.html">https://www.indeed.com/q-Shader-Programmer-jobs.html</a> and <a href="https://www.indeed.com/jobs?q=3d+artist&l=">https://www.indeed.com/jobs?q=3d+artist&l=</a>).<br><br><br>Leonard Daly<br><br><br><br><br>On 4/25/2017 10:51 PM, Michalis Kamburelis wrote:<o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>2017-04-26 7:31 GMT+02:00 Michalis Kamburelis <a href="mailto:michalis.kambi@gmail.com"><michalis.kambi@gmail.com></a>:<o:p></o:p></pre><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><pre>E.g. I will definitely defend cube maps, 3D textures and</pre><pre>generated texture coordinates<o:p></o:p></pre></blockquote><pre><o:p> </o:p></pre><pre>Although, while I will defend cube maps and 3D textures, I will not</pre><pre>defend (as much) the current MultiTexture or</pre><pre>ComposedTexture3D or ComposedCubeMapTexture.</pre><pre><o:p> </o:p></pre><pre>- If we add CommonSurfaceShader to the spec, it can fill many usecases</pre><pre>where right now people use (with varying success) MultiTexture. I can</pre><pre>easily see that the MultiTexture component gets removed at that point.</pre><pre><o:p> </o:p></pre><pre>- ComposedTexture3D and ComposedCubeMapTexture could be in principle</pre><pre>removed. The existing ImageTexture3D and ImageCubeMapTexture could</pre><pre>perform all their roles (but we should recommend there some formats</pre><pre>with a good and open specification, like Khronos KTX; the existing</pre><pre>prose for ImageCubeMapTexture recommends only Microsoft DDS). So the</pre><pre>cube maps could be specified as "generated" or "url(xxx.ktx)", and</pre><pre>that's it.</pre><pre><o:p> </o:p></pre><pre>- Some of the TextureProperties information can be derived from other</pre><pre>information, or implementation-dependent (e.g. whether to use texture</pre><pre>compression). But not all (e.g. anisotropicDegree really needs to be</pre><pre>specified per-texture by a graphic artist, there is no escape from</pre><pre>that, with existing technology).</pre><pre><o:p> </o:p></pre><pre>IOW, I do see various ways in how the current specification could be</pre><pre>simplified, to have less nodes (and thus, enable more concise</pre><pre>description of some features). I do think that the optimum may be</pre><pre>somewhere between the current specification and your flat Mesh</pre><pre>proposal.</pre><pre><o:p> </o:p></pre><pre>Best regards,</pre><pre>Michalis</pre><pre><o:p> </o:p></pre></blockquote><p><o:p> </o:p></p><p class=MsoNormal>-- <br><b><span style='font-size:13.5pt;color:#333366'>Leonard Daly</span></b><span style='color:#333366'><br>3D Systems & Cloud Consultant<br>LA ACM SIGGRAPH Chair<br>President, Daly Realism - <i>Creating the Future</i> </span><o:p></o:p></p><p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p></div></body></html>