<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>I think x3dom wants to support getAttribute/setAttribute for MF fields in general, but I’m not sure we want that for X3D JSON, hence I use getFieldValue/setFieldValue unless they don’t exist on an element, then I fallback to the attribute methods in X3DJSONLD.</p><p class=MsoNormal><br>John</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:andreasplesch@gmail.com">Andreas Plesch</a><br><b>Sent: </b>Friday, April 6, 2018 4:01 PM<br><b>To: </b><a href="mailto:michalis.kambi@gmail.com">Michalis Kamburelis</a><br><b>Cc: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] remove SF/MFInt32 ?</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks for thinking this through more thoroughly, starting from a</p><p class=MsoNormal>rather vague idea.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On Fri, Apr 6, 2018 at 2:28 PM, Michalis Kamburelis</p><p class=MsoNormal><michalis.kambi@gmail.com> wrote:</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> 2018-04-06 19:41 GMT+02:00 Andreas Plesch <andreasplesch@gmail.com>:</p><p class=MsoNormal>> ...</p><p class=MsoNormal>> Hm, I do agree that "type strictness" of X3D is not the main argument</p><p class=MsoNormal>> here. You are right, I can see that sometimes you could even benefit</p><p class=MsoNormal>> from easily passing float to/from int, while now you need to put nodes</p><p class=MsoNormal>> in-between.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> Note that InstantReality has an extension</p><p class=MsoNormal>> http://doc.instantreality.org/documentation/nodetype/Converter/ .</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> ></p><p class=MsoNormal>> >></p><p class=MsoNormal>> >> More importantly, what happens with MFInt32? If it's now MFFloat, then</p><p class=MsoNormal>> >> we get a performance hit when reading a long list of coordinates (like</p><p class=MsoNormal>> >> IndexedFaceSet.coordIndex), because now we have to call round() on</p><p class=MsoNormal>> >> every list item.</p><p class=MsoNormal>> ></p><p class=MsoNormal>> ></p><p class=MsoNormal>> > I believe this would be a one time operation during loading which would be</p><p class=MsoNormal>> > barely noticeable on a modern system, even for large IFSs. The parsing of</p><p class=MsoNormal>> > the string to a number in the first place likely takes much longer.</p><p class=MsoNormal>> ></p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> 1. The parsing is indeed a problem for performance, and it probably</p><p class=MsoNormal>> costs more than "rounding a float". But to make this rounding happen</p><p class=MsoNormal>> early (at parsing or at glTF->X3D conversion) you need a way to mark</p><p class=MsoNormal>> the field "this is MFInt32". Otherwise, you will need to introduce a</p><p class=MsoNormal>> new field marked "this is MFFloat, but round it to integers at</p><p class=MsoNormal>> loading". Or make "IndexedFaceSet.coordIndex" a special case.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Yes, it would be in effect a special or marked case, eg. the type</p><p class=MsoNormal>conversion happens implicitly.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For x3dom, actually no change would be necessary as long as the</p><p class=MsoNormal>provided floats are round numbers.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> <sidenote></p><p class=MsoNormal>> We want to eliminate this parsing by using binary mesh formats. Like</p><p class=MsoNormal>> glTF and ExternalGeometry/Shape. Or (older but already standardized)</p><p class=MsoNormal>> X3D binary encoding format. But I realize that, for now, most X3D</p><p class=MsoNormal>> content is parsed from text files (X3D in XML or classic encoding).</p><p class=MsoNormal>> </sidenote></p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> 2. You can "embed" an X3D renderer, like Castle Game Engine or</p><p class=MsoNormal>> probably any other X3D renderer, to build or animate X3D graph by code</p><p class=MsoNormal>> in your own applications. In which case (right now) you can just use</p><p class=MsoNormal>> integers, from start to finish. If coordIndex would be defined as</p><p class=MsoNormal>> simple MFFloat, then you would need to provide floats.</p><p class=MsoNormal>><o:p> </o:p></p><p class=MsoNormal>> This is an untypical but important use-case for me. People are</p><p class=MsoNormal>> building procedurally-generated worlds or games, or machines, using</p><p class=MsoNormal>> Castle Game Engine. So our API wants to allow defining</p><p class=MsoNormal>> "IndexedFaceSet.coordIndex" efficiently.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ok, this is a good point. On the other hand an X3D engine still could</p><p class=MsoNormal>accept integer type numbers and internally treat them as integers from</p><p class=MsoNormal>start to finish for these float fields. Think a generic SFNumber</p><p class=MsoNormal>field.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> This use-case is also relevant to X3D used directly: a Script that</p><p class=MsoNormal>> can send MFFloat value to "IndexedFaceSet.set_coordIndex".</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This is actually what effectively needs to happen now in X3D scripts</p><p class=MsoNormal>which are written in js.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Note that this point is relevant even for JavaScript (when used as a</p><p class=MsoNormal>> scripting or renderer language). JavaScript doesn't have a "real</p><p class=MsoNormal>> integer" type for scalars, but it has a "real integer" type for lists</p><p class=MsoNormal>> (Int16Array, Int32Array etc.). There lists are actually stored as</p><p class=MsoNormal>> native integers, as far as I know.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Yes, the TypedArrays are for efficient use of native types. x3dom does</p><p class=MsoNormal>not actually use the TypedArrays for MF fields, I believe, until they</p><p class=MsoNormal>are submitted to webgl. Not really sure why not since mostly you can</p><p class=MsoNormal>treat TypedArrays as regular arrays in js. Perhaps TypedArrays were</p><p class=MsoNormal>experimental when x3dom got started.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Andreas</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-- </p><p class=MsoNormal>Andreas Plesch</p><p class=MsoNormal>Waltham, MA 02453</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>_______________________________________________</p><p class=MsoNormal>x3d-public mailing list</p><p class=MsoNormal>x3d-public@web3d.org</p><p class=MsoNormal>http://web3d.org/mailman/listinfo/x3d-public_web3d.org</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>