Already more than 2 years ago I wrote a blogpost about Weighted Blended Order-Independent Transparency. At that time, I introduced a blending function in the shape of a Gaussian. That worked well for some special effects, but if you had 2 nearly-opaque surfaces close to each other, you could see through them. Here's an example using the Gaussian function from the previous blogpost,

The red and white surfaces of the left are opaque, but you can see through them.

In order to address that, I changed the function to be simply 10 to the power of the negative distance to the surface, and multiplied by alpha like in the original paper. The function is configured with 2 parameters: the distance to the closest transparent surface, and the spacing between 2 transparent surfaces (s). Every (s) units you move away from the camera, the function gives the surface behind only 10% of the weight of what the surface in front has. The distance to the closest transparent surface is important because we are using 16-bit floats, and that means we run out of precision pretty quickly using this exponential function. So the weighting function is clamped and objects far away are all equally weighted.

Here's a video that shows the new function, plus a comparison with normal sorted transparency and with opaque surfaces for reference,

Notice that you can still see through the red surface, which is supposedly opaque, but the result is almost correct. In comparison, sorted transparency suffers from the usual popping artifacts, since the sorting is done per primitive, not per pixel. Primitives are either in front or behind one another, but we can't solve the generic problem without OIT. The result of rendering with the depth buffer, as if they were opaque, is to illustrate that a fully opaque pipeline has other issues like Z-fighting. The weight-blended OIT gives a consistent smooth result, free of popping and Z-fighting related artifacts.

As the original paper explains, it is useful using traditional alpha-blended transparency as reference, but that does not mean is more correct, since partial coverage is a complex phenomena and weight-blended OIT gives more plausible lighting results in many situations.

Tweet

Enumerations are one of those constructs that differ a lot across different programming languages. While in C they were just a series of named integer constants, in Java they are almost full-blown classes, and in fact, they are awesome for implementing singletons.

Swift doesn't follow the generalist route of Java, and instead it uses enums to enumerate things, that's it. But making them simple to understand doesn't mean that they need to be just ints, like in C. In fact, enums in Swift can hold associated values. For instance,

enum SerializationError: Error {
    case missing(String)
    case invalid(String, Any)
}

// in some deserialization code
    guard let vertexData = json["vertices"] as? [Float] else {
        throw SerializationError.missing("vertices")
    }

// handling errors with different associated values

switch serializationError {
case .missing(let what):
    print("\(what) is missing")
case .invalid(let what, let someObject):
    print("\(what) is invalid: \(someObject)"
}

So enums in Swift are awesome to deal with values in a type-safe way, and I tend to use them a lot.

However, there's a dark side: the implementation. In Swift relative short lifetime I have already 2 nasty bugs that have made me waste many hours. You never expect the language to be wrong, so you try to find what's wrong with your code first, until you realize it's not your code...

The first bug I found almost a couple of years ago had to do with variable accessors: Accessor bug in release. The values of an array of enums would appear as 0 values in all cases, but only in Release mode! Super obscure and really hard to debug. I found that in Swift 1.3 and it wasn't fixed until Swift 2.1.

The second bug I just found yesterday. I was checking for leaks in some Metal code. I found many leaks everywhere, and I started getting paranoid, because the Metal code is full of UnsafeRawPointers, memcopies, Metal buffers, Metal textures, ... After a 6-hour debugging session I just reduced it all to this small repro case: Swift 3 enums leak memory when the class also contains an array. It's very strange, because if I replace the enum by an int, then there's no leak. So I assumed labeling the enum @objc (same workaround as the first bug) would fix the problem, but it doesn't. And the thing that leaks is the array when it gets copied after appending an element to it. Very strange and still no solution for it.

The question now is: should I trust enums again? My code looks nicer with them than if I changed everything to ints, definitely... I guess I should trust Apple or Swift maintainers to do something about it. For the time being, I reported it to Apple. And I guess I won't change my code just right now...

As the title says, it's a love & hate relation between me and Swift enums. 😍😡

Tweet

I've scanned some old notes/cheat sheets from the subjects I studied at university, 15 years ago! 😂

Notes in Dropbox (check the UAB folder)

Maths and other subjects are still relevant, so you might find the cheat sheets useful. Most notes might be in Catalan, but since it's mostly formulas, I don't think it really matters.

The subjects covered: Linear Algebra, Algorithms, Mathematical Analysis, Automatons, Bioinformatics (Artificial Neural Networks), Calculus, Combinatorics, Optimization, Electricity, Electronics, Computer Hardware, Compute Graphics, Graphs and Complexity, Artificial Intelligence, Computational Logic, Discrete Mathematics, Numeric Calculus Methods, Probability, Image Processing, Digital Systems, Linear Systems, Operating Systems, Standard ML (as part of Programming Languages), Signal Processing, and Computer Networks.

Computer Engineering at the Autonomous University of Barcelona had (has?) more subjects, but I didn't produce Cheat Sheets for all the subjects (or maybe I lend them to someone and I never got them back... can't remember). Just saying just in case you were wondering where Computer Vision, Compilers, and other subjects went...

Tweet