Vertex colors with transparency yield weird results in 3D about asymptote

[johncbowman]

You need to update to Asymtpote 2.39. We don't support old versions.

[HeinrichApfelmus]

Sorry for reporting this problem with an old version of Asymptote.

Unfortunately, the issue persists in newer versions.

I have compiled Asymptote 2.40git from source, and the example now results in a segmentation fault:

$ cd asymptote-2.40git/
$ wget http://hboehm.info/gc/gc_source/gc-7.4.2.tar.gz
$ wget http://www.ivmaisoft.com/_bin/atomic_ops/libatomic_ops-7.4.2.tar.gz
$ ./autogen.sh
$ ./configure
[..]
$ make --version
GNU Make 3.81
[..]
$ make all
[..]
$ ./asy -dir ./base -config "" -noprc ../transparency-3d-bug.asy
Segmentation fault: 11

Other examples seem to work normally. In particular, the manual doc/asymptote.pdf is built correctly without problems.

TeXLive-2016 is bundled with Asymptote version 2.38, which produces the following picture, which is not correct either:

[johncbowman]

Yes, that is how the example should look with OpenGL (which as is well known, doesn't handle transparency perfectly). The segmentation fault you are reporting is likely coming from your graphics library. Which version of freeglut are you using? I recommend freeglut-3.0.0.

Your code runs fine on my machine with asy 2.40-1, even under valgrind.

[HeinrichApfelmus]

Yes, that is how the example should look with OpenGL (which as is well known, doesn't handle transparency perfectly)

... Oh. That was news to me.

I just have looked around on the internet a bit, and it seems to me that while using OpenGL transparency naïvely will fail, there are still methods to ensure that scenes are rendered correctly, for example depth peeling.

Wouldn't it be sensible to implement this in Asymptote? As far as I understand, Asymptote is a scene description language, and I was under the impression that rendering should be independent of particular technology artefacts like OpenGl not sorting triangles before blending colors. At least, that's how I would like it as a mathematician. 😄

Which version of freeglut are you using? I recommend freeglut-3.0.0.

Actually, I'm on OS X 10.9. It seems that the configure script simply picks up the resident OpenGL system library (framework).

EDIT: Fix version information on my OS

[johncbowman]

Yes, if you are only drawing triangles, you can split them along any intersections (that tutorial didn't even consider this possibility) and then sort the pieces. However, we are rendering smooth Bezier surfaces and before version 2.39, Asymptote delegated all rendering to the GLU library. That library is deprecated so, in preparation for the ultimate demise of the GLU library, as of version 2.39, Asymptote uses it's own in-house renderer for Bezier triangles, curves, and surfaces. So yes, it should now be possible to implement splitting and sorting at the triangle level. I'll reopen this issue as a reminder.

Can you recompile with

make clean
make CFLAGS=-g

and use the debugger (or valgrind) to produce a traceback that shows were the segmentation fault occurred? Do any other 3D examples that use OpenGL (i.e. not ones from the manual) fail?
There are many 3D examples in the Asymptote gallery and some of them use transparency.

[HeinrichApfelmus]

So yes, it should now be possible to implement splitting and sorting at the triangle level

Great! 😄

Can you recompile with
make clean
make CFLAGS=-g

Yes… and now it produces a good .png file without segfault! 😮 However, if I run

make clean
make

again, the obtained asy executable will segfault again when trying to render my example. ><

(Note: I am actually on OS X 10.9, sorry for the confusion.)

[johncbowman]

What happens when you compile with
make CFLAGS="-g -O2"

If that doesn't work, also try -O.

[johncbowman]

A partial workaround for this OpenGL bug is now implemented in
commit 31c6630

I didn't implement triangle splitting yet but transparent triangles for a single material are now sorted by their centroid depth.

I also fixed a seg fault in beziercurve.h so perhaps that issue is now resolved too.

[johncbowman]

P.S. To avoid degenerate patches at the poles you should slightly adjust the theta endpoints. For example:
surface s = surface(f,(sqrtEpsilon,0),(pi-10*sqrtEpsilon,2pi),41,Spline);

[HeinrichApfelmus]

Much better, thanks! 😄

The segmentation fault no longer happens for me with commit af2b9b1 .

The picture is much better as well! The treatment of transparency does not yet seem to be perfect, though. If I apply your suggested fix concerning degeneracy, and now also reduce the transparency of the left sphere as a whole, changing the following two lines,

// ...
surface s = surface(f,(sqrtEpsilon,0),(pi-10*sqrtEpsilon,2pi),41,Spline);
// ...
surface s = shift(0.5X+0.5Y) * mkSphere( Gradient(green, 0.9*white, green)+opacity(0.1) );

, then I get the following picture:

The left sphere is almost invisible, except for a green piece with a weird shape. The lower boundary of this piece is shaped like a straight, horizontal line, which indicates that this rendering is probably not correct.

[johncbowman]

This issue is fixed in commit c7878da.
Sorry that isn't the right fix as it breaks the original example. Commit reverted...

[johncbowman]

The problem with this modified example is that triangle splitting of transparent triangles with overlapping depths has not yet been implemented.

[johncbowman]

Fixed (for non-legacy OpenGL environments, meaning everywhere except MacOS X and WebGL)
in master branch and upcoming 2.71 release.

[asmwarrior]

Great work!
I'm hoping the 2.71 will release soon.

[asmwarrior]

I add some forum links, I guess/hope that the next release will fix the bugs reported in the forum, see:

Asymptote / Discussion / Help: Artifacts in 3D rendering of transparent surfaces

and

Asymptote / Discussion / Help: Status on OpenGL transparency bug