[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 09:41:01 PST 2023

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/Part01/
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://castle-engine.io/convert.php

*	HumanoidAnimation (HAnim) X3D Examples Archive
*	https://www.web3d.org/x3d/content/examples/HumanoidAnimation

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: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Michalis
Kamburelis
Sent: Wednesday, January 4, 2023 8:00 AM
To: Holger Seelig <holger.seelig at yahoo.de>
Cc: X3D <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://castle-engine.io/view3dscene.php), our results match X_ITE on
<https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeSkelet
onSkinSiteSaluteWalkX_ITE.html>
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeSkeleto
nSkinSiteSaluteWalkX_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://castle-engine.io/x3d_implementation_texturing_extensions.php#section
_ext_tex_coord_bounds. 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://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 <
<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/JoeS>
https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeS

> keletonSkinSiteSaluteWalkIndex.html

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

> keletonSkinSiteSaluteWalkX_ITE.html

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

> 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/96d9cf2c/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/96d9cf2c/attachment-0001.p7s>