<div dir="auto">Again, there is no “children” container field in HAnimHumanoid for XML, even though CGE model viewer 5.2.0 brashly claims there is.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Here it is again, for anyone to use:  <div><a href="https://github.com/coderextreme/x3dschema/blob/main/X3DJSONLD.java">https://github.com/coderextreme/x3dschema/blob/main/X3DJSONLD.java</a></div><div dir="auto"><br></div><div dir="auto">Note that you can use this to validate X3D JSON against XML schema, there’s no need for a JSON schema at all!</div><div dir="auto"><br></div><div dir="auto">There’s also this version, which may or may not be current or included in X3DJSAIL:  <div><a href="https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/net/coderextreme/X3DJSONLD.java">https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/net/coderextreme/X3DJSONLD.java</a></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Do you see that I don’t like switching to the mouse?</div></div></div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2024 at 2:20 PM Holger Seelig <<a href="mailto:holger.seelig@yahoo.de">holger.seelig@yahoo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="line-break:after-white-space">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.</div><div style="line-break:after-white-space"><div><br></div><div>Holger</div><div><br id="m_-625744905426916728lineBreakAtBeginningOfMessage"><div>
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;line-break:after-white-space;color:rgb(0,0,0)"><div dir="auto" style="text-align:start;text-indent:0px;line-break:after-white-space"><div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">--</div><div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">Holger Seelig</div><div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">Leipzig, Germany</div><div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)"><br></div><div style="letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)"><a href="mailto:holger.seelig@yahoo.de" target="_blank">holger.seelig@yahoo.de</a></div><div><a href="https://create3000.github.io/x_ite/" target="_blank">https://create3000.github.io/x_ite/</a></div></div></div></div></div></div></div>
</div>
<div><br><blockquote type="cite"><div>Am 08.11.2024 um 21:06 schrieb John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>>:</div><br><div><div dir="auto">The last paragraph is the most important.  </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Here’s a model I’ve been using.  I believe the animation doesn’t work in Sunrize:</div><div dir="auto"><br></div><div dir="auto"><div><a href="https://github.com/coderextreme/X3DJSONLD/blob/master/blend/JoeSkinTexcoordDisplacerKickUpdate2.x3d" target="_blank">https://github.com/coderextreme/X3DJSONLD/blob/master/blend/JoeSkinTexcoordDisplacerKickUpdate2.x3d</a></div><div dir="auto"><br></div><div dir="auto">But it doesn’t have a joints field, either.  Here’s a similar scene with joints and segments fields, which should work:</div><div dir="auto"><br></div><div dir="auto"><div><a href="https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JoeSkinUSE.x3d" target="_blank">https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JoeSkinUSE.x3d</a></div><br></div><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">A quick peek shows <br></div><div dir="auto"><div dir="auto"><a href="https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKickIndex.html" target="_blank">https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeKickIndex.html</a> still working.</div><div dir="auto"><br></div><div dir="auto">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.  <div dir="auto"><a href="https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JinLOA4withUSE.x3d" target="_blank">https://github.com/coderextreme/jaminate/blob/main/Jaminate/app/JinLOA4withUSE.x3d</a> I am using CGE Model Viewer 5.2.0.</div></div></div><div dir="auto"><br></div><div dir="auto">John </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Holger, perhaps you can either clarify or deny this?   Thanks!</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">We hope that CGE model viewer will support HAnimDisplacers in HAnimSegments.  There are examples here:</div><div dir="auto"><br></div><div dir="auto"><div><a href="https://github.com/coderextreme/ci2had/tree/main/resources" target="_blank">https://github.com/coderextreme/ci2had/tree/main/resources</a></div><div dir="auto"><br></div><div dir="auto">(Note that SingleMenuJin.x3d is still under construction, but the others should work).</div></div></div><div><div dir="auto"><br></div><div dir="auto">This may also affect the Blender loader and importer, as I’ve seen doppelgängers in recent loads/imports.</div></div><div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">John</div><div dir="auto"><br></div><div dir="auto"><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">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>
</blockquote></div></div>
</blockquote></div></div>
</div>
</blockquote></div></div>
</div></blockquote></div><br></div></div></blockquote></div></div>