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)
|
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.
|
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
|
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...
|
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.
|
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?
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.
|
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)
|
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?
|
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:
The following example with surfaces shows that printing "mostly" renders as on screen for surfaces too
(file #42222)
|
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?
|
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?
|
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).
|
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.
|
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 :-).
|
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.
|
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.
|
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:
|
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)
|
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.
|
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:
(file #42169)
|
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:
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)
|
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)
|
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?
|
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:
or bug #46538:
or the one in comment #0.
Since no sorting primitives are included, it fails with more complex layouts as in:
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)
|
Fri 18 Nov 2016 03:32:57 PM UTC, comment #4:
This bug is still present in the current dev 4.3.0 (39f39eb4e476).
|
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)
|
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.
|
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
|
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:
This seems like it should be possible since OpenGL can handle all kinds of strange colors/alpha blends.
|