[x3d-public] Problem with inverted polygons/normals: actually texture transparency

Michalis Kamburelis michalis.kambi at gmail.com
Sun Nov 12 13:37:12 PST 2017


2017-11-12 15:40 GMT+01:00 doug sanden <highaspirations at hotmail.com>:

> Andreas,
> (please forward to x3d-public - I'm not subscribed)
> Spec change?
> There was that specification complaint by a few (Michalis and Doug):
> replace vs modulation in lighting model:
> currently replace:
> texture > CPV > material
> modulate:
> texture x CPV x material
> Modulate would in theory give us more permutations to play with, but would
> break old scenes.
> http://x3dgraphics.com/examples/X3dForWebAuthors/
> KelpForestExhibit/SharkLefty.x3d
> - has material, CPV and texture
>
> Same with transparency - it could be modulated with spec change, breaking
> old scenes.
> For example if you have a texture with transparency, and on top of that
> you want to apply an overall material transparency, it doesn't work because
> image.transparancy > material.transparency
> http://dug9.users.sourceforge.net/web3d/tests/DebateModulateAlpha/
> - 2 scenes with image transparency.  _05 has material transparency set to
> .5
> - I have this scene working in freewrl right now with an internal
> half-modulation setting, at the expense of some other scenarios not
> rendering as per specs.
> - the _10 (material transparency 1.0) scenes: freewrl and view3dscene show
> no sphere (invisible)
> -- Octaga, Instant, H3D show sphere with texture transparency pattern
> -- Vivaty white-screens
>
>
It seems to me that this issue (how "Material.transparency" interacts with
texture alpha) is an independent problem from the one that started this
thread.

In the case of
http://x3dgraphics.com/examples/X3dForAdvancedModeling/ShayDPixel/ShayDPixelVersion2Index.html
model, it does not modify Material.transparency, so it is always default
1.0.

The problem with
http://x3dgraphics.com/examples/X3dForAdvancedModeling/ShayDPixel/ShayDPixelVersion2Index.html
is that some viewers may use blending when a texture with alpha channel
(*any* alpha channel, even one filled with constant 1.0) is present. So the
question is whether to differentiate between "has alpha channel and we
should do blending" or "does not have alpha channel and blending is not
necessary" is done by analyzing the contents (like your
sniffImageChannels_bruteForce()  , CGE has something equivalent) or by
looking at image header.

So, here the decision is about "whether to use blending or not".

It is not about "which lighting equations to use". In the case of lighting
equations, my proposal ("always modulate",
https://castle-engine.sourceforge.io/x3d_multi_texturing.php#section_default_texture_mode
)
would mean that it doesn't matter whether the X3D browser analyses the
image contents or not. That's a comfortable situation, when the equations
work the same, regardless of whether the browser analyzes the image
contents.

But in the case of "whether to use blending or not", we don't have such
easy solution. Honestly, I'm not sure what should the specification say. I
know what my engine is doing (detect alpha by analyzing image contents, and
allow to override by ImageTexture.alphaChannel field,
https://castle-engine.sourceforge.io/x3d_implementation_texturing_extensions.php#section_ext_alpha_channel_detection
), and it seems to work well.

Hm, I realize that my lengthy explanation possibly complicated the whole
issue even more :) Sorry about that :)

Regards,
Michalis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171112/e2099377/attachment.html>


More information about the x3d-public mailing list