[x3d-public] Proposal: sharedKeyDEF, sharedKeyUSE (John Carlson)

[John Carlson]

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?

On Tue, Oct 10, 2023 at 9:57 AM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> This reminded me of an earlier thread on a general mechanism to extend
> X3D nodes via special Metadata:
> The
> https://web3d.org/pipermail/x3d-public_web3d.org/2023-July/019061.html
> and earlier.
>
> It would apply here since the approach also allows for supplying
> values for regular fields through Metadata nodes. And Metadata nodes
> can use DEF/USE references to avoid duplication.
>
> So this option does not require any language changes, or scripts or
> protos. It does require a browsers which recognizes Metadata with
> special reference field values ("X3DFieldExtension") and applies the
> Metadata value to the parent node field.
>
> Another option to consider,
>
> Andreas
>
>
> > Message: 1
> > Date: Mon, 9 Oct 2023 19:39:39 -0500
> > From: John Carlson <yottzumm at gmail.com>
> > To: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
> > Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> > Subject: Re: [x3d-public] Proposal: sharedKeyDEF, sharedKeyUSE
> > Message-ID:
> >         <
> CAGC3UEk7N865VenmPKm-NkjyT7S1z3mVWKpDRxZdA+TcpNSidw at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Those are good alternatives, Don.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > John
> >
> > On Mon, Oct 9, 2023 at 6:32 PM Brutzman, Donald (Don) (CIV) <
> > brutzman at nps.edu> wrote:
> >
> > > Thanks for a good idea. It has come up before. We decided not to do
> that
> > > in the X3D architecture.
> > >
> > > I could think of a few alternative ways to implementers might want to
> do
> > > this.
> > >
> > >    - use source code, for example, JavaScript or Java or python
> > >    - 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.
> > >    - If such a technique is shown to be useful in practice, then you
> > >    could write a prototype declaration to facilitate reuse.
> > >
> > > Of course, BVH and HAnimMotion were all successfully designed to reduce
> > > the need for more verbose interpolators.
> > >
> > > 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.
> > >
> > > Bandwidth and disk sizes keep increasing too?
> > >
> > > And so, there are plenty of good options without resorting to
> > > reengineering the language.
> > >
> > > Have fun with X3D!  ?
> > >
> > > v/r Don
> > > ------------------------------
> > > *From:* x3d-public <x3d-public-bounces at web3d.org> on behalf of John
> > > Carlson <yottzumm at gmail.com>
> > > *Sent:* Monday, October 9, 2023 4:09:43 PM
> > > *To:* X3D Graphics public mailing list <x3d-public at web3d.org>
> > > *Subject:* [x3d-public] Proposal: sharedKeyDEF, sharedKeyUSE
> > >
> > > Proposal to share keys between Interpolators to reduce file size.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > Different types of interpolators could share key values this way.
> > >
> > > 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.
> > >
> > > This could be done with CSS class in HTML.
> > >
> > > John
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231009/24e82be8/attachment-0001.html
> >
> >
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20231010/7667120b/attachment.html>