[x3d-public] [x3dom-users] Ran across an interesting example.
Don Brutzman
brutzman at nps.edu
Fri May 19 10:22:10 PDT 2017
The use of -1 sentinel values occurs in a number of places throughout the VRML and X3D abstract specifications. So it is certainly not a new practice, and it is tricky to get the specification prose + node signatures + validators all 100% correct.
Wondering if there is an alternative approach to consider for this particular data representation?
There are some variations that avoid -1 sentinel values in X3D, either by using 3-tuples/4-tuples or specifying tuple sizes - for example LineSet vertexCount.
http://www.web3d.org/x3d/content/X3dTooltips.html#LineSet
Also wondering if -1 sentinel values are ever used in OpenGL or DirectX or other mesh-oriented renderers. If not, how do they disambiguate n-sided polygons within linear arrays of mesh indices?
It is always good to consider possible alternatives. Nevertheless this particular type of data structure would seem to be hard-wired into the scene graph design.
On 5/19/2017 7:30 AM, Leonard Daly wrote:
> It is bad software practice to use flags in data streams. This was standard practice decades ago because of the need to save memory. Now more memory-used solutions are used to prevent the problem of determining whether a value is a flag or real data. Of course, once the data has been verified and loaded into memory, internal structures would eliminate the need for flagging.
>
> Leonard Daly
>
>
>
>
>> Andreas,
>>
>> Thanks for your comments. Looking back at the standard again, that is ISO/IEC 19775-1 clause 13.3.6 IndexedFaceSet, notice what it says under list item e.1.:
>>
>> “If the /colorIndex/ field is not empty, colours are applied to each vertex of the IndexedFaceSet in exactly the same manner that the /coordIndex/ field is used to choose coordinates for each vertex from the Coordinate node. The /colorIndex/ field shall contain at least as many indices as the /coordIndex/ field, and shall contain end-of-face markers (−1) in exactly the same places as the /coordIndex/ field. If the greatest index in the /colorIndex/ field is N, then there shall be N+1 colours in the /X3DColorNode/ node.”
>>
>> In this case the end-of-face markers in /colorIndex/ are required to match the end-of-face markers in /coordIndex/. As we have already noted the /colorIndex/ rules also apply to /normalIndex/. Therefore, all three can have, in the right circumstances, -1 values. This is reflected in the node signature for each of these three fields.
>>
>> All the best,
>>
>> Roy
>>
>> *From:*Andreas Plesch [mailto:andreasplesch at gmail.com]
>> *Sent:* 19 May 2017 14:35
>> *To:* Roy Walmsley <roy.walmsley at ntlworld.com>
>> *Cc:* John Carlson <yottzumm at gmail.com>; X3D Graphics public mailing list <x3d-public at web3d.org>; x3dom mlist <x3dom-users at lists.sourceforge.net>
>> *Subject:* Re: [x3dom-users] [x3d-public] Ran across an interesting example.
>>
>> Hi Roy,
>>
>> sorry, I did not see your response in time.
>>
>> I do think the signatures for colorIndex and normalIndex should be corrected to not include "or -1". Currently, they state:
>>
>> MFInt32 [] colorIndex [] [0,∞) or -1
>>
>> MFInt32 [] normalIndex [] [0,∞) or -1
>>
>> Perhaps these were just copied from coordIndex ? Or did VRML allow the -1 ?
>>
>> On the other hand the signature for texCoordIndex is correct:
>>
>> MFInt32 [] texCoordIndex [] [-1,∞)
>>
>> -Andreas
>>
>> On Fri, May 19, 2017 at 6:24 AM, Roy Walmsley <roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com>> wrote:
>>
>> John,
>>
>> This is an interesting example, because technically it is not legal X3D !!
>>
>> That said, having saved it as a file, and tried it on the X3D Validator, it passed validation !!
>>
>> Your analysis is correct. Reviewing the standard explains why. Look at ISO/IEC 19775-1 clause 13.3.6 IndexedFaceSet (http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#IndexedFaceSet).
>>
>> We’ll start with the eighth paragraph, which includes the words:
>>
>> “If the /normal/ field is not |NULL|, it shall contain a node derived from /X3DNormalNode/ whose normals are applied to the vertices or faces of the IndexedFaceSet in a manner exactly equivalent to that described above for applying colours to vertices/faces (where /normalPerVertex/ corresponds to /colorPerVertex/ and /normalIndex/ corresponds to /colorIndex/).”
>>
>> Now let’s look at what should happen for colorIndex when colorPerVertex is false. This is specified at list item d.1. two paragraphs earlier. It reads:
>>
>> “If the /colorIndex/ field is not empty, one colour is used for each face of the IndexedFaceSet. There shall be at least as many indices in the /colorIndex/ field as there are faces in the IndexedFaceSet. If the greatest index in the /colorIndex/ field is N, there shall be N+1 colours in the /X3DColorNode/. The /colorIndex/ field shall not contain any negative entries.”
>>
>> Notice the last sentence, where it say there shall not be any negative values.
>>
>> So, applying these principles to the normals, we can see that there should be no negative values.
>>
>> Perhaps the Schematron could be improved by adding a rule to check for this scenario. And thinking about it, it would probably be possible to do it in JSON, although it would be complicated.
>>
>> All the best,
>>
>> Roy
>>
>> *From:*x3d-public [mailto:x3d-public-bounces at web3d.org <mailto:x3d-public-bounces at web3d.org>] *On Behalf Of *John Carlson
>> *Sent:* 19 May 2017 10:57
>> *To:* X3D Graphics public mailing list <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>; x3dom-users at lists.sourceforge.net <mailto:x3dom-users at lists.sourceforge.net>
>> *Subject:* [x3d-public] Ran across an interesting example.
>>
>> Below X3D XML NOT viewable in X3DOM, (Octaga??), Instant Player (console goes into infinite loop), H3D complains about: (Unnamed Normal.vector. Field has size 6). I think it may be because normalIndex has -1’s when normalPerVertex=false??? If I take out the -1’s, it’s viewable in X3DOM, Octaga, InstantPlayer, and H3D. The content still needs work, of course (It’s supposed to be a cube!).
>>
>> X3DOM’s console looks like:
>>
>> x3dom-full.js:4743 Uncaught TypeError: Cannot read property 'x' of undefined
>>
>> at x3dom.registerNodeType.defineClass.nodeChanged.nodeChanged (x3dom-full.js:4743)
>>
>> at x3dom.NodeNameSpace.setupTree (x3dom-full.js:2869)
>>
>> at x3dom-full.js:2869
>>
>> at Function.Array.forEach (x3dom-full.js:2)
>>
>> at x3dom.NodeNameSpace.setupTree (x3dom-full.js:2869)
>>
>> at x3dom-full.js:2869
>>
>> at Function.Array.forEach (x3dom-full.js:2)
>>
>> at x3dom.NodeNameSpace.setupTree (x3dom-full.js:2869)
>>
>> at x3dom-full.js:2869
>>
>> at Function.Array.forEach (x3dom-full.js:2)
>>
>> What does quality assurance report? I don’t get any significant warnings from X3D-Edit or X3DJSAIL, that I can tell!
>>
>> Not sure about the standard, but leaving out the -1’s makes sense if normalPerVertex = false, I think. I’ll let others weigh in about the standard.
>>
>> Thanks,
>>
>> John
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> <!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.3//EN" "http://www.web3d.org/specifications/x3d-3.3.dtd">
>>
>> <X3D profile='Interchange' version='3.3' xmlns:xsd='http://www.w3.org/2001/XMLSchema-instance' xsd:noNamespaceSchemaLocation='http://www.web3d.org/specifications/x3d-3.3.xsd'>
>>
>> <head>
>>
>> <meta name='title' content='template.json'/>
>>
>> <meta name='identifier' content='http://coderextreme.net/X3DJSONLD/template.json'/ <http://coderextreme.net/X3DJSONLD/template.json%27/>>
>>
>> <meta name='description' content='Template for an Indexed Face Set'/>
>>
>> <meta name='creator' content='John Carlson'/>
>>
>> <meta name='created' content='4 April 2017'/>
>>
>> </head>
>>
>> <Scene>
>>
>> <Group>
>>
>> <Shape>
>>
>> <IndexedFaceSet DEF='IndexedFaceSet' colorIndex='0 0 0 -1 0 0 0 -1 0 0 0 0 -1 0 0 0 0 -1 0 0 0 0 -1 0 0 0 0 -1 0 0 0 0 -1' coordIndex='0 0 1 -1 0 1 1 -1 2 2 3 3 -1 0 3 3 0 -1 0 3 2 1 -1 1 2 2 1 -1 1 2 3 0 -1' creaseAngle='1.57' normalIndex='0 -1 0 -1 1 -1 2 -1 3 -1 4 -1 5 -1' normalPerVertex='false'>
>>
>> <Color color='0 1 0'/>
>>
>> <Coordinate point='0 0 1 0 1 1 1 1 1 1 0 1'/>
>>
>> <Normal vector='1 0 0 -1 0 0 0 1 0 0 0 -1 0 -1 0 0 0 1'/>
>>
>> </IndexedFaceSet>
>>
>> </Shape>
>>
>> </Group>
>>
>> </Scene>
>>
>> </X3D>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> X3dom-users mailing list
>> X3dom-users at lists.sourceforge.net <mailto:X3dom-users at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>>
>>
>>
>> --
>>
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
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
More information about the x3d-public
mailing list