[x3d-public] PhysicalMaterial's texture types

Holger Seelig holger.seelig at yahoo.de
Tue Dec 14 09:49:54 PST 2021


Thank you very much for this clarification, now I see much more clear what is meant. I think I will go with this explanations, although it is not easy to implement this in JavaScript, but no one said its easy.

Best regards,
Holger

> Am 12.12.2021 um 18:29 schrieb Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>:
> 
> Thank you very much for close scrutiny.
> 
> If there are editorial improvements to be made in the specifications prose, or further explanations, or even further limits within the typing of fields, those are all options while we are finalizing committee draft for X3D4. Please consider the best long-term solutions.
> 
> v/r Don
> From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Michalis Kamburelis <michalis.kambi at gmail.com>
> Sent: Sunday, December 12, 2021 02:56
> To: Holger Seelig
> Cc: X3D
> Subject: Re: [x3d-public] PhysicalMaterial's texture types
>  
> >
> > PhysicalMaterial’s texture type is X3DSingleTextureNode, which includes X3DEnvironmentTextureNode, which makes no sense, and X3DTexture3DNode’ which is hard to implement. I don’t think that GLTF specifies that these texture type should work, it is designed for simplicity.
> >
> > The same is for new X3Dv4 Material texture type.
> >
> > I think that X3DTexture2DNode is enough for these special textures.
> >
> 
> Im my eyes, both cubemaps (X3DEnvironmentTextureNode) and 3D textures
> (X3DTexture3DNode) make sense in "Material.diffuseTexture" and
> "PhysicalMaterial.baseTexture"
> exactly as they did for "Appearance.texture" field in X3D 3. For
> consistency, it follows they should also be allowed in all
> "Material.xxxTexture" and "PhysicalMaterial.xxxTexture" slots.
> 
> Use-cases:
> 
> - 3D texture allows you to apply a volume of pixels that can have
> trivial texture coordinates derived from 3D positions. E.g. to apply a
> noise to make a marble, or to make a fog.
> 
> - Cubemap texture allows you to make define colors based on normals,
> which includes the possibility to make mirrors (colors based on
> reflected vector). Like on
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fx3d_implementation_cubemaptexturing.php&data=04%7C01%7Cbrutzman%40nps.edu%7Cdb83275833064527b87b08d9bd5dfe59%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637749034112645372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TmJroHoi8g%2BC0a49%2F6rxvbuEYqTZ5%2FxDCz1jy3hwKFc%3D&reserved=0 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fx3d_implementation_cubemaptexturing.php&data=04%7C01%7Cbrutzman%40nps.edu%7Cdb83275833064527b87b08d9bd5dfe59%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637749034112645372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TmJroHoi8g%2BC0a49%2F6rxvbuEYqTZ5%2FxDCz1jy3hwKFc%3D&reserved=0>
> 
> I am using these features in Castle Game Engine :) Note that in both
> cases, you likely want to use TextureCoordinateGenerator also.
> 
> These are the general reasons for using these textures (regardless of
> X3D), so it follows we'd like to allow them in X3D most important
> texture fields -- Material.diffuseTexture (if you use Phong) or
> PhysicalMaterial.baseTexture (if you use PBR). And allowing them on
> other texture fields is just consistent -- e.g. when you provide
> colors using 3D texture to "Material.diffuseTexture", you likely want
> to provide normals or specular values (if you provide them by texture
> at all) using the same texture type, which means you also want to use
> 3D texture there.
> 
> This also follows how GPUs think about textures. Texture is just a
> function to map some values (texture coordinates) into something else
> (some material parameter), that you can use to render the shape. 2D
> textures, 3D textures, cubemaps take different types of data, but then
> their usage is very similar -- you have some input (texture coord),
> you query the texture, you get a result. An implementation can mostly
> just allow all GPU textures types throughout the code, at least that's
> how I see it in CGE.
> 
> As for glTF only allowing 2D textures: that is true, but glTF
> specification doesn't talk about other textures than 2D at all. They
> did it for simplicity. In X3D, we had already invented cubemaps and 3D
> textures. It would be a shame to then not use them for
> "Material.xxxTexture" and "PhysicalMaterial.xxxTexture" slots. I think
> it's possible that glTF will follow at some point -- they'll add
> 3D/cubemap textures to glTF (e.g. their image-based lighting
> extensions need cubemaps, and right now invent it in isolation), and
> then allow them in material fields (though I speculate here, I didn't
> actually see glTF development in this area yet).
> 
> As for these texture types being harder to implement: that is true,
> and, combined with the fact that 3D/cubemap texture usage is much
> smaller than 2D texture usage, I understand some X3D browsers just
> don't want to go there. That is why they remain in separate X3D
> components, for 3D textures and cubemaps. We don't require all X3D
> browsers to implement 3D/cubemap textures in "Material.xxxTexture" and
> "PhysicalMaterial.xxxTexture" slots, just as we didn't require all X3D
> browsers to implement 3D/cubemap textures in "Appearance.texture" in
> X3D 3.
> 
> Note that I don't really treat the "Material.xxxTexture" and
> "PhysicalMaterial.xxxTexture" slots as something for "special
> textures". On the contrary, I treat these fields as a primary way to
> use textures in X3D. This is consistent with texture usage in glTF,
> Collada -- they all define textures inside material slots. I treat
> "Appearance.texture" as just a historic artifact -- from simpler (X3D
> 3) times when people wanted the texture to only affect Phong diffuse
> parameter.
> 
> I hope this helps. Discussion is absolutely most welcome. If there is
> a general consensus that "we should limit these textures to 2D", I can
> live with it -- and allow there 3D textures/cubemaps only as Castle
> Game Engine extensions.
> 
> Regards,
> Michalis
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_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/20211214/80a5b7a1/attachment.html>


More information about the x3d-public mailing list