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

[John Carlson]

I'm currently wondering if my models contain many duplicate HAnimJoints
(with USE) in the HAnimHumanoid joints field (or even the skeleton field).
That would be an interesting catch!  What happens in the browsers?  What
does the spec say?

That's just what's going through my mind after seeing doppelgangers in
Blender.  Probably due to USE nodes, either purposeful or not.  I did see
an extra skeleton field looking for 'containerField="s' in a recent model.

Wouldn't it be fun if we had containerField's in JSON?  There's some wisdom
there to not add them and use container fields, but dang trouble converting
JSON to DOM.  Thank goodness others have converted XML to JSON.  Kudos to
you!

John

On Fri, Nov 8, 2024 at 8:13 PM John Carlson <yottzumm at gmail.com> wrote:

>
>
> On Fri, Nov 8, 2024 at 6:52 PM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
>
>>
>> Answers to some things that I noticed above:
>>
>> 1. You wrote "Again, there is no “children” container field in
>> HAnimHumanoid for XML, even though CGE model viewer 5.2.0 brashly
>> claims there is."
>>
>>     -- This is not true. Castle Model Viewer doesn't ever "claim" that
>> there are "children" in HAnimHumanoid.
>
>
> See attached image of Castle Model Viewer 5.2.0 when sites or segments
> containerField is not present.  Attaching model as well
>
> [image: image.png]
>
>>
>>     Maybe you mean that some nodes have containerField="children" but
>> HAnimHumanoid does not have "children" field? ( BTW it's not OK that I
>> have to guess what your statement means! ) If I guessed your actual
>> meaning right:
>>
>>     That can happen, yes, and it follows X3D specification. As said
>> before, by me and others, in this and other threads on x3d-public, the
>> way containerField in X3D XML works is simple: X3D XML has some
>> "default containerField value", specific for every X3D XML node. They
>> are given in X3D XML spec. This is the parent field where this node is
>> added to, by default. If you want to add the node to some other parent
>> field, than write containerField explicitly.
>>
>
> Okay, I assume that the default containerField for HAnimSegment and
> HAnimSite is "children"  I can accept that.  I probably read the message
> wrong. I would use "of" instead of "by."
>
> I don't particuiarly have an issue with Castle Model Viewer, but I'm going
> to check the other item. I do have a problem with X3DJSAIL preventing me
> from setting a containerField for HAnimSegment or HAnimSite.  It doesn't
> yet, but I'm using a deprecated method.
>
>>
>>     As I said, there's no "auto-detection" for containerField in X3D
>> XML, and I don't think there should be (it would be complicated to
>> specify and then implement consistently). The current rule is
>> super-clear and easy to follow: there's some default containerField
>> for each node, and if you want something different -- write it.
>>
>> 2. You 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"
>>
>>     - I don't know about X3DJSAIL. That's a bugreport to X3DJSAIL.
>>
>>     As for the statement about CGE model viewer: This is not true.
>>
>>     CGE model viewer does fill containerField when saving. Following
>> the specification I paraphrased above. The rule, when saving, is "if
>> the parent field is different than node's default containerField from
>> X3D XML, then we write containerField to X3D file".
>>
>
> Running the same model attached through Castle Model Viewer 5.2.0.  See
> attached result.  The HAnimSite and HAnimSegment with USE were removed.
> I'm not sure of the intent of the spec at this point, but removing nodes
> really surprises me!
>
>
> Anyway.  Please people, fix your models and your software so I don't have
> to write more code to fix crappy models that don't animate in Sunrize.
>
> Here's the result of saving in CGE 5.2.0 Model Viewer for the record:
>
> $ egrep 'HAnimSite|HAnimSegment' JoeSkinUSE*
> JoeSkinUSE.x3d:          <HAnimSegment DEF='Joe_sacrum' name='sacrum'>
> JoeSkinUSE.x3d:            <HAnimSite DEF='Joe_RootFront' name='RootFront'>
> JoeSkinUSE.x3d:            </HAnimSite>
> JoeSkinUSE.x3d:          </HAnimSegment>
> JoeSkinUSE.x3d:        <HAnimSegment USE='Joe_sacrum'/>
> JoeSkinUSE.x3d:        <HAnimSite USE='Joe_RootFront'/>
> JoeSkinUSEwithoutCorrectContainerField.x3d:
> <HAnimSegment DEF="Joe_sacrum"
> JoeSkinUSEwithoutCorrectContainerField.x3d:
>       <HAnimSite DEF="Joe_RootFront"
> JoeSkinUSEwithoutCorrectContainerField.x3d:
>       </HAnimSite>
> JoeSkinUSEwithoutCorrectContainerField.x3d:
> </HAnimSegment>
>
> Yes, I realize that JoeSkinUSE.x3d does not have the required
> containerField.  That's what I fixed using X3DJSAIL, jaminate and
> setContainerFieldOverride().  If there's another way, please, please let
> people know.
>
> To me, the "default containerField" for HAnimSite and HAnimSegment is the
> only fields they fit in into HAnimHumanoid.  If there's more than one
> choice, sure, then containerField is required.  That's the HAnimJoint
> conversation.
>
> At some point, I may read the XML specification.
>
> John
>
>
>
>>     Again, if you found a bug and we do not do this, then submit a
>> bugreport, with a precise testcase to reproduce. Give me a model that
>> is correct on input and when saved, it gets containerField wrong. I
>> will be happy to make a fix then.
>
>
> This would not be a public issue if we had handled this privately.  Note
> the water on hot grease.
>
>>
>> Regards,
>> Michalis
>>
>> pt., 8 lis 2024 o 21:40 John Carlson <yottzumm at gmail.com> napisał(a):
>> >
>> > Again, there is no “children” container field in HAnimHumanoid for XML,
>> even though CGE model viewer 5.2.0 brashly claims there is.
>> >
>> > If I were to switch to JSON for X3DJSAIL, I would have to add
>> X3DJSONLD.java to all my apps.  Which might not be a bad option, just an
>> extra dependency.  Yes, I’ve offered X3DJSONLD.java as a gift to the Web3d
>> Consortium.
>> >
>> > Here it is again, for anyone to use:
>> > https://github.com/coderextreme/x3dschema/blob/main/X3DJSONLD.java
>> >
>> > Note that you can use this to validate X3D JSON against XML schema,
>> there’s no need for a JSON schema at all!
>> >
>> > There’s also this version, which may or may not be current or included
>> in X3DJSAIL:
>> >
>> https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/net/coderextreme/X3DJSONLD.java
>> >
>> > Generally, most of the files i get are from sourceforge, and they are
>> .x3d though, so converting to .json would have to be done, just an extra
>> step.
>> >
>> > Do you see that I don’t like switching to the mouse?
>> >
>> > John
>> >
>> > On Fri, Nov 8, 2024 at 2:20 PM Holger Seelig <holger.seelig at yahoo.de>
>> wrote:
>> >>
>> >> X3D XML encoding requires sometimes a custom container field when it
>> is not the default, but it is important for X3D XML encoding to do so. If
>> you don’t like containerField, you have the option to switch to X3D Classic
>> VRML encoding or even JSON. A X3D file format must be precise in specifying
>> all nodes and fields, some require this and some require that, but you must
>> do what is specified, because it is needed, and everything is well thought
>> out.
>> >>
>> >> Holger
>> >>
>> >> --
>> >> Holger Seelig
>> >> Leipzig, Germany
>> >>
>> >> holger.seelig at yahoo.de
>> >> https://create3000.github.io/x_ite/
>> >>
>> >> Am 08.11.2024 um 21:06 schrieb John Carlson <yottzumm at gmail.com>:
>> >>
>> >> The last paragraph is the most important.
>> >>
>> >>
>> >> Here’s a model I’ve been using.  I believe the animation doesn’t work
>> in Sunrize:
>> >>
>> >>
>> https://github.com/coderextreme/X3DJSONLD/blob/master/blend/JoeSkinTexcoordDisplacerKickUpdate2.x3d
>> >>
>> >> But it doesn’t have a joints field, either.  Here’s a similar scene
>> with joints and segments fields, which should work:
>> >>
>> >>
>> https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JoeSkinUSE.x3d
>> >>
>> >>
>> >> I believe there’s only one HAnimDisplacer.  But the whole skin won’t
>> animate in the former scene in Sunrize.  Please confirm this, as I am on my
>> phone.
>> >>
>> >> When I add the joints and segments fields, JoeSkin… animates.  But
>> perhaps i only needed to add a joints field, based on reviewing the archive.
>> >>
>> >> A quick peek shows
>> >>
>> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKickIndex.html
>> still working.
>> >>
>> >> Obviously, the joints require a containerField other than the
>> default.  The question is, do the HAnimHumanoid segments/sites field’s
>> children also need a containerField?  That’s where the conversation
>> started.  I don’t think that adding HAnimSites or HAnimSegments as direct
>> children of HAnimHumanoid should require a containerField.  That’s the
>> subject under discussion.  Here’s something to experiment with which does
>> have a containerField=“segments” Try taking it out.
>> >>
>> https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JinLOA4withUSE.x3d
>> I am using CGE Model Viewer 5.2.0.
>> >>
>> >> John
>> >>
>> >> On Fri, Nov 8, 2024 at 12:11 PM John Carlson <yottzumm at gmail.com>
>> wrote:
>> >>>
>> >>> 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/19461dc9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 1208444 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20241108/19461dc9/attachment-0001.png>