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

Thu Jan 5 14:13:19 PST 2023

My primary software works for modifying vertexes and normals in the
shader.  I do hope this is not changed, otherwise, there might be
significant changes to my code.  What I’m really hoping for is PBR Next
implemented in X3D engines and X3D standard (4.1).  I do realize these
features may not be supported in older graphics cards.  What i can do is
version my code once X3D revs 1-2 times.  I do hope that X3D vendors
continue to upgrade PBR beyond initial implementations.

Thanks!

John

On Wed, Jan 4, 2023 at 11:41 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> 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/JoeSkeletonSkinSiteSaluteWalkX_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 <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 <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/components/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/ad74f5212dae83c436bf0fc25eb4ac471301ae50/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
> >:
>
> >
>
> > 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
>
> > keletonSkinSiteSaluteWalkIndex.html
>
> > https://www.web3d.org/x3d/content/examples/HumanoidAnimation/Skin/JoeS
>
> > keletonSkinSiteSaluteWalkX_ITE.html
>
> > 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
> 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 Holger
>
> > Seelig
>
> > Sent: Tuesday, November 1, 2022 8:04 AM
>
> > To: X3D <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
>
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> >
>
> >
>
> > _______________________________________________
>
> > x3d-public mailing list
>
> > x3d-public at web3d.org
>
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> _______________________________________________
> x3d-public mailing list
> 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/20230105/9393eb89/attachment-0001.html>