Transparent and transparency revisited

[rogerjames99]

@marcus

The common profile is fairly simple so would it be enough to say that the abstract pipeline a simple composition of F = S + T + R layers? Plus <extra> layers too?

I think you probably guess that I am going to say no. Let’s run the example I outlined in my previous reply through it.

Firstly lets get a precise definition of what we mean by the framebuffer term. I said before I would prefer to call it outcome but framebuffer is probably more easily recognised. Both refer to the current colour of a point in the 2d coordinate space.

So looking at the geometry that is rendered first. The points in the 2d coordinate space which correspond to this geometry would receive

F = S
subsituting S
F = 0 0 1 1

The geometry that is rendered second is more complex because some points in the 2d coordinate space will receive colour from a part of the texture where the colour is 0 1 0 1 and some will get a colour of 0 0 0 0. Because of the way we have arranged our orthographic camera the 3d points of the second geometry map onto the same points in 2d space as the first geometry. So taking the 0 1 0 1 colour first and using the equations from page 249 as a definition of how the compositon S + T is going to work (I think that is what you meant rather than just a simple addition). We have values for <transparency> of 1 and <transparent> 1 1 1 1 (the default).

F = (0 0 1 1 )* (1 - 1 * 1) + (0 1 0 1) * (1 * 1)
F = 0 1 0 1

and for the 0 0 0 0 points
F = (0 0 1 1) * (1 - 1 * 1) + (0 0 0 0) * ( 1 * 1)
F = 0 0 0 0

i.e. a green and black chequerboard rather than green and blue one.

So I would argue that for things to work as expected our abstract pipeline must include a an “output merger” phase as you show in figure 5.5 on page 94 of your book, and we need to know how that merger phase is to operate (I would also suggest that the “layer result” equations should not include framebuffer terms, but let’s leave that for later).

Roger

[marcus]

Hi Roger,

I think green/black is the expected results for a transparent layer that is always fully opaque as in your example. The blue in the framebuffer will never show through in that case. The texture (i.e. its alpha channel) needs to be in the <transparent> element so that for the 0 0 0 0 points you get that blue:

F = (0 0 1 1) * (1 - 0 * 1) + (0 0 0 0) * (0 * 1)
F = 0 0 1 1

[rogerjames99]

@marcus

Hi Roger,

I think green/black is the expected results for a transparent layer that is always fully opaque as in your example. The blue in the framebuffer will never show through in that case. The texture (i.e. its alpha channel) needs to be in the <transparent> element so that for the 0 0 0 0 points you get that blue:

F = (0 0 1 1) * (1 - 0 * 1) + (0 0 0 0) * (0 * 1)
F = 0 0 1 1

Marcus,

Well I think we have now finally gone full circle. Very early on in this thread I said.

@roger

I cannot help feeling that the ability to specify a texture in the transparent field instead of a color plays into this somewhere. If the same RGBA material were specified for both <diffuse> and <transparent> then in A_ONE opaque mode and provided that <transparency> was 1, the equations from the spec would produce the desired result. However this would mean that Google (and others) would be seriously broken.

To which you replied

@marcus

I have not seen SketchUp export content as you just described. They export a texture in the <diffuse> channel only. Google has confirmed to me in email that they are aware of this bug in their exporter and they characterize it as follows:

[quote=google]It WAS fixed, but the fix was rolled back prior to SketchUp 7 release, so the defect is still there. Ideally the fix would look something like this:

Code:
<transparent opaque=A_ONE><color>1 1 1 1</color></transparency>
<transparency><float>a</float></transparency>

where the defect is we are writing this:

Code:
<transparency>1 - a</transparency>

[/quote]
This describes the bug in the transparency value, which I am well aware of and was not what I was referring to at that point, which was that they only export the texture in the diffuse channel as you correctly point out. However the display of that model prior to export in Sketchup and after import on Google Earth will show previously rendered fragments (i.e. the framebuffer) through the transparent parts of the texture. I have attached an example sketchup file.

I think this interpretation is a common one and as far as I can see would be contrary to the intrepration you give in your last post.

Happy Christmas

Roger

[marcus]

Hi Roger,

Good idea to review the discussion thread as we have wandered around a bit. I’ve reviewed what we said and what Google has suggested as a fix and I agree that exporting constant colors in the transparent layer would not be correct for SketchUp and similar use cases. SketchUp is not yet exporting enough information to represent their rendering semantics within the common profile.

I remember that the <profile_COMMON> design evolved from an RGB to RGBA color model. One that that included a transparent layer that was activated by the presence of element data (e.g. <transparent> and/or <transparency>, but not <index_of_refraction>), much as the spec says. Contrary to my earlier statement, this is a modality and I’m reminded (again) why I personally prefer explicit flags in a data model over this implicit style of representation.

The transparent layer is there to represent refracted light color for applications and renderers that support the concept (e.g. SketchUp does not). The spec is saying that if the <transparent> and/or <transparency> are present then this layer is activated and to use certain calculations if so. Otherwise it is inactive and the alternative by implication is not specified.

As we’ve pointed out there can still be alpha channels in the color/texture from other color contributions. COLLADA (common profile) does not say how that alpha channel data is used other then that it is an RGBA color and thus alpha is almost always going to be an opacity value (i.e. use familiar alpha blending calculations).

[rogerjames99]

Hi Mark,

@marcus

Hi Roger,

