bugGNU Octave - Bugs: bug #39535, FaceAlpha property not working for...

 
 

bug #39535: FaceAlpha property not working for OpenGL backend

Submitter:  Rik <rik5>
Submitted:  Fri 19 Jul 2013 11:01:35 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 29 Oct 2017 01:25:12 AM UTC, comment #28: 

I added a note to the NEWS file telling users of 4.4 that an initial implementation of alpha transparency exists (http://hg.savannah.gnu.org/hgweb/octave/rev/7dd3ab97ccd5)

Rik <rik5>
Group administrator
Sat 28 Oct 2017 09:44:52 PM UTC, comment #27: 

I pushed the patch here:

http://hg.savannah.gnu.org/hgweb/octave/rev/8365e584ebd8

I agree that now we have this basic support and the limitations are documented we can treat missing features in their own bug report.

Pantxo Diribarne <pantxo>
Group Member
Sat 28 Oct 2017 05:59:54 PM UTC, comment #26: 

I would prefer new bug reports to be opened for specific issues. 

From a process perspective, having a single bug tracker item for an ambiguous feature like "Make Octave Great!" is difficult.  The specific issue being worked on is always changing, it is not clear whether an issue is resolved and when the bug can be closed, many people drop off the CC list when there get to be more than 75 comments on a single report, etc.

--Rik

Rik <rik5>
Group administrator
Sat 28 Oct 2017 11:20:14 AM UTC, comment #25: 

@Pantxo: Sorry for taking so long. Your patch looks good to me. The print-out results (svg) look even better than on-screen when it comes to layered semi-transparent faces.
It also produces the same results for me with qt(4) and fltk.

From my point of view, you can go ahead and push it.

Should we leave this bug report open after that or open dedicated reports for the remaining points. The following comes to mind:
- Support for non-double facealpha.
- Better rendering order.
- Support for transparency in other output formats than svg.
- And probably lots more...

Markus Mützel <mmuetzel>
Group administrator
Thu 26 Oct 2017 11:57:20 AM UTC, comment #24: 

Ok, I'll wait for Markus' approval and push the patch from comment #22.

Pantxo Diribarne <pantxo>
Group Member
Tue 24 Oct 2017 04:39:40 PM UTC, comment #23: 

Using the alpha5 patch, I still have the same problem that the onscreen rendering is fine, but the printout is either opaque (Qt) or correctly translucent (FLTK).

I have two versions of gl2ps installed and maybe the Qt toolkit is picking up the wrong one?


ii  gl2ps-1.4.0                                     1.4.0-1
         amd64        OpenGL to Postscript Library
ii  libgl2ps0                                       1.3.8-1.2
         amd64        Lib providing high quality vector output for OpenGL application


I'm willing to say that this is a problem specific to my hardware and software setup.  If Pantxo and Markus can agree that the patch is correctly working then you should check it in.

Rik <rik5>
Group administrator
Mon 23 Oct 2017 10:16:50 AM UTC, comment #22: 

Sorry, I sent the wrong patch. Here is an updated and simplified patch. Looking at gl2ps sources I could gather that GL2PS_BLEND has 2 quirks:

  • it is more of an equivalent of GL_ALPHA_TEST than GL_BLEND
  • it is set for the whole viewport which makes most of the modifications I brought to gl-render.h/cc not necessary and eventually wrong.



(file #42236)

Pantxo Diribarne <pantxo>
Group Member
Sun 22 Oct 2017 09:33:00 PM UTC, comment #21: 

@Rik: maybbe "__opengl_info__" can help in determining which opengl implementation you rely on when using fltk and Qt on your system?

Pantxo Diribarne <pantxo>
Group Member
Sun 22 Oct 2017 09:27:51 PM UTC, comment #20: 

@Markus: the attached cset conditions the use of GL2PS_OCCLUSION_CULL on the presence of transparent objects polygons (not lines) in an axes. With this cset, the following example from comment #5 works for me in printout even though it does not work onscreen:


[x,y,z] = meshgrid (-2:0.2:2, -2:0.2:2, -2:0.2:2);
val = x.^2 + y.^2 + z.^2;
fv1 = isosurface (x, y, z, val, .6);
patch (fv1, "FaceAlpha", .3, "FaceColor", "r", "EdgeColor", "none");
fv2 = isosurface (x, y, z, val, 1);
patch (fv2, "FaceAlpha", .3, "FaceColor", "g", "EdgeColor", "none");
view (3);
print /tmp/tst.svg
open /tmp/tst.svg


The following example with surfaces shows that printing "mostly" renders as on screen for surfaces too


clf ();


subplot (2,2,1)
h = surface ();
xd = get (h, "xdata") + .5;
yd = get (h, "ydata") + .5;
zd = get (h, "zdata") * 0;
set (h, "zdata", zd);
surface (xd, yd, zd);

title "2D no transparency\nSpurious lines in printout"

subplot (2,2,2)
h = surface ();
xd = get (h, "xdata") + .5;
yd = get (h, "ydata") + .5;
zd = get (h, "zdata") * 0;
set (h, "zdata", zd);
surface (xd, yd, zd, "facealpha", 0.5);

title "2D transparency"

subplot (2,2,3)
h = surface ();
xd = get (h, "xdata") + .5;
yd = get (h, "ydata") + .5;
zd = get (h, "zdata") + 1;
## push axes background away so that it does not interfere
zlim ([-1 2]);
h = surface (xd, yd, zd, "facealpha", 0.5);

title "3D, transparent drawn last"

subplot (2,2,4)
h = surface ("facealpha", 0.5);
xd = get (h, "xdata") + .5;
yd = get (h, "ydata") + .5;
zd = get (h, "zdata") + 1;
h = surface (xd, yd, zd);
## push axes background away so that it does not interfere
zlim ([-1 2]);

title "3D, transparent drawn first"

print /tmp/tst.svg


(file #42222)

Pantxo Diribarne <pantxo>
Group Member
Sun 22 Oct 2017 06:07:13 PM UTC, comment #19: 

@Rik: I might have mis-read. Are you saying transparency works on screen with fltk but not with qt? Are you using qt4 or qt5?

Markus Mützel <mmuetzel>
Group administrator
Sun 22 Oct 2017 05:31:41 PM UTC, comment #18: 

@Rik: It looks like some viewers do not support rendering transparency. E.g. Evince didn't show transparency for both Pantxo and me while the very same pdf was rendering with transparency when I opened it in Adobe Acrobat Viewer. Which programs did you use to display the svg and pdf?

@Pantxo: It sound reasonable to delay that change.
A feasible improvement could be to first render all objects that DO NOT contain any semi-transparent faces, turn the depth check (occlusion) off after that and than render the objects that DO contain semi-transparent faces. That could help to reduce the number of faces (in some cases) but doesn't sound as complicated as true back to front sorting.
I never studied what "gl2ps-print" does and how it is doing it. Thus, I don't know whether that would be even possible.
Anyhow, that can probably wait for a later changeset.

The same change might improve some situations where solid objects disappear behind transparent objects in gl-render.

What do you think?

Markus Mützel <mmuetzel>
Group administrator
Sat 21 Oct 2017 09:25:52 PM UTC, comment #17: 

@Markus: For 3D scenes we would need to remove the GL2PS_OCCLUSION_CULL option so that primitives that have been tested to be at the back are drawn anyway. That works with your example but the size of the file is then 14M and inkscape takes a few minutes to open the svg (which finally looks good). 



Pantxo Diribarne <pantxo>
Group Member
Sat 21 Oct 2017 08:39:33 PM UTC, comment #16: 

I can't get even the basic transparent test code from example #9 to work.  It looks fine on screen, but both the svg and pdf are solid (no transparency at all).

Correction, it works if I use FLTK but fails with Qt.  This is with Linux Mint based on Ubuntu Xenial.


Rik <rik5>
Group administrator
Sat 21 Oct 2017 08:31:51 PM UTC, comment #15: 

@Markus: yes I also hopped that gl2ps would sort primitives better, but on the other hand I don't think we want to pretend we are able to print transparent 3D scenes at this stage :-).

Pantxo Diribarne <pantxo>
Group Member
Sat 21 Oct 2017 08:11:00 PM UTC, comment #14: 

The patch I pushed enables limited rendering of transparent patches and surfaces on screen (no sorting primitives). Pantxo's patch enables printing of transparent patches (not sure about surfaces) to svg and pdf. That patch needs to be reviewed and pushed.

Markus Mützel <mmuetzel>
Group administrator
Sat 21 Oct 2017 08:06:23 PM UTC, comment #13: 

@Markus: You pushed a patch for this.  Is there more to be done?  Does Pantxo's patch from comment #9 also need to be reviewed and pushed.

Rik <rik5>
Group administrator
Sat 21 Oct 2017 07:58:37 PM UTC, comment #12: 

I tried with your patch from comment #11 and it compiles without any errors.
With your test from comment #9, I also see opaque faces in Evince. But the same pdf renders with transparency in Acrobat Reader. The svg also looks good.

I also tried to print the example with the surfaces from comment #8. But both the svg and the pdf didn't look good and it took ages to render in Acrobat Reader. Is your patch supposed to enable printing of transparent surfaces as well?
I tried the following:

clf
[Xs, Ys, Zs] = sphere ();
hs = surf (2*Xs, 2*Ys, 2*Zs-3);
hold on

[Xp, Yp, Zp] = peaks ();
hp = surf (Xp, Yp, Zp, "facealpha", 0.8, "edgecolor", "none");
axis equal
view (2)
print alpha_surf.svg
print -dpdflatexstandalone alpha_surf.tex
system ("pdflatex alpha_surf.tex")


Markus Mützel <mmuetzel>
Group administrator
Thu 19 Oct 2017 09:24:15 AM UTC, comment #11: 

I attached a cleaned up version of the patch in comment #9

(file #42193)

Pantxo Diribarne <pantxo>
Group Member
Tue 17 Oct 2017 06:27:26 PM UTC, comment #10: 

Pantxo, thanks for reviewing. I pushed that patch here: http://hg.savannah.gnu.org/hgweb/octave/rev/78ff6ba5cbb1

I will try printing with your patch and report back with the results.

Markus Mützel <mmuetzel>
Group administrator
Mon 16 Oct 2017 07:27:21 PM UTC, comment #9: 

@Markus: sorry for the delay. I tested the patch and it works fine. The limitations are clearly documented and I could see no measurable impact on performance. Can you push this cset please?

I attached a patch that adds support for printing transparent patches to svg at least. The "pdflatext(standalone)" format also seams to support polygon transparency when rendered in Okular. Evince renders opaque surfaces and I did not test in acrobat.

I tested with this:


clf
rectangle("position", [0.2 0.2 0.5 0.4], "facecolor", "g", "FaceAlpha",.3)
rectangle("position", [0.3 0.1 0.3 0.6], "facecolor", "y", "FaceAlpha",.3)
axis([0 1 0 1])
print /tmp/toto.svg
open /tmp/toto.svg
print -dpdflatexstandalone /tmp/toto.tex
cd /tmp
system ("pdflatex toto.tex")
system ("okular toto.pdf")


(file #42169)

Pantxo Diribarne <pantxo>
Group Member
Tue 10 Oct 2017 07:13:32 PM UTC, comment #8: 

Attached is a patch that also adds the same basic support for facealpha to surface objects.

The following shows a circle that is covered by a semi-transparent peaks surface that partly clips through the circle:

close all
figure ();
[Xs, Ys, Zs] = sphere ();
hs = surf (2*Xs, 2*Ys, 2*Zs-3);
hold on

[Xp, Yp, Zp] = peaks ();
hp = surf (Xp, Yp, Zp, "facealpha", 0.8, "edgecolor", "none");
axis equal
view (2)


Since there are no sorting primitives, the solid objects have to be drawn before the ones with transparency. You can see the limits when rotating the plot or by reversing the order in the above example.

(file #42116)

Markus Mützel <mmuetzel>
Group administrator
Sun 08 Oct 2017 02:11:41 PM UTC, comment #7: 

@Pantxo: Thank you for picking this up. The attached patch adds some documentation for the facealpha property of patch objects to the manual.

Scrolling through the code for draw_surface it looks like a similarly limited support for transparency should be possible for surface objects as well. I'll report back after trying.

(file #42089)

Markus Mützel <mmuetzel>
Group administrator
Fri 06 Oct 2017 08:12:19 AM UTC, comment #6: 

@Markus: this is much better than what we currently have so I'd like to push this patch (and another one I'll write to enable support for printing transparent patches in svg and pdflatex).
Could you document that "facealpha" works for double values.

Do you think the same kind of job can be done on surface objects?

Pantxo Diribarne <pantxo>
Group Member
Sun 12 Mar 2017 05:13:21 PM UTC, comment #5: 

Attached is a patch that adds some very primitive support for alpha on faces of patch objects. It does not include any sorting primitives. However, it might give better results than the current implementation (which hides patches with alpha != 0) in very simple cases as the ones from bug #50520:

graphics_toolkit("qt")
figure
rectangle("position", [0.2 0.2 0.5 0.4], "facecolor", "g", "FaceAlpha",.3)
rectangle("position", [0.3 0.1 0.3 0.6], "facecolor", "y", "FaceAlpha",.3)
axis([0 1 0 1])


or bug #46538:

T =[
1 2 4
2 3 5
4 5 7
5 6 8
5 4 2
6 5 3
8 7 5
9 8 6];

P = [
0.00000 0.00000 0.00000 0.50000 0.50000 0.50000 1.00000 1.00000 1.00000
0.00000 0.50000 1.00000 0.00000 0.50000 1.00000 0.00000 0.50000 1.00000];

x = P(1,:); y = P(2,:);
z = 1 - (x-0.5).^2 - (y-0.5).^2;
i=1:length(T);

a1 = [ x(T(i,1)) ; y(T(i,1)) ; z(T(i,1)) ];
a2 = [ x(T(i,2)) ; y(T(i,2)) ; z(T(i,2)) ];
a3 = [ x(T(i,3)) ; y(T(i,3)) ; z(T(i,3)) ];

s = ( a1(1:2,i) + a2(1:2,i) + a3(1:2,i) )./3;

r1 = a3(:,i) - a1(:,i);
r2 = a2(:,i) - a1(:,i);
n = cross(r1,r2);

dx = n(1,:)./n(3,:);
%dy = n(2,:)./n(3,:);

patch('Faces',T,'Vertices',P','FaceVertexCData',dx','FaceColor','flat','FaceAlpha',.8);


or the one in comment #0.

Since no sorting primitives are included, it fails with more complex layouts as in:

[x,y,z] = meshgrid (-2:0.2:2, -2:0.2:2, -2:0.2:2);
val = x.^2 + y.^2 + z.^2;
fv1 = isosurface (x, y, z, val, .6);
patch (fv1, "FaceAlpha", .3, "FaceColor", "r", "EdgeColor", "none");
fv2 = isosurface (x, y, z, val, 1);
patch (fv2, "FaceAlpha", .3, "FaceColor", "g", "EdgeColor", "none");


It also only adds support for double valued "FaceAlpha". "flat" or "interp" skip rendering the faces (like without the patch).

Even if this is by far no complete implementation of transparency, this very limited support might be helpful in some use cases.

(file #39977)

Markus Mützel <mmuetzel>
Group administrator
Fri 18 Nov 2016 03:32:57 PM UTC, comment #4: 

This bug is still present in the current dev 4.3.0 (39f39eb4e476).

Pantxo Diribarne <pantxo>
Group Member
Sat 12 Sep 2015 10:22:41 PM UTC, comment #3: 

I am pinging this report as it is still valid.

facealpha < 1 doesn't render in opengl graphics toolkits (fltk, qt)

Juan Pablo Carbajal <juanpi>
Group Member
Fri 19 Jul 2013 11:58:32 PM UTC, comment #2: 

Rats!  I had thought it might be something simple like not passing a parameter over to OpenGL.  I see that it is definitely non-trivial.  I'll leave the bug report open as a placeholder.

Rik <rik5>
Group administrator
Fri 19 Jul 2013 11:29:19 PM UTC, comment #1: 

Support for transparency is globally not implemented yet in the OpenGL renderer. Although, transparency effects are possible in OpenGL, it's not trivial and requires sorting primitives from back to front [1]. I had some implementation in JHandles, but I never ported it to octave, IIRC I found is sub-optimal.

This was a suggestion for a GSoC project, but it wasn't picked up.

[1] http://www.opengl.org/archives/resources/faq/technical/transparency.htm

Michael Goffioul <goffioul>
Fri 19 Jul 2013 11:01:35 PM UTC, original submission:  

The FaceAlpha property determines the transparency of a face.  The FLTK backend, however, interprets everything that is not 1 (opaque) as 0 (transparent).  The property works with gnuplot.

Example code:


h = fill ([0 1 1 0], [0 0 1 1], 'b');
axis ([-1 2 -1 2]);
set (h, 'facealpha', 0.3);


This seems like it should be possible since OpenGL can handle all kinds of strange colors/alpha blends.

Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #42236:  printalpha5.patch added by pantxo (4KiB - text/x-patch)
file #42222:  txtback4.patch added by pantxo (8KiB - text/x-patch)
file #42193:  printalpha2.patch added by pantxo (5KiB - text/x-patch)
file #42169:  printalpha2.patch added by pantxo (5KiB - text/x-patch)
file #42116:  bug39535_basic_facealpha.patch added by mmuetzel (9KiB - application/octet-stream)
file #42089:  bug39535_patch_facealpha_v2.patch added by mmuetzel (4KiB - application/octet-stream)
file #39977:  bug39535_patch_facealpha.patch added by mmuetzel (2KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by juanpi (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-28 pantxo StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2017-10-23 pantxo Attached File- Added printalpha5.patch, #42236
    2017-10-22 pantxo Attached File- Added txtback4.patch, #42222
    2017-10-19 pantxo Attached File- Added printalpha2.patch, #42193
    2017-10-16 pantxo Attached File- Added printalpha2.patch, #42169
    2017-10-10 mmuetzel Attached File- Added bug39535_basic_facealpha.patch, #42116
        StatusPatch Reviewed In Progress
    2017-10-08 mmuetzel Attached File- Added bug39535_patch_facealpha_v2.patch, #42089
    2017-10-06 pantxo StatusPatch Submitted Patch Reviewed
    2017-03-12 mmuetzel Attached File- Added bug39535_patch_facealpha.patch, #39977
        StatusConfirmed Patch Submitted
        Operating SystemGNU/Linux Any
    2017-03-12 mmuetzel Dependencies- bugs #50520 is dependent
    2015-11-26 rik5 Dependencies- bugs #46538 is dependent
    2014-12-28 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code