Losing our privacy

Big brother of NSA

On the 19th of March 2015, a law was introduced in France. That law was entitled “loi du renseignement” and was presented in regard of what happened in the Charlie Hebdo awful week. The main idea of the law is to put peole on wire so that terrorist activities could be spotted and dismantled.

That law will be voted and apply on the the 5th of May 2015.

Although such a law sounds great for counter-terrorism, it has several major issues people should be aware of.

You’re on wire

Every people – in France and abroad as well of course – could be on wire. The French government might have access to whatever you do with your internet connection. Crypto-analysts working for the goverment will read dozens of thousands of messages from individuals. They’ll know where you go to and where you go from – think of your smartphone’s GPS capabilities. They’ll know which pictures you take, how much time you spend in your bathroom. They’ll even be able to read your e-mails if they want to.

Of course, most people “just don’t care”. “Why should I care that the government knows the litter brand I bought to my cat? I don’t give a damned heck as long as they catch bad people”. That’s a point, but that’s also being blind. Digital communication is not only about yourself. It’s about people. It’s about you and your friends. You, and your contacts. You can’t choose for them whether they’d like people to watch over their shoulders every now and then. If the government has access to your private data, it has access to your friends’ and contacts’ data as well. Not giving a damned heck is being selfish.

You’ll be violated

Then comes the issue with what the law is. It gives the government the right to spy on masses. They could even sell the data they collect. As a counter argument, the “Commission de contrôle des techniques de renseignement” – which French stands for “Control commission of intelligence techniques” – was created. That committe is there to watch the government and ensure it doesn’t go out of control and doesn’t violate people’s rights. The issue with that is that our prime minister has the right to ignore the committee’s decision. If the committee says “Wait a minute. You don’t have the right to gather those information without asking for M. Dupont’s approval”, the prime minister may answer back “Well, fuck off. I will and you can’t stop me”. And the sad truth is that… yeah, with that law, the prime minister and their team has the right to ignore the committee’s decision.

The committee then has no point. It just gives an opinion. Not a veto. What would happen if a terrorist hacked into your computer. Would you go to jail because the prime minister would have stated you were a terrorist? Damn me if I know.

We’re going to lose a right

French people will lose a very important right: the right to privacy. It’ll be sacrificied without your opinion for counter-terrorism, giving the government a power it shouldn’t have. You thought the NSA was/is wrong? Sure it is. But when the NSA watches over American and worldwide people, it is illegal whereas when the French government watches over French and worldwide people, it is legal. That makes the French government way worse than the NSA to me.

I think the first thing I’ll do will be to revoke my French VPS subscription to move it out of France, in a country in which people still have privacy. Keep your communication encrypted as much as possible (ssh and so on). And as a bad joke, don’t leave your camera in your bedroom. You might be spied on by Manuel Valls while having sex with your girlfriend.

Generalized swap

I pushed a pull request to Edward Kmett’s either package to implement two functions some guys was complaining not to find: flipEither :: Either e a -> Either a e and flipEitherT :: EitherT e m a -> EitherT a m e.

When implementing the functions, I wondered: “Hey, flipping stuff is a pretty common operation. Don’t we have an abstraction for that yet?”. I haven’t found any.

Meet Swap

I decided to make a little typeclass to see what it’d be.

class Swap s where
  swap :: s a b -> s b a

instance Swap (,) where
  swap (a,b) = (b,a)

instance Swap Either where
  swap = flipEither

-- let’s go wild and fooled
instance Swap Map where
  swap = fromList . fmap swap . toList

If you think that’s handy, I’ll write a little package with default instances to make it live.

Happy hacking folks!

Volumetric Light Shafts

Volumetric light scattering

On the last weekend, I was at the Revision demoparty (Easterparty). It’s a meeting of friends and great people doing graphics, music, code and that kind of fun and pretty stuff. I didn’t release anything, but I’ve been working on a release for a while now, and I was lacking something in my engine: light shafts.

I know a few ways to do that. They almost all fall in one of the two following classes:

1. screen-space-based;
2. raymarching-based.

