[x3d-public] vrml to x3d field name changes

Andreas Plesch andreasplesch at gmail.com
Thu Apr 26 10:48:05 PDT 2018


Hi Doug,

that could work but without further changes I think may just reverse
the problem due to the way x_ite currently works. In a vrml scene
'level_changed' would then become a recognized output SFInt field
although it should be treated as the equivalent of the x3d
'children_changed' field synonym.

It seems it is just a question at which level these differences
between vrml and x3d are addressed best,

-Andreas

> Date: Thu, 26 Apr 2018 10:01:17 -0600
> From: GPU Group <gpugroup at gmail.com>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] vrml to x3d field name changes
> Message-ID:
>         <CAM2ogRfR4Esq+WQsOGrvXcqc27JtsSTsXnud0f=NaKa2=FUrRA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> When hooking up routes, use a 2-pass search:
> 1. exact match
> if didn't find then
> 2. synonym match ie set_, _changed
> -Doug
>
> On Thu, Apr 26, 2018 at 8:48 AM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> The 'level_changed' field of the LOD node
>> (http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/
>> components/navigation.html#LOD)
>> currently does not work in the x_ite browser although it is correctly
>> implemented. The problem is that x_ite also understands vrml97 and
>> aliases vrml field names to equivalent x3d field names in a
>> straightforward manner
>> (https://github.com/create3000/x_ite/issues/11). This is fine in most
>> cases but for the LOD node it leads to a conflict. Vrml has a 'level'
>> field (http://www.web3d.org/documents/specifications/
>> 14772/V2.0/part1/nodesRef.html#LOD)
>> which is aliased to the corresponding 'children' x3d field. A
>> 'level_changed' event therefore is then treated as output from the
>> MFNode 'children' field, and not as output from the SFInt
>> 'level_changed' field.
>>
>> A possible fix is to only do the aliasing if we know the original
>> encoding of the LOD node was vrml. This fix may be ok if the LOD node
>> is the only node which could have this conflict stemming from renaming
>> a vrml field ('level' to 'children') and at the same time introducing
>> a new x3d field ('level_changed') with the old vrml name of the
>> renamed field.
>>
>> So my question is if there may be other nodes with fields which were
>> affected by renaming from vrml to x3d in such a way ?
>>
>> If there are a few others it may be worth looking for a solution which
>> does not need special treatment of certain nodes.
>>
>> -Andreas
>>
>>
>> --
>> 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/20180426/58d401b8/attachment.html>
>
> ------------------------------
>
> 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 109, Issue 83
> *******************************************



-- 
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list