[x3d-public] wondering about Texture mapping specified in material nodes [corrected]

Don Brutzman brutzman at nps.edu
Tue Sep 22 00:38:22 PDT 2020


Appreciate your patience.   Clearly we need a meeting to discuss this since we seem to be circling.

I have multiple workshops to attend this week.  Looks like my first available day to meet is Friday.  Can start as early as 0700 Pacific.  Regular X3D teleconference also available 08-0930 Pacific.  This remains high priority.

Reviewed again, summary: have offered more concise examples that seem to handle all of the shortfalls in the original failed alternatives.  Key details follow.

a. I believe you stated as a functional definition that each of the Texture fields modify the corresponding Material - that certainly seems to be their purpose.  If any one of those fields needs to have different TextureTransform and TextureCoordinate values than the others, then it needs to be defined right there with the texture in question.  In other words, you can't have multiple texCoord values over on the geometry itself.

b. For the primary Appearance "texture" field and corresponding TextureTransform and corresponding geometry texCoord, there is no change implied from X3D3 (just like you have it).

c. Maximizing USE is not a design requirement per se, just helpful design when achievable.  Having distinct "mapping" fields across multiple node types does not make a node (or collection of nodes within a Shape) suddenly re-USE-able.  If any of the fields are different, including "mapping" then the nodes are different.  If they are the same, then USE is allowed.  Avoiding redefinition of MultiTexture itself by re-USE of the MultiTexture internal nodes is why my example simply used ImageTexture, case by case, with appropriate USE found in multiple places.

Your Example C sidesteps this problem by overloading nodes with the same label, e.g.

         TextureTransform {  # part of example A
           mapping "diffuse-and-normal-mapping"
           translation 0.5 0.5
         }

         TextureTransform {  # deliberately added to example A by example C
           mapping "diffuse-and-normal-mapping"
           translation 0 0
         }

d. If the field approach has the same information as other programmatic styles, then it is functionally equivalent to (glTF, Blender, Unity, whatever).  The parent-child field relationship approach is certainly in keeping with X3D3.

e. If there is some aspect of model definition in your primary example not expressed in the field approach that I offered, please point out the gap.  My example was carefully derived step-by-step from yours, commenting each of your constructs in place when replaced by an alternative, so any logical misconception or disconnect should be isolable.  Here was the transition:

# Version 1-original
# Version 2-original-labeled   (simply adding DEF labels)
# Version 3-fieldnames-verbose (keeping mapping fields in place, commented)
# Version 4-fieldnames-terse   (same, minus comments)

So, is anything missing?  I just rechecked again and all information in your original seems to be accounted for.

f. Something you haven't said explicitly but may be thinking:  even if the two approaches are functionally equivalent, it is conceivable that we might decide to forego the usual X3D parent-child node relationships in order to preserve portability of content when translating to/from glTF etc.

... in which case we might well decide to keep "mapping" fields as a more-compatible but less-validatable approach,

... in which case we need to look at how difficult animation has become when author must change many parameters simultaneously (via Script node synchronization) in order to achieve a single effect,

Example underlying glTF code might be helpful to compare.  Would it help us to look at that for your Example A?

As we've seen many times in X3D when going from ClassicVRML to XML to binary to JSON to Java to Python to JavaScript to C/C++/C# to Turtle (and presumably ObjectPascal): declarative design patterns can be mapped to imperative code patterns, and vice versa.  Once the correspondence is defined, mappings in each direction might not be trivial but are usually straightforward.

So, I'm open to logical comparison, but remain resistant to allowing design of perhaps our most important new feature PBR to be failure prone and impossible to animate.  X3D reliability and repeatability are essential.  This whole review is necessary due diligence.

Looking forward to reaching clarity, again thanks for steady scrutiny.


On 9/21/2020 12:09 PM, Michalis Kamburelis wrote:
> 
> 
> Don,
> 
> AD 1 - I have labeled the examples A B C D E F on
> https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use

thanks, helpful

>      Four of them (the ones that present design that works IMO, with
> mapping as SFString) are inside
> https://github.com/michaliskambi/x3d-tests/tree/master/pbr/enhanced_phong_material
> , in files mapping_single_shape.x3dv, and
> mapping_second_shape_reusing_*.x3dv . They already work with
> view3dscene.

very important

