<div dir="auto">My guess is it would require tons of routes, or tons of ProtoInstances, but please expand.  How does one populate the key fields with values?   Through reference?</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 10, 2023 at 9:57 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@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)" dir="auto">This reminded me of an earlier thread on a general mechanism to extend<br>
X3D nodes via special Metadata:<br>
The <br>
<a href="https://web3d.org/pipermail/x3d-public_web3d.org/2023-July/019061.html" rel="noreferrer" target="_blank">https://web3d.org/pipermail/x3d-public_web3d.org/2023-July/019061.html</a><br>
and earlier.<br>
<br>
It would apply here since the approach also allows for supplying<br>
values for regular fields through Metadata nodes. And Metadata nodes<br>
can use DEF/USE references to avoid duplication.<br>
<br>
So this option does not require any language changes, or scripts or<br>
protos. It does require a browsers which recognizes Metadata with<br>
special reference field values ("X3DFieldExtension") and applies the<br>
Metadata value to the parent node field.<br>
<br>
Another option to consider,<br>
<br>
Andreas<br>
<br>
<br>
> Message: 1<br>
> Date: Mon, 9 Oct 2023 19:39:39 -0500<br>
> From: John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>
> To: "Brutzman, Donald (Don) (CIV)" <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
> Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> Subject: Re: [x3d-public] Proposal: sharedKeyDEF, sharedKeyUSE<br>
> Message-ID:<br>
>         <<a href="mailto:CAGC3UEk7N865VenmPKm-NkjyT7S1z3mVWKpDRxZdA%2BTcpNSidw@mail.gmail.com" target="_blank">CAGC3UEk7N865VenmPKm-NkjyT7S1z3mVWKpDRxZdA+TcpNSidw@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Those are good alternatives, Don.<br>
><br>
> The preprocessor or compression idea for reducing network bandwidth seems<br>
> best, CSS classes are probably too general purpose.  JavaScript or Python<br>
> could be used, if the X3dTo* could be made compression aware, but if the<br>
> author didn?t intend it, one is fouling things up.  X3DJSONLD and my<br>
> serializers will probably not be implementing this feature without<br>
> standards support.  That is, I am reliant on others (you and Holger) to<br>
> produce JSON with preprocessor symbols.  So I?m returning your volley.<br>
><br>
> So I won?t be writing a PROTO or especially Script anytime soon.  It seems<br>
> very ungainly design, but please expand on your idea as I don?t fully<br>
> comprehend it.<br>
><br>
> I?m still thinking a high component level or FULL profile might be used in<br>
> interpolators for keyDEF or keyUSE or keyClass.  This can add benefit to<br>
> the runtime memory footprint size as well, which one can also hand program,<br>
> if desired.  CSS classes seem like a quagmire right now.<br>
><br>
> Another advantages to shared keys is making a change in one place in the<br>
> runtime instead of everywhere.  I realize that mutex locking may be an<br>
> issue.  Some languages have the concept of ?ownership? of a reference or<br>
> pointer.  But it would be interesting to change values in a shared key and<br>
> see effects in a looping animation.  Possibly without scripting!  One can<br>
> also specify mutable/immutable options to relieve issues about mutexes.<br>
><br>
> John<br>
><br>
> On Mon, Oct 9, 2023 at 6:32 PM Brutzman, Donald (Don) (CIV) <<br>
> <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
><br>
> > Thanks for a good idea. It has come up before. We decided not to do that<br>
> > in the X3D architecture.<br>
> ><br>
> > I could think of a few alternative ways to implementers might want to do<br>
> > this.<br>
> ><br>
> >    - use source code, for example, JavaScript or Java or python<br>
> >    - It is possible to put those array values in a MetadataFloat node.<br>
> >    That node might be used by a Script node, that pass the values at runtime<br>
> >    to the corresponding interpolators.<br>
> >    - If such a technique is shown to be useful in practice, then you<br>
> >    could write a prototype declaration to facilitate reuse.<br>
> ><br>
> > Of course, BVH and HAnimMotion were all successfully designed to reduce<br>
> > the need for more verbose interpolators.<br>
> ><br>
> > As our compression tools become more competent, I expect that they will<br>
> > have no trouble reducing the size of models with such repetitive large<br>
> > float values.<br>
> ><br>
> > Bandwidth and disk sizes keep increasing too?<br>
> ><br>
> > And so, there are plenty of good options without resorting to<br>
> > reengineering the language.<br>
> ><br>
> > Have fun with X3D!  ?<br>
> ><br>
> > v/r Don<br>
> > ------------------------------<br>
> > *From:* x3d-public <<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@web3d.org</a>> on behalf of John<br>
> > Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>
> > *Sent:* Monday, October 9, 2023 4:09:43 PM<br>
> > *To:* X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> > *Subject:* [x3d-public] Proposal: sharedKeyDEF, sharedKeyUSE<br>
> ><br>
> > Proposal to share keys between Interpolators to reduce file size.<br>
> ><br>
> > A big part of the increased file size for animations is the duplication of<br>
> > the key fields in Interpolators.  My proposal is to add two fields, a<br>
> > DEF-like field and a USE-like field to all? Interpolator definitions in the<br>
> > standard.<br>
> ><br>
> > The first interpolator in a shared key group would have a keyDEF field<br>
> > naming the group.  A shared key field would be specified in the first<br>
> > interpolator, but not subsequent interpolators.  Subsequent interpolators<br>
> > in the group would have a keyUSE field referring to the shared key group.<br>
> > Subsequent Interpolators would not have a key field.  A keyValue which is<br>
> > not shared would also be specified in all the interpolators.<br>
> ><br>
> > Different types of interpolators could share key values this way.<br>
> ><br>
> > This is already basically done for HAnimMotion, but HAnim lacks the<br>
> > nonlinear aspect of interpolator keys, which could be added to HAnimMotion<br>
> > if not there.<br>
> ><br>
> > This could be done with CSS class in HTML.<br>
> ><br>
> > John<br>
> ><br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231009/24e82be8/attachment-0001.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231009/24e82be8/attachment-0001.html</a>><br>
><br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>