[x3d-public] wondering about Texture mapping specified in material nodes [corrected]
Don Brutzman
brutzman at nps.edu
Sat Sep 19 07:59:57 PDT 2020
Preliminary 1: can you please label your examples and counterexamples A B C D or somesuch so that we can refer to them effectively.
Preliminary 2: we need to place high priority on getting the full suite of examples available publicly. This is necessary for anyone checking the specification.
Preliminary 3: you also need to provide a precise definition of "mapping" field, not finding it anywhere in PhysicalMaterial or
[1] X3D Architecture 12.4.6 PhysicalMaterial
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#PhysicalMaterial
[2] 12.2.4 Texture mapping specified in material nodes
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#TextureMapping
A better way to think about what I proposed before is not to focus solely on DEF/USE, rather first focus on the use of explicit field names to define relationships. More below...
On 9/19/2020 1:59 AM, Michalis Kamburelis wrote:
> The approaches do not have the same expressive power.
> - When we connect material with geometry with a named (SFString) mapping, a different geometry may use a different texture coordinate node, but specify the same mapping name.
>
> So the material and geometry are separable in this case. The mapping is not a way to assign global identifiers to nodes, the mapping is only resolved within each Shape, this is critical.
Am OK with the requirements you are posing, and think that explicit field names can accomplish the same relationships with the flexibility you are seeking.
> This example is shown on
> https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use . It's where I show how to reuse material or appearance with the same geometry.
The nodes utilized in those Appearance structures are the same as yours, just labeled in a different manner.
It is difficult to transcribe your example unambiguously because the node instances don't have DEF names.
Here is a verbatim copy of your helpful initial "deliberately complicated" example:
================================================================
# Version 1-original
Shape {
appearance DEF MyAppearance Appearance {
material DEF MyMaterial Material {
diffuseTexture ImageTexture { url "diffuse.png" }
diffuseTextureMapping "diffuse-and-normal-mapping"
normalTexture ImageTexture { url "normal-map.png" }
normalTextureMapping "diffuse-and-normal-mapping"
specularTexture ImageTexture { url "specular.png" }
specularTextureMapping "specular-mapping"
}
textureTransform MultiTextureTransform {
textureTransform [
TextureTransform {
mapping "diffuse-and-normal-mapping"
translation 0.5 0.5
}
TextureTransform {
mapping "specular-mapping"
translation 0.1 0.1
}
]
}
}
geometry DEF MyMesh IndexedFaceSet {
coordIndex [ 0 1 2 3 ]
coord Coordinate {
point [
0 0 0,
1 0 0,
1 1 0,
0 1 0,
]
}
texCoord MultiTextureCoordinate {
texCoord [
TextureCoordinate {
mapping "diffuse-and-normal-mapping"
point [
0 0,
4 0,
4 4,
0 4,
]
}
TextureCoordinate {
mapping "specular-mapping"
point [
0.1 0,
40 0,
4 40,
0 4,
]
}
]
}
}
}
================================================================
Here is a slightly edited (but exactly equivalent) copy of your deliberately complicated example in ClassicVRML Encoding, solely adding DEF identifiers and subtracting extraneous point fields. Hoping this will enable definition of unambiguous alternative representations.
================================================================
# Version 2-original-labeled
Shape {
appearance DEF MyAppearance Appearance {
material DEF MyMaterial Material {
diffuseTexture ImageTexture { url "diffuse.png" }
diffuseTextureMapping "diffuse-and-normal-mapping"
normalTexture ImageTexture { url "normal-map.png" }
normalTextureMapping "diffuse-and-normal-mapping"
specularTexture ImageTexture { url "specular.png" }
specularTextureMapping "specular-mapping"
}
textureTransform DEF MULTITEXTURETRANSFORM_1 MultiTextureTransform {
textureTransform [
DEF TEXTURETRANSFORM_2 TextureTransform {
mapping "diffuse-and-normal-mapping"
translation 0.5 0.5
}
DEF TEXTURETRANSFORM_3 TextureTransform {
mapping "specular-mapping"
translation 0.1 0.1
}
]
}
}
geometry DEF MyMesh IndexedFaceSet {
coordIndex [ 0 1 2 3 ]
coord DEF COORDINATE_4 Coordinate {}
texCoord DEF MULTITEXTURECOORDINATE_5 MultiTextureCoordinate {
texCoord [
DEF TEXTURECOORDINATE_6 TextureCoordinate {
mapping "diffuse-and-normal-mapping"
}
DEF TEXTURECOORDINATE_7 TextureCoordinate {
mapping "specular-mapping"
}
]
}
}
}
================================================================
Here is my attempt at a functionally equivalent representation, using explicitly named fields rather than mapping labels. I moved geometry field first to proceed appearance field and maintain closest correspondence to your example.
================================================================
# Version 3-fieldnames-verbose
Shape {
geometry DEF MyMesh IndexedFaceSet {
coordIndex [ 0 1 2 3 ]
coord DEF COORDINATE_4 Coordinate { }
texCoord DEF MULTITEXTURECOORDINATE_5 MultiTextureCoordinate {
texCoord [
DEF TEXTURECOORDINATE_6 TextureCoordinate {
# mapping "diffuse-and-normal-mapping"
}
DEF TEXTURECOORDINATE_7 TextureCoordinate {
# mapping "specular-mapping"
}
]
}
}
appearance DEF MyAppearance Appearance {
material DEF MyMaterial Material {
diffuseTexture ImageTexture { url "diffuse.png" }
normalTexture ImageTexture { url "normal-map.png" }
specularTexture ImageTexture { url "specular.png" }
# diffuseTextureMapping "diffuse-and-normal-mapping"
# normalTextureMapping "diffuse-and-normal-mapping"
# specularTextureMapping "specular-mapping"
# }
# textureTransform DEF MULTITEXTURETRANSFORM_1 MultiTextureTransform {
# textureTransform [
diffuseTextureTransform DEF TEXTURETRANSFORM_2 TextureTransform {
# mapping "diffuse-and-normal-mapping"
translation 0.5 0.5
}
normalTextureTransform USE TEXTURETRANSFORM_2
specularTextureTransform DEF TEXTURETRANSFORM_3 TextureTransform {
# mapping "specular-mapping"
translation 0.1 0.1
}
diffuseTextureCoord USE TEXTURECOORDINATE_6
normalTextureCoord USE TEXTURECOORDINATE_6
specularTextureCoord USE TEXTURECOORDINATE_7
# ]
}
}
}
================================================================
Seems like omitting the use of MULTITEXTURETRANSFORM_1 was a key step here. If you really want a MULTITEXTURETRANSFORM_1 as a container somewhere then OK, we could certainly define it before or after with DEF/USE.
If we've gotten this far, then subtracting correlation comments and subtracting extraneous fields and consistently indenting is interesting too:
================================================================
# Version 4-fieldnames-terse
Shape {
geometry DEF MyMesh IndexedFaceSet {
coord DEF COORDINATE_4 Coordinate { }
texCoord DEF MULTITEXTURECOORDINATE_5 MultiTextureCoordinate {
texCoord [
DEF TEXTURECOORDINATE_6 TextureCoordinate {}
DEF TEXTURECOORDINATE_7 TextureCoordinate {}
]
}
}
appearance DEF MyAppearance Appearance {
material DEF MyMaterial Material {
diffuseTexture ImageTexture { url "diffuse.png" }
normalTexture ImageTexture { url "normal-map.png" }
specularTexture ImageTexture { url "specular.png" }
diffuseTextureTransform DEF TEXTURETRANSFORM_2 TextureTransform {}
normalTextureTransform USE TEXTURETRANSFORM_2
specularTextureTransform DEF TEXTURETRANSFORM_3 TextureTransform {}
diffuseTextureCoord USE TEXTURECOORDINATE_6
normalTextureCoord USE TEXTURECOORDINATE_6
specularTextureCoord USE TEXTURECOORDINATE_7
}
}
}
================================================================
So I think that matches yours. Please check.
Again, order of geometry and appearance fields might be easily swapped/rearranged. The preceding form seems closest to your example.
I hope this example gets us closer and is indeed functionally equivalent. If so, then hopefully it leads us on a clearer path so that "mapping" field might be avoided as an X3D scene graph construct, without breaking the underlying connections needed by implementers using glTF.
Triple-checking field names, here is proposed field signature for PhysicalMaterial (slightly refined from previous version):
============================================
PhysicalMaterial : X3DOneSidedMaterialNode {
SFColor [in,out] baseColor 1 1 1 [0,1]
SFNode [in,out] baseTexture NULL [X3DSingleTextureNode]
SFNode [in,out] baseTexCoord NULL [X3DSingleTextureCoordinateNode]
SFNode [in,out] baseTextureTransform NULL [X3DSingleTextureTransformNode]
SFFloat [in,out] metallic 1 [0,1]
SFNode [in,out] metallicTexture NULL [X3DSingleTextureNode]
SFNode [in,out] metallicTexCoord NULL [X3DSingleTextureCoordinateNode]
SFNode [in,out] metallicTextureTransform NULL [X3DSingleTextureTransformNode]
SFColor [in,out] emissiveColor 0 0 0 [0,1]
SFNode [in,out] emissiveTexture NULL [X3DSingleTextureNode]
SFNode [in,out] emissiveTexCoord NULL [X3DSingleTextureCoordinateNode]
SFNode [in,out] emissiveTextureTransform NULL [X3DSingleTextureTransformNode]
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFFloat [in,out] normalScale 1 [0, ∞]
SFNode [in,out] normalTexture NULL [X3DSingleTextureNode]
SFNode [in,out] normalTexCoord NULL [X3DSingleTextureCoordinateNode]
SFNode [in,out] normalTextureTransform NULL [X3DSingleTextureTransformNode]
SFFloat [in,out] occlusionStrength 1 [0,1]
SFNode [in,out] occlusionTexture NULL [X3DSingleTextureNode]
SFNode [in,out] occlusionTexCoord NULL [X3DSingleTextureCoordinateNode]
SFNode [in,out] occlusionTextureTransform NULL [X3DSingleTextureTransformNode]
SFFloat [in,out] roughness 1 [0,1]
SFFloat [in,out] transparency 0 [0,1]
}
============================================
If we are converging, then identical field pattern for PhysicalMaterial above would be similarly applied to Material and UnlitMaterial in X3D4 specification.
> It is also closest to what glTF is doing where it has attribute names like TEXCOORD0 .
If the explicit field name approach works with equivalent expressive power, then of course an implementation will need its own internal housekeeping (node id naming convention) when invoking gltf.
> - If we would place texture coordinate in material, as you propose, then material and geometry would be unseparable. I show example how that would make further reusing of materials on that wiki page.
>
> Regards,
> Michalis
Thanks for patient perseverance, by all of us. This is a worthy endeavor, even with clock ticking fast. Getting best answer for long term has great value.
p.s. "Decide in haste, repent at leisure!" :0
> W dniu sob., 19.09.2020 o 03:19 Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> napisał(a):
>
> OK thanks but... I read that in detail and am still not convinced.
>
>
>
> The explicit approach of named fields that I spelled out has the same expressive power as the indirect mapping-label approach in your writeup.
>
>
>
> It would also appear that the indirect mapping-label approach has the exact same limitation you describe. Yes a combination is inseparable. Yes any DEF and be re-USED but without changing the node in question. Yes if you have that same parent-child information in a label field, it is inseparable.
>
>
>
> Given the flexibility of node children DEF/USE it seems like slight variations and combinations are just as possible as they are now inside all them many nodes which might comprise a Shape.
>
>
>
> I looked at your writeup once again but am still not seeing the unreachable use case. A texture node with a pair of explicit accompanying fields (e.g. baseColorTexture, baseColorTextureCoordinate, baseColorTextureTransform) has the exact same information as those same 3 nodes sharing a common label.
>
>
>
> If the same information is present either way, then both are possible or both are impossible.
>
>
>
> Labels are very error prone, difficult to validate and not how X3D usually works. That is why other approach seems more appealing.
>
>
>
> If the information about node relationships is indeed different, then let's get clear why you think so.
>
>
>
> If information is the same, then we might restart from the other direction . Can you please show what you think is a simple adequate glTF case and represent that. Let's focus on once subset first, for example.
>
>
>
> The correlations between declarative and imperative can be subtle/confusing sometimes. Am hoping that we can sort it out satisfactorily for best long-term representations.
>
>
>
> Thanks for persisting on this design issue, looking forward to complete clarity on this matter.
>
>
>
>
>
>
>
> On 9/18/2020 5:57 PM, Michalis Kamburelis wrote:
>
> > NPS WARNING: *external sender* verify before acting.
>
> >
>
> > This is exactly addressed in the long answer I wrote and linked previously on
>
> > https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use . I analyze there something even more flexible than what you propose, but still find it failing.
>
> >
>
> > Simply put, adding texture coordinate nodes to materials would mean that reusing materials / appearances is impossible. Geometry with the accompanying material / appearance would be an unseparable set. This would break an important usecase of reusing (important, because common in practice and also very useful for browsers to optimize rendering and resource loading). It would also be contrary to how materials and meshes are separated in all other graphic formats (glTF, Collada, even OBJ, even x3d 3) and software (Blender, Unity, 3dsMax ..)
>
> >
>
> > Regards,
>
> > Michalis
>
> >
>
> > W dniu sob., 19.09.2020 o 02:00 Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>>> napisał(a):
>
> >
>
> > [corrected copy follows, apologies for prior send]
>
> >
>
> >
>
> >
>
> > * X3D Architecture 12.4.6 PhysicalMaterial
>
> >
>
> > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#PhysicalMaterial
>
> >
>
> >
>
> >
>
> > 1. The current "mapping" approach seems like a new/involved approach technique that adds a layer of indirection.
>
> >
>
> >
>
> >
>
> > Why not a simpler design pattern similar to the rest of the scene graph?
>
> >
>
> >
>
> >
>
> > Instead of a (bitmap) texture plus a string label for "mapping" that must appear identically on 2 additional nodes,
>
> >
>
> >
>
> >
>
> > ============================================
>
> >
>
> > PhysicalMaterial : X3DOneSidedMaterialNode {
>
> >
>
> > SFColor [in,out] baseColor 1 1 1 [0,1]
>
> >
>
> > SFNode [in,out] baseTexture NULL [X3DSingleTextureNode]
>
> >
>
> > SFString [in,out] baseTextureMapping "" # string label points to matching labels in
>
> >
>
> > # TextureCoordinate, TextureTransform
>
> >
>
> > ...
>
> >
>
> > ============================================
>
> >
>
> >
>
> >
>
> > simply
>
> >
>
> >
>
> >
>
> > ============================================
>
> >
>
> > PhysicalMaterial : X3DOneSidedMaterialNode {
>
> >
>
> > SFColor [in,out] baseColor 1 1 1 [0,1]
>
> >
>
> > SFNode [in,out] baseTexture NULL [X3DSingleTextureNode]
>
> >
>
> > SFNode [in,out] baseTextureCoordinate NULL [X3DSingleTextureCoordinateNode]
>
> >
>
> > SFNode [in,out] baseTextureTransform NULL [X3DSingleTextureTransformNode]
>
> >
>
> > ...
>
> >
>
> > ============================================
>
> >
>
> >
>
> >
>
> > and similarly apply this naming pattern each for each field:
>
> >
>
> > - baseColor
>
> >
>
> > - metallicRoughness
>
> >
>
> > - emissiveColor
>
> >
>
> > - normal
>
> >
>
> > - occlusionStrength
>
> >
>
> >
>
> >
>
> > ...so, adding some name regularization, resulting in full form something like:
>
> >
>
> >
>
> >
>
> > ============================================
>
> >
>
> > PhysicalMaterial : X3DOneSidedMaterialNode {
>
> >
>
> > SFColor [in,out] baseColor 1 1 1 [0,1]
>
> >
>
> > SFNode [in,out] baseTexture NULL [X3DSingleTextureNode]
>
> >
>
> > SFNode [in,out] baseTextureCoordinate NULL [X3DSingleTextureCoordinateNode]
>
> >
>
> > SFNode [in,out] baseTextureTransform NULL [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> > SFFloat [in,out] metallic 1 [0,1]
>
> >
>
> > SFNode [in,out] metallicTexture NULL [X3DSingleTextureNode]
>
> >
>
> > SFNode [in,out] metallicTextureCoordinate NULL [X3DSingleTextureCoordinateNode]
>
> >
>
> > SFNode [in,out] metallicTextureTransform NULL [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> > SFColor [in,out] emissiveColor 0 0 0 [0,1]
>
> >
>
> > SFNode [in,out] emissiveTexture NULL [X3DSingleTextureNode]
>
> >
>
> > SFNode [in,out] emissiveTextureCoordinate NULL [X3DSingleTextureCoordinateNode]
>
> >
>
> > SFNode [in,out] emissiveTextureTransform NULL [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> > SFNode [in,out] metadata NULL [X3DMetadataObject]
>
> >
>
> >
>
> >
>
> > SFFloat [in,out] normalScale 1 [0, ∞]
>
> >
>
> > SFNode [in,out] normalTexture NULL [X3DSingleTextureNode]
>
> >
>
> > SFNode [in,out] normalTextureCoordinate NULL [X3DSingleTextureCoordinateNode]
>
> >
>
> > SFNode [in,out] normalTextureTransform NULL [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> > SFFloat [in,out] occlusionStrength 1 [0,1]
>
> >
>
> > SFNode [in,out] occlusionTexture NULL [X3DSingleTextureNode]
>
> >
>
> > SFNode [in,out] occlusionTextureCoordinate NULL [X3DSingleTextureCoordinateNode]
>
> >
>
> > SFNode [in,out] occlusionTextureTransform NULL [X3DSingleTextureTransformNode]
>
> >
>
> >
>
> >
>
> > SFFloat [in,out] roughness 1 [0,1]
>
> >
>
> > SFFloat [in,out] transparency 0 [0,1]
>
> >
>
> > }
>
> >
>
> > ============================================
>
> >
>
> >
>
> >
>
> > This approach seems unambiguous, directly inspectable, validatable, and gives authors complete flexibility of DEF/USE.
>
> >
>
> >
>
> >
>
> > What do you think?
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > On 9/15/2020 1:51 PM, Michalis Kamburelis wrote:
>
> >
>
> > > NPS WARNING: *external sender* verify before acting.
>
> >
>
> > >
>
> >
>
> > > I wrote an explanation about why xxxTextureMapping are not realized by DEF / USE on https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use .
>
> >
>
> > >
>
> >
>
> > > Please read that, it contains the reasoning, and examples that are possible thanks to the current design. In short, this means that you can naturally reuse (by DEF / USE) materials, appearances, geometries. This reuse is possible, because appearances and geometries are not inter-linked together by DEF / USE inside.
>
> >
>
> > >
>
> >
>
> > > It also contains counter-examples. That is, it shows how problematic it would be if we tried to force xxxTextureMapping (or something equivalent) using DEF / USE. I present there how, in various scenarios, reusing materials or appearances or geometries would then be impossible.
>
> >
>
> > >
>
> >
>
> > > Regards,
>
> >
>
> > > Michalis
>
> >
>
> > >
>
> >
>
> > > wt., 15 wrz 2020 o 04:26 Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>>>> napisał(a):
>
> >
>
> > >
>
> >
>
> > > On 9/14/2020 1:12 PM, Michalis Kamburelis wrote:
>
> >
>
> > > > NPS WARNING: *external sender* verify before acting.
>
> >
>
> > > >
>
> >
>
> > > > xxxTextureMapping are not an enumerated value. There is no constrained set of values you can put there. The authors are free to invent their own names. As long as they match (that is, the section " 12.2.4 Texture mapping specified in material nodes" is satisfied) then any value is OK.
>
> >
>
> > > >
>
> >
>
> > > > We talked about this :) xxxTextureMapping is just a unique identifier.
>
> >
>
> > >
>
> >
>
> > > Sorry but it makes even less sense now. We already have DEF and USE as unique identifiers.
>
> >
>
> > >
>
> >
>
> > > Perhaps some examples might illustrate this?
>
> >
>
> > >
>
> >
>
> > > > If we wanted to make a limited set of options, we would instead make xxxTextureMapping an SFInt32 field.
>
> >
>
> > >
>
> >
>
> > > No need to create, that was just our trying to understand what you meant by mapping.
>
> >
>
> > >
>
> >
>
> > > > xxxTextureMapping as a string is similar to glTF attribute names like TEX_COORD0, TEX_COORD1.
>
> >
>
> > >
>
> >
>
> > > Haven't thought of an example yet that can't be accomplished by DEF/USE of nodes, rather than ID labels as references. Again examples might help.
>
> >
>
> > >
>
> >
>
> > > > > Dick is wondering if booleans are appropriate as well, perhaps renaming them (or adding them).
>
> >
>
> > > >
>
> >
>
> > > > The booleans "xxxTextureEnabled" are not necessary, and would complicate the specification. Simply leaving the "xxxTexture" = NULL is a clear information that a texture doesn't exist. There's no point in adding an additional field to "turn off" a non-NULL texture. Neither glTF or other formats I know about need an additional "xxxEnabled" boolean.
>
> >
>
> > >
>
> >
>
> > > sounds good on that point, thanks.
>
> >
>
> > >
>
> >
>
> > > > Regards,
>
> >
>
> > > > Michalis
>
> >
>
> > > >
>
> >
>
> > > >
>
> >
>
> > > > pon., 14 wrz 2020 o 19:19 Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>>> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>>>>> napisał(a):
>
> >
>
> > > >
>
> >
>
> > > > While looking at the following, it seems like accepted enumeration values for the *Mapping strings (xxxTextureMapping fields) are not provided.
>
> >
>
> > > >
>
> >
>
> > > > [1] X3D4 Architecture, 12.2.4 Texture mapping specified in material nodes
>
> >
>
> > > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#TextureMapping
>
> >
>
> > > >
>
> >
>
> > > > > The X3DOneSidedMaterialNode and descendants (Material, PhysicalMaterial, UnlitMaterial) introduce a number of fields to modify material parameters using textures. They are consistently defined by a pair of fields like this:
>
> >
>
> > > > >
>
> >
>
> > > > > SFNode [in,out] xxxTexture NULL
>
> >
>
> > > > > SFString [in,out] xxxTextureMapping ""
>
> >
>
> > > > >
>
> >
>
> > > > > The field xxxTexture indicates a texture node.
>
> >
>
> > > > >
>
> >
>
> > > > > The xxxTextureMapping determines the texture coordinates and texture coordinates transformation for given texture xxxTexture.
>
> >
>
> > > > >
>
> >
>
> > > > > The corresponding texture coordinate and texture coordinate transformation nodes have a field mapping that will match the value of the xxxTextureMapping field. See the X3DSingleTextureCoordinateNode and X3DSingleTextureTransformNode definitions.
>
> >
>
> > > > >
>
> >
>
> > > > > Multiple textures may use the same texture coordinates and their transformations. For example, it is common that both normalTextureMapping and diffuseTextureMapping are equal, if the graphic artist prepared both normalTexture and diffuseTexture simultaneously, assuming the same mapping.
>
> >
>
> > > >
>
> >
>
> > > > and
>
> >
>
> > > >
>
> >
>
> > > > [2] X3D4 Architecture, 12.4.5 Material
>
> >
>
> > > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#Material
>
> >
>
> > > >
>
> >
>
> > > > > SFString [in,out] ambientTextureMapping ""
>
> >
>
> > > > >
>
> >
>
> > > > > SFString [in,out] diffuseTextureMapping ""
>
> >
>
> > > > >
>
> >
>
> > > > > SFString [in,out] emissiveTextureMapping ""
>
> >
>
> > > > >
>
> >
>
> > > > > SFString [in,out] occlusionTextureMapping ""
>
> >
>
> > > > >
>
> >
>
> > > > > SFString [in,out] shininessTextureMapping ""
>
> >
>
> > > > >
>
> >
>
> > > > > SFString [in,out] specularTextureMapping ""
>
> >
>
> > > >
>
> >
>
> > > > Dick is wondering if booleans are appropriate as well, perhaps renaming them (or adding them).
>
> >
>
> > > >
>
> >
>
> > > > SFBool [in out] ambientTextureEnabled TRUE
>
> >
>
> > > > ...
>
> >
>
> > > > SFBool [in out] specularTextureEnabled TRUE
>
> >
>
> > > >
>
> >
>
> > > > Please advise what are candidate values for these strings. Thanks!
>
> >
>
> > all the best, Don
>
> >
>
> > --
>
> >
>
> > Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu <mailto: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
>
> >
>
>
>
> all the best, Don
>
> --
>
> Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto: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
>
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
More information about the x3d-public
mailing list