<div dir="auto">Those are good alternatives, Don.</div><div dir="auto"><br></div><div dir="auto">The preprocessor or compression idea for reducing network bandwidth seems best, CSS classes are probably too general purpose.  JavaScript or Python could be used, if the X3dTo* could be made compression aware, but if the author didn’t intend it, one is fouling things up.  X3DJSONLD and my serializers will probably not be implementing this feature without standards support.  That is, I am reliant on others (you and Holger) to produce JSON with preprocessor symbols.  So I’m returning your volley.</div><div dir="auto"><br></div><div dir="auto">So I won’t be writing a PROTO or especially Script anytime soon.  It seems very ungainly design, but please expand on your idea as I don’t fully comprehend it.</div><div dir="auto"><br></div><div dir="auto">I’m still thinking a high component level or FULL profile might be used in interpolators for keyDEF or keyUSE or keyClass.  This can add benefit to the runtime memory footprint size as well, which one can also hand program, if desired.  CSS classes seem like a quagmire right now.</div><div dir="auto"><br></div><div dir="auto">Another advantages to shared keys is making a change in one place in the runtime instead of everywhere.  I realize that mutex locking may be an issue.  Some languages have the concept of “ownership” of a reference or pointer.  But it would be interesting to change values in a shared key and see effects in a looping animation.  Possibly without scripting!  One can also specify mutable/immutable options to relieve issues about mutexes.</div><div dir="auto"><br></div><div dir="auto">John</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Oct 9, 2023 at 6:32 PM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</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="ltr">
<div></div>
<div>
<div>Thanks for a good idea. It has come up before. We decided not to do that in the X3D architecture.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I could think of a few alternative ways to implementers might want to do this.</div>
<div dir="ltr">
<ul>
<li>use source code, for example, JavaScript or Java or python</li><li>It is possible to put those array values in a MetadataFloat node. That node might be used by a Script node, that pass the values at runtime to the corresponding interpolators.</li><li>If such a technique is shown to be useful in practice, then you could write a prototype declaration to facilitate reuse. </li></ul>
</div>
<div id="m_6381909398532621934ms-outlook-mobile-signature">
<div>Of course, BVH and HAnimMotion were all successfully designed to reduce the need for more verbose interpolators. </div>
<div dir="ltr"><br>
</div>
<div>As our compression tools become more competent, I expect that they will have no trouble reducing the size of models with such repetitive large float values.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Bandwidth and disk sizes keep increasing too…</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">And so, there are plenty of good options without resorting to reengineering the language. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Have fun with X3D!  😀</div>
<div dir="ltr"><br>
</div>
<div>v/r Don</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_6381909398532621934divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><b style="font-family:Calibri,sans-serif">From:</b> x3d-public <<a href="mailto:x3d-public-bounces@web3d.org" target="_blank" style="font-family:Calibri,sans-serif">x3d-public-bounces@web3d.org</a>> on behalf of John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank" style="font-family:Calibri,sans-serif">yottzumm@gmail.com</a>><br>
<b style="font-family:Calibri,sans-serif">Sent:</b> Monday, October 9, 2023 4:09:43 PM<br>
<b style="font-family:Calibri,sans-serif">To:</b> X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank" style="font-family:Calibri,sans-serif">x3d-public@web3d.org</a>><br>
<b style="font-family:Calibri,sans-serif">Subject:</b> [x3d-public] Proposal: sharedKeyDEF, sharedKeyUSE</font>
<div> </div>
</div></div><div>
<div>Proposal to share keys between Interpolators to reduce file size.
<div dir="auto"><br>
</div>
<div dir="auto">A big part of the increased file size for animations is the duplication of the key fields in Interpolators.  My proposal is to add two fields, a DEF-like field and a USE-like field to all? Interpolator definitions in the standard.</div>
<div dir="auto"><br>
</div>
<div dir="auto">The first interpolator in a shared key group would have a keyDEF field naming the group.  A shared key field would be specified in the first interpolator, but not subsequent interpolators.  Subsequent interpolators in the group would have a
 keyUSE field referring to the shared key group.  Subsequent Interpolators would not have a key field.  A keyValue which is not shared would also be specified in all the interpolators.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Different types of interpolators could share key values this way.</div>
<div dir="auto"><br>
</div>
<div dir="auto">This is already basically done for HAnimMotion, but HAnim lacks the nonlinear aspect of interpolator keys, which could be added to HAnimMotion if not there.</div>
<div dir="auto"><br>
</div>
<div dir="auto">This could be done with CSS class in HTML.</div>
<div dir="auto"><br>
</div>
<div dir="auto">John</div>
</div>
</div>

</blockquote></div></div>