> AD 2 - As you know, all my examples are public (and open-source,
> license is in the repo) since day one of my work of PBR + X3Dv4. They
> are all on https://github.com/michaliskambi/x3d-tests/tree/master/pbr/

no challenge there - thanks of course - just am trying to get schema/dtd/tools aligned and models into the regression tests.  my build scripts can't test your repository.  so we need to port them somewhere in one of the projects in the X3D Examples Archive.

> AD 3 - The xxxTextureMapping fields and how it matches with
> TextureCoordinate.mapping / TextureTransform.mapping is explained at
> the very link you mention:
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#TextureMapping
> . The field "mapping" itself is mentioned at the nodes where it is
> present ( https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/texturing.html#X3DSingleTextureCoordinateNode
> , https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/texturing.html#X3DSingleTextureTransformNode
> ). Indeed there should be a link from X3DSingleTextureCoordinateNode /
> X3DSingleTextureTransformNode -> """12.2.4 Texture mapping specified
> in material nodes""".

Agreed we should add a link from that section to the other.

The point remains however, there is no specification prose provided such as "The /mapping/ field __(does this and that)__" in section 18.2.1 Texture map formats.  Mentioning it in a few places (as you indicate above) is insufficient for ISO prose.  Every field must have its own specific definition, typically either in the node or the node type where it is first defined.

The following is in the right place but is not a satisfactory definition for /mapping/ field, because that /mapping/ string does not define either texture coordinates or transformations:

12.2.4 Texture mapping specified in material nodes
"The xxxTextureMapping determines the texture coordinates and texture coordinates transformation for given texture xxxTexture."

