Hi,
I just found out that if I try to create a TEveBoxSet and manually set the color for each box I add to it then the transparency setting for the given color is never applied.
I see this issue on both OSX (ROOT version 6.18/00) and Linux (ROOT version 6.14/04)
Here a small reproducer based on the boxset.C tutorial macro
TEveBoxSet *boxset(Float_t x = 0, Float_t y = 0, Float_t z = 0, Int_t num = 100, Bool_t registerSet = kTRUE) {
TEveManager::Create();
auto q = new TEveBoxSet("BoxSet");
q->Reset(TEveBoxSet::kBT_AABox, kTRUE, 64);
float dim = 100.0 / num;
float zmin = 0.0, zmax = 100.0;
for (Int_t i = 0; i < num; ++i) {
q->AddBox(0., 0., zmin + i * zmax / num, dim, dim, dim);
Char_t trans = 100 * ((float)i / num);
// q->DigitColor(kGreen, i);
q->DigitColor(0, 255, 0, trans);
}
q->RefitPlex();
TEveTrans &t = q->RefMainTrans();
t.SetPos(x, y, z);
if (registerSet) {
gEve->AddElement(q);
gEve->Redraw3D(kTRUE);
}
return q;
}
Sorry, this was a crazy week with chep just ending + travel etc. I think you need to set the main transparency of the box-set to something more than 0 (IIRC, q->SetMainTransparency(50)). The GL renderer decides in which pass to draw the object based on this. I’ll give it a try as soon as I can.
Just a curiosity, is this the intended behaviour? Because it was quite puzzling, it would never have occurred to me that the overall transparency of the boxset was overriding the one of the digits.
Yes, it is … because opaque objects are rendered first with blending disabled and the transparent ones are rendered in the second pass, with blending enabled. And an object is thrown into opaque / transparent vectors based on its MainTransparency.
So the problem was that the renderer thought your object is opaque and drew it in the pass where transparency was disabled in GL.