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

Tue Oct 10 09:27:53 PDT 2023

Yes!

I was talking about non-linear animation, stretching out or shrinking
certain portions.

John

On Tue, Oct 10, 2023 at 11:17 AM Joe D Williams <joedwil at earthlink.net>
wrote:

> In bvh,the keyfield is populated by the number of frames and the fixed
> interval between frames
> It is this way because for making a video you don't need
> interpolation,just render each keyValue data
> t data.
>
>
> -----Original Message-----
> From: Andreas Plesch <andreasplesch at gmail.com>
> Sent: Oct 10, 2023 9:10 AM
> To: John Carlson <yottzumm at gmail.com>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] Proposal: sharedKeyDEF, sharedKeyUSE (John
> Carlson)
>
> Yes, through the reference field. Please see the earlier thread. -Andreas
>
> On Tue, Oct 10, 2023 at 11:58 AM John Carlson wrote:
> >
> > 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 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
> >> > To: "Brutzman, Donald (Don) (CIV)"
> >> > Cc: X3D Graphics public mailing list
> >> > Subject: Re: [x3d-public] Proposal: sharedKeyDEF, sharedKeyUSE
> >> > Message-ID:
> >> >
> >> > 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 on behalf of John
> >> > > Carlson
> >> > > *Sent:* Monday, October 9, 2023 4:09:43 PM
> >> > > *To:* X3D Graphics public mailing list
> >> > > *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:
> >> >
> >>
> >> _______________________________________________
> >> x3d-public mailing list
> >> x3d-public at web3d.org
> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> 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/5d958c59/attachment-0001.html>