[x3d-public] X3DCanvas vs x3d-canvas, X_ITE - conversion stylesheet results; X3D4 specification rendering issue: recomputation of browser-computed texture coordinates when animating meshes?

Wed Jan 4 11:20:53 PST 2023

Sounds good on all counts.  Not trying to add unplanned/burdensome work.
Had assumed that zero-time computation of texture coordinates might be
accessible by view3dscene but can see where that might be inaccessible in
GPU.

If there is a good way to get texture coordinates into the example archives
that someone wants to pursue, will do so.

Have created Mantis issue for prose changes to X3D4 DIS document.  All
improvements always welcome.  Thanks for rapid resolution on this one.

*	Mantis 1418: Ambiguity about texture coordinate generation
*	https://www.web3d.org/member-only/mantis/view.php?id=1418
*	Description.  Lack of clarity on texture coordinate generation led
to mixed expectations and inconsistent rendering of HAnim skin model by
multiple browsers. Extended email thread discusses issues and alternatives.
*	3DCanvas vs x3d-canvas, X_ITE - conversion stylesheet results
*	X3D4 specification rendering issue: recomputation of
browser-computed texture coordinates when animating meshes?
*
http://web3d.org/pipermail/x3d-public_web3d.org/2023-January/018158.html
*	Essence: texture coordinates get regenerated (by GPU) when meshes
are animated, even if morphology is unchanged. Thus authors need to provide
TextureCoordinate values for consistent texture rendering (for example,
humanoids). Specification clarification can help.

Suggested specification clarifications:

. X3D4, Texturing component, 18.2.3 Texture coordinates
.
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/
components/texturing.html#TextureCoordinates
. "Texture coordinates are reapplied or else recomputed (if initially NULL)
whenever the corresponding vertex-based geometry changes."

Similarly add to
. X3D4, Texturing component, 18.4.8 TextureCoordinateGenerator
.
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/
components/texturing.html#TextureCoordinateGenerator

Suggest adding authoring tooltips as well:

. author wants texture to stick -> map texture coordinates in Blender,

. author wants the texture to move -> start with texCoord NULL, rely on X3D
texture generation at runtime

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

-----Original Message-----
From: Michalis Kamburelis <michalis.kambi at gmail.com> 
Sent: Wednesday, January 4, 2023 10:23 AM
To: Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
Cc: Holger Seelig <holger.seelig at yahoo.de>; X3D <x3d-public at web3d.org>;
puk at igraphics.com
Subject: Re: [x3d-public] X3DCanvas vs x3d-canvas, X_ITE - conversion
stylesheet results; X3D4 specification rendering issue: recomputation of
browser-computed texture coordinates when animating meshes?

NPS WARNING: *external sender* verify before acting.

Thanks Don,

I understand we are aligned then -- and consider the current
X_ITE/view3dscene/CGE/InstantReality approach to be correct then.

And for Joe testcase, the resolution is just that (if you want texture to
"stick") then explicit texture coordinates should be specified, using
TextureCoordinate.

( Otherwise, I admit I wanted to object to your earlier suggestion -- I
think it would be harder to specify exactly when to recalculate and when not
to. And then we go into discussion how does it interact with
TextureCoordinateGenerator, whether it is doable on GPU etc. So it's better
to keep it simple, as it is now. )

