[x3d-public] Allowing Normal node to accompany PointSet, then achieving well-defined rendering
John Carlson
yottzumm at gmail.com
Fri Dec 27 11:08:37 PST 2019
Sounds good, Don. Are there any other geometry nodes we need to inherit
from composed node?
John
On Wed, Dec 25, 2019 at 5:06 PM Don Brutzman <brutzman at nps.edu> wrote:
> 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
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20191227/ebb1ed3b/attachment.html>
More information about the x3d-public
mailing list