hi everybody,

i'm happy to share with you my first attempt with a depth of field effect on gem. it's still very beta but it's working fine and i'm quite excited by the results. feedback is welcome as always.

note: i'll be releasing the slightly modified glsl code and the pd patch as soon as I get the permission from the author of the bokeh shader.

I had a look at your site guido, some very nice work! Let us know if you're releasing patches for any of your other work, I'd love to check it out.

thanks everybody for the feedback. i'm glad it's working fine on linux.

pob: let me know how it goes, i'm quite sure it's going to fall apart on windows.

rep: i updated the glsl code, the warning should be gone now. what's wrong with the blur masks? it's weird, they are plain jpg images.

dubtub and glitchpop: i'm planning to release some stuff soon. glsl is fast and it's actually easier to learn that it seems but the profound lack of documentation for that part in gem makes everything difficult. i guess this article might be a nice start to understand how glsl works, have a look. feel free to use the [pix_shader] abstraction when loading a shader in gem, it's nothing fancy but it makes the task even easier.

Hi.

I spent the afternoon yesterday and got it to run on Windows and adapted the code to have a webcam as a depth texture.
Had a problem with [text3D]. I also have problems with [pix_image] - All GEM related. I should try on an earlier version of GEM to see if it solves anything.

edit. Now fixed. Had to remove a dll to disable imagemagick.

I made a few modifications. Now the jpg maps work fine. I think a gemframebuffer was missing.
i got rid of the text since I had a few problems with [text3d]

edit: New version below, closer to the original patch.

thank you for spending some time testing the depth of field effect. I give a look at your patch but I don't think I understand what's going on there.

1. why are you setting the color of the framebuffer to 0.3 0.3 0.3?

2. is it really necessary to put everything under a single gemhead? why is that? i find all that crazy retriggering to be counterintuitive. i see you also had to put the render order in the gemhead, is this a windows thing?

3. what's wrong with [text3d]? maybe you can add an entry to the bug tracker.

I didn't set the colour, it was there in the first place. I don't know what caused this if you didn't put it there...

A single [gemhead] with a [t a a ...] is good to know what is rendered in what order.
The number in the [gemhead] is good to know what is rendered in what order as well.
First the are rendered the positive numbers in increasing order (ie. first 1 then 2) then the negative numbers in decreasing order (ie. first -1 then -2). This is not specific to Windows.
Otherwise I think it's the patching order that defines what is rendered first and so on. I find this to be very confusing since you can't really see the order and it can be easily disrupted.
I've noticed that [gemhead] in subpatches are rendered out of order too, even with a numbered [gemhead]. Probably related to the order of creation of the subpatches there too.

I got rid of [text3d] because otherwise I couldn't use your patch. Feel free to put them back if you want. I think it crashes because it can't find the font. But this is more or less erratic depending on the version of GEM and Pd. We discussed this with IOhannes on IRC yesterday. He suggested this was related to the font not being found. Maybe including a font in the patch folder and specifying it to [text3d] would solve this issue.

i'm getting confused here apparently I put that color by myself in the released version of the patch (while it is not present in the version i'm playing with). I noticed that in your patch because both the scene and depth preview windows are really dark and this breaks the patch. I need to figure this out, sorry.

about the [gemhead] priority I know it's not specific to windows, I was just wondering why it is necessary on windows while it is working out of the box in osx and linux.

no worries for the text3d, i was just curious. i'll see what to do with that in the next "release". is [text2d] working maybe?

I just added the render order as a "good practice" measure (from my point of view) and since I was tinkering with the patch and I didn't want to break things because I would change something elsewhere.

Anyway, thanks again for patching all this together. I already have it in a big performance patch. I have to try working with it now.
Cheers

Here is a slightly modified version that now seems to work out of the box on Windows too.
[text3d] was probably unhappy, at least some instances because it couldn't find the font.
I couldn't get the .arg] to work at all so I have a direct connexion and now it works fine.
I also added the [gemframebuffer] for the jpg depth maps. I don't know if it was necessary, since I changed this before the I made the direct connexion to the bokeh shader and got things working then.

I also got rid of the color setting in one of the framebuffers.
texunit 0 seemed to be used by some other [gemframebuffer] (the ones with the blur shader) so I used texunit3 instead, but this may not be relevant.

http://www.pdpatchrepo.info/hurleur/depth_of_field_pob.zip

a new release of the depth of field effect with some bug fixes is available here. there is a good chance this is working out of the box on windows, linux and macosx. thanks to pob for all the debugging and improvements.

an handy abstraction to use this effect will be the next step.

nice one!