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

Tue Oct 10 09:17:14 PDT 2023

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