I'm cool with your proposed clarification sentence """Texture coordinates
are reapplied or else recomputed (if initially NULL) whenever the
corresponding vertex-based geometry changes.""".

Moreover, I would advise adding the same sentence to
TextureCoordinateGenerator prose,
<https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01
/components/texturing.html#TextureCoordinateGenerator>
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/Part01/
components/texturing.html#TextureCoordinateGenerator

, to make it clear that the situation is consistent for it.

Note that glTF doesn't have an equivalent feature, so we don't need to worry
about glTF here. In glTF, texture coordinates have to be always provided if
you want to render the texture. There's no automatic recalculation. So they
kind of avoided the whole issue :)

As for feature idea "might precomputation and addition of texture
coordinates be an option in your converter?" -- hmm, it is definitely
sensible and I see it would be useful (like in this case for Joe humanoid).
But I admit it is not trivial -- because we don't actually do such
calculation now on CPU, that is in CGE we *do not* at any point calculate
automatic texture coordinates on CPU. If the automatic coordinates are
needed (following bounds of shape, or following

TextureCoordinateGenerator) they are just calculated during rendering on
GPU, and we don't really save them anywhere (right now). So, it is certainly
possible but would be quite some additional work to add "precalculating
texture coords".

Regards,

Michalis

śr., 4 sty 2023 o 18:41 Brutzman, Donald (Don) (CIV) <
<mailto:brutzman at nps.edu> brutzman at nps.edu> napisał(a):

> 

> Michalis, apologies our mail crossed.  Thanks for excellent and thorough
explanation.

> 

> 

> 

> Am keen to keep things aligned as you and Holger (two leading
implementers) think best.

> 

> 

> 

> Wondering:  are there any further clarifications to add to specification,
preventing ambiguous interpretation?  For example, perhaps adding a
sentence:

> 

> X3D4, Texturing component, 18.2.3 Texture coordinates 

>  <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/P>
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-DIS/P

> art01/components/texturing.html#TextureCoordinates

> "Texture coordinates are reapplied or else recomputed (if initially NULL)
whenever the corresponding vertex-based geometry changes."

> 

> 

> 

> Also wondering: might precomputation and addition of texture coordinates
be an option in your converter?  Given continued inconsistencies of Blender
export to X3D, this might be especially helpful as we try to achieve
consistent X3D browser rendering for advanced HAnim skin examples. If that
is possible, Joe and I will be happy to update texture coordinates and test
relevant X3D HumanoidAnimation example models accordingly.

> 

> 

> 

> Castle Game Engine: Convert everything to X3D

>  <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcast>
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcast

> le-engine.io%2Fconvert.php&data=05%7C01%7Cbrutzman%40nps.edu%7Cc4001e2

> 8d11f40f5b4d908daee80c9c9%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7

> C638084535500659347%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj

> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=n4J1G4p

> S2ysIgvYTIMrWED2YcVxixBd80VH7uWrZtsg%3D&reserved=0

> 

> 

> 

> HumanoidAnimation (HAnim) X3D Examples Archive 

>  <https://www.web3d.org/x3d/content/examples/HumanoidAnimation>
https://www.web3d.org/x3d/content/examples/HumanoidAnimation

> 

> 

> 

> all the best, Don

> 

> --

> 

> Don Brutzman  Naval Postgraduate School, Code USW/Br
<mailto:brutzman at nps.edu> 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

> 

> 

> 

> -----Original Message-----

> From: x3d-public < <mailto:x3d-public-bounces at web3d.org>
x3d-public-bounces at web3d.org> On Behalf Of Michalis 

> Kamburelis

> Sent: Wednesday, January 4, 2023 8:00 AM

> To: Holger Seelig < <mailto:holger.seelig at yahoo.de>
holger.seelig at yahoo.de>

> Cc: X3D < <mailto:x3d-public at web3d.org> x3d-public at web3d.org>

> Subject: Re: [x3d-public] X3DCanvas vs x3d-canvas, X_ITE - conversion 

> stylesheet results

> 

> 

> 

> view3dscene and Castle Game Engine recompute the texture coordinates 

> at runtime, potentially each frame. Which, as I understand, is also 

> what X_ITE does. Testing with latest view3dscene 

> ( <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcas>
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcas

> tle-engine.io%2Fview3dscene.php&data=05%7C01%7Cbrutzman%40nps.edu%7Cc4

> 001e28d11f40f5b4d908daee80c9c9%7C6d936231a51740ea9199f7578963378e%7C0%

> 7C0%7C638084535500659347%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL

> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=Rq

> DTOnHc8UciVQXIjFK58oeNq%2BpJutc%2BN39MjSfGHDY%3D&reserved=0), our 

> results match X_ITE on 

>  <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeS>
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeS

> keletonSkinSiteSaluteWalkX_ITE.html

> 

> .

> 

> 

> 

> In short I think that

> 

> 

> 

> - view3dscene, Castle Game Engine and X_ITE are all correct with respect
to spec here. We had this discussion 11 years ago already (see thread
"Announcement: view3dscene 3.8.0" in your MUAs). From what I recall, back
then I also confirmed that InstantReality on desktop also recalculates
texture coordinates. But BS Contact did it differently.

> 

> 

> 

> - I think this is a sensible behavior in general, see below why. I see it
doesn't match what Joe expected in this case, but IMHO the resolution is
just "you should assign texture coordinates explicitly if you want them to
stick, i.e. use TextureCoordinate".

> 

> 

> 

> Details:

> 

> 

> 

> The texture generation based on bbox is treated by view3dscene/CGE as 

> just an implicit use of TextureCoordinateGenerator, with 

> mode="BOUNDS", see

> 

>
<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-en
gine.io%2Fx3d_implementation_texturing_extensions.php%23section_ext_tex_coor
d_bounds&data=05%7C01%7Cbrutzman%40nps.edu%7Cc4001e28d11f40f5b4d908daee80c9c
9%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638084535500659347%7CUnknown%
7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3D%7C2000%7C%7C%7C&sdata=V2oSgV2XZLymTojwktvP1Gste%2B8U6xoaO0cwWUxnQKs%3D&
reserved=0>
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-eng
ine.io%2Fx3d_implementation_texturing_extensions.php%23section_ext_tex_coord
_bounds&data=05%7C01%7Cbrutzman%40nps.edu%7Cc4001e28d11f40f5b4d908daee80c9c9
%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638084535500659347%7CUnknown%7
CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
%3D%7C2000%7C%7C%7C&sdata=V2oSgV2XZLymTojwktvP1Gste%2B8U6xoaO0cwWUxnQKs%3D&r
eserved=0. And TextureCoordinateGenerator can change coordinates at each
frame.

> 

> The idea is that such texture generation can be done on GPU, right at
rendering, so yes -- it can change each frame and this is a feature.

> 

> 

> 

> If you want the texture coordinates to stay unchanged, then just generate
texture coordinates in your authoring tool. This is a normal workflow in my
experience, artists routinely UV unwrap and assign textures this way to
characters. 3D artists do not really depend on automatic texture generation
at all in my experience, they also assign texture coordinates explicitly in
Blender or such.

> 

> 

> 

> I'm not saying this is some final decision, but I'm saying this ("texture
generation happens each frame, and may be done on GPU right at rendering")
is how I understood the X3D spec and I think it makes sense. This way
texture generation in X3D is a nice feature for some use-cases (if model is
static, or if you want the texture to "flow").

> 

> If you want the texture to "stick", then you should just assign texture
coordinates in 3D authoring tool, like in normal 3D workflow.

> 

> 

> 

> If we really want to (but I would discourage from it) we could change X3D
spec to have a different behavior, but in this case the X3D spec would
really have to be precise *when* should texture generation to be recomputed
(at start? and/or caused by some input events?), how it is related to
TextureCoordinateGenerator. Holger in last mail raised correct points --
they are some moments when you *have* to recompute the coordinates (like
when number of points changes) anyway. Trying to specify when to recompute,
and when not to recompute, feels like a "Pandora's box". Better to follow
what we have now, and just say "they can be recomputed at each frame".

> 

> 

> 

> So making the texture generation only at certain moments

> 

> 

> 

> - is an additional work for X3D browsers, where they cannot use GPU 

> (easily),

> 

> 

> 

> - is a work that duplicates what typically 3D authoring tools, like
Blender, are doing.

> 

> 

> 

> So,

> 

> 

> 

> - you want the texture to stick -> map texture in Blender,

> 

> 

> 

> - you want the texture to move -> rely on X3D texture generation at
runtime.

> 

> 

> 

> Regards,

> 

> Michalis

> 

> 

> 

> śr., 4 sty 2023 o 16:35 Holger Seelig < <mailto:holger.seelig at yahoo.de>
holger.seelig at yahoo.de> napisał(a):

> 

> >

> 

> > 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 <
<mailto:joedwil at earthlink.net> 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

> 

> > Sent: Tuesday, January 3, 2023 3:15 AM

> 

> > To: X3D

> 

> > 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/componen
ts/geometry3D.html#f-IndexedFaceSettextureDefaultMapping>
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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi>
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi

> > thub.com%2Fcreate3000%2Fx_ite%2Fblob%2Fad74f5212dae83c436bf0fc25eb4a

> > c471301ae50%2Fsrc%2Fx_ite%2FComponents%2FRendering%2FX3DGeometryNode

> > .js%23L357&data=05%7C01%7Cbrutzman%40nps.edu%7Cc4001e28d11f40f5b4d90

> > 8daee80c9c9%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C63808453550

> > 0659347%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi

> > LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=j17qg0%2BKHyovN

> > gYqxKloJ6NnwGZVM%2BR%2B7dRHLgp3KsM%3D&reserved=0

> 

> >

> 

> > 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 <
<mailto:joedwil at earthlink.net> joedwil at earthlink.net>:

> 

> >

> 

> > Humanoid Animation X3D Examples Archive, Skin, Joe Skeleton Skin 

> > Site

> 

> > Salute Walk (web3d.org)

> 

> >

> 

> > 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 thisto 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)

> 

> > Sent: Saturday, December 31, 2022 2:42 PM

> 

> > To: Holger Seelig

> 

> > Cc: X3D

> 

> > 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/Jo>
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/Jo

> > eS

> 

> > keletonSkinSiteSaluteWalkIndex.html

> 

> >  <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/Jo>
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/Jo

> > eS

> 

> > keletonSkinSiteSaluteWalkX_ITE.html

> 

> >  <https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/Jo>
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/Jo

> > eS

> 

> > keletonSkinSiteSaluteWalk_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
<mailto:brutzman at nps.edu> 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

> 

> >

> 

> > -----Original Message-----

> 

> > From: x3d-public < <mailto:x3d-public-bounces at web3d.org>
x3d-public-bounces at web3d.org> On Behalf Of Holger

> 

> > Seelig

> 

> > Sent: Tuesday, November 1, 2022 8:04 AM

> 

> > To: X3D < <mailto:x3d-public at web3d.org> 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

> 

> >  <mailto:x3d-public at web3d.org> x3d-public at web3d.org

> 

> >  <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

> 

> >

> 

> >

> 

> > _______________________________________________

> 

> > x3d-public mailing list

> 

> >  <mailto:x3d-public at web3d.org> x3d-public at web3d.org

> 

> >  <http://web3d.org/mailman/listinfo/x3d-public_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/cb6e418c/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/cb6e418c/attachment-0001.p7s>