for (auto e : enumerate(container)) e.value = 12;

looked surprising. Does that change the container or not?

First I made value const so this would just not compile. But in practice, you often do want to change the value. Once I decided to change the name to enumerate_byref I felt I also had to provide enumerate_byval.

Currently I’m leaning towards just not having enumerate – the code may be more verbose, but it’s also more readable.

More to the point, enumerate_byval seems to provide little benefit over enumerate_byref. Benchmarking seems to suggest that this is almost no overhead in passing by reference instead of by value, e.g. for integers.

The only other point is if the user is going to modify the value / counter inside the loop, and he/she wants to discard such changes. This seems to be an odd and confusing paradigm…

Admittedly, the usual distinctions between using const T&, T& and T “don’t work” when using an enumerating range. But that is true for enumerate_byref as well.

Thus with：

for (auto e : enumerate_byref(container))

even with the “byref” in the name, are we going to know for sure that “e.value” here is a reference, rather than a copy?

Have I missed anything?

What I was thinking about when writing the statement about modern gpus was that the algorithm described here was mainly constrained by the limited number of blend modes available in the old fixed function pipeline. I haven’t thought about improving it in detail. Using vertex buffers and some sort of spacial tree data structure for the lights would definitely make sense though.

As for overbrightening: floating point textures would work. You can also continue to use ARGB32 and change the pixel shader used for blending the lights onto the scene to do a scaled multiplication (something like result_color = 2 * unlit_color * light_amount) . You’d lose some accuracy and would have a maximum amount of overbrightening, but that’s probably ok.

If you release your code somewhere, let me know! People have been asking for a C++ implementation quite a bit.

Also I think there are two limitations right now with this method. First, you can’t get overbrighting effects as described in the original article. I solved this by rendering the whole scene in a seperate fbo and blend it over each light, but I think this is not the most optimal way of doing it. It would be ideal if you could somehow save color values greater than 1 in a fbo, but I don’t know how.(maybe floating point textures or something)
Second, this currently only works if the lights size is smaller than the shadowblockers. I think this can be solved by rendering both the penumbras and umbra in full darkness and then subtracting the areas of the penumbras appropriately.

Anyways, this helped me a lot, I am only interested in knowing what can be improved to make it even better. This is how my implementation looks right know, you can also see the mentioned overbrightening effects:
http://www.iamwhoiam.net/max/shadow-test2.ogv

for (size_t i = rightpenumbra.sections.size() - 1; i < blockerLine.size() - leftpenumbra.sections.size() + 1; ++i) {
    Vert &vert = blockerLine[i];
    umbra.sections.push_back(Umbra::Section(vert, extendDir(0.5 * (leftpenumbra.sections.last().direction + rightpenumbra.sections.last().direction)));
}

Would you mind converting this line to me, I can’t understand the loop, begins where and finishes where?

foreach(ref vert; blockerLine[rightpenumbra.sections.length-1..$-leftpenumbra.sections.length+1])
umbra.sections ~= Umbra.Section(vert, extendDir(0.5 * (leftpenumbra.sections[$-1].direction + rightpenumbra.sections[$-1].direction)));

I’m also having some troubles on other parts but for now this would help a bunch. I’ve placed my email on the form.
Thanks