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

[John Carlson]

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/89859698/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/89859698/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JoeSkinUSEwithCorrectContainerField.x3d
Type: model/x3d+xml
Size: 121671 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20241108/89859698/attachment-0002.x3d>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JoeSkinUSE.x3d
Type: model/x3d+xml
Size: 88723 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-ecosystem_web3d.org/attachments/20241108/89859698/attachment-0003.x3d>