<div dir="ltr">My student Yanshen Sun has a few comments (below)<div> and an implementation here:</div><div><a href="http://metagrid2.sv.vt.edu/~yansh93/archimedes_pp_normal.html" target="_blank">http://metagrid2.sv.vt.edu/~yansh93/archimedes_pp_normal.html</a> </div><div><br></div><div><br></div><div><div dir="ltr"><span class="gmail-im" style="color:rgb(80,0,80)"><div><b><br class="gmail-Apple-interchange-newline">What is the motivation for having a colorMode field ? Should coloring<br>not be handled the same way as it is for other geometries, eg. use<br>color if no texture, use texture if no color, and blend if both are<br>provided ? Other geometries do not require a colorMode field after<br>all.</b></div><div><br></div></span><div>By default, when a shape has both texture and material nodes with it, RGB textures make colors useless in X3D. While it seems that they do want mix the texture color and point color together for point-based geometries.  <br><br><b><span class="gmail-im" style="color:rgb(80,0,80)">Even if there is an additional benefit of having the colorMode field, I think "<br></span>TEXTURE_AND_POINT_COLOR" should multiply rather than add.</b><br><br>I agree with this. I tried to used "add" and found that, just like Andreas mentioned,  it led to more white points and lower saturability than using "multiply". I also used "multiply" in my own implementation. The phrase "added to" in the description feels more like "mixed with" to me, instead of adding up the values.<span class="gmail-im" style="color:rgb(80,0,80)"><br><br><b>Also, only RGBA textures are mentioned. Should one component (alpha),<br>2 component (greyscale plus alpha) and 3 component (RGB) textures also<br>be allowed or well defined?  </b><br></span></div><div><br></div><div>This problem handled during texture data processing. For each texture node, X3D checks the number of components of the texture node and sets the corresponding parameter in gl.texImage2D(). By doing so, even though there are a different number of the component in textures, they are all considered to be 4-channel data in GLSL. For example, the r, g, and b channels of a grayscale texture are set to be the same values; The alpha channel is defaulting to be 1.0 while alpha data is not given. Therefore, the type of textures doesn't affect the implementation of PointProperties.</div><div><br></div><div>Hope this helps!</div><div><br></div><div>Best regards,</div><div>Yanshen</div></div><div class="gmail-yj6qo gmail-ajU" style="outline:none;padding:10px 0px;width:22px;margin:2px 0px 0px"><br class="gmail-Apple-interchange-newline"></div></div><div> <br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Michalis Kamburelis</strong> <span dir="auto"><<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>></span><br>Date: Sun, Aug 23, 2020 at 6:10 AM<br>Subject: Re: [x3d-public] PointProperties revisited<br>To: Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br></div><br><br><div dir="ltr"><div>I second this. I would be best if we can simply render points *in the same, exact way, using the same texture/color/lighting equations* as all other geometric nodes.<br></div><div><br></div><div>The existing prose for rendering already says what to do with textures, colors, lighting etc. Let's let the same equations be just used for points (and lines, BTW). Of course the non-unlit lighting models are only available if explicit normals are provided. But when normals are provided, points and lines can just utilize the same rendering logic as other nodes.<br></div><div><br></div><div>This would also be consistent with glTF.</div><div><br></div><div>Regards,</div><div>Michalis<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">niedz., 23 sie 2020 o 06:43 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#PointProperties" rel="noreferrer" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#PointProperties</a><br>
<br>
has the current draft.<br>
<br>
What is the motivation for having a colorMode field ? Should coloring<br>
not be handled the same way as it is for other geometries, eg. use<br>
color if no texture, use texture if no color, and blend if both are<br>
provided ? Other geometries do not require a colorMode field after<br>
all.<br>
<br>
Even if there is an additional benefit of having the colorMode field, I think "<br>
TEXTURE_AND_POINT_COLOR" should multiply rather than add:<br>
<br>
"TEXTURE_AND_POINT_COLOR shall display the RGBA channels of a texture<br>
added to the RGB channels of the color defined in X3DMaterialNode or<br>
X3DColorNode node, and the A channel of the texture if any."<br>
<br>
Adding introduces the problem of how to deal with oversaturated<br>
components and contradicts how combining colors is defined for other<br>
geometries.<br>
<br>
Also, only RGBA textures are mentioned. Should one component (alpha),<br>
2 component (greyscale plus alpha) and 3 component (RGB) textures also<br>
be allowed or well defined ?<br>
<br>
<a href="https://www.web3d.org/x3d/content/X3dTooltips.html#PointProperties.containerField" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/content/X3dTooltips.html#PointProperties.containerField</a><br>
<br>
has a copy and paste typo. It still refers to "lineProperties"<br>
<br>
-Andreas<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</div><br clear="all"><div><br></div>-- <br><div dir="ltr" data-smartmail="gmail_signature">Nicholas F. Polys, Ph.D.<br><br>Director of Visual Computing <br>Virginia Tech Research Computing <br><br>Affiliate Professor<br>Virginia Tech Department of Computer Science<br></div></div></div>