I need someone's help.

Kg try this quick fix , you'll have to fine tune but with a bit of a fiddle you should get similar [ does need adjusting ] you can change thickness of plaster roughness and texture of b/g to be lighter and rougher etc

helpmeplease2.ffxml

You guys really really rock.

Carl- I love the way you did that filter, I'm probably going to go with ThreeDee's one because it's a bit closer to the original. I'm tweaking it right now and am pretty pleased with the results. I'll post some examples (maybe the final filter) later to explain what I'm doing

Fullsize image link: http://img183.imageshack.us/img183/91...mapso0.png

(Sorry for the quadruple post)

Basically what I'm trying to do is mix this: http://www.ultimateuploader.com/files/7228ji.jpg (the output from my damage filter)

with this: http://www.ultimateuploader.com/files/9656jijijiji.jpg (the output of that manually created normal map to generate something like this:


(I used "crazy bump" to blend the above files. It works totally fine but I would really like to do this all within filterforge.)

That last image is like 100% gold. It's exactly what I'm looking for.

Quote
KGtheway2B wrote: Carl- I love the way you did that filter, I'm probably going to go with ThreeDee's one

I'd do the same TD's is much closer

if i remember correctly, you simply desaturate a normal to make it a bump, though the two are normally used differently and therefore not a straight conversion type thing that applies really well. normals are more for lighting where bumps are more for height/depth.

Well, I don't know the exact mathematics of the normal map, so I can't say, but it has at least one problem, which is how the gradient seam gets offset into the image.

I made some experiments along this line earlier and made this filter that I thought was creating a normal map, but that is just reverse engineering from how one looks, not through any actual math. It uses refraction instead of offset which seemed more correct, IMO. It also has a shrink/enlarge routine that seeks to avoid the seam problem. And I gave it a few more controls for other purposes.

So, I can't swear on the accuracy of either, but there's another possibility.

normal map.ffxml

Oh good, that seems to work fine.

Do you know what the heck that blue channel is supposed to represent? I get what the read and green ones are, in that they give you the x and y directions of the surface normals, but I don't quite get what the blue is supposed to do. The logical answer would of course be the z component of the surface normal. If that is it, I could probably do something that resembled it. I guess I could read about it somewhere if I really wanted...

I really hate to be naggy like this but have you had a chance to try that blue channel ThreeDee? You had such a solid start with the first two I think you ought to wrap it up, release a snippet, and crown yourself normal map king.

Hey Sphinx! I'm so sorry I totally missed your earlier response. I'm experimenting with it right now and it's looking really promising thanks!

A few things to keep in mind with normal maps:

The r and g channels of normal maps are usually stored "packed" into 0..1 space (the X and Y components of a normal vector are in -1..1 space). The b channel is not packed, it is in 0..1 space to begin with. To go from (color) texture.rgb to (vector) normal.xyz, the conversion is: normal.xy = color.rg*2-1; normal.z = color.b. For each pixel value in a normal map, the (unpacked) r, g, and b channels form a single [R G B] vector, whose length is exactly 1.0.

FF offset maps work similarly to "packed" normal maps. Offset maps are in 0..1 space, but get "unpacked" behind the scenes. A value of 0 in an offset map is treated like -1, and 0.5 is treated like 0. I'm sure everybody already knows this stuff, but I figured I would put it out there in case it does somebody some good.

If unclamped math worked, this filter would give a correct blue channel I think.

You can check the (not-quite-accurate) results by toggling between render maps "diffuse map" and "normal map"

Normal Map mtook a stab at blue channeld.ffxml

Take a look at http://dunnbypaul.net/blends/ it is a great site which explains Photoshop-style blend math (which I assume FF is using).

Let's take the "Extract RGB" red channel as a starting point (we'll call it "r"). From that point:

1. We have a "linear burn" (100% opacity) blend node with r as both foreground and background. The blend math page tells us that "linear burn" is (base + blend - 1), which in FF is (foreground + background - 1). If foreground and background are both r, (foreground + background) = 2*r. Which means that (foreground + background - 1) = 2*r-1. Let's call the output of this linear burn blend node "2*r-1".

2. The next node is a "multiply" blend (100% opacity), with 2*r-1 as both foreground and background. Multiply blend returns (foreground * background), which means we are getting (2*r-1)*(2*r-1), which is (2*r-1)^2. Let's call the output of this multiply blend node "(2*r-1)^2".

3. We do the same stuff for the "Extract RGB" green channel... so let's call the output of the other multiply blend node "(2*g-1)^2".

