<div dir="auto"><div><br><br><div data-smartmail="gmail_signature">---on the phone---</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 29, 2019, 10:13 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>>:<br>
><br>
> In my view, the natural and probably least surprising, or most<br>
> expected mode of visualization of a Pointset with Normals is shading<br>
> according to the Appearance, in the same way as triangles are shaded.<br>
> This is I think Vince's option 2.<br>
<br>
I agree this would be natural.<br>
<br>
> A Pointset without a Normal node would not be shaded, eg. be rendered<br>
> in a backward compatible way, essentially color as emissive.<br>
<br>
I'm after this approach.<br>
<br>
> Another issue are Textures. With shading, the expectation is that<br>
> relevant properties such a diffuse, specular, emissive, potentially<br>
> displacement, others and also normals (or PBR properties), (and<br>
> tangents) can be provided by texture maps and uv tex. coords. This<br>
> would be relatively straightforward to spec. because it is analogous<br>
> to surface geometry nodes. Not sure what a sensible set of default<br>
> tex. coords would be, perhaps just NULL, meaning textures are ignored.<br>
<br>
I think that a sensible default texture coordinates could be generated<br>
for PointSet just like they are for IndexedFaceSet: use local bounding<br>
box of the node. See<br>
<a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#IndexedFaceSet" rel="noreferrer noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#IndexedFaceSet</a><br>
, text from "If the texCoord field is NULL, a default texture<br>
coordinate mapping is calculated using the local coordinate system<br>
bounding box of the shape.".<br>
<br>
This texture coordinate generation scheme is useful in general. It's<br>
so useful (on any shape) that I allow in CGE to request it explicitly<br>
by "TextureGenerator { mode "BOUNDS2D" }", see<br>
<a href="https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_tex_coord_bounds" rel="noreferrer noreferrer" target="_blank">https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_tex_coord_bounds</a><br>
.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, agreed. uv mapped from the axis aligned bounding box would be a good default. u from X and v from Y.</div><div dir="auto"><br></div><div dir="auto">Are tangents really necessary for Phong shading ? see </div><div dir="auto"><a href="https://en.m.wikipedia.org/wiki/Blinn%E2%80%93Phong_reflection_model">https://en.m.wikipedia.org/wiki/Blinn%E2%80%93Phong_reflection_model</a><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Andreas</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> How does glTF deal with Pointsets ? Let's look it up:<br>
> <a href="https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#point-and-line-materials" rel="noreferrer noreferrer" target="_blank">https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#point-and-line-materials</a><br>
><br>
> POINTS and LINES should have widths of 1px in viewport space.<br>
> For LINES with NORMAL and TANGENT properties, render with standard<br>
> lighting including normal maps.<br>
> For POINTS or LINES with no TANGENT property, render with standard<br>
> lighting but ignore any normal maps on the material.<br>
> For POINTS or LINES with no NORMAL property, don't calculate lighting<br>
> and instead output the COLOR value for each pixel drawn.<br>
><br>
> So no sprites, and one size. I guess PBR needs tangents in addition to<br>
> normals. That does not seem to be too helpful.<br>
<br>
The glTF text seems natural to me, and indicates that they do exactly<br>
what we want to do -- cool :)<br>
<br>
- If the points don't have normals, they cannot be lit. This is<br>
similar to X3D that will "render them in backward-compatible fashion"<br>
as you wrote above.<br>
<br>
- Otherwise all lighting features work. Once you have normals, you can<br>
calculate lighting...<br>
<br>
- ....except normal maps. The need for "tangents" here is natural. You<br>
cannot interpret normal map data without knowing "tangents".<br>
<br>
For polygons, tangents can be auto-calculated knowing the<br>
connectivity, because you know "how the texture coordinates change<br>
across surface". (Both glTF and X3D 4.0 say that browser should be<br>
able to do this auto-calculation -- in my PR about PBR I wrote a<br>
section introducing normal maps to X3DOneSidedMaterial.)<br>
<br>
But for points, there is no "connectivity" defined, so browser<br>
cannot calculate tangents. They need to be provided. That's a<br>
requirement coming from how normalmaps work, the glTF specification<br>
doesn't really have a choice here.<br>
<br>
For X3D spec, we can do 2 things:<br>
<br>
1. For now, say that normal maps are unused on PointSet (and say<br>
this may be addressed in future spec version).<br>
<br>
2. Or introduce a way to provide tangent data (not just for<br>
points; for anything that can have explicit normals). Just "SFNode<br>
tangent" that accepts X3DNormalNode (tangent data is a set of 3D<br>
normalized directions, so it can be expressed as a "Normal" node,<br>
although the node name is confusing in this case).<br>
<br>
Such "tangent" node would be useful on *all* X3D nodes where<br>
"normal" field is defined. But on points, it would be *necessary* to<br>
use normal maps, on other nodes it's optional to provide it (useful to<br>
optimize, and/or to have perfect match with normalmap-baking<br>
application). That's how glTF and Unity do it too.<br>
<br>
Regards,<br>
Michalis<br>
</blockquote></div></div></div>