Khronos Public Bugzilla
Bug 39 - Notes on transparent/transparency elements are still unclear
Notes on transparent/transparency elements are still unclear
Status: RESOLVED DUPLICATE of bug 52
Product: COLLADA
Classification: Unclassified
Component: Specification
1.4.1
All All
: P3 normal
: Spec 1.4.1 2nd Ed.
Assigned To: Ellen Finch
Mark Barnes
: collada-fx
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-18 07:44 PDT by Thomas Bucher
Modified: 2011-09-09 11:01 PDT (History)
1 user (show)

See Also:
elf: relnotes_141b+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Bucher 2007-04-18 07:44:32 PDT
The specification of transparent and transparency elements is still unclear, as many DCCs do not export the same data... and thus its hard to import COLLADA from all of them.

Even if 1.4.1 release notes clarify those elements, it is still unclear as I explain in this topic (see the last posts) :

https://collada.org/public_forum/viewtopic.php?p=2585#2585
Comment 1 Mark Barnes 2007-04-18 18:27:29 PDT
Ellen do you have enough information to write this clarification?
Comment 2 Mark Barnes 2007-07-09 18:42:21 PDT
Note from internal issue 400...

If either transparent or transparency exist then this style of rendering is activated...ie assume that the renderer needs to enable (otherwise disabled) alpha blending mode.

From there... 
using the equation we follow to combine the two values...

If <transparent> does not exist then it has no affect on the equation's result. And the opaque mode is the default opaque mode. This is equivalent to a color that is 1.0,1.0,1.0,1.0

If <transparency> does not exist then it too has no affect on the equation's result. This is equivalent to a color that is 1.0

Comment 3 Ellen Finch 2007-07-27 18:24:44 PDT
Adding to 1.4.1B release notes.
Comment 4 Ellen Finch 2007-08-30 15:35:57 PDT
Duplicate of internal issue 400 https://cvs.khronos.org/bugzilla/show_bug.cgi?id=400 .

*** This bug has been marked as a duplicate of bug 52 ***
Comment 5 Mark Barnes 2011-09-09 11:01:24 PDT
(In reply to comment #2)
> Note from internal issue 400...
> 
> If either transparent or transparency exist then this style of rendering is
> activated...ie assume that the renderer needs to enable (otherwise disabled)
> alpha blending mode.
> 
> From there... 
> using the equation we follow to combine the two values...
> 
> If <transparent> does not exist then it has no affect on the equation's result.
> And the opaque mode is the default opaque mode. This is equivalent to a color
> that is 1.0,1.0,1.0,1.0
> 
> If <transparency> does not exist then it too has no affect on the equation's
> result. This is equivalent to a color that is 1.0

From: Daniel Horowitz [mailto:dhorowitz@nvidia.com]
To: public_collada@khronos.org, collada_adopters@khronos.org
Sent: Thu, 08 Sep 2011 20:09:57 -0700
Subject: RE: [COLLADA] [Collada Adopters] Re: [Public COLLADA] what color this material should be?

The final surface is not transparent because the alpha value does not directly correlate to transparency.

While you are thinking about the alpha value right, you have to take into account the default render state assumed by the profile_COMMON.

We specified it in the section “Rendering: Determining Transparency (Opacity)”.  It roughly stated that if <transparent> or <transparency> were not added then blending is not enabled to begin with so the alpha value would not be considered.

Same thing happens in d3d and gl.  Even if you have an alpha value but don’t enable the blending states then you get no transparency.

Of course if you are opposed to messing with the blend state in your API then you could mess with the alpha value, forcing it to 1, but that gets nasty if you were using a texture, so I’d recommend you just support the blend state toggling properly.

Best regards,

    -Daniel Horowitz
    NVIDIA Corportion