[x3d-public] wondering about Texture mapping specified in material nodes [corrected]
Andreas Plesch
andreasplesch at gmail.com
Mon Sep 21 21:06:47 PDT 2020
In Michalis mapping approach, what happens if the given mapping strings do
not match up, eg. do not have the proper partner ? Presumably undefined
behaviour, but probably hard to validate with a stylesheet.
Intuitively, it seems desirable to follow Don's explicit field naming
approach, to allow for better validation and to keep with precedence of not
having custom labels. This is just intuition, let's think about it.
However, I think the explicit xxxTexCoord fields would need to stay in the
geometry node (where it is now). This would then allow for reuse of
Appearance (for example if it uses a texture catalog) for multiple
geometries. But then the geometry (IFS) could not be reused with another
Appearance (same officer but different uniform). I think there the solution
is traditionally to indeed define a new Geometry but still reuse the 'meat'
of the base Geometry, eg. the coordinate node and indices (indicating that
they should perhaps be in their own node as well).
Another option may be to put the explicit xxxTexCoord fields in Appearance
but outside of Material. Then Geometry could be shared. New Appearances
would be required for different Geometries but they could still reuse the
same Material with all the textures. That option may have potential but
would be a departure.
Tricky business, Andreas
---on the phone---
> ---------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 21 Sep 2020 21:09:42 +0200
> From: Michalis Kamburelis <michalis.kambi at gmail.com>
> To: Don Brutzman <brutzman at nps.edu>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] wondering about Texture mapping specified in
> material nodes [corrected]
> Message-ID:
> <CAKzBGZM=7pQPVS=ipkBy87GSUsN2qnkJ7jSve9s1SzXyav7U=
> g at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
> .
>
> 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.
>
> 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/
> .
>
> 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""".
>
> 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 21 Sep 2020 21:17:10 +0200
> From: Michalis Kamburelis <michalis.kambi at gmail.com>
> To: Don Brutzman <brutzman at nps.edu>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: Re: [x3d-public] Presentation about View3dScene and Castle
> Game Engine for X3D4
> Message-ID:
> <
> CAKzBGZPUTSgmLgU2_KUuPV1rb5zS3to95YV4oMshy34AuqXNXQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Don,
>
> Thank you for the good words but this is probably not the video you think
> about :)
>
> On
>
> https://castle-engine.io/wp/2020/09/06/presentation-about-view3dscene-and-castle-game-engine/
> I merely reshared the presentation about view3dscene from
> https://www.youtube.com/c/Web3DConsortium channel. It is a talk that I
> gave
> for the Web3D webinar about X3D Browsers. This wasn't a talk focused on PBR
> in X3Dv4, although I certainly mentioned it by the way :) I show there
> various view3dscene features.
>
> I also gave a presentation at Web3D teleconference about PBR and X3Dv4. We
> had 2 such sessions, they were recorded by Zoom. You mentioned you'll put
> them online after some cuts, but they are not online yet, as far as I know.
>
> Regards,
> Michalis
>
>
> niedz., 20 wrz 2020 o 21:02 Don Brutzman <brutzman at nps.edu> napisa?(a):
>
> > Michalis, thanks 1M for your recent post. Your video given to X3D
> Working
> > Group is essential viewing for anyone seeking to understand how X3D4 is
> > upgrading to include Physically Based Rendering (PhysicalMaterial),
> > advanced Material capabilities, and non-photorealistic rendering
> > (UnlitMaterial). These major improvements also allow X3D scenes to
> inline
> > glTF scenes compatibly.
> >
> > =====================================================
> > Presentation about View3dScene and Castle Game Engine
> >
> >
> >
> https://castle-engine.io/wp/2020/09/06/presentation-about-view3dscene-and-castle-game-engine/
> >
> > At the beginning of August, I made a presentation about View3dScene and
> > Castle Game Engine, for Web3D webinar about X3D Browsers. The
> presentation
> > is now publicly available:
> >
> > https://www.youtube.com/watch?v=-Ku143SI2zA
> >
> > Enjoy ? I focus in the presentation on View3dscene features, which you
> > get just by opening some X3D and glTF files, no coding (or knowledge of
> CGE
> > API in Pascal) required. For CGE developers, all these features are
> > available as part of our TCastleScene class, documented in a few chapters
> > of the manual.
> > =====================================================
> >
> > Apologies that I wasn't able to turn around video postproduction sooner,
> > am very glad you have done this. Have also retweeted and cross-linked
> your
> > presentation in Web3D Consortium Twitter and YouTube sites.
> >
> > The X3D Working Group has adopted Michalis design for X3D version 4.
> > Working draft 2 of X3D4 is published online, Michalis Dick and I are
> > fine-tuning prose and field signatures in full sight of the x3d-public
> > mailing list, ensuring the best possible specification that the working
> > group is capable of producing.
> >
> > * X3D4 Architecture, Shape component
> >
> >
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/shape.html
> >
> > We are on track to have X3D4 ready for public review and Web3D member
> > advancement to ISO at the upcoming Web3D 2020 Conference November 9-13,
> > online at
> >
> > * https://web3d.siggraph.org
> >
> > Once again, thanks Michalis for magnificent achievements. For everyone:
> > have fun with advanced X3D4 rendering! 8)
> >
> > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200921/f2869b87/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Mon, 21 Sep 2020 16:25:18 -0500
> From: John Carlson <yottzumm at gmail.com>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: [x3d-public] SAI to native
> Message-ID:
> <CAGC3UEkLkkHrDrMQzpAP-RzsgJY+4U6gZ64vHtSOEO=
> iC1iORg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I am wondering if we have any working SAI to native example conversions?
> I know we have bytecoded conversions.
>
> Thanks!
>
> John
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200921/1482becd/attachment.html
> >
>
> ------------------------------
>
> 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 138, Issue 65
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200922/a64b88a2/attachment-0001.html>
More information about the x3d-public
mailing list