[x3d-public] Allowing Normal node to accompany PointSet, then achieving well-defined rendering

[Don Brutzman]

Continuing with the subject concept, I think several issues are fairly clear.

a.  Since many 3D scanning tools generate normals as part of their producing point clouds and meshes, there is a clear use case for including Normal vectors with point values in X3D models.

b.  When such information is available, there remain a number of issues with point rendering that need to be sorted out.

c.  Since Coordinate nodes can be re-USEd for making points lines and polygons, having clarity and consistent approaches for node relationships can have benefits for authors and tools.

d.  Any approach will need to be workable for classic X3Dv3 rendering and forthcoming X3Dv4 physically based rendering (which in turn is being designed for glTF compatibility).

So... I was looking at scene-graph structural relationships in the X3D Schema and DOCTYPE.  Fairly involved with a lot of variation; typically do-able but rather complex.

Interestingly, a simplifying principle may be possible.  If we look at X3DComposedGeometryNode, it is implemented by each of the polygonal nodes.

* org.web3d.x3d.sai.Rendering.X3DComposedGeometryNode
   https://www.web3d.org/specifications/java/javadoc/org/web3d/x3d/sai/Rendering/X3DComposedGeometryNode.html

* IndexedFaceSet, IndexedQuadSet, IndexedTriangleFanSet, IndexedTriangleSet, IndexedTriangleStripSet, QuadSet, TriangleFanSet, TriangleSet, TriangleStripSet

==============================
11.3.2 X3DComposedGeometryNode
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/rendering.html#X3DComposedGeometryNode

X3DComposedGeometryNode : X3DGeometryNode {
   MFNode [in,out] attrib          []   [X3DVertexAttributeNode]
   SFNode [in,out] color           NULL [X3DColorNode]
   SFNode [in,out] coord           NULL [X3DCoordinateNode]
   SFNode [in,out] fogCoord        NULL [FogCoordinate]
   SFNode [in,out] metadata        NULL [X3DMetadataObject]
   SFNode [in,out] normal          NULL [X3DNormalNode]
   SFNode [in,out] texCoord        NULL [X3DTextureCoordinateNode]
   SFBool []       ccw             TRUE
   SFBool []       colorPerVertex  TRUE
   SFBool []       normalPerVertex TRUE
   SFBool []       solid           TRUE
}
==============================

One might reasonably make a case that, similar to use of Normal information, authors might want to apply fog or shader rendering techniques to lines and points.  Sure enough, the X3D specification already supports that:

==============================
11.4.11 PointSet

PointSet : X3DGeometryNode {
   MFNode [in,out] attrib   []   [X3DVertexAttributeNode]
   SFNode [in,out] color    NULL [X3DColorNode]
   SFNode [in,out] coord    NULL [X3DCoordinateNode]
   SFNode [in,out] fogCoord NULL [FogCoordinate]
   SFNode [in,out] metadata NULL [X3DMetadataObject]
}
==============================
11.4.9 LineSet

LineSet : X3DGeometryNode {
   MFNode  [in,out] attrib         []   [X3DVertexAttributeNode]
   SFNode  [in,out] color          NULL [X3DColorNode]
   SFNode  [in,out] coord          NULL [X3DCoordinateNode]
   SFNode  [in,out] fogCoord       NULL [FogCoordinate]
   SFNode  [in,out] metadata       NULL [X3DMetadataObject]
   MFInt32 [in,out] vertexCount    []   [2,∞)
}
==============================

So here is a unifying proposal for treating points and lines similarly to polygons: *use X3DComposedGeometryNode consistently throughout*. Such a step simply adds normal and texCoord fields to point and line nodes.  We know that such a change is implementable in source code because a such large number of nodes shares that abstract node interface already.

Certainly the specifics of expected rendering will then need to be specified and implemented as appropriate for X3Dv4 upgrades, but we will have much more regularity for all models utilizing X3D coordinate-related data.

Such an alignment would have no backwards compatibility issues with prior X3D/VRML content since those extra fields (normal and texcoord) are simply not present in X3Dv3 content.  Further we have already decided that old-style models are rendered in old-style fashion, side by side with X3Dv4 PBR models, unless some modification has occurred to upgrade their rendering to X3Dv4.

Hope this makes sense!  If so it should simplify and generalize a number of design issues, to good effect.

Thanks for considering the possibilities.  I hope that everyone has a great holiday season, full of good will and good cheer towards all.

v/r Don


On 12/12/2019 11:05 AM, Michalis Kamburelis wrote:
> czw., 12 gru 2019 o 19:16 Don Brutzman <brutzman at nps.edu> napisał(a):
>>
>> On 12/5/2019 7:01 AM, Andreas Plesch wrote:
>>> Hi Michalis,
>>>
>>> thanks for thinking this through.
>>
>> yes
>>
>>> To me, then, there are really two options concerning normal maps for Pointset:
>>>
>>> (A) allow normal maps for Pointsets, and introduce a MFVec3f Tangent
>>> and probably Bitangent nodes, similar to the existing Normal node.
>>> Similar to the Normal node, values would be automatically computed for
>>> continuous surfaces using the MIKKTspace method when not provided.
>>> (B) If introducing Tangent nodes is not feasible at this point, do not
>>> allow normal maps for Pointsets and rely exclusively on the Normal
>>> node to provide normals, per vertex.
>>
>> hmmm, aren't tangents unambiguously computable from surface geometry and Normal vectors?  Knowing the surrounding mesh geometry constrains the more-general case of a point.
>>
>> If they are computable (tangent, bitangent, whatever) and accurately renderable only when another property or two is specified, then such properties might be included in PointProperties (i.e. tangent=true/false).
> 
> The tangent and bitangent are not computable at all for PointSet.
> PointSet is missing the necessary connectivity information (that
> allows to compute tangents on polygons, like IndexedFaceSet).
> 
> Also, "tangent" informations is a list of 3D vectors. It's an
> additional list of 3D vectors (in addition to all existing stuff, like
> coordinates and normals). So it would not look like
> "tangent=true/false".
> 
> About polygons: While the tangent/bitangent can be computed for
> polygons, like IndexedFaceSet.... but it's not perfect.
> 
> There are multiple ways to do this computation, that yield similar but
> not exactly the same results. If you want to the X3D browser to render
> normalmaps in exactly the same way as it was authored (e.g. Blender
> baking normalmaps), then the authoring tool should provide explicit
> tangent information.
> 
> A nice screenshot what happens if the calculation of tangents
> "mismatches" between the renderer and authoring tool is on
> https://gamedev.stackexchange.com/questions/146855/how-do-you-compute-the-tangent-space-vectors-with-normals-given-in-the-mesh
> (the screenshot is in the answer,
> https://gamedev.stackexchange.com/a/147030 ).
> 
> That's why, if we consider adding "tangent" to X3D, it makes sense to
> add it to all geometry nodes that already include "normal" field. This
> would be consistent. It would also be consistent with glTF.
> 
> Regards,
> Michalis
all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman