<div dir="ltr">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?<div><br></div><div>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.</div><div><br></div><div>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!</div><div><div><div><br></div><div>John</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2024 at 8:13 PM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2024 at 6:52 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Answers to some things that I noticed above:<br>
<br>
1. You wrote "Again, there is no “children” container field in<br>
HAnimHumanoid for XML, even though CGE model viewer 5.2.0 brashly<br>
claims there is."<br>
<br>
    -- This is not true. Castle Model Viewer doesn't ever "claim" that<br>
there are "children" in HAnimHumanoid.</blockquote><div><br></div><div>See attached image of Castle Model Viewer 5.2.0 when sites or segments containerField is not present.  Attaching model as well </div><div><br></div><div><img src="cid:ii_m39hxs680" alt="image.png" width="562" height="316"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
    Maybe you mean that some nodes have containerField="children" but<br>
HAnimHumanoid does not have "children" field? ( BTW it's not OK that I<br>
have to guess what your statement means! ) If I guessed your actual<br>
meaning right:<br>
<br>
    That can happen, yes, and it follows X3D specification. As said<br>
before, by me and others, in this and other threads on x3d-public, the<br>
way containerField in X3D XML works is simple: X3D XML has some<br>
"default containerField value", specific for every X3D XML node. They<br>
are given in X3D XML spec. This is the parent field where this node is<br>
added to, by default. If you want to add the node to some other parent<br>
field, than write containerField explicitly.<br></blockquote><div><br></div><div>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."</div><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
    As I said, there's no "auto-detection" for containerField in X3D<br>
XML, and I don't think there should be (it would be complicated to<br>
specify and then implement consistently). The current rule is<br>
super-clear and easy to follow: there's some default containerField<br>
for each node, and if you want something different -- write it.<br>
<br>
2. You wrote "It’s pretty obvious that X3DJSAIL (there might be<br>
confusion about which version I am using) does not fill in<br>
containerField automatically.  Neither does CGE model viewer 5.2.0 for<br>
sites and segments when saving.  If they would do this, then there<br>
wouldn’t be a problem"<br>
<br>
    - I don't know about X3DJSAIL. That's a bugreport to X3DJSAIL.<br>
<br>
    As for the statement about CGE model viewer: This is not true.<br>
<br>
    CGE model viewer does fill containerField when saving. Following<br>
the specification I paraphrased above. The rule, when saving, is "if<br>
the parent field is different than node's default containerField from<br>
X3D XML, then we write containerField to X3D file".<br></blockquote><div><br></div><div>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!</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>Here's the result of saving in CGE 5.2.0 Model Viewer for the record:</div><div><br></div><div>$ egrep 'HAnimSite|HAnimSegment' JoeSkinUSE*<br>JoeSkinUSE.x3d:          <HAnimSegment DEF='Joe_sacrum' name='sacrum'><br>JoeSkinUSE.x3d:            <HAnimSite DEF='Joe_RootFront' name='RootFront'><br>JoeSkinUSE.x3d:            </HAnimSite><br>JoeSkinUSE.x3d:          </HAnimSegment><br>JoeSkinUSE.x3d:        <HAnimSegment USE='Joe_sacrum'/><br>JoeSkinUSE.x3d:        <HAnimSite USE='Joe_RootFront'/><br>JoeSkinUSEwithoutCorrectContainerField.x3d:                             <HAnimSegment DEF="Joe_sacrum"<br>JoeSkinUSEwithoutCorrectContainerField.x3d:                                     <HAnimSite DEF="Joe_RootFront"<br>JoeSkinUSEwithoutCorrectContainerField.x3d:                                     </HAnimSite><br>JoeSkinUSEwithoutCorrectContainerField.x3d:                             </HAnimSegment></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>At some point, I may read the XML specification.</div><div><br></div><div>John</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
    Again, if you found a bug and we do not do this, then submit a<br>
bugreport, with a precise testcase to reproduce. Give me a model that<br>
is correct on input and when saved, it gets containerField wrong. I<br>
will be happy to make a fix then.</blockquote><div><br></div><div>This would not be a public issue if we had handled this privately.  Note the water on hot grease. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Michalis<br>
<br>
pt., 8 lis 2024 o 21:40 John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> napisał(a):<br>
><br>
> Again, there is no “children” container field in HAnimHumanoid for XML, even though CGE model viewer 5.2.0 brashly claims there is.<br>
><br>
> 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.<br>
><br>
> Here it is again, for anyone to use:<br>
> <a href="https://github.com/coderextreme/x3dschema/blob/main/X3DJSONLD.java" rel="noreferrer" target="_blank">https://github.com/coderextreme/x3dschema/blob/main/X3DJSONLD.java</a><br>
><br>
> Note that you can use this to validate X3D JSON against XML schema, there’s no need for a JSON schema at all!<br>
><br>
> There’s also this version, which may or may not be current or included in X3DJSAIL:<br>
> <a href="https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/net/coderextreme/X3DJSONLD.java" rel="noreferrer" target="_blank">https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/net/coderextreme/X3DJSONLD.java</a><br>
><br>
> 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.<br>
><br>
> Do you see that I don’t like switching to the mouse?<br>
><br>
> John<br>
><br>
> On Fri, Nov 8, 2024 at 2:20 PM Holger Seelig <<a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a>> wrote:<br>
>><br>
>> 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.<br>
>><br>
>> Holger<br>
>><br>
>> --<br>
>> Holger Seelig<br>
>> Leipzig, Germany<br>
>><br>
>> <a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a><br>
>> <a href="https://create3000.github.io/x_ite/" rel="noreferrer" target="_blank">https://create3000.github.io/x_ite/</a><br>
>><br>
>> Am 08.11.2024 um 21:06 schrieb John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>>:<br>
>><br>
>> The last paragraph is the most important.<br>
>><br>
>><br>
>> Here’s a model I’ve been using.  I believe the animation doesn’t work in Sunrize:<br>
>><br>
>> <a href="https://github.com/coderextreme/X3DJSONLD/blob/master/blend/JoeSkinTexcoordDisplacerKickUpdate2.x3d" rel="noreferrer" target="_blank">https://github.com/coderextreme/X3DJSONLD/blob/master/blend/JoeSkinTexcoordDisplacerKickUpdate2.x3d</a><br>
>><br>
>> But it doesn’t have a joints field, either.  Here’s a similar scene with joints and segments fields, which should work:<br>
>><br>
>> <a href="https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JoeSkinUSE.x3d" rel="noreferrer" target="_blank">https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JoeSkinUSE.x3d</a><br>
>><br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> A quick peek shows<br>
>> <a href="https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKickIndex.html" rel="noreferrer" target="_blank">https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKickIndex.html</a> still working.<br>
>><br>
>> 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.<br>
>> <a href="https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JinLOA4withUSE.x3d" rel="noreferrer" target="_blank">https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JinLOA4withUSE.x3d</a> I am using CGE Model Viewer 5.2.0.<br>
>><br>
>> John<br>
>><br>
>> On Fri, Nov 8, 2024 at 12:11 PM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> Holger, perhaps you can either clarify or deny this?   Thanks!<br>
>>><br>
>>> 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.<br>
>>><br>
>>> We hope that CGE model viewer will support HAnimDisplacers in HAnimSegments.  There are examples here:<br>
>>><br>
>>> <a href="https://github.com/coderextreme/ci2had/tree/main/resources" rel="noreferrer" target="_blank">https://github.com/coderextreme/ci2had/tree/main/resources</a><br>
>>><br>
>>> (Note that SingleMenuJin.x3d is still under construction, but the others should work).<br>
>>><br>
>>> This may also affect the Blender loader and importer, as I’ve seen doppelgängers in recent loads/imports.<br>
>>><br>
>>> John<br>
>>><br>
>>> On Fri, Nov 8, 2024 at 10:56 AM John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> wrote:<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> 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?<br>
>>>><br>
>>>> Thanks,<br>
>>>><br>
>>>> John<br>
>>>><br>
>>>><br>
>>>> On Fri, Nov 8, 2024 at 7:44 AM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> There is no auto-detection of containerField in the X3D standard. I<br>
>>>>> remember we talked about this, also on x3d-public mailing list. If<br>
>>>>> such auto-detection of containerField will be added to the X3D<br>
>>>>> standard (but I think it should not be added, see below), then CGE<br>
>>>>> (and other X3D browsers) can implement this, in a consistent way.<br>
>>>>><br>
>>>>> Trying to implement such auto-detection without spec, with each X3D<br>
>>>>> browser doing something else, would lead to confusion of everyone.<br>
>>>>><br>
>>>>> As for authors "throwing the towel": "brevity" is not a good enough<br>
>>>>> argument to change something in a file format.<br>
>>>>><br>
>>>>> - File format must also be consistent and simple to understand for<br>
>>>>> implementors. The current rule for containerField is simple: it has<br>
>>>>> node-specific default value, but if you want the parent field to be<br>
>>>>> different, then write containerField in X3D XML.<br>
>>>>> - And in case of X3D, real-life 3D models are mostly generated by<br>
>>>>> software, not written by humans. The software should be capable of<br>
>>>>> writing containerField="xxx" a zillion times without any issue.<br>
>>>>><br>
>>>>> Please direct related questions to the x3d-public mailing list, not to<br>
>>>>> me privately. We are discussing now something that touches what has<br>
>>>>> been said on x3d-public lists, and what happens with X3D spec (which<br>
>>>>> has to be coordinated, whatever the decision), and what is being done<br>
>>>>> by Don/X3DJSAIL... Discussing it in private may easily lead to<br>
>>>>> misunderstanding, when all interested parties know different subset of<br>
>>>>> what others think/do.<br>
>>>>><br>
>>>>> Regards,<br>
>>>>> Michalis<br>
>>>>><br>
>>>>> pt., 8 lis 2024 o 06:20 John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> napisał(a):<br>
>>>>> ><br>
>>>>> > 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.<br>
>>>>> ><br>
>>>>> > 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.<br>
>>>>> ><br>
>>>>> > 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.<br>
>>>>> ><br>
>>>>> > 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?<br>
>>>>> ><br>
>>>>> > This is low priority for me.<br>
>>>>> ><br>
>>>>> > The containerField for HAnimSite and HAnimSegment in HAnimHumanoid can be auto-detected based on node type, AFAIK.  This is what my email was about.<br>
>>>>> ><br>
>>>>> > 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.<br>
>>>>> ><br>
>>>>> > Ideally, the standard could be changed such that sites, segments and joints fields are not required.<br>
>>>>> ><br>
>>>>> > John<br>
>>>>> ><br>
>>>>> > On Thu, Nov 7, 2024 at 7:11 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
>>>>> >><br>
>>>>> >> Every node has a default containerField value (specified by X3D XML<br>
>>>>> >> encoding spec and encoded in CGE). The containerField in X3D XML is<br>
>>>>> >> required when the parent field you want to insert your node differs<br>
>>>>> >> from the default containerField. When it does not differ, then you<br>
>>>>> >> don't need to specify containerField.<br>
>>>>> >><br>
>>>>> >> The above mechanism (in Castle Model Viewer and all other X3D<br>
>>>>> >> browsers) follows X3D spec.<br>
>>>>> >><br>
>>>>> >> Please post such questions to x3d-public, avoid writing email to me<br>
>>>>> >> directly. Your statement "Don is turning on the screws making<br>
>>>>> >> setContainerFieldOverrid" has unclear meaning. I don't know what Don<br>
>>>>> >> is doing but I'm pretty sure he doesn't make something against X3D<br>
>>>>> >> spec. These things are better discussed with all participants<br>
>>>>> >> involved, instead of in private email threads, to avoid<br>
>>>>> >> misunderstandings.<br>
>>>>> >><br>
>>>>> >> Regards,<br>
>>>>> >> Michalis<br>
>>>>> >><br>
>>>>> >><br>
>>>>> >> czw., 7 lis 2024 o 16:28 John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> napisał(a):<br>
>>>>> >> ><br>
>>>>> >> > Michalis,<br>
>>>>> >> ><br>
>>>>> >> > I question whether a containerField for sites and segments MFNode fields in HAnimHumanoid required in CGE Model Viewer?<br>
>>>>> >> ><br>
>>>>> >> > 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).<br>
>>>>> >> ><br>
>>>>> >> > Thanks,<br>
>>>>> >> ><br>
>>>>> >> > John<br>
>><br>
>><br>
</blockquote></div></div>
</blockquote></div>