[x3d-public] X3D4 specification rendering issue: recomputation of browser-computed texture coordinates when animating meshes?

Wed Jan 4 08:58:45 PST 2023

Very interesting and important discussion.  Thank you Holger and Joe.

As an author, similar to explicitly providing texture coordinates, I'd
expect that texture coordinate precomputation would be a one-time
occurrence.  This is important to avoid unexpected computational expense
during animated rendering, and also provide consistent texture display
throughout any user navigation or animation.

Recomputing texture coordinate based on any changes in the mesh (number of
coords, number of polygons) certainly seems sensible and typical.  FWIW, I
think we haven't encountered this issue before because HAnimHumanoid skin
animation is essentially implicit, following along wherever the skeleton
joints are moved.  Am expecting that we might encounter a similar issue
again when we have further practice animating skeleton joints using
HAnimMotion node.

Nevertheless, when texture coordinates are not provided (a useful reduction
in file size and complexity), any ambiguity of determining S and T axes
seems problematic.  We need to address any ambiguities.  Note that browser
frame rates might change bounding box proportions and thus become
determining factor for whether such S, T axis flips.  This would change the
displayed model (which is what we are currently seeing in the example)
either for multiple browsers or even a single browser operating at different
frame rates.  Such unpredictable differences are contrary to X3D design
principle that a model is sufficiently well defined so that it looks and
animates and interacts consistently across different
hardware/software/display combinations.

X3D4 Draft International Specification (DIS) references:

*	X3D4 Architecture, Texturing component, 18.2.3 Texture coordinates
*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/
components/texturing.html#TextureCoordinates

*	X3D4 Architecture, Texturing component, 13.3.6 IndexedFaceSet
*
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/
components/geometry3D.html
*	Scrolling down. key paragraph of interest: 
*	"If the texCoord field is NULL, a default texture coordinate mapping
is calculated using the local coordinate system bounding box of the shape.
The longest dimension of the bounding box defines the S coordinates, and the
next longest defines the T coordinates. If two or all three dimensions of
the bounding box are equal, ties shall be broken by choosing the X, Y, or Z
dimension in that order of preference. The value of the S coordinate ranges
from 0 to 1, from one end of the bounding box to the other. The T coordinate
ranges between 0 and the ratio of the second greatest dimension of the
bounding box to the greatest dimension."

Holger, from your message quoting the above, it looks like you consider the
texCoord field is no longer NULL once initial computation has occurred, and
thus eligible for recomputation.  Hmmm.

To avoid mixed expectations, perhaps we can add clarifications to above X3D4
prose.  What if we say something like the following suggestions:

*	(first sentence) "If the provided texCoord field is NULL, a default
texture coordinate mapping is calculated using the local coordinate system
bounding box of the initially provided shape."

*	(append after last sentence in paragraph quoted above) "If the
underly mesh is changed (number of coordinates, number of polygons, etc.)
then original texture coordinate mappings must be reapplied (if initial
texCoord field is provided) or else recomputed (if provided texCoord field
is NULL)."   

Any objections, or any improvements please?

Michalis, please advise if a similar issue might also occur in glTF and how
it might get handled.  Perhaps there is an omission in our updated X3D4
rendering-model parameters?

Other alternatives welcome.  TIA for considering completeness and
correctness to properly handle this important specification omission.

p.s. Request that we try to resolve the problem this week, so that it can be
recorded in Mantis and included in the upcoming X3D4 DIS specification
editors meeting.

all the best, Don

-- 

Don Brutzman  Naval Postgraduate School, Code USW/Br        brutzman at nps.edu

Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149

X3D graphics, virtual worlds, Navy robotics https://
faculty.nps.edu/brutzman

From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Holger Seelig
Sent: Wednesday, January 4, 2023 7:35 AM
To: Joseph D Williams <joedwil at earthlink.net>
Cc: X3D <x3d-public at web3d.org>
Subject: Re: [x3d-public] X3DCanvas vs x3d-canvas, X_ITE - conversion
stylesheet results

Hi Joe, but this is not what spec say, reading it strictly. Your approach
has some caveats. The text coords should be calculated once. But what
happens when the number of coords changes, or the num triangles or quads, or
polygons. It is no more easy to determine when the tex coords should be
regenerated.

Holger

Am 04.01.2023 um 16:06 schrieb Joseph D Williams <joedwil at earthlink.net
<mailto:joedwil at earthlink.net> >:

>> "The longest dimension of the bounding box defines the S coordinates, and
the next longest defines the T coordinates."

Hi Holger, I certainly agree with this, but not during animation. We would
use the default mapping once, for the default pose, then the same after
animation begins. Again, the way it is showing is a neat effect, but not
realistic, since the texture should stay mapped to the default pose, not
recomputed at each frame. 

Thanks, 

Joe

