[x3d-public] MatrixTextureTransform node
Andreas Plesch
andreasplesch at gmail.com
Thu Oct 24 10:16:40 PDT 2019
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
More information about the x3d-public
mailing list