[x3d-public] X3D4 PBR specification review: updates and demos
GPU Group
gpugroup at gmail.com
Wed Mar 4 17:01:04 PST 2020
One more channel packing method:
1) have a standard channel packing order that must be followed in X3D for
physicsmaterial
2) Add a new node type:
TextureChannelRearranger :: TextureNode
SFNode texture NULL
MFInt32 newChannelOrder [0,1,2,3]
Then if an end user is stuck with the wrong channel ordering and no tool to
rearrange, they can over-ride the order with this wrapper node.
Web3d spec comment rules apply to what I said in this post and the last,
namely I make no proprietary claims, and that's because I'm a COMMUNITY
MEMBER of web3d.org and SIGNED THE ONLINE AGREEMENT.
Doug Sanden.
On Wed, Mar 4, 2020 at 4:46 PM GPU Group <gpugroup at gmail.com> wrote:
> I like the channels idea for its complete generality, and no need to list
> permulations of effect channel packing.. You could have an MFNode list of
> textures, and for each of your physical effects give a (texture #. channel
> #) address
> Or use characters to name the channels:
> R=roughness M=metallic O=occlusion G=glossiness S=specular X=not used
> texturelist MFNode []
> channels MFString []
> example use:
> textureList [USE T1, USE T2]
> channels ["ORM","SG"]
> Or if you want your number of channels explicit
> channels ["O1R1M1", "S3G1"]
> In practice for physicalMaterial i gather (specular-glossiness
> (transparency?)) and (metallic-roughness-opacity) are substitutes - you do
> one or the other, so if there's a common convention for how the channels
> are packed that's good enough for freewrl users..
>
> On Wed, Mar 4, 2020 at 1:32 PM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
>
>> Thank you both for the good words and work!
>>
>> As for the completeness of PhysicalMaterial:
>>
>> - As far I know, the only remaining functionality missing from
>> PhysicalMaterial, that is present in glTF 2.0 spec (
>>
>> https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#materials
>> ) is the "occlusion" texture. I have it in my TODO list, I'll probably
>> add it -- first I have to understand it fully :)
>>
>> - Note that, at least in this PR, I deliberately decided to *not*
>> account for the KHR_materials_pbrSpecularGlossiness (
>>
>> https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_materials_pbrSpecularGlossiness
>> ), which allows to
>> specify physical material using a bit different parameters. I see that
>> X3DOM accounts for that.
>>
>> - Some other stuff I decided to *not* include in this PR (because it
>> seems it can be added later, and it's somewhat independent):
>>
>> - alphaCutoff from glTF (this is something independent of the
>> lighting model, so would be an extension for all material types; as
>> far as I recall, X3DOM has "Appearance.alphaClipThreshold" to address
>> this, and it seems cool for me)
>>
>> - alphaMode from glTF (although I do have a solution for this in
>> CGE, called "Appearance.alphaChannel", see
>>
>> https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_alpha_channel
>> )
>>
>> - the fact that per-vertex colors in glTF multiply, while in X3D
>> they replace the color. I think we'll add some day a field like "mode"
>> = REPLACE | MULTIPLY to Color/ColorRGBA, where "REPLACE" would be
>> default (compatible with X3D 3) and "MULTIPLY" would allow to achieve
>> exactly glTF behavior.
>>
>> The channels stuff indeed requires rethinking. I recorded our
>> discussions and my reasons for various decisions on
>> https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F
>> . But I think I'll revisit the issue "how does xxxTextureChannel field
>> work" again, and make it better :) -- I need to experiment a bit and
>> see what feels right. I keep recording there my reasoning for various
>> decisions.
>>
>> Regards,
>> Michalis
>>
>>
>> śr., 4 mar 2020 o 15:33 GPU Group <gpugroup at gmail.com> napisał(a):
>> >
>> > Thanks Andreas - yes I see a bit different channel packing and field
>> naming - with the same information, so I can implement now (somehow) and
>> adjust the field conventions when the specs are finalized. Thanks,
>> > Doug Sanden
>> >
>> > On Tue, Mar 3, 2020 at 8:55 PM Andreas Plesch <andreasplesch at gmail.com>
>> wrote:
>> >>
>> >> wow, great progress !
>> >>
>> >>
>> >>
>> https://github.com/x3dom/x3dom/blob/master/src/nodes/Shape/PhysicalMaterial.js
>> >>
>> >> has x3dom's PhysicalMaterial which largely is consistent and may not
>> need too much work to make compliant with the finalized definition.
>> >>
>> >> I think I did notice that x3dom has some additional fields which were
>> necessary for full gltf support. We likely discussed that and either
>> thought these were outside the scope or should go into some other node. But
>> I do not want to distract.
>> >>
>> >> On a gltf related note, x3dom has BufferGeometry for gpu-friendly,
>> efficient binary geometry storage. The path to bring this into the spec.
>> may be to wait after gltf inline is more widely adopted. gltf inline will
>> internally require dealing with such a geometry format. From there it
>> should be a more digestable step to formalize a suitable node.
>> >>
>> >> On Tue, Mar 3, 2020, 8:54 PM <x3d-public-request at web3d.org> wrote:
>> >>>
>> >>> Send x3d-public mailing list submissions to
>> >>> x3d-public at web3d.org
>> >>>
>> >>> To subscribe or unsubscribe via the World Wide Web, visit
>> >>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>> >>> or, via email, send a message with subject or body 'help' to
>> >>> x3d-public-request at web3d.org
>> >>>
>> >>> You can reach the person managing the list at
>> >>> x3d-public-owner at web3d.org
>> >>>
>> >>> When replying, please edit your Subject line so it is more specific
>> >>> than "Re: Contents of x3d-public digest..."
>> >>>
>> >>>
>> >>> Today's Topics:
>> >>>
>> >>> 1. Re: X3D4 PBR specification review: updates and demos
>> >>> (Michalis Kamburelis)
>> >>> 2. Re: X3D4 PBR specification review: updates and demos (GPU Group)
>> >>> 3. Re: X3D4 PBR specification review: updates and demos
>> >>> (Michalis Kamburelis)
>> >>>
>> >>>
>> >>> ----------------------------------------------------------------------
>> >>>
>> >>> Message: 1
>> >>> Date: Wed, 4 Mar 2020 01:01:56 +0100
>> >>> From: Michalis Kamburelis <michalis.kambi at gmail.com>
>> >>> To: GPU Group <gpugroup at gmail.com>
>> >>> Cc: Don Brutzman <brutzman at nps.edu>, X3D Graphics public mailing
>> list
>> >>> <x3d-public at web3d.org>
>> >>> Subject: Re: [x3d-public] X3D4 PBR specification review: updates and
>> >>> demos
>> >>> Message-ID:
>> >>> <
>> CAKzBGZPgxUfkv27NEnp6De+TJ3_BJ4d4TinzeAKhTN-WnHtn+g at mail.gmail.com>
>> >>> Content-Type: text/plain; charset="UTF-8"
>> >>>
>> >>> GPU Group <gpugroup at gmail.com> wrote:
>> >>> >
>> >>> > Michalis,
>> >>> > Q1. I downloaded today view3dscene_3.18.0-win64-x86_64.zip and
>> master/pbr and ran all the samples and some seemed to work but this
>> particular sample all the teapots looked normal and shiny - does that mean
>> it couldn't find the material images?
>> >>>
>> >>> Tested, confirmed:
>> >>> For some (unknown for now) reason, Jenkins didn't update the
>> >>> view3dscene in snapshots (
>> >>> http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ ) after recent
>> >>> merge of PhysicalMaterial implementation to CGE master. I kicked it
>> >>> manually now. Thanks for reporting!
>> >>>
>> >>> Fixed:
>> >>> Please get the latest view3dscene from
>> >>> http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ -- now
>> >>> everything should work :)
>> >>>
>> >>> Tested:
>> >>> ```
>> >>> curl
>> http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/view3dscene-3.18.0-win64-x86_64.zip
>> >>> -o v.zip
>> >>> unzip v.zip
>> >>> cd view3dscene/
>> >>> ./view3dscene.exe pbr/physical_material/metallic_roughness.x3dv
>> >>> ```
>> >>>
>> >>> -> this is the best way to use Windows :) But you can also download
>> >>> through a browser like a normal human being :)
>> >>>
>> >>> > Q2. what if I'm a 'community member' of web3d -the free membership-
>> is there a way I can log in and get the pull?
>> >>>
>> >>> If you're a community member, then I think you should be able to
>> >>> access -- someone just has to give you permissions to access
>> >>> https://github.com/Web3DConsortium/X3D/ . GitHub permissions are not
>> >>> automatically synchronized with the Web3D membership status, as far as
>> >>> I know.
>> >>>
>> >>> Don will hopefully answer better here.
>> >>>
>> >>> >From my side, I really really want Doug to see my PR :) (But please
>> >>> bear in mind that it's work-in-progress, substantial edits are
>> >>> incoming, at 13th of March I hope to make it more-or-less-complete :)
>> >>> ).
>> >>>
>> >>> Regards,
>> >>> Michalis
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------
>> >>>
>> >>> Message: 2
>> >>> Date: Tue, 3 Mar 2020 17:36:53 -0700
>> >>> From: GPU Group <gpugroup at gmail.com>
>> >>> To: Michalis Kamburelis <michalis.kambi at gmail.com>
>> >>> Cc: Don Brutzman <brutzman at nps.edu>, X3D Graphics public mailing
>> list
>> >>> <x3d-public at web3d.org>
>> >>> Subject: Re: [x3d-public] X3D4 PBR specification review: updates and
>> >>> demos
>> >>> Message-ID:
>> >>> <
>> CAM2ogRdwSQZzn+hfhLXL+73CCP6PC5AHtS3xYO_Ta1hnSMux2A at mail.gmail.com>
>> >>> Content-Type: text/plain; charset="utf-8"
>> >>>
>> >>> OK thanks and the curl got the right one, renders like your
>> screenshot now
>> >>> thanks very much Michalis.
>> >>> (but if I went back through something else then (some cache somewhere,
>> >>> maybe local) would give me the older/stale version )
>> >>>
>> >>> I looked at the sample files and from that I inferred the following
>> nodes
>> >>> and fields (which I assume are subject to change)
>> >>>
>> >>> PhysicalMaterial
>> >>>
>> >>> baseColor SFVec3f
>> >>>
>> >>> baseTexture SFNode {ImageTexture,...}
>> >>>
>> >>> baseTextureChannel SFInt32 0
>> >>>
>> >>> normalTexture SFNode {ImageTexture...}
>> >>>
>> >>> normalTextureChannel SFInt32 0
>> >>>
>> >>> roughness SFFloat
>> >>>
>> >>> metallic SFFloat
>> >>>
>> >>> transparency SFFloat 0
>> >>>
>> >>>
>> >>>
>> >>> Material
>> >>>
>> >>> diffuseTexture SFNode {ImageTexture
>> >>>
>> >>> diffuseTextureChannle SFInt32 0
>> >>>
>> >>> ambientTexture SFNode {ImageTexture}
>> >>>
>> >>> ambientTextureChannel SFInt32 0
>> >>>
>> >>> specularTexture SFNode {ImageTexture}
>> >>>
>> >>> specularTextureChannel SFInt32 0
>> >>>
>> >>> normalTexture SFNode {ImageTexture...}
>> >>>
>> >>> normalTextureChannel SFInt32 0
>> >>>
>> >>> emissiveTexture SFNode {ImageTexture...}
>> >>>
>> >>> emissiveTextureChannel SFInt32 0
>> >>>
>> >>> shininessTexture SFNode {ImageTexture...}
>> >>>
>> >>> shininessTextureChannel SFInt32 0
>> >>>
>> >>> //you still have normal material fields
>> >>>
>> >>> diffulseColor SFvec3f
>> >>>
>> >>> emissiveColor SFVec3f
>> >>>
>> >>> specularColor SFVec3f
>> >>>
>> >>> shininess SFFloat 1.0
>> >>>
>> >>>
>> >>> Can I start with this? I don't think it will take long to re-vamp if
>> the
>> >>> fields and nodes change.
>> >>>
>> >>> Q. Is there any etiquette/constraint about using the same image
>> dimensions
>> >>> for each material/physicalMaterial texture, perhaps relating to
>> conserving
>> >>> GPU samplers by using samplerArray?
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Doug
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Mar 3, 2020 at 5:03 PM Michalis Kamburelis <
>> michalis.kambi at gmail.com>
>> >>> wrote:
>> >>>
>> >>> > GPU Group <gpugroup at gmail.com> wrote:
>> >>> > >
>> >>> > > Michalis,
>> >>> > > Q1. I downloaded today view3dscene_3.18.0-win64-x86_64.zip and
>> >>> > master/pbr and ran all the samples and some seemed to work but this
>> >>> > particular sample all the teapots looked normal and shiny - does
>> that mean
>> >>> > it couldn't find the material images?
>> >>> >
>> >>> > Tested, confirmed:
>> >>> > For some (unknown for now) reason, Jenkins didn't update the
>> >>> > view3dscene in snapshots (
>> >>> > http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ ) after
>> recent
>> >>> > merge of PhysicalMaterial implementation to CGE master. I kicked it
>> >>> > manually now. Thanks for reporting!
>> >>> >
>> >>> > Fixed:
>> >>> > Please get the latest view3dscene from
>> >>> > http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ -- now
>> >>> > everything should work :)
>> >>> >
>> >>> > Tested:
>> >>> > ```
>> >>> > curl
>> >>> >
>> http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/view3dscene-3.18.0-win64-x86_64.zip
>> >>> > -o v.zip
>> >>> > unzip v.zip
>> >>> > cd view3dscene/
>> >>> > ./view3dscene.exe pbr/physical_material/metallic_roughness.x3dv
>> >>> > ```
>> >>> >
>> >>> > -> this is the best way to use Windows :) But you can also download
>> >>> > through a browser like a normal human being :)
>> >>> >
>> >>> > > Q2. what if I'm a 'community member' of web3d -the free
>> membership- is
>> >>> > there a way I can log in and get the pull?
>> >>> >
>> >>> > If you're a community member, then I think you should be able to
>> >>> > access -- someone just has to give you permissions to access
>> >>> > https://github.com/Web3DConsortium/X3D/ . GitHub permissions are
>> not
>> >>> > automatically synchronized with the Web3D membership status, as far
>> as
>> >>> > I know.
>> >>> >
>> >>> > Don will hopefully answer better here.
>> >>> >
>> >>> > From my side, I really really want Doug to see my PR :) (But please
>> >>> > bear in mind that it's work-in-progress, substantial edits are
>> >>> > incoming, at 13th of March I hope to make it more-or-less-complete
>> :)
>> >>> > ).
>> >>> >
>> >>> > Regards,
>> >>> > Michalis
>> >>> >
>> >>> -------------- next part --------------
>> >>> An HTML attachment was scrubbed...
>> >>> URL: <
>> http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200303/09eff836/attachment-0001.html
>> >
>> >>>
>> >>> ------------------------------
>> >>>
>> >>> Message: 3
>> >>> Date: Wed, 4 Mar 2020 02:53:37 +0100
>> >>> From: Michalis Kamburelis <michalis.kambi at gmail.com>
>> >>> To: GPU Group <gpugroup at gmail.com>
>> >>> Cc: Don Brutzman <brutzman at nps.edu>, X3D Graphics public mailing
>> list
>> >>> <x3d-public at web3d.org>
>> >>> Subject: Re: [x3d-public] X3D4 PBR specification review: updates and
>> >>> demos
>> >>> Message-ID:
>> >>> <
>> CAKzBGZM+6ZA515h9R0y7_qJ7kpfZK_Gi5qUPDhptD2tAQ7OaNQ at mail.gmail.com>
>> >>> Content-Type: text/plain; charset="UTF-8"
>> >>>
>> >>> The new nodes and fields are visible publicly in a concise way in CGE
>> >>> repo already:
>> https://github.com/castle-engine/castle-engine/tree/master/tools/internal/x3d-nodes-to-pascal/nodes-specification
>> >>> . So you don't have to guess them looking at examples :)
>> >>>
>> >>> Look into Shape.txt (
>> >>>
>> https://github.com/castle-engine/castle-engine/blob/master/tools/internal/x3d-nodes-to-pascal/nodes-specification/Shape.txt
>> >>> ) for most additions. Look there for
>> >>>
>> >>> - X3DOneSidedMaterialNode
>> >>> - Material
>> >>> - PhysicalMaterial
>> >>> - UnlitMaterial
>> >>>
>> >>> These files are used to autogenerate some Pascal CGE code, so the
>> >>> things written there reflect the CGE implementation. So it is tested.
>> >>>
>> >>> They are indeed subject to some change. At least:
>> >>> - xxxTextureChannel may change to be a string, and the way it works
>> may change.
>> >>> - X3DOneSidedMaterialNode will be removed, the new fields will be just
>> >>> at X3DMaterialNode (I initially thought that X3DOneSidedMaterialNode
>> >>> is indeed, but after many talks about ""what to do with 2-sided
>> >>> materials" it seems it is not necessary).
>> >>> - shininessTexture and specularTexture will most likely merge into
>> >>> just "specularShininessTexture" (with shininess in alpha).
>> >>>
>> >>> Regards,
>> >>> Michalis
>> >>>
>> >>> ?r., 4 mar 2020 o 01:37 GPU Group <gpugroup at gmail.com> napisa?(a):
>> >>> >
>> >>> > OK thanks and the curl got the right one, renders like your
>> screenshot now thanks very much Michalis.
>> >>> > (but if I went back through something else then (some cache
>> somewhere, maybe local) would give me the older/stale version )
>> >>> >
>> >>> > I looked at the sample files and from that I inferred the following
>> nodes and fields (which I assume are subject to change)
>> >>> >
>> >>> > PhysicalMaterial
>> >>> >
>> >>> > baseColor SFVec3f
>> >>> >
>> >>> > baseTexture SFNode {ImageTexture,...}
>> >>> >
>> >>> > baseTextureChannel SFInt32 0
>> >>> >
>> >>> > normalTexture SFNode {ImageTexture...}
>> >>> >
>> >>> > normalTextureChannel SFInt32 0
>> >>> >
>> >>> > roughness SFFloat
>> >>> >
>> >>> > metallic SFFloat
>> >>> >
>> >>> > transparency SFFloat 0
>> >>> >
>> >>> >
>> >>> >
>> >>> > Material
>> >>> >
>> >>> > diffuseTexture SFNode {ImageTexture
>> >>> >
>> >>> > diffuseTextureChannle SFInt32 0
>> >>> >
>> >>> > ambientTexture SFNode {ImageTexture}
>> >>> >
>> >>> > ambientTextureChannel SFInt32 0
>> >>> >
>> >>> > specularTexture SFNode {ImageTexture}
>> >>> >
>> >>> > specularTextureChannel SFInt32 0
>> >>> >
>> >>> > normalTexture SFNode {ImageTexture...}
>> >>> >
>> >>> > normalTextureChannel SFInt32 0
>> >>> >
>> >>> > emissiveTexture SFNode {ImageTexture...}
>> >>> >
>> >>> > emissiveTextureChannel SFInt32 0
>> >>> >
>> >>> > shininessTexture SFNode {ImageTexture...}
>> >>> >
>> >>> > shininessTextureChannel SFInt32 0
>> >>> >
>> >>> > //you still have normal material fields
>> >>> >
>> >>> > diffulseColor SFvec3f
>> >>> >
>> >>> > emissiveColor SFVec3f
>> >>> >
>> >>> > specularColor SFVec3f
>> >>> >
>> >>> > shininess SFFloat 1.0
>> >>> >
>> >>> >
>> >>> > Can I start with this? I don't think it will take long to re-vamp
>> if the fields and nodes change.
>> >>> >
>> >>> > Q. Is there any etiquette/constraint about using the same image
>> dimensions for each material/physicalMaterial texture, perhaps relating to
>> conserving GPU samplers by using samplerArray?
>> >>> >
>> >>> > Thanks,
>> >>> >
>> >>> > Doug
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Tue, Mar 3, 2020 at 5:03 PM Michalis Kamburelis <
>> michalis.kambi at gmail.com> wrote:
>> >>> >>
>> >>> >> GPU Group <gpugroup at gmail.com> wrote:
>> >>> >> >
>> >>> >> > Michalis,
>> >>> >> > Q1. I downloaded today view3dscene_3.18.0-win64-x86_64.zip and
>> master/pbr and ran all the samples and some seemed to work but this
>> particular sample all the teapots looked normal and shiny - does that mean
>> it couldn't find the material images?
>> >>> >>
>> >>> >> Tested, confirmed:
>> >>> >> For some (unknown for now) reason, Jenkins didn't update the
>> >>> >> view3dscene in snapshots (
>> >>> >> http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ ) after
>> recent
>> >>> >> merge of PhysicalMaterial implementation to CGE master. I kicked it
>> >>> >> manually now. Thanks for reporting!
>> >>> >>
>> >>> >> Fixed:
>> >>> >> Please get the latest view3dscene from
>> >>> >> http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/ -- now
>> >>> >> everything should work :)
>> >>> >>
>> >>> >> Tested:
>> >>> >> ```
>> >>> >> curl
>> http://michalis.ii.uni.wroc.pl/view3dscene-snapshots/view3dscene-3.18.0-win64-x86_64.zip
>> >>> >> -o v.zip
>> >>> >> unzip v.zip
>> >>> >> cd view3dscene/
>> >>> >> ./view3dscene.exe pbr/physical_material/metallic_roughness.x3dv
>> >>> >> ```
>> >>> >>
>> >>> >> -> this is the best way to use Windows :) But you can also download
>> >>> >> through a browser like a normal human being :)
>> >>> >>
>> >>> >> > Q2. what if I'm a 'community member' of web3d -the free
>> membership- is there a way I can log in and get the pull?
>> >>> >>
>> >>> >> If you're a community member, then I think you should be able to
>> >>> >> access -- someone just has to give you permissions to access
>> >>> >> https://github.com/Web3DConsortium/X3D/ . GitHub permissions are
>> not
>> >>> >> automatically synchronized with the Web3D membership status, as
>> far as
>> >>> >> I know.
>> >>> >>
>> >>> >> Don will hopefully answer better here.
>> >>> >>
>> >>> >> From my side, I really really want Doug to see my PR :) (But please
>> >>> >> bear in mind that it's work-in-progress, substantial edits are
>> >>> >> incoming, at 13th of March I hope to make it more-or-less-complete
>> :)
>> >>> >> ).
>> >>> >>
>> >>> >> Regards,
>> >>> >> Michalis
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------
>> >>>
>> >>> 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 132, Issue 18
>> >>> *******************************************
>> >>
>> >> _______________________________________________
>> >> x3d-public mailing list
>> >> x3d-public at web3d.org
>> >> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>> >
>> > _______________________________________________
>> > x3d-public mailing list
>> > x3d-public at web3d.org
>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200304/17a3bb25/attachment-0001.html>
More information about the x3d-public
mailing list