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

[Andreas Plesch]

---on the phone---

On Fri, Nov 29, 2019, 10:13 PM Michalis Kamburelis <michalis.kambi at gmail.com>
wrote:

> 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
> .
>

Yes, agreed. uv mapped from the axis aligned bounding box would be a good
default. u from X and v from Y.

Are tangents really necessary for Phong shading ? see
https://en.m.wikipedia.org/wiki/Blinn%E2%80%93Phong_reflection_model

PointProperties currently assumes that the Appearance texture is the
texture repeated for each extended point as a kind of sprite. I think it
will be necessary to have both, a global texture and a sprite texture.

Andreas


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