[x3d-public] Proposal: sharedKeyDEF, sharedKeyUSE

[John Carlson]

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