News aggregator

Dimitri Sabadie: Volumetric Light Shafts

Planet Haskell - Wed, 04/08/2015 - 4:01am
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 trick1 – 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.


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.w;

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.


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.


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

Categories: Offsite Blogs

Recommendations for a Linux stack for Haskell web dev?

Haskell on Reddit - Wed, 04/08/2015 - 3:32am

As a long-time windows user, and an infrequent "Google Linux bash commands until it works" user, you could say my experience with Linux is limited at best.

All the web work I do ends up on a Linux machine eventually, so I've always run a WAMP or WAPP server locally, then pushing to some pre-configured VPS, having to just set up vhosts. I've never even installed MySQL on a Linux server (though done plenty of configuration via MySQL Workbench).

A friend of mine suggested Bitnami (e.g. and running a Linux instance in a VM. Which I thought was a pretty good idea. I noticed that Bitnami has no Haskell stacks. But I assume (hope) it's not the only catalog of its kind on the web.

I managed to get Yesod to install locally on Windows with GHC 7.10, sans any database connection. But I figured I'd stop there. Considering how much hell I went through getting a simple Haskell app to talk to MySQL on Windows before, I'm not keen on repeating it.

So I figure it's probably a good idea if I do my development in an environment I'll use in production anyway. And I'll probably want to use LTS anyway rather than trying to persevere with GHC 7.10.

With that back story / rant in mind... does anyone have a recommendation for a Linux ISO / Stack? Ideally something with a webserver already configured so that the most I have to do is set up virtual hosts... and even more ideally with Haskell LTS / Yesod already setup like those Bitnami stacks.

submitted by TheCriticalSkeptic
[link] [15 comments]
Categories: Incoming News

What's the current status of ghcjs vs haste?

Haskell on Reddit - Wed, 04/08/2015 - 12:36am

I've been using Haste a bit for small test programs. As I'm planning to write a fairly large web app using haskell, and I want to choose the right compiler for it. Basically, I like Haste's philosophy that it's going to be used in the client side and don't pretend to be a complete GHC environment. But GHCJS can be really good at compiling existing libraries. Though GHCJS's generated code and performance seems not as good as Haste. I've learned a lot from this subreddit on differences between ghcjs and haste. Example threads: But those discussions are at least 1 year ago and before GHC7.8 was released. What's the current status of both compiler and how does GHCJS compared to Haste, especially on code size and performance? Thanks!

submitted by manyoo
[link] [26 comments]
Categories: Incoming News

Anyone interested in taking over network-uri?

haskell-cafe - Tue, 04/07/2015 - 10:18pm
Hi! I find myself with less time to hack lately and I'm trying to reduce the number of libraries I maintain so I can invest time in new things. Would anyone be interested taking over maintenance of network-uri? It should not be much work at all. Bump a few dependencies and fix a bug or two. The package is very widely used so I suggest that the new maintainer should avoid breaking changes whenever possible*. * In other words, if you want to completely rethink network URI handling, this package is probably not the place for it.
Categories: Offsite Discussion

Why should I learn Haskell?

Haskell on Reddit - Tue, 04/07/2015 - 8:31pm

hi /r/haskell,

I get the arguments about functional vs imperative. I get the multithreaded wonderfulness. I get the build speed difference. What I don't get is what I could build in Haskell that would be so tremendous.

I'm not trying to piss on it, I swear. I'm just scratching my head trying to figure out a project that would really and truly benefit from Haskell over some other language.

I do enjoy learning Haskell, I must say. I'm a js dev and it totally helps me see my own work in a new light.

submitted by kingbobofyourhouse
[link] [11 comments]
Categories: Incoming News


General haskell list - Tue, 04/07/2015 - 6:08pm
[apologies for any cross-posting] *** SUBMISSIONS ARE NOW OPEN *** Call for Papers --------------------------------------------------------------------------- 13th International Conference on Logic Programming and Non-monotonic Reasoning LPNMR 2015 Lexington, KY, USA September 27-30, 2015 (Collocated with the 4th Conference on Algorithmic Decision Theory 2015) --------------------------------------------------------------------------- AIMS AND SCOPE LPNMR 2015 is the thirteenth in the series of international meetings on logic programming and non-monotonic reasoning. LPNMR is a forum for exchanging ideas on declarative logic programming, non-monotonic reasoning, and knowledge representation. The aim of the conference is to facilitate interactions between researchers and practition
Categories: Incoming News

help w/ improving custom Stream for parsec

haskell-cafe - Tue, 04/07/2015 - 5:25pm
I need a custom stream that supports insertion of include files and expansions of macros. I also want to be able to give nice error messages (think of clang macro-expansion backtrace), so I cannot use the standard trick of concatenating included files and expanded macros to the current input with setInput/getInput (I think I can't maybe there's a way of keeping a more complex "position" and since the use in producing an error backtrac is rare, it migth be worth exploring; if anybody has ideas here, I'm listening) Assuming I need a more compelx stream, this is what I have (Macro and File both have a string argument, but it will be more compicated, a list of expansions for Macro for instance). Is there a better way for doing this? What are the performance implications with backtracking? I'll be benchmarking it, but if people see obvious problems, let me know. Thanks a lot, Maurizio {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MultiParamTy
Categories: Offsite Discussion

status of

haskell-cafe - Tue, 04/07/2015 - 5:15pm
The haskell status page says that has been down since mid-February. Are there any plans to bring it back up? -- View this message in context: Sent from the Haskell - Haskell-Cafe mailing list archive at
Categories: Offsite Discussion

Distribution of GHC extensions on Hackage

Haskell on Reddit - Tue, 04/07/2015 - 5:12pm

I decided it would be interesting to see how many files on hackage were using CPP (4473) and whilst I was doing so, it made sense to collect stats for all the other extensions as well. These are the raw figures gathered from parsing the LANGUAGE pragmas, the numbers include any implied flags. The high number for TypeSynonymInstances is a bit confusing but make of it what you want!

(Opt_TraditionalRecordSyntax,62729) (Opt_PatternGuards,62717) (Opt_EmptyDataDecls,62717) (Opt_DoAndIfThenElse,62717) (Opt_RelaxedPolyRec,62717) (Opt_ForeignFunctionInterface,62716) (Opt_NondecreasingIndentation,62649) (Opt_MonomorphismRestriction,62130) (Opt_ImplicitPrelude,60283) (Opt_TypeSynonymInstances,7815) (Opt_FlexibleInstances,7503) (Opt_OverloadedStrings,7050) (Opt_ExplicitForAll,6181) (Opt_ExplicitNamespaces,5852) (Opt_MonoLocalBinds,5471) (Opt_KindSignatures,5408) (Opt_MultiParamTypeClasses,5205) (Opt_TypeFamilies,4654) (Opt_FlexibleContexts,4534) (Opt_Cpp,4473) (Opt_ScopedTypeVariables,4185) (Opt_DeriveDataTypeable,4162) (Opt_GeneralizedNewtypeDeriving,3288) (Opt_RankNTypes,2901) (Opt_TemplateHaskell,2858) (Opt_DisambiguateRecordFields,2654) (Opt_RecordWildCards,2636) (Opt_DeriveGeneric,2236) (Opt_UndecidableInstances,2036) (Opt_BangPatterns,2032) (Opt_TypeOperators,1883) (Opt_DataKinds,1857) (Opt_LambdaCase,1523) (Opt_GADTSyntax,1319) (Opt_ExistentialQuantification,1316) (Opt_GADTs,1316) (Opt_FunctionalDependencies,1309) (Opt_StandaloneDeriving,1080) (Opt_MagicHash,890) (Opt_UnicodeSyntax,852) (Opt_DeriveFunctor,844) (Opt_OverlappingInstances,800) (Opt_ViewPatterns,682) (Opt_TupleSections,645) (Opt_UnboxedTuples,634) (Opt_DeriveFoldable,573) (Opt_DeriveTraversable,553) (Opt_RecursiveDo,539) (Opt_ParallelListComp,536) (Opt_QuasiQuotes,529) (Opt_ImplicitParams,524) (Opt_LiberalTypeSynonyms,459) (Opt_UnliftedFFITypes,455) (Opt_PostfixOperators,441) (Opt_ConstrainedClassMethods,427) (Opt_RecordPuns,407) (Opt_ConstraintKinds,395) (Opt_PackageImports,390) (Opt_IncoherentInstances,307) (Opt_PolyKinds,226) (Opt_Arrows,163) (Opt_DefaultSignatures,161) (Opt_ExtendedDefaultRules,102) (Opt_DatatypeContexts,93) (Opt_ImpredicativeTypes,82) (Opt_RebindableSyntax,67) (Opt_PatternSynonyms,51) (Opt_MultiWayIf,43) (Opt_InstanceSigs,38) (Opt_NPlusKPatterns,14) (Opt_MonadComprehensions,10) (Opt_AutoDeriveTypeable,10) (Opt_AllowAmbiguousTypes,9) (Opt_NullaryTypeClasses,6) (Opt_GHCForeignImportPrim,6) (Opt_TransformListComp,5) (Opt_OverloadedLists,5) (Opt_EmptyCase,4) (Opt_CApiFFI,4) (Opt_ParallelArrays,3) (Opt_NegativeLiterals,2) (Opt_RoleAnnotations,2) (Opt_NumDecimals,2) (Opt_MonoPatBinds,2) submitted by Lossy
[link] [15 comments]
Categories: Incoming News

Noam Lewis: Type guards are not inferable

Planet Haskell - Tue, 04/07/2015 - 4:00pm

Type guards, or typecase expressions allow refining a binding’s type and are commonly used in dynamic languages such as JavaScript. Consider (adapted from Simple Unification-based Type Inference for GADTs):

f x y = typecase x of Int -> i + y other -> 0

The function can have either of these two types (among others):

a -> Int -> Int


a -> a -> Int

Neither is more general, so there is no principal type.

Unless the user tells us something (in a type annotation) we have no way of deciding which type should be inferred.

So for now, Infernu will probably not have support for type guards like Flow and TypeScript do (both of which don’t have full type inference). Another possibility is to allow type guards in trivial cases only.

Categories: Offsite Blogs

Distributed and persistent events bus in Haskell

haskell-cafe - Tue, 04/07/2015 - 3:50pm
Hello, I am implementing an application using event sourcing as primary storage for data, which implies I need a way to durably and reliably store streams of events on stable storage. I also need to be able to have an event distribution system on top of that persistent storage so that components can subscribe to stored events. So far I have implemented a simple store, e.g. a flat file, which reuses the format of Apache Kafka (just in case...). Not very robust nor sophisticated but can work for moderate loads. Now I am looking for the event distribution part in the hope of being able to reuse some distributed event bus system that might exist somewhere and not having to roll my own. I have had a look couple of months ago at Vaultaire, Marquise and friends, but I am not sure they are really suited to my use case: They seem to be geared toward very high workload and throughput, like log or huge data streams analysis. Thanks for any pointer you might share,
Categories: Offsite Discussion

[EPIT2015] Call for participation to a Spring School about the Coq proof assistant

General haskell list - Tue, 04/07/2015 - 2:56pm
*** Call for participation, please distribute. *** EPIT'2015 ( Spring School in Theoretical Computer Science Mechanizing Proofs of Programs in Coq May 25 to May 29, 2015, Frejus, France * Presentation The french spring school in theoretical computer science (EPIT) is a recurrent school which was created 40 years ago by Maurice Nivat. This year, the school is about the mechanization of proofs of programs using the proof assistant Coq. As no prerequisite is needed, the school targets any computer scientist that is curious about what a proof assistant is and how it can be integrated in its daily research work. * Program The school will take place between May 24 and May 29 and it will be divided into eight sessions. A session will consist in a (rather short) lecture (given in english) followed by practical exercises on computer. The five first sessions will be dedicated to a presentation of the main concepts and techniques
Categories: Incoming News