[x3d-public] Feedbacks related to x3d.py: creaseAngle support by Triangle nodes
Michalis Kamburelis
michalis.kambi at gmail.com
Wed Jun 17 14:22:55 PDT 2020
1. Indeed, please *do not* add creaseAngle to non-indexed nodes. It would
then require manually "recovering" the neighborhood by searching for
duplicates on the coordinate list. Which is slow. And also this "searching"
would be inconsistent with indexed nodes, which do not treat 2 triangles as
neighbors just because their corners have equal positions, they treat 2
triangles as neighbors only if their corners have equal indexes.
2. I would not deprecate TriangleFanSet or TriangleStripSet. They are
possible in glTF, and my importer glTF -> X3D nodes utilizes them, see
https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dloadinternalgltf.pas#L1404
.
Essentially, any geometry primitive possible in normal graphic APIs
(like OpenGL[ES]) can be expressed in glTF, and can be indexed or not
indexed.
3. Indeed I think that the reason why these nodes don't have "creaseAngle"
was that their use-case was for "maximum efficiency". If you don't want
maximum efficiency, then use IndexedFaceSet. If you want efficiency, then
you can use these nodes, and also provide explicit normals instead of
relying on the X3D browser to calculate them.
4. I'm not sure do we need to introduce "creaseAngle" even on the indexed
nodes (IndexedTriangleSet, IndexedTriangleFanSet, IndexedTriangleStripSet).
- On IndexedTriangleFanSet, IndexedTriangleStripSet the creaseAngle
doesn't seem very useful (if you only follow indexes, then you don't have
too many neighbors).
- On IndexedTriangleSet, creaseAngle seems useful.. but would
complicate the implementation and make loading of IndexedTriangleSet (in
case of non-trivial creaseAngle) slower, since you generally need to
"re-index" the geometry when calculating normals using creaseAngle, because
some vertexes with equal index and equal position may have different normal
value because of creaseAngle.
Note that glTF doesn't have anything equivalent to createAngle. glTF
specification just says """Implementation note: When normals are not
specified, client implementations should calculate flat normals.""". Which
practically means that any decent glTF exporter should just write normal
vectors in the file.
All in all, I'm here mostly after "leaving things as-is". There are good
arguments for the current situation, and why creaseAngle is only on
IndexedFaceSet :)
The one place where I would say "change is sensible" (although not
required) is that indeed introducing "IndexedTriangleSet.creaseAnglee"
makes sense.
Regards,
Michalis
śr., 17 cze 2020 o 21:54 Andreas Plesch <andreasplesch at gmail.com>
napisał(a):
> I noticed that there was not a lot of (any?) feedback.
>
> We came across the lack of a creaseAngle field for TriangleSet because
> this node was conceptually straightforward to use for occ x3dom export
> but switched now to indexed nodes.
>
> I do not know the VRML background but suspect that the fanset and
> stripset nodes were possibly introduced because they offered hardware
> based performance gains. In order to preserve these gains, perhaps the
> more expensive creaseAngle field was reserved for nodes which were not
> directly hardware accelerated. I would be surprised if this
> performance aspect still applies to modern GPUs.
>
> Another, related reason for the lack of creaseAngle may be the fact
> that the field requires finding neighbouring triangles. This is
> expensive, especially for the non-indexed geometries which would
> essentially need internal indexing of vertices with duplication
> checks. The typical use case for TriangleSet, on the other hand, is an
> unconnected triangle soup where creaseAngle is not useful. This reason
> would not apply to indexed geometries such as IndexedTriangleSet.
>
> As as result, I think it is worth considering to start to deprecate
> all FanSet and StripSet geometry nodes, and to add a creaseAngle field
> to IndexedTriangleSet. Too radical ?
>
> My two cents, -Andreas
>
> > Date: Sun, 14 Jun 2020 21:09:19 -0700
> > From: Don Brutzman <brutzman at nps.edu>
> > To: Thomas Paviot <tpaviot at gmail.com>, X3D Graphics public mailing
> > list <x3d-public at web3d.org>
> > Subject: Re: [x3d-public] Feedbacks related to x3d.py: creaseAngle
> > support by Triangle nodes
> >
> > Open question: why isn't creaseAngle supported by the Triangle nodes?
> Seems like an unintended omission. All feedback welcome, we will resolve
> this during next Friday's X3D Working Group meeting.
> >
> > [1] X3D Architecture, Rendering component
> >
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#IndexedTriangleSet
> >
> > IndexedTriangleFanSet,
> > IndexedTriangleSet,
> > IndexedTriangleStripSet,
> > TriangleFanSet,
> > TriangleSet, and
> > TriangleStripSet.
> >
> > [2] X3D Architecture, Rendering component, 11.2.3 Common geometry fields
> >
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#CommonGeometryFields
> >
> > "Certain geometry nodes have several fields that provide information
> about the rendering of the geometry. These fields specify the vertex
> ordering, if the shape is solid, if the shape contains convex faces, and at
> what angle a crease appears between faces, and are named ccw, solid, convex
> and creaseAngle, respectively."
> > [...]
> > "The creaseAngle field affects how default normals are generated. If the
> angle between the geometric normals of two adjacent faces is less than the
> crease angle, normals shall be calculated so that the faces are shaded
> smoothly across the edge; otherwise, normals shall be calculated so that a
> lighting discontinuity across the edge is produced. Crease angles shall be
> greater than or equal to 0.0 angle base units."
> > Entered as
> >
> > [3] Mantis issue 1308: creaseAngle support by Triangle nodes
> > https://www.web3d.org/member-only/mantis/view.php?id=1308
> >
> > Thanks for the excellent feedback Thomas. If accepted following group
> review, these fields go directly into X3DUOM and then subsequent x3d.py
> build.
> >
> >
> > On 6/12/2020 3:24 AM, Thomas Paviot wrote:
> > > 2. I noticed the IndexedTriangleSet does not have any creaseAngle
> field, whereas x3dom supports it.
> > >
> > > >>> x3d.IndexedFaceSet(creaseAngle=0.2)
> > > <x3d.IndexedFaceSet object at 0x000001EA5ED7A7B8>
> > > >>> x3d.IndexedTriangleSet(creaseAngle=0.2)
> > > Traceback (most recent call last):
> > > ? File "<stdin>", line 1, in <module>
> > > TypeError: __init__() got an unexpected keyword argument 'creaseAngle'
> > >
> > > It actually follows the standard specification (
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#IndexedTriangleSet),
> my question is then related to the standard itself: why do the
> IndexedTriangleSet (and some other geometries) does not define the
> creaseAngle field ?
> > >
> > > Best Regards,
> > >
> > > Thomas Paviot
> >
> > 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
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Mon, 15 Jun 2020 00:03:14 -0500
> > From: John Carlson <yottzumm at gmail.com>
> > To: X3D Graphics public mailing list <x3d-public at web3d.org>, Don
> > Brutzman <brutzman at nps.edu>
> > Subject: [x3d-public] Rereporting X3dToNodeJS.xslt possible divergent
> > error
> > Message-ID:
> > <CAGC3UEm7cjB=
> XVLdp3t7iTMnbxDW_-+gp5q4x_D+jJqNhq0wRQ at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Tis a puzzle. Perhaps missing material?
> >
> > $ node examples/HelloWorldProgramOutput.Node.js
> > C:\x3d-code\www.web3d.org
> > \x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:399
> > .addShaders((new autoclass.ProtoInstance("TestShader3",
> > "ShaderProto")).
> > setDEF("TestShader3").setName("ShaderProto"))
> > ^
> >
> > TypeError: Cannot read property 'addShaders' of null
> > at HelloWorldProgramOutput_Node.initialize (C:\x3d-code\
> www.web3d.org
> >
> \x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:399:9)
> > at new HelloWorldProgramOutput_Node (C:\x3d-code\www.web3d.org
> >
> \x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:123:10)
> > at Object.<anonymous> (C:\x3d-code\www.web3d.org
> > \x3d\stylesheets\java\node\e
> > xamples\HelloWorldProgramOutput.Node.js:470:1)
> > ?[90m at Module._compile (internal/modules/cjs/loader.js:1176:30)?[39m
> > ?[90m at Object.Module._extensions..js
> > (internal/modules/cjs/loader.js:1196:1
> > 0)?[39m
> > ?[90m at Module.load (internal/modules/cjs/loader.js:1040:32)?[39m
> > ?[90m at Function.Module._load
> > (internal/modules/cjs/loader.js:929:14)?[39m
> > ?[90m at Function.executeUserEntryPoint [as runMain]
> > (internal/modules/run_ma
> > in.js:71:12)?[39m
> > ?[90m at internal/main/run_main_module.js:17:47?[39m
> >
> > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> > www.web3d.org/x3d/stylesheets/java/node
> > $ node.exe !$
> > node.exe examples/HelloWorldProgramOutput.Node.js
> > WARNING_MESSAGE: ProtoInstance name='ShaderProto' DEF='TestShader3'
> USE=''
> > is missing containerField relationship to parent node, assuming
> > containerField='shaders' from initial node in corresponding ProtoDeclare.
> > Need to fix ProtoInstance definition in model source.
> > HelloWorldProgramOutput_Node execution self-validation test results:
> > WARNING_MESSAGE: ProtoInstance name='ShaderProto' DEF='TestShader3'
> USE=''
> > is missing containerField relationship to parent node, assuming
> > containerField='shaders' from initial node in corresponding ProtoDeclare.
> > Need to fix ProtoInstance definition in model source.
> >
> >
> > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> > www.web3d.org/x3d/stylesheets/java/node
> > $ node --version
> > v14.2.0
> >
> > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> > www.web3d.org/x3d/stylesheets/java/node
> > $ node.exe --version
> > v14.2.0
> >
> > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> > www.web3d.org/x3d/stylesheets/java/node
> > $ type node.exe
> > node.exe is hashed (/c/Program Files/nodejs/node.exe)
> >
> > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> > www.web3d.org/x3d/stylesheets/java/node
> > $ type node
> > node is aliased to `winpty node.exe'
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200615/21b4f943/attachment-0001.html
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Sun, 14 Jun 2020 23:07:11 -0700
> > From: Don Brutzman <brutzman at nps.edu>
> > To: John Carlson <yottzumm at gmail.com>
> > Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> > Subject: Re: [x3d-public] Rereporting X3dToNodeJS.xslt possible
> > divergent error
> > Message-ID: <30dbd515-971a-25f4-df83-93e1ed055831 at nps.edu>
> > Content-Type: text/plain; charset="utf-8"; format=flowed
> >
> > John, I haven't announced a new release after the major refactoring.
> Did a number of improvements today to X3dForWebAuthors archive, not
> possible to overload X3D node names with an X3D file name.
> >
> > Not sure what the parent of 'addShaders' might be because you have
> cropped it here.
> >
> > had trouble telling what your intent was when inspecting my local code.
> should be workable since it came from the master smoke-test program.
> >
> > probably want to compare to the corresponding java code.
> >
> > can you run in debug mode?
> >
> > can we look at it together Monday? good luck!
> >
> > On 6/14/2020 10:03 PM, John Carlson wrote:
> > > Tis a puzzle.? Perhaps missing?material?
> > >
> > > $ node examples/HelloWorldProgramOutput.Node.js
> > > C:\x3d-code\www.web3d.org <http://www.web3d.org
> >\x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:399
> > > ? ? ? ? .addShaders((new autoclass.ProtoInstance("TestShader3",
> "ShaderProto")).
> > > setDEF("TestShader3").setName("ShaderProto"))
> > > ? ? ? ? ^
> > >
> > > TypeError: Cannot read property 'addShaders' of null
> > > ? ? at HelloWorldProgramOutput_Node.initialize (C:\x3d-code\
> www.web3d.org <http://www.web3d.org
> >\x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:399:9)
> > > ? ? at new HelloWorldProgramOutput_Node (C:\x3d-code\www.web3d.org <
> http://www.web3d.org
> >\x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:123:10)
> > > ? ? at Object.<anonymous> (C:\x3d-code\www.web3d.org <
> http://www.web3d.org>\x3d\stylesheets\java\node\e
> > > xamples\HelloWorldProgramOutput.Node.js:470:1)
> > > ?[90m ? ?at Module._compile
> (internal/modules/cjs/loader.js:1176:30)?[39m
> > > ?[90m ? ?at Object.Module._extensions..js
> (internal/modules/cjs/loader.js:1196:1
> > > 0)?[39m
> > > ?[90m ? ?at Module.load (internal/modules/cjs/loader.js:1040:32)?[39m
> > > ?[90m ? ?at Function.Module._load
> (internal/modules/cjs/loader.js:929:14)?[39m
> > > ?[90m ? ?at Function.executeUserEntryPoint [as runMain]
> (internal/modules/run_ma
> > > in.js:71:12)?[39m
> > > ?[90m ? ?at internal/main/run_main_module.js:17:47?[39m
> > >
> > > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> www.web3d.org/x3d/stylesheets/java/node <
> http://www.web3d.org/x3d/stylesheets/java/node>
> > > $ node.exe !$
> > > node.exe examples/HelloWorldProgramOutput.Node.js
> > > WARNING_MESSAGE: ProtoInstance name='ShaderProto' DEF='TestShader3'
> USE='' is missing containerField relationship to parent node, assuming
> containerField='shaders' from initial node in corresponding ProtoDeclare.
> Need to fix ProtoInstance definition in model source.
> > > HelloWorldProgramOutput_Node execution self-validation test results:
> > > WARNING_MESSAGE: ProtoInstance name='ShaderProto' DEF='TestShader3'
> USE='' is missing containerField relationship to parent node, assuming
> containerField='shaders' from initial node in corresponding ProtoDeclare.
> Need to fix ProtoInstance definition in model source.
> > >
> > >
> > > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> www.web3d.org/x3d/stylesheets/java/node <
> http://www.web3d.org/x3d/stylesheets/java/node>
> > > $ node --version
> > > v14.2.0
> > >
> > > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> www.web3d.org/x3d/stylesheets/java/node <
> http://www.web3d.org/x3d/stylesheets/java/node>
> > > $ node.exe --version
> > > v14.2.0
> > >
> > > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> www.web3d.org/x3d/stylesheets/java/node <
> http://www.web3d.org/x3d/stylesheets/java/node>
> > > $ type node.exe
> > > node.exe is hashed (/c/Program Files/nodejs/node.exe)
> > >
> > > coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/
> www.web3d.org/x3d/stylesheets/java/node <
> http://www.web3d.org/x3d/stylesheets/java/node>
> > > $ type node
> > > node is aliased to `winpty node.exe'
> > >
> >
> > 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
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> >
> > ------------------------------
> >
> > End of x3d-public Digest, Vol 135, Issue 87
> > *******************************************
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> 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/20200617/f2cf49fc/attachment-0001.html>
More information about the x3d-public
mailing list