[x3d-public] X3D4 PBR specification review: updates and demos
GPU Group
gpugroup at gmail.com
Wed Mar 4 17:40:49 PST 2020
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200304/b8a5ff5e/attachment-0001.html>
More information about the x3d-public
mailing list