[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:38:58 PST 2023

As a developer, i agree that normal and vector geometry (not mesh indexes)
should be done on the CPU.  On older systems <= 2016, modifying mesh vertex
coordinates (from spheres or primarily IFS) is otherwise performance
inhibited, at least on my 100x100 grids.  Computing in the shader works
great in browser, as shown with PlayCanvas and non-standard subdivisions in
X3DOM.  We probably shouldn’t be setting or modifying the vertices or
normals in CPU.  Yes, we should be laying out indexes and mesh connections
in the CPU, especially when mesh connections change.

Note:  I am not talking about texture at this point, since existing
textures in my programs are provided by fragment shaders and cube maps
(after any vertex manipulation).   I don’t know how to do X3D texture
coordinated at all.  Indeed, I don’t really know how the fragment shader is
working.  All i know is, the fragment shader and vertex shader work great.
My goal is primarily ray tracing or ray marching, etc.

I hope people understand my prose.

John

On Wed, Jan 4, 2023 at 12:24 PM Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

> 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
> , 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)
> <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/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/3cdef092/attachment-0001.html>