Apache OpenOffice (AOO) Bugzilla – Issue 107500
Transparency in 3D charts is wrong
Last modified: 2017-05-20 11:41:53 UTC
See the example file. The left chart has the series in default order, and the transparency looks like it's evaluated from back to front. In the right chart the 3D view was rotated 180 degrees and the series and axis inverted, then the order looks right.
Created attachment 66537 [details] Example file
iha->aw: this looks like a problem with the rendering engine, please evaluate.
AW: Interesting effect. Need to take a closer look at what the default renderer does here. It's a Z-Buffer, so the mix of transparent parts should be independent from the order of rendering.
AW: Reason is the standard ZBuffer technique. For overlapping transparent geometry, it gets necessary to paint from back to front, after all non-transparent were painted. To do so there are two possibilities: (a) remember all transparent pixels and solve them after rendereiung or (b) remember all transparent geometries and render them Z-sorted after all non-transparent. It makes no sense to do two rendering runs (as currently used) since the 2nd run for transparent paint also would need to remember all geometry and sort in Z, thus (b) is the logical consequence. I first tried (a) since it would have been easier to implement, but in normal scenes easily 5 mio pixels need to be remembered. For a pixel with 12bytes (X,Y,Z,color,opacity) this gets to expensive. Thus i had to implement (b) what is not trivial since the current state including texturing and transparent texturing for each transparent geometry needs to be buffered. To do so, i moved the texture::GeoTexSvx usages in DefaultProcessor3D to refcounted using boost::shared_ptr and adapting all usages consequently. Works now as intended. The only extra requirements are some more memory (only little compared to (a)) and one sort for Z.
Okay, done.
AW->WG: Please verify as described.
Target adapted.
Verified in CWS.