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