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

[John Carlson]

And yes, I understand the difficulty with saving an animation in progress.

John

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

> Oh, BTW, I just viewed the saved file,
> JoeSkinUSEwithoutCorrectContainerField.x3d,  in CGE Model Viewer.  Maybe
> compare the two previous attachments in CGE Model Viewer to compare!
>
> I will fix JoeSkinUSE.x3d and try the conversion again.  I added the two
> containerFields.  Please view the two attached files in CGE Model Viewer.
> Again, JoeSkinUSE.x3d is different than the previous attachment.
>
> Grr.  I like X3DJSAIL.
>
> I'll file a formal bug report with CGE.
>
> Thanks!
>
> 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/2c2ea51d/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/2c2ea51d/attachment-0001.png>