[x3d-public] remove SF/MFInt32 ?

[Michalis Kamburelis]

 2018-04-06 19:41 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
>> This is a limitation of JavaScript (there are no separate "integer" or
>> "float" types, just "number"), but all other programming languages
>> have separate integer / float types. So I would a bit reluctant to do
>> this...
>>
>> Equating "SFFloat == SFInt32" would mean we have less strict typing
>> when it comes to checking ROUTE connections. All SFFloat fields/events
>> could be then connected with SFInt32. E.g. in my opinion it is good
>> that right now you are forced to animate "Switch.whichChoice" with
>> "IntegerSequencer", and you cannot do it with "ScalarInterpolator".
>> And it allows X3D specification to avoid making some general rules
>> whether we round (with round(0.75)=1.0), or truncate (ceil).
>
>
> I am not sure if X3D should be considered a programming language although it
> is probably Turing complete. Its declarative nature and its abstracted
> foundation serve to strike a balance between ease of use and full
> programmability. So I think there may be room for simplification.
>
> You are right that the loss of some strictness in type checking would be
> probably the main drawback/impact.
>
> The rule on how to convert to an index would be just a decision.
> Alternatively, indices could still be required to be round numbers.
> Otherwise, the value would be undefined. The strict type checking is a
> doubly edged sword. It encourages more precision on the input and therefore
> presumably more correctness but then requires more nodes and fields to
> enable that precision. For example, I would like to route a level_changed
> SFInt32 value to a SFFloat key field of a BooleanSequencer. Now I need a
> type converter and since there is not one, I have to have a type converter
> script just to satisfy type correctness.

Hm, I do agree that "type strictness" of X3D is not the main argument
here. You are right, I can see that sometimes you could even benefit
from easily passing float to/from int, while now you need to put nodes
in-between.

Note that InstantReality has an extension
http://doc.instantreality.org/documentation/nodetype/Converter/ .

>
>>
>> More importantly, what happens with MFInt32? If it's now MFFloat, then
>> we get a performance hit when reading a long list of coordinates (like
>> IndexedFaceSet.coordIndex), because now we have to call round() on
>> every list item.
>
>
> I believe this would be a one time operation during loading which would be
> barely noticeable on a modern system, even for large IFSs. The parsing of
> the string to a number in the first place likely takes much longer.
>

1. The parsing is indeed a problem for performance, and it probably
costs more than "rounding a float". But to make this rounding happen
early (at parsing or at glTF->X3D conversion) you need a way to mark
the field "this is MFInt32". Otherwise, you will need to introduce a
new field marked "this is MFFloat, but round it to integers at
loading". Or make "IndexedFaceSet.coordIndex" a special case.

<sidenote>
We want to eliminate this parsing by using binary mesh formats. Like
glTF and ExternalGeometry/Shape. Or (older but already standardized)
X3D binary encoding format. But I realize that, for now, most X3D
content is parsed from text files (X3D in XML or classic encoding).
</sidenote>

2. You can "embed" an X3D renderer, like Castle Game Engine or
probably any other X3D renderer, to build or animate X3D graph by code
in your own applications. In which case (right now) you can just use
integers, from start to finish. If coordIndex would be defined as
simple MFFloat, then you would need to provide floats.

  This is an untypical but important use-case for me. People are
building procedurally-generated worlds or games, or machines, using
Castle Game Engine. So our API wants to allow defining
"IndexedFaceSet.coordIndex" efficiently.

  This use-case is also relevant to X3D used directly: a Script that
can send MFFloat value to "IndexedFaceSet.set_coordIndex".

  Note that this point is relevant even for JavaScript (when used as a
scripting or renderer language). JavaScript doesn't have a "real
integer" type for scalars, but it has a "real integer" type for lists
(Int16Array, Int32Array etc.). There lists are actually stored as
native integers, as far as I know.

Regards,
Michalis