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

Richard Puk puk at igraphics.com
Tue Oct 10 16:58:45 PDT 2023 

Hi --

All angle specifications in X3D are in radians which are the base unit. This can be changed using the UNIT statement. See the description of the UNIT statement in the Base Component clause.

  -- Dick

/******************************************
| Richard F. Puk, Ph.D.
| 7644 Cortina Court
| Carlsbad, CA  92009-8206
| Tel: +1-760-753-9027  Mobile:  +1-760-809-9027
| Email:  puk at igraphics.com
\****************************************** 



-----Original Message-----
From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Andreas Plesch
Sent: Tuesday, October 10, 2023 9:09 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 <yottzumm at gmail.com> 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 <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.htm
>> l
>> 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/202310
>> > 09/24e82be8/attachment-0001.html>
>> >
>>
>> _______________________________________________
>> 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

More information about the x3d-public mailing list