<div dir="ltr"><div>This all makes sense to me. Some comments below.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 5:23 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>Ah, yes, I agree. One cannot decide if two vertices with the same location are meant to be connected or separated.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>2. I would not deprecate TriangleFanSet or TriangleStripSet. They are possible in glTF, and my importer glTF -> X3D nodes utilizes them, see <a href="https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dloadinternalgltf.pas#L1404" target="_blank">https://github.com/castle-engine/castle-engine/blob/master/src/x3d/x3dloadinternalgltf.pas#L1404</a> . <br></div><div><br></div><div>    Essentially, any geometry primitive possible in normal graphic APIs (like OpenGL[ES]) can be expressed in glTF, and can be indexed or not indexed.<br></div></div></blockquote><div><br></div><div>Ok. I guess OpenGL still has these primitives. But it is not clear if they internally provide any performance benefit for rendering although they might. x3dom does not translate the gltf geometries but introduces a new BufferGeometry x3d node which takes the gltf data (from accessors) more or less directly. Also I am not sure if these primitives are used much at all. Do castle engine games use these primitives ?</div><div><br></div><div>Does the blender exporter generate fan sets or strip sets ?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>Agreed. This is also why x3dom does not fully implement creaseAngle. If you want detailed control just provide the normals.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>4. I'm not sure do we need to introduce "creaseAngle" even on the indexed nodes (IndexedTriangleSet, IndexedTriangleFanSet, IndexedTriangleStripSet). <br></div><div><br></div><div>    - On IndexedTriangleFanSet, IndexedTriangleStripSet the creaseAngle doesn't seem very useful (if you only follow indexes, then you don't have too many neighbors). <br></div><div><br></div><div>     - 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.</div></div></blockquote><div><br></div><div>Most IndexedFaceSets may be actually IndexedTriangleSet. I think it would be nice to use IndexedTriangleSet for easy, smoothed rendering, with the main benefit of not having to add the "-1" marker of the triangle indices. You could consider limited, x3dom like, all or nothing support which makes the implementation a bit less complicated and faster.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>    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. </div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>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 :) </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>The one place where I would say "change is sensible" (although not required) is that indeed introducing "IndexedTriangleSet.creaseAnglee" makes sense.</div><div><br></div><div>Regards,</div><div>Michalis<br></div><br><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">śr., 17 cze 2020 o 21:54 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I noticed that there was not a lot of (any?) feedback.<br>
<br>
We came across the lack of a creaseAngle field for TriangleSet because<br>
this node was conceptually straightforward to use for occ x3dom export<br>
but switched now to indexed nodes.<br>
<br>
I do not know the VRML background but suspect that the fanset and<br>
stripset nodes were possibly introduced because they offered hardware<br>
based performance gains. In order to preserve these gains, perhaps the<br>
more expensive creaseAngle field was reserved for nodes which were not<br>
directly hardware accelerated. I would be surprised if this<br>
performance aspect still applies to modern GPUs.<br>
<br>
Another, related reason for the lack of creaseAngle may be the fact<br>
that the field requires finding neighbouring triangles. This is<br>
expensive, especially for the non-indexed geometries which would<br>
essentially need internal indexing of vertices with duplication<br>
checks. The typical use case for TriangleSet, on the other hand, is an<br>
unconnected triangle soup where creaseAngle is not useful. This reason<br>
would not apply to indexed geometries such as IndexedTriangleSet.<br>
<br>
As as result, I think it is worth considering to start to deprecate<br>
all FanSet and StripSet geometry nodes, and to add a creaseAngle field<br>
to IndexedTriangleSet. Too radical ?<br>
<br>
My two cents, -Andreas<br>
<br>
> Date: Sun, 14 Jun 2020 21:09:19 -0700<br>
> From: Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
> To: Thomas Paviot <<a href="mailto:tpaviot@gmail.com" target="_blank">tpaviot@gmail.com</a>>, X3D Graphics public mailing<br>
>         list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> Subject: Re: [x3d-public] Feedbacks related to x3d.py: creaseAngle<br>
>         support by Triangle nodes<br>
><br>
> 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.<br>
><br>
> [1] X3D Architecture, Rendering component<br>
>      <a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#IndexedTriangleSet" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#IndexedTriangleSet</a><br>
><br>
> IndexedTriangleFanSet,<br>
> IndexedTriangleSet,<br>
> IndexedTriangleStripSet,<br>
> TriangleFanSet,<br>
> TriangleSet, and<br>
> TriangleStripSet.<br>
><br>
> [2] X3D Architecture, Rendering component, 11.2.3 Common geometry fields<br>
>      <a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#CommonGeometryFields" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#CommonGeometryFields</a><br>
><br>
> "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."<br>
> [...]<br>
> "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."<br>
> Entered as<br>
><br>
> [3] Mantis issue 1308: creaseAngle support by Triangle nodes<br>
>      <a href="https://www.web3d.org/member-only/mantis/view.php?id=1308" rel="noreferrer" target="_blank">https://www.web3d.org/member-only/mantis/view.php?id=1308</a><br>
><br>
> Thanks for the excellent feedback Thomas.  If accepted following group review, these fields go directly into X3DUOM and then subsequent x3d.py build.<br>
><br>
><br>
> On 6/12/2020 3:24 AM, Thomas Paviot wrote:<br>
> > 2. I noticed the IndexedTriangleSet does not have any creaseAngle field, whereas x3dom supports it.<br>
> ><br>
> >  >>> x3d.IndexedFaceSet(creaseAngle=0.2)<br>
> > <x3d.IndexedFaceSet object at 0x000001EA5ED7A7B8><br>
> >  >>> x3d.IndexedTriangleSet(creaseAngle=0.2)<br>
> > Traceback (most recent call last):<br>
> >  ? File "<stdin>", line 1, in <module><br>
> > TypeError: __init__() got an unexpected keyword argument 'creaseAngle'<br>
> ><br>
> > It actually follows the standard specification (<a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#IndexedTriangleSet" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#IndexedTriangleSet</a>), my question is then related to the standard itself: why do the IndexedTriangleSet (and some other geometries) does not define the creaseAngle field ?<br>
> ><br>
> > Best Regards,<br>
> ><br>
> > Thomas Paviot<br>
><br>
> all the best, Don<br>
> --<br>
> Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br>
> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Message: 3<br>
> Date: Mon, 15 Jun 2020 00:03:14 -0500<br>
> From: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>
> To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>, Don<br>
>         Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
> Subject: [x3d-public] Rereporting X3dToNodeJS.xslt possible divergent<br>
>         error<br>
> Message-ID:<br>
>         <CAGC3UEm7cjB=<a href="mailto:XVLdp3t7iTMnbxDW_-%2Bgp5q4x_D%2BjJqNhq0wRQ@mail.gmail.com" target="_blank">XVLdp3t7iTMnbxDW_-+gp5q4x_D+jJqNhq0wRQ@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Tis a puzzle.  Perhaps missing material?<br>
><br>
> $ node examples/HelloWorldProgramOutput.Node.js<br>
> C:\x3d-code\<a href="http://www.web3d.org" rel="noreferrer" target="_blank">www.web3d.org</a><br>
> \x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:399<br>
>         .addShaders((new autoclass.ProtoInstance("TestShader3",<br>
> "ShaderProto")).<br>
> setDEF("TestShader3").setName("ShaderProto"))<br>
>         ^<br>
><br>
> TypeError: Cannot read property 'addShaders' of null<br>
>     at HelloWorldProgramOutput_Node.initialize (C:\x3d-code\<a href="http://www.web3d.org" rel="noreferrer" target="_blank">www.web3d.org</a><br>
> \x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:399:9)<br>
>     at new HelloWorldProgramOutput_Node (C:\x3d-code\<a href="http://www.web3d.org" rel="noreferrer" target="_blank">www.web3d.org</a><br>
> \x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:123:10)<br>
>     at Object.<anonymous> (C:\x3d-code\<a href="http://www.web3d.org" rel="noreferrer" target="_blank">www.web3d.org</a><br>
> \x3d\stylesheets\java\node\e<br>
> xamples\HelloWorldProgramOutput.Node.js:470:1)<br>
> ?[90m    at Module._compile (internal/modules/cjs/loader.js:1176:30)?[39m<br>
> ?[90m    at Object.Module._extensions..js<br>
> (internal/modules/cjs/loader.js:1196:1<br>
> 0)?[39m<br>
> ?[90m    at Module.load (internal/modules/cjs/loader.js:1040:32)?[39m<br>
> ?[90m    at Function.Module._load<br>
> (internal/modules/cjs/loader.js:929:14)?[39m<br>
> ?[90m    at Function.executeUserEntryPoint [as runMain]<br>
> (internal/modules/run_ma<br>
> in.js:71:12)?[39m<br>
> ?[90m    at internal/main/run_main_module.js:17:47?[39m<br>
><br>
> coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<br>
> <a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a><br>
> $ node.exe !$<br>
> node.exe examples/HelloWorldProgramOutput.Node.js<br>
> WARNING_MESSAGE: ProtoInstance name='ShaderProto' DEF='TestShader3' USE=''<br>
> is missing containerField relationship to parent node, assuming<br>
> containerField='shaders' from initial node in corresponding ProtoDeclare.<br>
> Need to fix ProtoInstance definition in model source.<br>
> HelloWorldProgramOutput_Node execution self-validation test results:<br>
> WARNING_MESSAGE: ProtoInstance name='ShaderProto' DEF='TestShader3' USE=''<br>
> is missing containerField relationship to parent node, assuming<br>
> containerField='shaders' from initial node in corresponding ProtoDeclare.<br>
> Need to fix ProtoInstance definition in model source.<br>
><br>
><br>
> coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<br>
> <a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a><br>
> $ node --version<br>
> v14.2.0<br>
><br>
> coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<br>
> <a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a><br>
> $ node.exe --version<br>
> v14.2.0<br>
><br>
> coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<br>
> <a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a><br>
> $ type node.exe<br>
> node.exe is hashed (/c/Program Files/nodejs/node.exe)<br>
><br>
> coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<br>
> <a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a><br>
> $ type node<br>
> node is aliased to `winpty node.exe'<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200615/21b4f943/attachment-0001.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200615/21b4f943/attachment-0001.html</a>><br>
><br>
> ------------------------------<br>
><br>
> Message: 4<br>
> Date: Sun, 14 Jun 2020 23:07:11 -0700<br>
> From: Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
> To: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>
> Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> Subject: Re: [x3d-public] Rereporting X3dToNodeJS.xslt possible<br>
>         divergent error<br>
> Message-ID: <<a href="mailto:30dbd515-971a-25f4-df83-93e1ed055831@nps.edu" target="_blank">30dbd515-971a-25f4-df83-93e1ed055831@nps.edu</a>><br>
> Content-Type: text/plain; charset="utf-8"; format=flowed<br>
><br>
> 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.<br>
><br>
> Not sure what the parent of 'addShaders' might be because you have cropped it here.<br>
><br>
> had trouble telling what your intent was when inspecting my local code.  should be workable since it came from the master smoke-test program.<br>
><br>
> probably want to compare to the corresponding java code.<br>
><br>
> can you run in debug mode?<br>
><br>
> can we look at it together Monday?  good luck!<br>
><br>
> On 6/14/2020 10:03 PM, John Carlson wrote:<br>
> > Tis a puzzle.? Perhaps missing?material?<br>
> ><br>
> > $ node examples/HelloWorldProgramOutput.Node.js<br>
> > C:\x3d-code\<a href="http://www.web3d.org" rel="noreferrer" target="_blank">www.web3d.org</a> <<a href="http://www.web3d.org" rel="noreferrer" target="_blank">http://www.web3d.org</a>>\x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:399<br>
> >  ? ? ? ? .addShaders((new autoclass.ProtoInstance("TestShader3", "ShaderProto")).<br>
> > setDEF("TestShader3").setName("ShaderProto"))<br>
> >  ? ? ? ? ^<br>
> ><br>
> > TypeError: Cannot read property 'addShaders' of null<br>
> >  ? ? at HelloWorldProgramOutput_Node.initialize (C:\x3d-code\<a href="http://www.web3d.org" rel="noreferrer" target="_blank">www.web3d.org</a> <<a href="http://www.web3d.org" rel="noreferrer" target="_blank">http://www.web3d.org</a>>\x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:399:9)<br>
> >  ? ? at new HelloWorldProgramOutput_Node (C:\x3d-code\<a href="http://www.web3d.org" rel="noreferrer" target="_blank">www.web3d.org</a> <<a href="http://www.web3d.org" rel="noreferrer" target="_blank">http://www.web3d.org</a>>\x3d\stylesheets\java\node\examples\HelloWorldProgramOutput.Node.js:123:10)<br>
> >  ? ? at Object.<anonymous> (C:\x3d-code\<a href="http://www.web3d.org" rel="noreferrer" target="_blank">www.web3d.org</a> <<a href="http://www.web3d.org" rel="noreferrer" target="_blank">http://www.web3d.org</a>>\x3d\stylesheets\java\node\e<br>
> > xamples\HelloWorldProgramOutput.Node.js:470:1)<br>
> > ?[90m ? ?at Module._compile (internal/modules/cjs/loader.js:1176:30)?[39m<br>
> > ?[90m ? ?at Object.Module._extensions..js (internal/modules/cjs/loader.js:1196:1<br>
> > 0)?[39m<br>
> > ?[90m ? ?at Module.load (internal/modules/cjs/loader.js:1040:32)?[39m<br>
> > ?[90m ? ?at Function.Module._load (internal/modules/cjs/loader.js:929:14)?[39m<br>
> > ?[90m ? ?at Function.executeUserEntryPoint [as runMain] (internal/modules/run_ma<br>
> > in.js:71:12)?[39m<br>
> > ?[90m ? ?at internal/main/run_main_module.js:17:47?[39m<br>
> ><br>
> > coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a> <<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/stylesheets/java/node</a>><br>
> > $ node.exe !$<br>
> > node.exe examples/HelloWorldProgramOutput.Node.js<br>
> > 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.<br>
> > HelloWorldProgramOutput_Node execution self-validation test results:<br>
> > 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.<br>
> ><br>
> ><br>
> > coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a> <<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/stylesheets/java/node</a>><br>
> > $ node --version<br>
> > v14.2.0<br>
> ><br>
> > coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a> <<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/stylesheets/java/node</a>><br>
> > $ node.exe --version<br>
> > v14.2.0<br>
> ><br>
> > coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a> <<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/stylesheets/java/node</a>><br>
> > $ type node.exe<br>
> > node.exe is hashed (/c/Program Files/nodejs/node.exe)<br>
> ><br>
> > coderextreme@DESKTOP-DOPK2VD MINGW64 /c/x3d-code/<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">www.web3d.org/x3d/stylesheets/java/node</a> <<a href="http://www.web3d.org/x3d/stylesheets/java/node" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/stylesheets/java/node</a>><br>
> > $ type node<br>
> > node is aliased to `winpty node.exe'<br>
> ><br>
><br>
> all the best, Don<br>
> --<br>
> Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br>
> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
><br>
><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<br>
><br>
> _______________________________________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> End of x3d-public Digest, Vol 135, Issue 87<br>
> *******************************************<br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Andreas Plesch<br>Waltham, MA 02453</div></div></div></div>