This is a mix of a height field from mask with emboss filter, with a blend mode that adds color of the source back in. I've used this extensively for a long time, and thought it might be useful to post.
Yeah, total agree! It's really simple to add that color back in. Some of my older comps feature this basic filter with monotone looks. Then one day, the blindingly obvious concept of adding in the original color of the image source came to me. In a way, it's kind of weird for something like this to not be a stock emboss example, imo.
Kind of cool (well, i've done it before too..) but why are you using a height map as an environment map? The env map is used only for reflections, not for the emboss filter. Try some gradients for a nice envmap :)
Btw, one of my own emboss effects, using luminance instead of straight colour values. Slower, but 'better quality'. Theoretically. :)
This is pure GLSL without using any QC effects, and it's not optimised and not really done 'the right way' either (I was writing shaders for the iphone, so sampler2DRect etc. aren't possible). The roundness doesn't work in the same way, it's only really good for 1-2 pixels spread.
This also includes my own rgb->hsl and hsl->rgb glsl functions. You can do a whole ton of cool stuff with these, like eg.:
That converts the pixel to HSL colour, replaces the hue value with 2.0 (green I think), then converts back to rgb. Change the number (range is 0..6) to colourise in any colour you want. If you want to hue shift, just use:
Fair enough, just didn't look much different to me. Actually one of my favourite tricks used to be using a moving image (camera or whatever) as the emboss image, and a blurred version of the same image as the env map. You can get really cool reflective effects like this :)
Yeah. It's not a great emboss effect, I need to improve it a bit, allow the lighting angle to be rotated and perhaps some blurring for proper 'roundness' (although it's going to need a ton of optimisation to run well on an iphone :/ )
Main point was really the rgb/hsl functions, they open up a whole bunch of new effects because you can work on the colour and chroma values separately. E.g. the colour separation that was discussed here (or maybe the mailing list?) is trivial using HSL :)
Did you actually try to just use straight color values instead at any point? I've done some stuff with CI and GLSL where the difference with using luminance is surprisingly slow. One of those "huh, why should this make a difference?" things. This seems to perform very well.
Recently, after looking at some shaders Time Machine uses, after my HD debacle last week, I've done a few things with using GLSL shaders like this in QC, and nesting each GLSL inside of a RII, so that I can keep adding, basically performing something similar to CI chains. It seems to have some interesting implications, in that you can force bit depth, mess around with the color correction, do AA, etc.
It's a heavy abstraction, but I have always wished that render patches could slip into being "RII type providers" for ease of use in these type of scenarios of chaining GLSL and doing other geometric transforms.
Yeah, I included the same filter using straight colour values instead in that comp :) If you enable it, both shaders run concurrently though, you'd have to disable one to compare performance.
HSL conversion is definitely going to eat some GPU time, although it's reasonably speedy. As I said, it's unoptimised too. Then again, it's not super slow, doing reasonable processing stuff isn't going to hurt too much. GLSL tends to be quite a bit faster than CI anyway :) (Especially once you start using all the bits that are missing in CI!)
I don't think there's actually much performance hit using GLSL in RII patches. All it does is render to texture instead of a render buffer (i.e. screen). I can't see that being slower than a CI filter!
You're right though, GLSL should be combined with RII, with an extra setting (something like 'Draw to: Screen/Image'). Selecting screen would be the same as now, image would do RTT and enable inputs for image dimensions, plus settings for depth buffer etc.
On that last one; it's something I've harped on in private conversation, and have also put in feature request. You're the first person that is like "yeah, it really should do that". This seems pretty damn obvious to me!
Going further (into non feature request land) I think it makes more sense for the "start" (or end, depending how we view it....the thing that "calls" for data) of a chain to just be a "dud" patch with no function other than to start the chain, or define what tech is being driven maybe. Geometry, etc., seems that it shouldn't necessarily be inherent to the renderer. So, "enable"s start becoming more like "bangs" etc. I don't want to go off on a big tangent...
I agree about there not being much of a hit with multiple GLSL/RII, at least in my test cases. Funny comment about CI filters; agree to agree on that one.
Hmm.. not too sure on this 'dud patch at the start' concept. What if I want to switch from image to geometry half-way down the chain? I'd say the data type being used is generally obvious from the first patch.. if it's an image import, you're using images, if it's a math patch you're doing some numeric/logic processing (and likely feeding it into a CI filter or something, again switching data type mid-chain).
I think the current system makes more sense, the input types of each patch in the chain determines the output of what goes before it. Maybe less obvious in some ways, but pretty clear and flexible.
Or am I misunderstanding you there? [at this time of the morning, there's a good chance of that :D ]
By start, I sort of mean "heavy emphasis on the Enable/Real Name/Key Name" aspect of a Renderer, and that the thing that defines those aspects shouldn't define geometric shape (splitting geometry from Render tech already happens in the "integrated geometry pipeline" of QC, QCMesh).
The concept wouldn't abstract away data types, it would just help layering z sorting be automatic, and allow one to receive info elsewhere in the composition, or "push" info in other cases. I started to write a more in depth explanation, but I don't want to outline the concept in depth here, because it solves a problem of loading current compositions and having them automatically adapt into this schema if desired (or not).
Wow! Very nice. I'll use this a lot. Thanks!
I love such simple and effective effects. Very nice.
Thanks; it's exceedingly simple but I do find it to be useful.
Well, putting the color back in is the mark of quality in this image filter assembly. Greatly appreciated. A very useful filter indeed, in my opinion.
Yeah, total agree! It's really simple to add that color back in. Some of my older comps feature this basic filter with monotone looks. Then one day, the blindingly obvious concept of adding in the original color of the image source came to me. In a way, it's kind of weird for something like this to not be a stock emboss example, imo.
Photoshop perfect!
Gives some lovely smooth results when I 'up' the Roundness on the CIEmboss. Thanks for sharing.
Kind of cool (well, i've done it before too..) but why are you using a height map as an environment map? The env map is used only for reflections, not for the emboss filter. Try some gradients for a nice envmap :)
I know how to use it appropriately; it's just that this "looks cool".
Btw, one of my own emboss effects, using luminance instead of straight colour values. Slower, but 'better quality'. Theoretically. :)
This is pure GLSL without using any QC effects, and it's not optimised and not really done 'the right way' either (I was writing shaders for the iphone, so sampler2DRect etc. aren't possible). The roundness doesn't work in the same way, it's only really good for 1-2 pixels spread.
This also includes my own rgb->hsl and hsl->rgb glsl functions. You can do a whole ton of cool stuff with these, like eg.:
vec4 hsl = rgb2hsl(pixel); hsl.r = 2.0; pixel = hsl2rgb(hsl);
That converts the pixel to HSL colour, replaces the hue value with 2.0 (green I think), then converts back to rgb. Change the number (range is 0..6) to colourise in any colour you want. If you want to hue shift, just use:
hsl.r = mod(hsl.r + shiftAmount, 6.0);
Fair enough, just didn't look much different to me. Actually one of my favourite tricks used to be using a moving image (camera or whatever) as the emboss image, and a blurred version of the same image as the env map. You can get really cool reflective effects like this :)
...an old thing that does just that.
That's cool. It ends up giving an effect that looks much like a sharpen filter at some settings.
Yeah. It's not a great emboss effect, I need to improve it a bit, allow the lighting angle to be rotated and perhaps some blurring for proper 'roundness' (although it's going to need a ton of optimisation to run well on an iphone :/ )
Main point was really the rgb/hsl functions, they open up a whole bunch of new effects because you can work on the colour and chroma values separately. E.g. the colour separation that was discussed here (or maybe the mailing list?) is trivial using HSL :)
That rgb/hsl function info is very useful. I would give a point if it had the "point" doodad by your post.
Did you actually try to just use straight color values instead at any point? I've done some stuff with CI and GLSL where the difference with using luminance is surprisingly slow. One of those "huh, why should this make a difference?" things. This seems to perform very well.
Recently, after looking at some shaders Time Machine uses, after my HD debacle last week, I've done a few things with using GLSL shaders like this in QC, and nesting each GLSL inside of a RII, so that I can keep adding, basically performing something similar to CI chains. It seems to have some interesting implications, in that you can force bit depth, mess around with the color correction, do AA, etc.
It's a heavy abstraction, but I have always wished that render patches could slip into being "RII type providers" for ease of use in these type of scenarios of chaining GLSL and doing other geometric transforms.
Yeah, I included the same filter using straight colour values instead in that comp :) If you enable it, both shaders run concurrently though, you'd have to disable one to compare performance.
HSL conversion is definitely going to eat some GPU time, although it's reasonably speedy. As I said, it's unoptimised too. Then again, it's not super slow, doing reasonable processing stuff isn't going to hurt too much. GLSL tends to be quite a bit faster than CI anyway :) (Especially once you start using all the bits that are missing in CI!)
I don't think there's actually much performance hit using GLSL in RII patches. All it does is render to texture instead of a render buffer (i.e. screen). I can't see that being slower than a CI filter!
You're right though, GLSL should be combined with RII, with an extra setting (something like 'Draw to: Screen/Image'). Selecting screen would be the same as now, image would do RTT and enable inputs for image dimensions, plus settings for depth buffer etc.
On that last one; it's something I've harped on in private conversation, and have also put in feature request. You're the first person that is like "yeah, it really should do that". This seems pretty damn obvious to me!
Going further (into non feature request land) I think it makes more sense for the "start" (or end, depending how we view it....the thing that "calls" for data) of a chain to just be a "dud" patch with no function other than to start the chain, or define what tech is being driven maybe. Geometry, etc., seems that it shouldn't necessarily be inherent to the renderer. So, "enable"s start becoming more like "bangs" etc. I don't want to go off on a big tangent...
I agree about there not being much of a hit with multiple GLSL/RII, at least in my test cases. Funny comment about CI filters; agree to agree on that one.
Hmm.. not too sure on this 'dud patch at the start' concept. What if I want to switch from image to geometry half-way down the chain? I'd say the data type being used is generally obvious from the first patch.. if it's an image import, you're using images, if it's a math patch you're doing some numeric/logic processing (and likely feeding it into a CI filter or something, again switching data type mid-chain).
I think the current system makes more sense, the input types of each patch in the chain determines the output of what goes before it. Maybe less obvious in some ways, but pretty clear and flexible.
Or am I misunderstanding you there? [at this time of the morning, there's a good chance of that :D ]
Very painterly :-).
I love what HSL colour shifting can do.
What's quite demonstrative is enabling the RGB GLSL macro and then switching on / off the HSL GLSL macro.
Interesting study example / demo . rgb->hsl & hsl->rgb :-) .
Cheers ,n thnx for sharing.
are the post point doodads gone for good do you know?
Looks like it. Well, to be fair they weren't used all that much I think, maybe they've had their day.
George: Thanks, missed this post before :)
By start, I sort of mean "heavy emphasis on the Enable/Real Name/Key Name" aspect of a Renderer, and that the thing that defines those aspects shouldn't define geometric shape (splitting geometry from Render tech already happens in the "integrated geometry pipeline" of QC, QCMesh).
The concept wouldn't abstract away data types, it would just help layering z sorting be automatic, and allow one to receive info elsewhere in the composition, or "push" info in other cases. I started to write a more in depth explanation, but I don't want to outline the concept in depth here, because it solves a problem of loading current compositions and having them automatically adapt into this schema if desired (or not).