[x3d-public] MatrixTextureTransform node
Andreas Plesch
andreasplesch at gmail.com
Thu Oct 24 13:51:33 PDT 2019
> Date: Thu, 24 Oct 2019 19:25:41 +0200
> From: Holger Seelig <holger.seelig at googlemail.com>
> To: x3d-public at web3d.org
> Subject: Re: [x3d-public] MatrixTextureTransform node
> Message-ID: <adfacda1-5243-3e78-1dfd-9d6b2d038b2e at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> What about TextureTransformMatrix3D
> http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/texture3D.html#TextureTransformMatrix3D
That's it ! It just might make sense to get rid of the 3D reference
since it can also be used for 2d texture coordinates.
-Andreas
>
> Yes, very similar. Instead of center, translation, rotation and scale
> fields it has a single matrix SFMatrix4f field.
>
> Holger
>
>
> On 24.10.19 19:16, Andreas Plesch wrote:
> > Thanks for looking into this.
> >
> > On Thu, Oct 24, 2019 at 11:05 AM Brutzman, Donald (Don) (CIV)
> > <brutzman at nps.edu> wrote:
> >> Thanks Andreas for bringing this up and help us think it through fully.
> >>
> >> Wasn't able to find documentation at regular site. An example or two would be interesting as well.
> >>
> >> https://doc.x3dom.org/
> >> https://doc.x3dom.org/author/nodes.html
> > It looks like documentation builder does not pick up the new node.
> > Here is the readable source definition:
> > https://github.com/x3dom/x3dom/blob/master/src/nodes/Texturing/MatrixTextureTransform.js
> >
> >> Would MatrixTextureTransform functionality be similar to
> >>
> >> X3Dv4 Public Working Draft Specification
> >> 18.4.10 TextureTransform
> >> http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/texturing.html#TextureTransform
> >>
> > Yes, very similar. Instead of centre, translation, rotation and scale
> > fields it has a single matrix SFMatrix4f field.
> >
> >> Also wondering if any variants of MatrixTextureTransform node are appropriate for 3D textures? Presumably MultiTextureTransform is already sufficient.
> >>
> >> 18.4.5 MultiTextureTransform
> >> http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/texturing.html#MultiTextureTransform
> > MultitextureTransform can use any X3DTextureTransform type. It would
> > not be affected by introducing a new X3DTextureTransform node type.
> > It would not be sufficient by itself to allow for use of a matrix
> > value.
> >
> >> presumably MatrixTextureTransform would inherit from badge interface
> >>
> >> 18.3.4 X3DTextureTransformNode
> >> http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/texturing.html#X3DTextureTransformNode
> > Yes.
> >
> >> In general X3D specification development has avoided transformation matrices, only offering occasional access. So a crisp use case would help, and also a rationale if we think that some animation or modification or sharing of assets within glTF models might occur. Sometimes building an X3D prototype can help illustrate potential use and offer an example implementation as well.
> > The use case is really only gltf support by translation into x3d, for
> > now. gltf uses a different convention for texture transforms which
> > cannot be translated into a regular x3d TextureTransform node. See
> > below for details. So for translation purposes it becomes necessary to
> > introduce another type of texture transform node. A node which accepts
> > matrix values directly works fine for this purpose since the matrix
> > can be computed at the translation step. It also is of general value.
> > Allowing a 4x4 matrix would make it applicable to 3D texture
> > coordinates as well.
> >
> > It would be possible to keep the translation process internal to the
> > browser and not expose it. But internally a browser implementation
> > would have to go through the same procedures. So why not expose it ?
> >
> > This is similar to the situation of Transform and MatrixTransform
> > which also every browser already needs to support internally but which
> > is currently not exposed in the spec. So the reasons for not exposing
> > a MatrixTransform presumably would apply also to
> > MatrixTextureTransform. But I do not know what these reasons may be ?
> > Exotic values in the provided matrix ?
> >
> > It is convoluted to build a prototype since it would requires
> > decomposing a matrix into translation, scale, rotation components, to
> > pass on to a regular TextureTransformNode. (The browser would then
> > just multiply those components back together to the matrix which was
> > the input to begin with).
> >
> > The arguments against such a node would be presumably the same
> > arguments which were probably discussed for MatrixTransform.
> >
> > The argument for having a MatrixTextureTransform node would be that it
> > is effectively required for glTF support. Not exposing it for public
> > consumption may mean additional code in many browser. It should be
> > very easy to implement.
> >
> > -Andreas
> >
> > Here is how a gltf texture transform matrix is computed from its
> > offset, rotation, and scale values:
> >
> > negCenter = new x3dom.fields.SFVec3f(-0, -0, 0); // in case of a
> > future gltf pivot
> > posCenter = new x3dom.fields.SFVec3f(0, 0, 0);
> >
> > trans3 = new x3dom.fields.SFVec3f(offset[0], offset[1], 0);
> > scale3 = new x3dom.fields.SFVec3f(scale[0], scale[1], 0);
> >
> > trafo =
> > x3dom.fields.SFMatrix4f.translation(posCenter.add(trans3)).
> > mult(x3dom.fields.SFMatrix4f.rotationZ(rotation * -1.0)).
> > mult(x3dom.fields.SFMatrix4f.scale(scale3)).
> > mult(x3dom.fields.SFMatrix4f.translation(negCenter)); // center is not
> > used in gltf
> >
> > This contrasts with how a x3d texture transform matrix is computed:
> >
> > negCenter = new x3dom.fields.SFVec3f(-this._vf.center.x, -this._vf.center.y, 0);
> > posCenter = new x3dom.fields.SFVec3f(this._vf.center.x, this._vf.center.y, 0);
> > trans3 = new x3dom.fields.SFVec3f(this._vf.translation.x,
> > this._vf.translation.y, 0);
> > scale3 = new x3dom.fields.SFVec3f(this._vf.scale.x, this._vf.scale.y, 0);
> >
> > trafo =
> > x3dom.fields.SFMatrix4f.translation(negCenter).
> > mult(x3dom.fields.SFMatrix4f.scale(scale3)).
> > mult(x3dom.fields.SFMatrix4f.rotationZ(this._vf.rotation)).
> > mult(x3dom.fields.SFMatrix4f.translation(posCenter.add(trans3)));
> >
> >
> >> If it looks like a candidate addition, then let's go ahead and add it to the Mantis issues list so that final prose/examples/implementation can be reviewed and documented 1Q2020 as we finalize X3Dv4.0 specification. Looking forward to learning more.
> >>
> >>
> >> On 10/21/2019 12:01 PM, Andreas Plesch wrote:
> >>> x3dom introduced a MatrixTextureTransform node in the Texturing
> >>> component, mostly to support glTF to x3d translation since gltf allows
> >>> for such a texture coordinate transform matrix. It accepts a 2x2
> >>> matrix which is the equivalent of the transformation matrix resulting
> >>> from the scale and rotation of a regular TextureTransform node.
> >>>
> >>> Such a node is more convenient than decomposing a provided matrix to
> >>> use in a regular TransformMatrix node, only to then recalculate the
> >>> matrix from the components when the actual texture coordinates are
> >>> computed.
> >>>
> >>> glTF support will make this node very desirable but I am not sure if
> >>> other browser have something similar already.
> >>>
> >>> -Andreas
> >>
> >> 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 http://faculty.nps.edu/brutzman
> >
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
> --
> Holger Seelig
> Digital Media Designer
>
> Scheffelstra?e 31a
> 04277 Leipzig
> Germany
>
> Cellular: +49 176 420 479 37
> E-Mail: holger.seelig at create3000.de
> Web: http://create3000.de
>
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 127, Issue 58
> *******************************************
--
Andreas Plesch
Waltham, MA 02453
More information about the x3d-public
mailing list