4. The next thing we have is a "linear dodge" blend with "(2*r-1)^2" as the foreground and "(2*g-1)^2" as the background. The blend math page tells us that "linear dodge" is (base + blend), which is just (foreground + background). So let's call the output of the linear dodge blend node "(2*r-1)^2 + (2*g-1)^2".

5. Next we have an invert node, which just returns (1 - input). So let's call the output of the invert node "1 - (2*r-1)^2 + (2*g-1)^2".

6. The gamma node, set to 30.10 (taken from byRo's post in the "Gamma" thread), returns something which I hope is the square root of its input. I did some basic validation by multiplying the output of the gamma node against itself, and it looked visually identical to what we're inputting to the gamma node (I don't think it is quite precise enough to be mathematically identical). So let's cross our fingers and call the output of the gamma node "sqrt(1 - (2*r-1)^2 + (2*g-1)^2".

7. At this point we have z as derived above.

8. To get from z to b, we need to get z*0.5+0.5.

9. The multiply blend with 50% gray as the foreground performs z*0.5, so we'll call the output of that node "z*0.5".

10. As above, linear dodge is just (foreground + background), so again 50% gray as the foreground adds 0.5 to the input. We'll call the output of this node "z*0.5+0.5", and at this point we have what *could* be a valid blue channel for an RGB normal map texture, if my logic and math is all correct

OK, gave it another shot (with the math above in mind) - preset 1 is the output of our normal construction, preset 2 is the FF generated normal map. Try rendering the FF map (preset 2) save it as EXR and open it again before opening the filter graph - there are some seemingly unused branches that lets you compare the FF map and the map generated by the filter. It might be possible to tweak it even closer to the FF normal map, though this one is quite close already

Normal Map - with Blue channel.ffxml

Sphinx, can you explain the use of curves in your filter and how they relate to the math from earlier? That is one part of FF I don't understand. I have something cool (as far as normal maps go) in the works, but I need a way to actually subtract one sample from another...

Here's the actual blue channel (subtle differences, almost looks inverted inside the gray area )

Actual Red normal channel

surface height controls the opacity of a lerp (regular blend) between your calculated normal map and RGB [127.5,127.5,255], such that zero surface height returns just RGB [127.5,127.5,255]

Quote
rgoer wrote: Sphinx, can you explain the use of curves in your filter and how they relate to the math from earlier? That is one part of FF I don't understand.

The two first linear curves are simply used to get into the curve "space" (blue connectors). While it may not seem intuitive, the spatial information is actually passed on during the curve operations (i.e. its not simple functions, f(x), its more like f(x,y,v)). The last Tone Curve + Assemble RGB is how we get back into the normal sample flow (green connectors) - the actual color of the Assemble RGB is irrelevant as we are getting a constant result no matter what we plug in (its really just a work around because of the required source input in the tone curve)

I can't give you an exact explanation of what I did - with FF your solutions are often a mix of theoretical ideas and intuitive experimentation However, telling from your math, we're dealing with some sort of modified euclidean distance function, so this was my starting point - now how does this "look"? Like a radial gradient with black center. A radial gradient can be faked by doing something like x * (1 - x) + y * (1 - y) with some additional adjustments. Its not perfect but its very fast The rest of the curve math and settings were simply made by experimenting and comparing with the real normal map.

Quote
rgoer wrote: I need a way to actually subtract one sample from another...

In curve "space" you can use the Math component for that.

Quote
rgoer wrote: but again the value clamping was breaking the result

The secret is to scale down and offset temporary to get around the clamping, so instead of working in full [0..1] range, you work in a much smaller range, say [0.45..0.55]. It should not have significant impact on precision. I do that in the blue channel calculations too. The easiest way to make this transformation is to remap via a linear curve where you set its minimum and maximum props. To get back to the ordinary range you then use the start and stop props instead. Follow?

edit: nevermind, I was being stupid

edit again: OK Sphinx, now I'm back to being confused. I thought I was in good shape remapping amplitudes to a compressed space... but now I think I'm screwed again.

Let's say we have 3 curves, A, B, and C, and their values are all very close to one another (less than ~0.1% difference between them, but different and unique nonetheless). If I leave them in [0..1] space, then (A - B)+(2*C) is going to be something like ~0.1% away from 2*A (or 2*B or 2*C). If I compress them to [0.45..0.55] space before I do any math, (A - B)+(2*C) is still going to be very close to 2*A (or 2*B or 2*C)... and I'm still going to end up going negative (or greater than 1) eventually as the math continues. Sorry for being somewhat dense here, but am I missing something stupid?

I have to go out of town for a couple of days, but when I'll post what I have so far when I get back on Saturday. Hopefully it is a solvable problem