pouët.net

whatever bayimg is - it does not work here.

psonice: just work in linear colour space with proper hdr range and it just works out..

xernobyl: thinking about it some more, i'm kind of half right, half wrong. The dark areas can't spread/blur as I said, but in practice it doesn't matter. The light areas spread out into the dark areas, but at the same time because the light there is spread out the brightness is reduced - which darkens the area around the hole in your picture, so it's the same effect in the end. Confusing, but it's good to figure these things out and understand them :)

Las: right click + open in new tab works for me, but it's still a broken image in the thread for some reason.

smash: yep. Also, you've just put me in a bad mood by mentioning colorspaces ;) I don't know what it's like on windows, but on mac they seem to be ingrained pretty much everywhere, and give me no end of headaches. That and pre-multiplied alpha. Such simple things, yet they seem to keep popping up where i'm not expecting them and fucking stuff up ;(

Hmm, why does the OS matter? :) I just render to a 16 bit target, enable SRGB for the right texture reads, and tone map / gamma at the end.

Once you're into pure opengl, its probably the same. But image loading, core image, and particularly video (which I do a lot of lately, combined with opengl) can be a bit of a nightmare. In the last demo I did, the noise overlay (which was important for a few scenes) totally disappeared in the party version because I got the colorspace wrong somewhere. And loading a LUT or normal map and forgetting the colorspace can really fuck you over, so can pre-multiplied alpha if it's stored in an RGBA image. Some of the stuff I've done with video can be ruined if you let the video capture APIs apply the colorspace transform before passing you the image.

It's a minor thing really, but it's one of those minor things that can cause some unexpected result somewhere that takes ages to track down so it's fucking annoying when it catches you out :)

I try to keep everything linear in fp buffers until the final srgb pass.

I try to keep everything linear in fp buffers until the final srgb pass.

psonice: well, all your texture inputs into opengl should be in gamma2.2 space if they're LDR; linear space isnt really good for 8 bit per channel images.
So you should be fine using any source you like as long as you gamma unconvert the right textures in opengl and dont apply colourspace conversions elsewhere.

I try to keep everything linear in fp buffers until the final srgb pass.

smash: linear space isnt really good for 8 bit per channel COLOR images. For other images (like normal maps etc) it's perfectly fine.

im pretty sure thats that he meant. You don't want more resolution on the negative side.

You don't want your lighting shifting to one corner with a normal map too :) (Which is what happened to me recently - NOT useful when you don't realise it's a colorspace issue, and you're trying to write a normal map generator and assume the bug is at that end!)

Also, I'm not sure that there's a gamma2.2 space on osx. There's device native (GPU) space, linear, and display native. Plus a bunch more for special cases, greyscale etc. Plus more for input formats.

I guess it's the mac's background in photoshop + design, but it really is everywhere. It's brilliant if you're working on one (there's even a built-in display calibration tool in the display prefs) but it gets annoying when you're coding. (Until you try modifying the colour tables in realtime, that can be fun ;)

Oh, I'm sure it's what he MEANT - it's just not what he SAID :)

A little update in case you're interested...



Volumetric Occlusion (not that you can see it) + Depth of Field + Hypnoglow + FXAA

The black parts are simply empty and the error propagates (divzero, infinity...).

Still running >60fps at 1600x900 on my AMD 4000 and something laptop.

I discuss cheap ways to compute lens blurring here: http://yehar.com/blog/?p=1495

Wow. You make something simple give me nightmares.

That's pretty interesting yehar. As far as I can tell, the IIR and summed-table approaches don't really lend themselves to a GPU implementation, or am I missing something?

yehar: cool work indeed :)

The hexagonal blur technique was published at Siggraph '11 and your intro is from Kindergarden '10. I demand that you publish the blueprints for your time machine!

He's just rendering particles with the size of the COC. Of course I could be write and I could be raytracing all that with magic. But I'm not.

Revival: Recursive Gaussian blur uses IIR filters, and they have been implemented on GPU's, so IIR filters should be possible. On the same notion, summed area tables should be possible as they are in principle calculated by IIR filters.

xrl: nope.

stop with your ugly-ass shit.