[X3D-Ecosystem] containerField for HAnimSites and HAnimSegments in HAnimHumanoid required?

Fri Nov 8 12:18:46 PST 2024

Then should X3DJSAIL auto-populate the containerField when
HAnimHumanoid.addSkins() and HAnimHumanoid.addSites() is called?  Recent
tests (perhaps with an older X3DJSAIL as I was  trying to fix my build)
show that this is not done.  One must call setContainerFieldOverride() to
achieve this, which is deprecated.  If one doesn’t call this method, then
all hell breaks loose in CGE model viewer 5.2.0.

John

On Fri, Nov 8, 2024 at 1:22 PM Holger Seelig <holger.seelig at yahoo.de> wrote:

> It is a simple answer HAnimHumanoid has these fields to list joints,
> segments, skeleton, skin, and so on. These fields are either very important
> or to optimize access to these nodes. X_ITE makes good use of this
> because these fields exist. Nobody would even think of leaving the
> skeleton field empty. So it is important to populate the HAnimHumanoid
> node properly, then we will do our best and everything will work.
>
> Best regards,
> Holger
>
> --
> Holger Seelig
> Leipzig, Germany
>
> holger.seelig at yahoo.de
> https://create3000.github.io/x_ite/
>
> Am 08.11.2024 um 19:11 schrieb John Carlson <yottzumm at gmail.com>:
>
> It may be important to note AFAIAA, Sunrize now requires a HAnimHumanoid
> segments field to achieve animation for at least one model I tried.   I
> think Holger mailed me privately regarding this.  This may require updating
> a lot of models.  Whether this can be done automatically is now under
> discussion.
>
> Holger, perhaps you can either clarify or deny this?   Thanks!
>
> What’s important is we get the archive up-to-date with browser
> requirements.  I do not know why adding a segments field is a requirement,
> but when Holger added a HAnimSegment displacers field, adding a segments
> field became important.
>
> We hope that CGE model viewer will support HAnimDisplacers in
> HAnimSegments.  There are examples here:
>
> https://github.com/coderextreme/ci2had/tree/main/resources
>
> (Note that SingleMenuJin.x3d is still under construction, but the others
> should work).
>
> This may also affect the Blender loader and importer, as I’ve seen
> doppelgängers in recent loads/imports.
>
> John
>
> On Fri, Nov 8, 2024 at 10:56 AM John Carlson <yottzumm at gmail.com> wrote:
>
>> It’s pretty obvious that X3DJSAIL (there might be confusion about which
>> version I am using) does not fill in containerField automatically.  Neither
>> does CGE model viewer 5.2.0 for sites and segments when saving.  If they
>> would do this, then there wouldn’t be a problem.  If there’s a better open
>> source tool that fills in containerField for sites and segments
>> automatically, please point me at it.  My point is, that code would be the
>> same as auto-detection, which could be put into browsers.
>>
>> Additionally, if one is hand coding an X3DJSAIL app, one would have to
>> traverse the hierarchy finding all HAnimSite an HAnimSegment nodes and
>> adding USE nodes with a containerField.  This would have to appear in every
>> single HAnim X3DJSAIL program, instead of being programmed once in
>> X3DJSAIL.  If X3DJSAIL already has such a utility, please let me know, then
>> I don’t have to maintain my code.  If setContainerFieldOverride() is no
>> longer necessary, what replaces it?
>>
>> Thanks,
>>
>> John
>>
>>
>> On Fri, Nov 8, 2024 at 7:44 AM Michalis Kamburelis <
>> michalis.kambi at gmail.com> wrote:
>>
>>> There is no auto-detection of containerField in the X3D standard. I
>>> remember we talked about this, also on x3d-public mailing list. If
>>> such auto-detection of containerField will be added to the X3D
>>> standard (but I think it should not be added, see below), then CGE
>>> (and other X3D browsers) can implement this, in a consistent way.
>>>
>>> Trying to implement such auto-detection without spec, with each X3D
>>> browser doing something else, would lead to confusion of everyone.
>>>
>>> As for authors "throwing the towel": "brevity" is not a good enough
>>> argument to change something in a file format.
>>>
>>> - File format must also be consistent and simple to understand for
>>> implementors. The current rule for containerField is simple: it has
>>> node-specific default value, but if you want the parent field to be
>>> different, then write containerField in X3D XML.
>>> - And in case of X3D, real-life 3D models are mostly generated by
>>> software, not written by humans. The software should be capable of
>>> writing containerField="xxx" a zillion times without any issue.
>>>
>>> Please direct related questions to the x3d-public mailing list, not to
>>> me privately. We are discussing now something that touches what has
>>> been said on x3d-public lists, and what happens with X3D spec (which
>>> has to be coordinated, whatever the decision), and what is being done
>>> by Don/X3DJSAIL... Discussing it in private may easily lead to
>>> misunderstanding, when all interested parties know different subset of
>>> what others think/do.
>>>
>>> Regards,
>>> Michalis
>>>
>>> pt., 8 lis 2024 o 06:20 John Carlson <yottzumm at gmail.com> napisał(a):
>>> >
>>> > Don marked the “setContainerFieldOverride()” method as deprecated in
>>> X3DJSAIL.  If it’s removed without providing a way to set the
>>> containerField, then I will have difficulty getting Sunrize and CGE working
>>> with HAnim exports from X3DJSAIL.
>>> >
>>> > I don’t think that the method is required, because addSites() and
>>> addSegments() could set the containerField.  I have suggested this.  I
>>> don’t mail x3d-public because it’s like pouring water on hot grease.
>>> >
>>> > I can probably provide a Java example where CGE and Sunrize fail, but
>>> I’m actually trying to get them working, currently successfully by adding a
>>> containerField with setContainerFieldOverride().  These are old examples
>>> that don’t contain joints, sites and segments fields.
>>> >
>>> > What i will try to do at some point is create a Java program that
>>> fails to create an X3D file that works in CGE and Sunrize.  But if I do,
>>> will anyone care?
>>> >
>>> > This is low priority for me.
>>> >
>>> > The containerField for HAnimSite and HAnimSegment in HAnimHumanoid can
>>> be auto-detected based on node type, AFAIK.  This is what my email was
>>> about.
>>> >
>>> > Some people don’t have the desire to add all the necessary
>>> containerFields to HAnim to make CGE and Sunrize work and will just throw
>>> in the towel (give up).  Imagine something like 100+ segments or sites for
>>> a non-programmer.
>>> >
>>> > Ideally, the standard could be changed such that sites, segments and
>>> joints fields are not required.
>>> >
>>> > John
>>> >
>>> > On Thu, Nov 7, 2024 at 7:11 PM Michalis Kamburelis <
>>> michalis.kambi at gmail.com> wrote:
>>> >>
>>> >> Every node has a default containerField value (specified by X3D XML
>>> >> encoding spec and encoded in CGE). The containerField in X3D XML is
>>> >> required when the parent field you want to insert your node differs
>>> >> from the default containerField. When it does not differ, then you
>>> >> don't need to specify containerField.
>>> >>
>>> >> The above mechanism (in Castle Model Viewer and all other X3D
>>> >> browsers) follows X3D spec.
>>> >>
>>> >> Please post such questions to x3d-public, avoid writing email to me
>>> >> directly. Your statement "Don is turning on the screws making
>>> >> setContainerFieldOverrid" has unclear meaning. I don't know what Don
>>> >> is doing but I'm pretty sure he doesn't make something against X3D
>>> >> spec. These things are better discussed with all participants
>>> >> involved, instead of in private email threads, to avoid
>>> >> misunderstandings.
>>> >>
>>> >> Regards,
>>> >> Michalis
>>> >>
>>> >>
>>> >> czw., 7 lis 2024 o 16:28 John Carlson <yottzumm at gmail.com>
>>> napisał(a):
>>> >> >
>>> >> > Michalis,
>>> >> >
>>> >> > I question whether a containerField for sites and segments MFNode
>>> fields in HAnimHumanoid required in CGE Model Viewer?
>>> >> >
>>> >> > Don is turning on the screws making setContainerFieldOverride
>>> deprecated in X3DJSAIL, so it would be desired that the containerField is
>>> not required (and I don't think it is).
>>> >> >
>>> >> > Thanks,
>>> >> >
>>> >> > John
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20241108/44aa8652/attachment-0001.html>