[x3d-public] containerField for HAnimSites and HAnimSegments in HAnimHumanoid required?

Fri Nov 8 16:51:40 PST 2024

John,

This thread contains now numerous confused/imprecise/or just plain
wrong statements from your side. I'm sorry, it's really hard for me to
follow and derive anything constructive. It doesn't help that this
thread talks about at least 3 pieces of software (Castle Model Viewer,
X3DJSAIL, X_ITE) and you don't "back up" your statements by exact
testcases to show what you mean (necessary for *every* case where you
claimed in this thread, usually incorrectly, that some software does
something wrong).

To be clear: If you found an error in some piece of software, please
submit a bugreport, with exact reproduction. That is, with input that
is valid, but makes wrong behavior (like display) or conversion (and
"wrong" here means usually "wrong according to the X3D spec"). For
Castle Model Viewer, bugreports may go here:
https://github.com/castle-engine/castle-model-viewer/issues . Make it
precise, make this bugreport clear to the developer, make it limited
to one given problem, make it clear what specification part is being
broken.

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.

    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.

    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".

    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.

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
>>
>>