[x3d-public] missing textureProperties field in ComposedCubeMapTexture, elsewhere?

[Don Brutzman]

 From Dick and Don: thanks for close scrutiny and clear answer.

This improvement has been applied to draft specification.  When convenient, please double-check node signatures in all three relevant components.

* https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/Architecture.html

  |   +- X3DTextureNode -+- MultiTexture
  |   |                  |
  |   |                  + X3DSingleTextureNode -+- X3DEnvironmentTextureNode -+- ComposedCubeMapTexture
  |   |                  |                       |                             +- GeneratedCubeMapTexture
  |   |                  |                       |                             +- ImageCubeMapTexture (X3DUrlObject)*
  |   |                  |                       |
  |   |                  |                       +- X3DTexture2DNode -+- ImageTexture (X3DUrlObject)*
  |   |                  |                       |                    +- MovieTexture (X3DSoundSourceNode, X3DUrlObject)*
  |   |                  |                       |                    +- PixelTexture
  |   |                  |                       |
  |   |                  |                       +- X3DTexture3DNode -+- ComposedTexture3D
  |   |                  |                                            +- ImageTexture3D (X3DUrlObject)*
  |   |                  |                                            +- PixelTexture3D


still TODO: updating X3D XML Schema, DTD and X3DUOM.  This can be tricky because of ProtoInstance repetitions must not break XML "deterministic content model" rules.  Will report when complete.

On 12/15/2020 2:09 AM, Michalis Kamburelis wrote:
> 
> Indeed, textureProperties should be added to ComposedCubeMapTexture.
> (Looking at CGE implementation, we support it already.) This is not
> really related to PBR or my other changes,
> "ComposedCubeMapTexture.textureProperties" always made sense in X3D
> 3.x too, it specifies e.g. filtering.
> 
> Actually it should be added to the ancestor, X3DEnvironmentTextureNode.
> 
> Actually it should be added to the higher ancestor, X3DSingleTextureNode :)
> 
> So we just found another advantage of having abstract
> X3DSingleTextureNode. Everything descending from X3DSingleTextureNode
> (which means: all textures except MultiTexture) deserves a
> textureProperties field.

agreed in all respects.  again thanks.

> Regards,
> Michalis
> 
> wt., 15 gru 2020 o 01:47 Don Brutzman <brutzman at nps.edu> napisał(a):
>>
>> Looking for additional opinions.  Michalis, can you please confirm (following your refactoring of all textures for PBR and NPR) that textureProperties should be added as described?  Also wondering if it is missing anywhere else.  TIA for all scrutiny.
>>
>> -----------------
>> * Mantis 805: 34.4.1 ComposedCubeMapTexture - Missing textureProperties field
>>     https://www.web3d.org/member-only/mantis/view.php?id=805
>>
>> -----------------
>> Description: ComposedCubeMapTexture missing textureProperties field, may belong in X3DEnvironmentTextureNode
>>
>> ComposedCubeMapTexture missing textureProperties field.
>>
>> Note that textureProperties does appear in the other X3DEnvironmentTextureNode nodes, GeneratedCubeMapTexture and ImageCubeMapTexture.
>>
>> Probably textureProperties should simply be part of the common abstract type, X3DEnvironmentTextureNode.
>>
>> Reference:
>> http://web3d.org/mailman/private/x3d_web3d.org/2015-May/003024.html
>> -----------------
>>
>> 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

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