[x3d-public] Fwd: HAnim sample failing in X3DOM, error in view3dscene, additional tests

[Andreas Plesch]

Resending after shortening

---------- Forwarded message ---------
From: Andreas Plesch <andreasplesch at gmail.com>
Date: Sat, Jun 24, 2023, 11:05 PM
Subject: Re: HAnim sample failing in X3DOM, error in view3dscene,
additional tests
To: Joseph D Williams <joedwil at earthlink.net>
Cc: Michalis Kamburelis <michalis.kambi at gmail.com>, John Carlson <
yottzumm at gmail.com>, Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>, X3D
Graphics public mailing list <x3d-public at web3d.org>


On Fri, Jun 23, 2023 at 5:39 PM Joseph D Williams <joedwil at earthlink.net>
wrote

>>>. So, if the tool does not do that, the user may be disappointed. In the
long past most every player had many ’tolerant’ behaviors.

It is nice to have more tolerant viewers but a user should not be
disappointed if an non-valid scene generates errors or does not display.

If there was a defacto standard behavior in the long past, that means there
may be a good reason to formalize that behaviour. Alternatively, dedicated
validation tools could help with detecting and then correcting incomplete
and therefore invalid content.

Thanks,

-Andreas


> Thanks,
>
> Joe
>
>
>
>
>
>
>
>
>
> *From: *Andreas Plesch <andreasplesch at gmail.com>
> *Sent: *Thursday, June 22, 2023 2:52 PM
> *To: *Michalis Kamburelis <michalis.kambi at gmail.com>
> *Cc: *John Carlson <yottzumm at gmail.com>; Brutzman, Donald (Don) (CIV)
> <brutzman at nps.edu>; Joe D Williams <joedwil at earthlink.net>; X3D Graphics
> public mailing list <x3d-public at web3d.org>
> *Subject: *Re: HAnim sample failing in X3DOM, error in view3dscene,
> additional tests
>
>
>
> Also agreed on performance impacts. There are set_index in fields for the
> index fields, meaning that dynamic changes to the indices are allowed. This
> is impacting performance in itself and if checking and potentially filling
> in values would be required as well it would further affect performance on
> a per frame basis.
>
>
>
> For example, Three.js is very strict, for performance reasons, in
> expecting all input to its interfaces to be valid. It does not perform
> error checking itself.
>
>
>
> I only mentioned spec changes because in practice users - after a warning
> - would still expect some non-fatal behaviour anyways which requires
> checking and potentially filling in or altering values. So why not
> standardize this behaviour ?
>
>
>
> I think I may add checking and recycling with a warning only to the
> initial setup of the IFS node but not for dynamic changes via routes or
> SAI. Animating textures through texcoord indices seems a valid use case.
>
>
>
> Cheers,
>
>
>
> -Andreas
>
>
>
> On Thu, Jun 22, 2023 at 12:36 PM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
>
> I would be against introducing spec wording to guarantee any behavior when
> there's not enough per-vertex data.
>
>
>
> 1. There's no obvious resolution (replicating last texture coordinate may
> not be "what the author wanted" -- the texture will be likely weirdly
> stretched),
>
>
>
> 2. Other model formats also don't specify anything in this case. It's just
> invalid model causing undefined behavior for glTF, Collada etc.
>
>
>
> 3. It may be a performance issue in some scenarios. Some browsers could be
> bundled with models essentially guaranteed to be correct (e.g. when you
> deliver a game runtime + game assets locally). ( This is just a theoretical
> example, CGE doesn't do this now -- we check models for correctness the
> same, no matter if it's in view3dscene or in some game using CGE. ) Such
> browsers can right now upload the data to GPU in a straightforward fashion
> without checking for correctness. Or just check for correctness and fail if
> the model is wrong. If the browsers will have to instead potentially
> process the data, because even correct models may not have enough data...
> then we've lost performance in some cases.
>
>
>
>     Basically, if we allow something in the spec as "valid model", then we
> make a guarantee it is supported. Authors will use it, and developers have
> to make sure it is supported. In this particular case, I'd say the benefit
> (supporting models where someone likely just made a mistake) is not big
> enough to justify the costs (need to process per-vertex data, doing
> operation that may not be what author wanted anyway).
>
>
>
> The arguments 1 and 2 are really critical for me. There's no sensible
> default behavior to do IMHO, author should get a clear message "this is
> invalid model, please fix it".
>
>
>
> Regards,
>
> Michalis
>
>
>
> czw., 22 cze 2023 o 17:55 Andreas Plesch <andreasplesch at netscape.net>
> napisał(a):
>
> Agreed. I can add a warning to the x3dom console log. But checking for
> correctness is really the job of a validator, not necessarily of a viewer.
> This is also true for glTF, and probably Collada, which have their own
> dedicated validators.
>
>
>
> Another possibility is to change the spec. to define a behaviour other
> than undefined, unpleasant as it is. The simplest would be probably "use
> the last available" to fill in missing
> 2d3d4dtexcoords/2d3dcoords/rgbrgbacolors . Alternatively, "replace out of
> range indices with the highest in range index". Very similar but has some
> consequences for event routing since different fields are altered.
>
>
>
> -Andreas
>
>
>
> On Thu, Jun 22, 2023 at 8:10 AM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
>
> Andreas,
>
>
>
> I especially agree with statement """I can add recycling of texCoords in
> x3dom for such a case but it is almost not worth doing since the problem is
> that there are many reasonable strategies to divine an author's
> intention""" :)
>
>
>
> Exactly -- there are many possible options "what to do, what was the
> author's intention". There are even more options if we recall that texture
> coordinates may also be 3D and 4D, for 3D textures. And the same issue can
> occur with other per-vertex data, e.g. colors per vertex, normals, fog
> coordinates, shader attributes.
>
>
>
> My recommendation would be to first make a clear warning/error to user
> about it, so that users know to fix this issue in the model. This is also
> what (from my knowledge) everyone else does -- glTF, Collada, Wavefront
> OBJ... they all have some indexes and texture coordinates, and they just
> require that author provides enough texture coordinates. It's undefined
> what happens if model is invalid, it is even possible that renderer uploads
> to GPU something invalid and then GPU decides what happens (but letting GPU
> choose the undefined behavior is not good from security standpoint --
> ideally the renderer should catch it and make reliable error/warning).
>
>
>
> We don't want to have a talk in +5 years """OK, what do we do with not
> enough per-vertex data, because FreeWRL now fills it with zeroes, X3DOM
> cycles from beginning, CGE fills it with 1s""" etc. :) We want our
> resolution to be "such models are invalid, authors should get message about
>
> ·
> https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Characters/JinLOA4X_ITE.html
>
>
>
> 6.      Xj3D has a verbose console without any errors apparent,  However
> only renders a black screen.
>
> 7
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230626/ad88656e/attachment-0001.html>