Re: [FreeWRL-develop] Shaders > Castle Compositing Shaders

[Michalis K. <mic...@gm...>]

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