|
From: Michalis K. <mic...@gm...> - 2016-08-21 18:02:34
|
Hi! I'm back from a short vacation. Cool that things are going forward! > The reason for the split: the web3d Lighting equation, and table 17-3, the diffuse Drgb comes from > Texture, not material.diffuse, when there's a texture. Note that in Castle Game Engine and view3dscene, we deliberately decided to not follow X3D specification at this *one single point*. Instead, we chose much simpler rule: "the texture colors are by default always multiplied by the material color". This is in contrast this with X3D specification, that requires RGB textures (but not grayscale textures) to override (replace) material color. It's not a decision I took lightly. And it's the only such case when I deliberately decided that the X3D specification is so bad that we just have to knowingly break it. This explains why shader code in CGE is simpler around this place. If you're interested in the details, see the http://castle-engine.sourceforge.net/x3d_multi_texturing.php#section_default_texture_mode .The X3D specification seemed: 1. Really inconsistent. - The specification requires treating grayscale textures differently that RGB textures -- grayscale textures are multiplied by color, while RGB textures replace the color. This is counter-intuitive for authors. - Another inconsistency is with MultiTexture specification, that uses MODULATE by default, for all texture types (RGB and grayscale). 2. Specification makes the material "diffuse" color useless in the presence of an RGB texture, which is a shame. If you remove this limitation, you get nice features (at no cost), e.g. you can animate Material.diffuse to animate shape color (regardless if it's textured or not). 3. X3D browsers were already inconsistent with implementing it. See the "9. material_color_mixed_with_texture_color:" test results on http://castle-engine.sourceforge.net/x3d_multi_texturing.php . Regards, Michalis |