From: Holger Seelig <mailto:holger.seelig at yahoo.de> 
Sent: Tuesday, January 3, 2023 3:15 AM
To: X3D <mailto:x3d-public at web3d.org> 
Subject: Re: [x3d-public] X3DCanvas vs x3d-canvas,X_ITE - conversion
stylesheet results

X_ITE does exactly what is documented here
https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/component
s/geometry3D.html#f-IndexedFaceSettextureDefaultMapping to automatically
calculate tex coords.

>> "The longest dimension of the bounding box defines the S coordinates, and
the next longest defines the T coordinates."

In your example the longest dimension is as we can see the Y-axis, but the
next longest dimension will change when the IFS is animated, sometimes it is
the X-axis and sometimes it is the Z-axis. (You can see a flip)

Second, because the IFS is animated the tex coords will always change. (You
see the texture moving)

Here are the lines how X_ITE does the calc:
https://github.com/create3000/x_ite/blob/ad74f5212dae83c436bf0fc25eb4ac47130
1ae50/src/x_ite/Components/Rendering/X3DGeometryNode.js#L357

Please have a look at it. I cannot find a bug.

Best regards,

Holger

Am 02.01.2023 um 18:58 schrieb Joseph D Williams <joedwil at earthlink.net
<mailto:joedwil at earthlink.net> >:

Humanoid Animation X3D Examples Archive, Skin, Joe Skeleton Skin Site Salute
Walk (web3d.org)
<https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeSkelet
onSkinSiteSaluteWalkIndex.html> 

Notice how skin moves around with animations. 

I still think this is because browser does not honor textCoords, Do I need
to make a change to get this to work right when it works correctly in
others. As I recall from past, xite doesn't autogenerate texcoords and needs
repeat for every point? 

Thanks, 

Joe

From: Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu> 
Sent: Saturday, December 31, 2022 2:42 PM
To: Holger Seelig <mailto:holger.seelig at yahoo.de> 
Cc: X3D <mailto:x3d-public at web3d.org> 
Subject: Re: [x3d-public] X3DCanvas vs x3d-canvas,X_ITE - conversion
stylesheet results

[related topic:  upgrading "X3D to X_ITE" stylesheet, to match your
announcement]

Holger, thanks for all of the amazing work that you continue to accomplish.

After finishing much other work, I've finally been able to update the (newly
renamed) X3dToX3domX_ITE.xslt stylesheet to support your use of <x3d-canvas>
element.

Apologies for delays reaching this point.  The new version of X_ITE looks
good!

Hoping that you can confirm I'm using your publishing patterns correctly.
Might you please check HTML/CSS source for the following developmental
example.  If there are better ways of doing things please advise.

*	X3D Example Archives: Humanoid Animation, Skin, Joe Skeleton Skin
Site Salute Walk
*
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeSkeleto
nSkinSiteSaluteWalkIndex.html
*
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeSkeleto
nSkinSiteSaluteWalkX_ITE.html
*
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeSkeleto
nSkinSiteSaluteWalk_X_ITE.png

One thing I was not able to figure out. if you unzoom the
JoeSkeletonSkinSiteSaluteWalkX_ITE.html page (using 4-arrow button in upper
left) there is space for X_ITE Console, to appear as before in prior
version.  However this feature is no longer working.  Am happy to correct
it, or omit it, as appropriate.

         <div>

            <h3>X_ITE Console</h3>

            <p class="x_ite-console"/>

         </div>

Hmm, reviewing: another thing is that the stylesheet link is still there but
without apparent harm.  Will try removing that later.

Having fun with X_ITE, X3D and HTML5!  8)

all the best, Don

-- 

Don Brutzman  Naval Postgraduate School, Code USW/Br        brutzman at nps.edu
<mailto:brutzman at nps.edu> 

Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149

X3D graphics, virtual worlds, Navy robotics https://
faculty.nps.edu/brutzman <http://faculty.nps.edu/brutzman> 

-----Original Message-----
From: x3d-public <x3d-public-bounces at web3d.org
<mailto:x3d-public-bounces at web3d.org> > On Behalf Of Holger Seelig
Sent: Tuesday, November 1, 2022 8:04 AM
To: X3D <x3d-public at web3d.org <mailto:x3d-public at web3d.org> >
Subject: [x3d-public] X3DCanvas vs x3d-canvas, X_ITE

With version 6.0.0, X_ITE uses the new element name <x3d-canvas>, lowercase
and with dash. Because X_ITE uses the Custom Element API from JavaScript
now. This has the advantages that the element can be created with
document.createElement, and is then immediately ready to use :). Other
advantage is that the CSS file must not be included anymore.

For compatibility the old name can still be used, but we encourage all users
to update to the new tag name.

Best regards,

Holger

_______________________________________________

x3d-public mailing list

x3d-public at web3d.org <mailto: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/20230104/5807ff79/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5353 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230104/5807ff79/attachment-0001.p7s>