[x3d-public] PointProperties revisited

Michalis Kamburelis michalis.kambi at gmail.com
Sun Aug 23 13:49:19 PDT 2020


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 :)

See the X3D v4 draft, where I document this explicitly:
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/lighting.html#LightingTextureSampling
. This statement is consistent with the following equations (later in this
section), and some other prose around the X3D spec that I modified.

I wrote a lot of text about why it is a good change on
https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent
and
https://github.com/michaliskambi/x3d-tests/wiki/X3D-version-4:-New-features-of-materials,-lights-and-textures#treatment-of-rgb-and-grayscale-textures-consistent
:)

Regards,
Michalis

niedz., 23 sie 2020 o 18:29 Andreas Plesch <andreasplesch at gmail.com>
napisał(a):

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200823/3bb82065/attachment.html>


More information about the x3d-public mailing list