[x3d-public] X3D4 PBR specification review: updates and demos
Michalis Kamburelis
michalis.kambi at gmail.com
Wed Mar 4 18:13:54 PST 2020
You can look at Castle Game Engine shader code too:
https://github.com/castle-engine/castle-engine/tree/master/src/x3d/opengl/glsl/source
Notice we have a subdirectory for each lighting model:
- Phong
- Unlit
- Physical (PBR, compatible with glTF)
The core of PBR calculations is inside
https://github.com/castle-engine/castle-engine/blob/master/src/x3d/opengl/glsl/source/lighting_model_physical/shading_phong.fs
. Portions of it have been taken from glTF-Sample-Viewer already :)
I do hope you will get access to my PR
https://github.com/Web3DConsortium/X3D/pull/8 , hope Don can resolve
it. I took a lot of effort to write there a prose that explains
everything, and my goal was to make it available and understandable
exactly for people like you -- who implement X3D browsers. And I
definitely would be happy to hear your review of i (bearing in mind
it's still work-in-progress).
Regards,
Michalis
czw., 5 mar 2020 o 02:41 GPU Group <gpugroup at gmail.com> napisał(a):
>
> OK thanks for clarifying Michalis, will spend a few days trying to implement, based on the khronos example.
> -Doug
> https://github.com/KhronosGroup/glTF-Sample-Viewer/
>
> On Wed, Mar 4, 2020 at 6:28 PM Michalis Kamburelis <michalis.kambi at gmail.com> wrote:
>>
>> Doug,
>>
>> The "xxxTextureChannel" isn't about choosing the purpose of the
>> red/green/blue/alpha channels. The arrangement of data in
>> red/green/blue/alpha channels will be determined by the spec in X3D
>> v4. E.g. for specularShininessTexture, the texture RGB is multiplied
>> by the specularColor, and the texture alpha is multiplied by the
>> shininess. Reasons:
>>
>> - Trying to make the red/green/blue/alpha meaning configurable (as
>> e.g. InstantReality CommonSurfaceShader did it) is very difficult to
>> implement efficiently, in my experience. So it's better if the
>> specification *dictates* this arrangement, and then browsers can
>> implement it efficiently.
>>
>> - And glTF also doesn't make it configurable. E.g. glTF says
>> explicitly how metallicRoughnessTexture is packed (roughness in green,
>> metallic in blue), and there's no way to customize it.
>>
>> The purpose of my "xxxTextureChannel" is to choose the appropriate
>> texture coordinate slot (and texture transform slot).
>>
>> Which tells me that
>>
>> - I really want you to get access to my PR, as this is explained there :)
>>
>> - I chose the wrong name for this field :) The name "channel" was
>> clearly misleading here. Maybe "xxxTextureIndex" (it is tempting to
>> call it "xxxTextureCoordinateIndex", but I want to indicate both
>> texture coordinate and texture transform).
>>
>> I have to think how to name it to be most natural.
>>
>> Regards,
>> Michalis
>>
>> czw., 5 mar 2020 o 02:02 GPU Group <gpugroup at gmail.com> napisał(a):
>> >
>> > 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
>> >
>> > _______________________________________________
>> > 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
More information about the x3d-public
mailing list