<div dir="ltr"><div>In X3D v4, I deliberately removed the problem of RGB and grayscale textures treated inconsistently. I think this was a serious problem with X3D 3, I complained about it a lot, and finally I got to actually fix it in X3D 4 :)</div><div><br></div><div>See the X3D v4 draft, where I document this explicitly: <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html#LightingTextureSampling">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html#LightingTextureSampling</a> . This statement is consistent with the following equations (later in this section), and some other prose around the X3D spec that I modified.</div><div><br></div><div>I wrote a lot of text about why it is a good change on <a href="https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent">https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent</a> and <a href="https://github.com/michaliskambi/x3d-tests/wiki/X3D-version-4:-New-features-of-materials,-lights-and-textures#treatment-of-rgb-and-grayscale-textures-consistent">https://github.com/michaliskambi/x3d-tests/wiki/X3D-version-4:-New-features-of-materials,-lights-and-textures#treatment-of-rgb-and-grayscale-textures-consistent</a> :)</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 18:29 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">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">Hi Yanshen,<br>
<br>
Thanks for these comments. See below for short responses.<br>
<br>
On Sun, Aug 23, 2020 at 10:49 AM Nicholas Polys <<a href="mailto:npolys@vt.edu" target="_blank">npolys@vt.edu</a>> wrote:<br>
><br>
> My student Yanshen Sun has a few comments (below)<br>
>  and an implementation here:<br>
> <a href="http://metagrid2.sv.vt.edu/~yansh93/archimedes_pp_normal.html" rel="noreferrer" target="_blank">http://metagrid2.sv.vt.edu/~yansh93/archimedes_pp_normal.html</a><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>
> 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>
I believe in X3D version 4.0 the default behaviour will change to<br>
mixing (by multiplying), for any geometry. So allowing for mixing<br>
could not have been the motivation for introducing a colorMode field.<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>
> 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.<br>
<br>
Yes, it does indeed. Unfortunately, "added to" would need to be<br>
interpreted in the mathematical sense to make sense of the choice of<br>
the phrase. After all, the choice for the phrase could have been<br>
"mixed with" or "combined with".<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>
> 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.<br>
<br>
This is all true on the implementation/x3dom side. But the X3D spec.<br>
really is decoupled from webgl/opengl and needs to spell out these<br>
behaviours. Fortunately, the spec. already does, for other geometries.<br>
<br>
There appears to be wider support for a change in the draft spec.<br>
language. My feeling is that the colorMode field could just be omitted<br>
without loss of functionality or precision. It is probably necessary<br>
to add a sentence explaining that only the emissiveColor or baseColor<br>
component needs to be applied unless there are normals available<br>
(although this would be really the only choice anyways).<br>
<br>
-Andreas<br>
<br>
> Hope this helps!<br>
><br>
> Best regards,<br>
> Yanshen<br>
><br>
><br>
><br>
> ---------- Forwarded message ---------<br>
> From: Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>><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>
><br>
><br>
> 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>
><br>
> 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>
><br>
> This would also be consistent with glTF.<br>
><br>
> Regards,<br>
> Michalis<br>
><br>
> niedz., 23 sie 2020 o 06:43 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> napisał(a):<br>
>><br>
>> <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>
><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>
><br>
><br>
> --<br>
> 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>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div>