[x3d-public] PointProperties revisited

[Andreas Plesch]

Hi Yanshen,

Thanks for these comments. See below for short responses.

On Sun, Aug 23, 2020 at 10:49 AM Nicholas Polys <npolys at vt.edu> wrote:
>
> My student Yanshen Sun has a few comments (below)
>  and an implementation here:
> http://metagrid2.sv.vt.edu/~yansh93/archimedes_pp_normal.html
>
> What is the motivation for having a colorMode field ? Should coloring
> not be handled the same way as it is for other geometries, eg. use
> color if no texture, use texture if no color, and blend if both are
> provided ? Other geometries do not require a colorMode field after
> all.
>
> 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.

I believe in X3D version 4.0 the default behaviour will change to
mixing (by multiplying), for any geometry. So allowing for mixing
could not have been the motivation for introducing a colorMode field.

> Even if there is an additional benefit of having the colorMode field, I think "
> TEXTURE_AND_POINT_COLOR" should multiply rather than add.
>
> 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.

Yes, it does indeed. Unfortunately, "added to" would need to be
interpreted in the mathematical sense to make sense of the choice of
the phrase. After all, the choice for the phrase could have been
"mixed with" or "combined with".

> Also, only RGBA textures are mentioned. Should one component (alpha),
> 2 component (greyscale plus alpha) and 3 component (RGB) textures also
> be allowed or well defined?
>
> 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.

This is all true on the implementation/x3dom side. But the X3D spec.
really is decoupled from webgl/opengl and needs to spell out these
behaviours. Fortunately, the spec. already does, for other geometries.

There appears to be wider support for a change in the draft spec.
language. My feeling is that the colorMode field could just be omitted
without loss of functionality or precision. It is probably necessary
to add a sentence explaining that only the emissiveColor or baseColor
component needs to be applied unless there are normals available
(although this would be really the only choice anyways).

-Andreas

> Hope this helps!
>
> Best regards,
> Yanshen
>
>
>
> ---------- Forwarded message ---------
> From: Michalis Kamburelis <michalis.kambi at gmail.com>
> Date: Sun, Aug 23, 2020 at 6:10 AM
> Subject: Re: [x3d-public] PointProperties revisited
> To: Andreas Plesch <andreasplesch at gmail.com>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
>
>
> 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.
>
> 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.
>
> This would also be consistent with glTF.
>
> Regards,
> Michalis
>
> niedz., 23 sie 2020 o 06:43 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>>
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#PointProperties
>>
>> has the current draft.
>>
>> What is the motivation for having a colorMode field ? Should coloring
>> not be handled the same way as it is for other geometries, eg. use
>> color if no texture, use texture if no color, and blend if both are
>> provided ? Other geometries do not require a colorMode field after
>> all.
>>
>> Even if there is an additional benefit of having the colorMode field, I think "
>> TEXTURE_AND_POINT_COLOR" should multiply rather than add:
>>
>> "TEXTURE_AND_POINT_COLOR shall display the RGBA channels of a texture
>> added to the RGB channels of the color defined in X3DMaterialNode or
>> X3DColorNode node, and the A channel of the texture if any."
>>
>> Adding introduces the problem of how to deal with oversaturated
>> components and contradicts how combining colors is defined for other
>> geometries.
>>
>> Also, only RGBA textures are mentioned. Should one component (alpha),
>> 2 component (greyscale plus alpha) and 3 component (RGB) textures also
>> be allowed or well defined ?
>>
>> https://www.web3d.org/x3d/content/X3dTooltips.html#PointProperties.containerField
>>
>> has a copy and paste typo. It still refers to "lineProperties"
>>
>> -Andreas
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> --
> Nicholas F. Polys, Ph.D.
>
> Director of Visual Computing
> Virginia Tech Research Computing
>
> Affiliate Professor
> Virginia Tech Department of Computer Science



-- 
Andreas Plesch
Waltham, MA 02453