> To answer the rest of your message:
> 
> I'm afraid you didn't understand where the issue is.
> 
> You presented how to express my "example A" using a different approach
> (where you put the texture coordinate nodes inside Material).
> 
> But in your approach, texture coordinates are now inside a Material
> node. Which goes contrary to the design of meshes/materials in all
> other software and formats (glTF, Blender, Unity, X3D 3...). And in
> your approach, you cannot express things like:
> 
> - another shape uses the same Appearance node, but with different
> IndexedFaceSet (my example B)
> 
> - another shape uses the same Material node, but with different
> IndexedFaceSet (my example C)
> 
> And "sharing" an Appearance and/or Material is a very common thing,
> available across various 3D authoring tools and formats. This
> "sharing" is also very useful also to browsers to optimize loading /
> rendering. So we want to keep this sharing possible, just as it was in
> X3D 3.
> 
> In my text on https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F#can-we-make-texture-mapping-using-def--use
> , I already tried to do what you did, in examples E and F. Yes, it
> works for one shape. But it breaks as soon as someone tries to reuse
> - Appearance (which is possible in my example B) or
> - Material (which is possible in my example C) or
> - IndexedFaceSet (which is possible in my example D).
> 
> Regards,
> Michalis
> 
> sob., 19 wrz 2020 o 19:55 Don Brutzman <brutzman at nps.edu> napisał(a):
>>
>> continuing just a little more.
>>
>> [...]
>>
>> On 9/19/2020 7:59 AM, Don Brutzman wrote:
>>> If we are converging, then identical field pattern for PhysicalMaterial above would be similarly applied to Material and UnlitMaterial in X3D4 specification.
>>
>> [3] 12.4.5 Material
>>       https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html#Material
>>
>> ============================================
>> # Current WD2 Material with mapping fields, backwards compatible with X3D3
>>
>> Material : X3DOneSidedMaterialNode {
>>     SFFloat  [in,out] ambientIntensity          0.2          [0,1]
>>     SFNode   [in,out] ambientTexture            NULL         [X3DSingleTextureNode]
>>     SFString [in,out] ambientTextureMapping     ""
>>
>>     SFColor  [in,out] diffuseColor              0.8 0.8 0.8  [0,1]
>>     SFNode   [in,out] diffuseTexture            NULL         [X3DSingleTextureNode]
>>     SFString [in,out] diffuseTextureMapping     ""
>>
>>     SFColor  [in,out] emissiveColor             0 0 0        [0,1]
>>     SFNode   [in,out] emissiveTexture           NULL         [X3DSingleTextureNode]
>>     SFString [in,out] emissiveTextureMapping    ""
>>
>>     SFNode   [in,out] metadata                  NULL         [X3DMetadataObject]
>>
>>     SFNode   [in,out] normalTexture             NULL         [X3DTexture2DNode]
>>     SFString [in,out] normalTextureMapping      ""
>>     SFFloat  [in,out] normalScale               1            [0, ∞]
>>
>>     SFFloat  [in,out] occlusionStrength         1            [0,1]
>>     SFNode   [in,out] occlusionTexture          NULL         [X3DTexture2DNode]
>>     SFString [in,out] occlusionTextureMapping   ""
>>
>>     SFFloat  [in,out] shininess                 0.2          [0,1]
>>     SFNode   [in,out] shininessTexture          NULL         [X3DSingleTextureNode]
>>     SFString [in,out] shininessTextureMapping   ""
>>
>>     SFColor  [in,out] specularColor             0 0 0        [0,1]
>>     SFNode   [in,out] specularTexture           NULL         [X3DSingleTextureNode]
>>     SFString [in,out] specularTextureMapping    ""
>>
>>     SFFloat  [in,out] transparency              0            [0,1]
>> }
>> ============================================
>>
>> to follow the explicit-field pattern shown in PhysicalMaterial would replace "mapping" fields to become something like
>>
>> ============================================
>> # Suggested Material without mapping fields, backwards compatible with X3D3
>>
>> Material : X3DOneSidedMaterialNode {
>>     SFFloat  [in,out] ambientIntensity          0.2          [0,1]
>>     SFNode   [in,out] ambientTexture            NULL         [X3DSingleTextureNode]
>>     SFNode   [in,out] ambientTexCoord           NULL         [X3DSingleTextureCoordinateNode]
>>     SFNode   [in,out] ambientTextureTransform   NULL         [X3DSingleTextureTransformNode]
>>
>>     SFColor  [in,out] diffuseColor              0.8 0.8 0.8  [0,1]
>>     SFNode   [in,out] diffuseTexture            NULL         [X3DSingleTextureNode]
>>     SFNode   [in,out] diffuseTexCoord           NULL         [X3DSingleTextureCoordinateNode]
>>     SFNode   [in,out] diffuseTextureTransform   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]
>>
>>     SFNode   [in,out] normalTexture             NULL         [X3DTexture2DNode]
>>     SFNode   [in,out] normalTexCoord            NULL         [X3DSingleTextureCoordinateNode]
>>     SFNode   [in,out] normalTextureTransform    NULL         [X3DSingleTextureTransformNode]
>>
>>     SFFloat  [in,out] occlusionStrength         1            [0,1]
>>     SFNode   [in,out] occlusionTexture          NULL         [X3DTexture2DNode]
>>     SFNode   [in,out] occlusionTexCoord         NULL         [X3DSingleTextureCoordinateNode]
>>     SFNode   [in,out] occlusionTextureTransform NULL         [X3DSingleTextureTransformNode]
>>
>>     SFFloat  [in,out] shininess                 0.2          [0,1]
>>     SFNode   [in,out] shininessTexture          NULL         [X3DSingleTextureNode]
>>     SFString [in,out] shininessTexCoord         NULL         [X3DSingleTextureCoordinateNode]
>>     SFNode   [in,out] shininessTextureTransform NULL         [X3DSingleTextureTransformNode]
>>
>>     SFColor  [in,out] specularColor             0 0 0        [0,1]
>>     SFNode   [in,out] specularTexture           NULL         [X3DSingleTextureNode]
>>     SFNode   [in,out] specularTexCoord          NULL         [X3DSingleTextureCoordinateNode]
>>     SFNode   [in,out] specularTextureTransform  NULL         [X3DSingleTextureTransformNode]
>>
>>     SFFloat  [in,out] transparency              0            [0,1]
>> }
>> ============================================
>>
>> ... so for proper spelling of field names ("*TexCoord" vice "*TextureCoord"), consistency correction to previous Version 3-fieldnames-verbose and Version 4-fieldnames-terse examples:
>>
>>         diffuseTextureCoord  USE TEXTURECOORDINATE_6
>>         normalTextureCoord   USE TEXTURECOORDINATE_6
>>         specularTextureCoord USE TEXTURECOORDINATE_7
>>
>> should be
>>
>>         diffuseTexCoord      USE TEXTURECOORDINATE_6
>>         normalTexCoord       USE TEXTURECOORDINATE_6
>>         specularTexCoord     USE TEXTURECOORDINATE_7
>>
>> No change to logic or topology here, just getting precise on spelling.

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