[x3d-public] x3d-public Digest, Vol 128, Issue 30

[Michalis Kamburelis]

Andreas Plesch <andreasplesch at gmail.com>:
>
> In my view, the natural and probably least surprising, or most
> expected mode of visualization of a Pointset with Normals is shading
> according to the Appearance, in the same way as triangles are shaded.
> This is I think Vince's option 2.

I agree this would be natural.

> A Pointset without a Normal node would not be shaded, eg. be rendered
> in a backward compatible way, essentially color as emissive.

I'm after this approach.

> Another issue are Textures. With shading, the expectation is that
> relevant properties such a diffuse, specular, emissive, potentially
> displacement, others and also normals (or PBR properties), (and
> tangents) can be provided by texture maps and uv tex. coords. This
> would be relatively straightforward to spec. because it is analogous
> to surface geometry nodes. Not sure what a sensible set of default
> tex. coords would be, perhaps just NULL, meaning textures are ignored.

I think that a sensible default texture coordinates could be generated
for PointSet just like they are for IndexedFaceSet: use local bounding
box of the node. See
https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#IndexedFaceSet
, text from "If the texCoord field is NULL, a default texture
coordinate mapping is calculated using the local coordinate system
bounding box of the shape.".

This texture coordinate generation scheme is useful in general. It's
so useful (on any shape) that I allow in CGE to request it explicitly
by "TextureGenerator { mode "BOUNDS2D" }", see
https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_tex_coord_bounds
.

> How does glTF deal with Pointsets ? Let's look it up:
> https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#point-and-line-materials
>
> POINTS and LINES should have widths of 1px in viewport space.
> For LINES with NORMAL and TANGENT properties, render with standard
> lighting including normal maps.
> For POINTS or LINES with no TANGENT property, render with standard
> lighting but ignore any normal maps on the material.
> For POINTS or LINES with no NORMAL property, don't calculate lighting
> and instead output the COLOR value for each pixel drawn.
>
> So no sprites, and one size. I guess PBR needs tangents in addition to
> normals. That does not seem to be too helpful.

The glTF text seems natural to me, and indicates that they do exactly
what we want to do -- cool :)

- If the points don't have normals, they cannot be lit. This is
similar to X3D that will "render them in backward-compatible fashion"
as you wrote above.

- Otherwise all lighting features work. Once you have normals, you can
calculate lighting...

- ....except normal maps. The need for "tangents" here is natural. You
cannot interpret normal map data without knowing "tangents".

    For polygons, tangents can be auto-calculated knowing the
connectivity, because you know "how the texture coordinates change
across surface". (Both glTF and X3D 4.0 say that browser should be
able to do this auto-calculation -- in my PR about PBR I wrote a
section introducing normal maps to X3DOneSidedMaterial.)

    But for points, there is no "connectivity" defined, so browser
cannot calculate tangents. They need to be provided. That's a
requirement coming from how normalmaps work, the glTF specification
doesn't really have a choice here.

   For X3D spec, we can do 2 things:

    1. For now, say that normal maps are unused on PointSet (and say
this may be addressed in future spec version).

    2. Or introduce a way to provide tangent data (not just for
points; for anything that can have explicit normals). Just "SFNode
tangent" that accepts X3DNormalNode (tangent data is a set of 3D
normalized directions, so it can be expressed as a "Normal" node,
although the node name is confusing in this case).

        Such "tangent" node would be useful on *all* X3D nodes where
"normal" field is defined. But on points, it would be *necessary* to
use normal maps, on other nodes it's optional to provide it (useful to
optimize, and/or to have perfect match with normalmap-baking
application). That's how glTF and Unity do it too.

Regards,
Michalis