Good idea to review the discussion thread as we have wandered around a bit. I’ve reviewed what we said and what Google has suggested as a fix and I agree that exporting constant colors in the transparent layer would not be correct for SketchUp and similar use cases. SketchUp is not yet exporting enough information to represent their rendering semantics within the common profile.

I apologise for not pointing out earlier that their reply had not really addressed the point I was making, it might have saved a bit of time . A lot of the usage we are seeing for the OSG Collada loader seems to come from Sketchip models. My original implementation of transparency stuck very closely to the spec and so produced behaviour that was not what Sketchup users expected, which led to numerous postings(complaints ) on the OSG list. Which of course was what sparked off this thread!

@marcus

I remember that the <profile_COMMON> design evolved from an RGB to RGBA color model. One that that included a transparent layer that was activated by the presence of element data (e.g. <transparent> and/or <transparency>, but not <index_of_refraction>), much as the spec says. Contrary to my earlier statement, this is a modality and I’m reminded (again) why I personally prefer explicit flags in a data model over this implicit style of representation.

That explains a lot! I wholeheartedly agree with your statement on explicit flags. They make things so much easier to understand for an ‘outsider’.

@marcus

The transparent layer is there to represent refracted light color for applications and renderers that support the concept (e.g. SketchUp does not). The spec is saying that if the <transparent> and/or <transparency> are present then this layer is activated and to use certain calculations if so. Otherwise it is inactive and the alternative by implication is not specified.

My problem in real life is that most of the Collada exporters I have come across always write both transparency and transparent terms even if they are the default opaque values. This leads to the complex “do they really mean transparent” code I have had to implement. A quick check through the Collada model bank will confirm this. This code currently tries to factor in the “opacity” of the incoming material colour as well. Obviously this gets really complex when the incoming colour has texture based components in it. It becomes just about impossible when RGB_X_OPAQUE modes are specified. Maybe I have to fall back to a “treat opaque transparent and transparency as not present” flag on the importer.

@marcus

As we’ve pointed out there can still be alpha channels in the color/texture from other color contributions. COLLADA (common profile) does not say how that alpha channel data is used other then that it is an RGBA color and thus alpha is almost always going to be an opacity value (i.e. use familiar alpha blending calculations).

Another real life problem is that many textures have alpha channels that the modeller does not want to use. So we are back once again to guessing when blending should be used. Again I will probably fall back on an importer flag for “turn on blender for textures with alpha” (or maybe its inverse). It seems to me that

the alternative by implication is not specified

is not really a viable option. Finally, are you going to re-raise this issue with Google.

Roger

P.S. I like the new look forum, but if the admin sees this can he/she please do something to stop the edit box I am entering this message in scrolling back to the start every time the mouse cursor leaves the box!

[rogerjames99]

Marcus,

A quick clarification.

@marcus

I remember that the <profile_COMMON> design evolved from an RGB to RGBA color model. One that that included a transparent layer that was activated by the presence of element data (e.g. <transparent> and/or <transparency>, but not <index_of_refraction>), much as the spec says. Contrary to my earlier statement, this is a modality and I’m reminded (again) why I personally prefer explicit flags in a data model over this implicit style of representation.

Can you indicate to which earlier statement you are referring, and what you mean by modality in that context.

Roger

[marcus]

@rogerjames99

A quick clarification.[quote=marcus]Contrary to my earlier statement, this is a modality and I’m reminded (again) why I personally prefer explicit flags in a data model over this implicit style of representation.

Can you indicate to which earlier statement you are referring, and what you mean by modality in that context.
Roger[/quote]
I was referring to this post and my deemphasis of ‘run-time mode’.

[rogerjames99]

@marcus

I was referring to this post and my deemphasis of ‘run-time mode’.

Thanks Mark,

Thats what I thought, and what I assumed in my original implementation. However as I mention in this message I soon found out that almost all the models I was coming across included both the transparent and transparency terms even for opaque materials. Turning on the blender and sorting those geometries so that they are drawn after everything else was not very performant and did not give good results when everything was marked that way !

Happy New Year

Roger

[rogerjames99]

@marcus

Good idea to review the discussion thread as we have wandered around a bit. I’ve reviewed what we said and what Google has suggested as a fix and I agree that exporting constant colors in the transparent layer would not be correct for SketchUp and similar use cases. SketchUp is not yet exporting enough information to represent their rendering semantics within the common profile.

Hi Marcus,

My turn to review now.

I think we have now arrived at this (But I may be wrong!)

1. The following statement from page 7-5 of the 1.5.1 spec.

If either <transparent> or <transparency> exists then transparency rendering is activated, the
renderer needs to turn on alpha blending mode
Should be treated as part of the formal specification. i.e. The alpha blending mode is controlled by presence of one or the other of these elements.

2. The correct way to specify an effect in which the alpha component of a texture in (say) the diffuse channel is to be used to control the blending of the material into the scene is to specify the same texture in the transparent channel. For example

<lambert>
   <diffuse>
      <texture texture="material_0_1_0-image-sampler" texcoord="UVSET0"/>
   </diffuse>
   <transparent>
      <texture texture="material_0_1_0-image-sampler" texcoord="UVSET0"/>
   </transparent>
</lambert>

3. Sketchup is not conformant to the spec in this area.

I have started another thread to try to collate a set of examples of how other exporters write transparency in this simple case.

Roger

[pinacollada]

Roger,

Based on what you have said here, I was wondering if you have any experience with Cinema4D…

[rogerjames99]

@pinacollada

Roger,

Based on what you have said here, I was wondering if you have any experience with Cinema4D…

None whatsoever I am afraid.