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

[Andreas Plesch]

This reminded me of an earlier thread on a general mechanism to extend
X3D nodes via special Metadata:

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>
>