Both the techniques produce interesting images. However, the screen-space-based method produces bad results when you don’t look directly to the light – it may even produce nothing if the light is out of screen – and the raymarching-based is a step process that might generate artifacts and can be slow.

The idea I had is very simple. I haven’t tested it yet, but it’s planned for very soon. I’ll post images with benchmarks as soon as I have something on screen. I’m not sure it’s an unknown way to do it. I just haven’t found anything describing that yet. If you have, please leave a link in the comments below! :)

Volume extraction

The idea is the following. You need a depthmap. If you’re used to shadow mapping you already have a depthmap for your light. In order to simplify this, we’ll use the depthmap used for shadow mapping, but I guess it’s totally okay to use another depthmap – we’ll see that it could be even handier.

For each point in that depthmap is the distance – in a specific space coordinates system – of the corresponding point in world space to the position of the light. If you have the projection and the view matrices of the light, it’s easy to deproject the depthmap. What would we get if we deproject all the depthmap texels into the world space? We’d get the exact lit surfaces.

For a spot light, you can imagine the deprojected version of the depthmap as a cone of light. The “disk” of the cone will deform and shape as the lit environment. That’s the first part of the algorithm.

We have a points cloud. What happens if, for each deprojected texel – i.e. point – we draw a line to the position of the light? We get an actual lines field representing… photons paths! How amazing is that?! Furthermore, because of the depthmap sampling, if you look at the light and that an object is between you and the light, the photons paths won’t go through the obstructing object! Like the following image:

Of course, because of using raw lines, the render might be a bit blocky at first. If you know the laser trick¹ – i.e. quad-based lasers, you can apply it to our lines as well, in order to get better results. The first improvement is to disable depth test and enable additive blending.

Algorithm

In the first place, you need to generate the depthmap of the light. Then, you need to extract the volumetric shaft. You’ll need a vertex buffer for that. Allocate w*h elements, where w and h are the depthmap’s width and height. Yeah, a point per texel.

Create a shader and make a render with glDrawArrays(GL_POINTS, 0, w*h) with an attributeless vertex array object. Don’t forget to bind the depthmap for use in the shader.

In your vertex shader, use gl_VertexID to sample from the depthmap. Transform the resulting texel in world-space. You can use something like the following deprojection formula:

vec3 deproject() {
  float depth = 2. * texelFetch(depthmap, ivec2(gl_FragCoord.xy), 0).r - 1.;
  vec4 position = vec4(vv, depth, 1.);
  position = iProjView * position;
  position.xyz /= position.w;
  return position.xyz;
}

Pass that to the next stage, the geometry shader. There, build whatever kind of new primitive you want. In the first place, I’ll go for a simple line connected to the light’s position. In further implementation, I’ll go for lasers-like base shapes, like star-crossed quads.

In the fragment shader, put whatever color you want the shaft to have. You could use interpolation to reduce lighting wherever you want to create nice effects.

Don’t forget to use additive blending, as we do for lasers.

Considerations

I see two major problems. The first one is the bright aspect the shaft will have if you don’t blend correctly. Play with alpha to reduce more if the fragment is near the light’s position and make the alpha bigger when you’re far away from the light’s position. Because you’ll blend way more photons paths near the light’s position than far from it.

The second issue is the resolution of the extracted volume. For a 512x512 depthmap, you’ll get around 262k points, then 524k lines. That’s a lot for such an object. And that’s only for a simple spot light. An omnidirectional light would require six times more lines. What happens if we don’t use lines, but star-crossed quads an that we want several shafts? You see the problem.

A solution could be to sample from high mipmap level, so that you don’t use the full resolution of the shadow map. That would result in less visual appealing shafts, but I’m pretty sure it’d be still good. You could also branch a blur shader to smooth out the whole thing.

Conclusion

I’ll try to implement that as soon as possible, because I think my idea is pretty interesting compared to raymarching, which is expensive, and way better than screen-space, because the shaft will still be visible if the light goes out of screen.

---

1. I’ll write an article about it if you don’t – leave a comment for asking↩