Somebody asked me about stuff like this in a PM.

I don't have it figured out yet. This render took extremely long to do. I don't even know what the formula is - nothing is published.

Just sharing - don't have a point yet. Hopefully this thread will turn into something. What's really strange about bronze is that it almost always has some coating applied (patina) that prevents it from behaving like a true metal. It doesn't reflect exclusively in it's natural color like other metals. I have therefore made this shader with a double layer of reflection (much like the pearl shader I did last year). I don't know what to make of it. I haven't any bronze in my possession, so I look at Googled images. But they're like 20 wildly different appearances. So confusing.

Very good emulation of bronze... spent quite a bit of time around artists working at foundries and studios casting in the material. Unfortunately my discipline was in ceramic sculpture and surfaces, so other than first person experience of having handled and examined the stuff nothing relavatory to add.

I think the shader work you've done here makes a nice addition to your catalogue... I don't recall seeing too many procedural based bronzes for Poser out there.

Pre-1962 US pennies are made of a bronze, if you have any tucked away. Later ones are brass, and post-1982 pennies are coper plated zinc

I like the look of the dog...

Oooh, tasty sample, BB.  The only idea I can offer is that if you were doing patina material, that should have little/no specular, and have a fine granular/powdery surface texture.

     I have an old armillary model which would look good with that effect.  I probably should update it, though, putting a fine bevel on edges to hold metallic highlights.  It was originally released for the FaerieWylde Christmas 2009. 

   Ah, it's in the freestuff here  armillary

.

Lovely work BB.

I suppose a big problem with bronze is the huge diversity of patina finishes, altering both texture and colour, as well as levels of polish, one can see in real world examples, e.g. even just in terms of bronze statuettes like those in your sample render above...

However, the above looks like a very good generic bronze that I'm sure could be tweaked to emulate a good proportion of the examples of bronze I can find.

The technique from that previous pearlescent shader totally pays off here, eh?

The verdigris effect looks great. How does that work when the coverage / density of that layer is ramped up?

Those book spines are also pretty fine I should say. Thought they were real ;-)

Part of what I'm investigating here is not bronze, per se, but something we can use in lots of materials. Back in 2008, a new participant appeared in the Node Cult and gave the first usable curvature detector. (as matmatic script - nodes are overwhelming here)

http://forum.runtimedna.com/showthread.php?35269-Curvature-Calculation-using-dNdu-dNdv-dPdu-dPdv

Subsequently, runtimedna decided to "improve" their forum software (much like here) and they ruined that thread. Links are gone - text disappeared. (That is why I somewhat abandoned RDNA - now I'm doing the same here - where will I go? At Daz the users think my math is offensive.) Anyway it's hard to decipher the thread. But I'm trying to resurrect that thread because one of the common effects here is that on convex curves, the brass is polished by rubbing. On concave curves, the brass is dull from lack of contact and the easier buildup of verdigris and environmental crud (dust).

I only just found that rdna thread - I had completely forgotten about it. So I have not used the math from it yet.

Prior to my search (of just 20 minutes ago) I had been experimenting with a curvature sensor in nodes.

It is crude and wrong, but directionally correct. Here is a map of the curvature detected on my material test pawn. More curve = more white, less curve = more black.

Using the curvature sensor as a control map for shine, I can get a modulated brass like this.

What I'm doing here is changing the blur and the reflection strength based on the curvature detector value.

Baggins Wrote:
"... now I'm doing the same here - where will I go?"

Like most of us who haunt this place, I'm guessing you'll go mad :-D
Nice mat, looks good on the cat.

I love that puppy material :D

The fresh wear on the edges is a great effect, BB.  :-)  The formula seems to be measuring eccentricity well but not distinguishing between convex (lots of wear) and concave (little wear).

you plug the dN/dU (et al.) nodes into reflect node softness, and you colour-multiply reflect node by those first-derivative nodes?

The fresh wear on the edges is a great effect, BB.  :-)  The formula seems to be measuring eccentricity well but not distinguishing between convex (lots of wear) and concave (little wear).

Yes. I confess my reputation at math exceeds my actual skills. It is only that most people are so disinterested in practice with math that it seems I understand it well. I actually don't - I just practice a lot. I have had almost no instruction in multi-dimensional calculus and so how you go about detecting concave versus convex functions is barely above a mystery to me. I'm hoping that the thread I referenced above, wherein bluearms did the work, turns out to be correct work and I can just use it. I can copy/paste a formula as well as the next monkey, I suppose.

The concave/convex detector (if I can get it to work) would be an excellent use case for the new compound nodes in Poser. I could give you what looks like a single new node that does the work for you, while inside the 50 (or however many) nodes remain hiding, leaving users blissfully free to deal with application, not implementation.

you plug the dN/dU (et al.) nodes into reflect node softness, and you colour-multiply reflect node by those first-derivative nodes?

Almost. If I colour-multiply reflect with first-derivative, and the first-derivative is 0 (flat) then it would be black. Instead, what I'm doing is driving a Blender with the first-derivative. The Blender returns one of two colors to use as the reflection color that gets multipled with the reflect. One is dark brown, the other is goldish. For softness, I modulated it as 3 - 2 * c, where c is the curvature detector output (0 to 1). Thus the flat parts are softness = 3, and the curved parts are softness = 1. (Still not mirror sharp, but much sharper)

Since I don't know the math, this is just an ignorant suggestion that ... perhaps could send you in the right direction ... if by accident, could you use a variation of your rust on metal shader?  LIke I said, shot in the dark, probably unrelated.

is great thread at rdna!   bluearms uses surface integral calcs., e.g. for sphere (convex), where wolfram also uses parametric mapping of surface.

it almost looks like bluearms wrote sections of poser manual on these surface functions.  I have not known how to use them.

am wondering if bluearms wrote this for P7 at time when IDL still in beta (unsupported).

Since I don't know the math, this is just an ignorant suggestion that ... perhaps could send you in the right direction ... if by accident, could you use a variation of your rust on metal shader?  LIke I said, shot in the dark, probably unrelated.

I am doing that, exactly. The difference is rather than modulating the concentration of corrosion on a UV rectangle (used on a door) or on a hand-drawn UV-based map, I'm trying to discover, entirely within the shader, which are the crevices and which are the protrusions.

From the sounds of it, maybe researching 'Vector Displacement' might give pointers and trigger something in you.

Only reason I say that is because of how Vector Displacement behaves compared to Standard Displacement, and it sounds like what you're trying to do is pretty much get at what would essentially be the same sort of crevice information as Vector displacement uses, same trick if you like.  That new Vector Displacement stuff allows undershoots etc, pretty cool, and it definitely needs to know the sort of stuff you're getting at.

Not saying it's the same, but those 2D Vector Displacement maps end up creating 3D crevices and protrusions and even under and overshoots, so the way it works might trigger something in you.

3D vector displacement is interesting stuff and now that you mention it, I do not know how the orientation is decided if the prop has no UV map. Note that a normal vector is unambiguous - there is only one normal, or "out" direction no matter what. But perpendicular to that, in tangent space, is an "up" vector that has an infinite number of solutions. I know that normal maps generally rely on the fact that they are UV maps, and they pick the "up" vector that lies in the same plane as the local "V" coordinate seems to point to. In the absence of a UV mapping, I guess there is no unambiguous "up" vector.

In any case, I know the math of 3D displacement and tangent space pretty well and it's much simpler than determining curvature. But thanks for the suggestion.

What if ... again this is a wonky idea ... you select the AO JUST for that object and attach a color based node to effect the "occlusion" or crevice areas.  I'm trying to think outside the box here.  Probably this would mess up the lighting ... but what the heck.

To be honest, Baggins, this stuff is way above my head, but my layman way of imagining how it works makes me think that Vector Displacement might be working like a raytracer, but using different vector calculations instead.  When I look at what it does, especially the overshoots, it must be technically impossible for a light ray to come from above, pass an overshoot, and then still have a means of controlling what is below the overshoot.  In other words, it feels to me like it would be impossible for it to control whatever lies in the 'shadow' of the overshoot.

But it does, so ...

It might be drawing a virtual object around the main object, like a cube for example, and then firing off those vectors you speak of, basically just firing them off your object like reflections, and bouncing them off, say, the inside of an invisible cube, so that when they bounce, they are able to reach the undercuts that Standard Displacement can't reach.  Like shining a torch down a narrow maze, the Standard Displacement would fail due to the overshoots, but Vector Displacement, if it works sort of like a raytracer, might be bouncing vectors around like in a raytracer - just done different.

Re: Ambient Occlusion node

Already did that like 8 years ago. Using the AO node to detect nearby geometry (and thus conclude you're in a crevice) is a definite way to go. However, there are certain things it won't do right. It can't tell you that something is a protrusion - only that there is no apparent nearby object. So if you're trying to add extra "rubbing" or wear off some paint, you'll end up doing that on anyplace that isn't pointing near something else. So it's not so great for the effect of wear and tear on "exposed" parts.

Also, AO can't tell you if that nearby object is some other object or a part of the same object. (So for example, it will tell you that any part of a prop near the ground or a wall is in a crevice). That may be ok for statues, where stuff near the ground is dirtier and wetter. But it's not a general solution. How about a desktop statue of some kind - should the part near the desk be more dust-filled? (The answer is no)

Still it will be part of the bag of tricks for making "dirty" shader effects. 

But an additional problem is that the behavior of the AO node has changed drastically in recent Poser releases. (The parameters don't get interpreted nearly the way they used to.) And it's full of mesh artifacts I never saw before.

Finally, AO with IDL is a CPU killer. For some reason, the AO node slows to a crawl when IDL is on as well.

So - AO doesn't do what I want, it makes mistakes when I use it, and it means a 30 minute render takes 12 hours instead. 

I'll show you how to use it, but I don't want it for my main technique in dirty shaders.

To be honest, Baggins, this stuff is way above my head, but my layman way of imagining how it works makes me think that Vector Displacement might be working like a raytracer, but using different vector calculations instead.  When I look at what it does, especially the overshoots, it must be technically impossible for a light ray to come from above, pass an overshoot, and then still have a means of controlling what is below the overshoot.  In other words, it feels to me like it would be impossible for it to control whatever lies in the 'shadow' of the overshoot.

But it does, so ...

It might be drawing a virtual object around the main object, like a cube for example, and then firing off those vectors you speak of, basically just firing them off your object like reflections, and bouncing them off, say, the inside of an invisible cube, so that when they bounce, they are able to reach the undercuts that Standard Displacement can't reach.  Like shining a torch down a narrow maze, the Standard Displacement would fail due to the overshoots, but Vector Displacement, if it works sort of like a raytracer, might be bouncing vectors around like in a raytracer - just done different.

What you describe is possible if I had a full-blown shading language and I could write such algorithms. Poser doesn't allow that. I have to use the same set of nodes like all the rest of you, and if I want to do something more sophisticated, despite me knowing how to do it, there is no way for me to say it. The node system has dumbed the whole thing down. 

Working with nodes is like trying to bake a pie from scratch, and they gave you a chainsaw, an axe, a bathtub, a welding torch, and two screwdrivers as tools. Try to make a pie with that.

Speaking of that, I was looking at the latest Pixar renderman shading API (not RSL - the full blown API where I can add code in C or C++ or whatever I want) and I could do tons with that one.

Cool. thanks for the clarification.  Someone told me a few months ago that in effect IDL had the reverse effect of AO  so that the 2 fight each other in an IDL render.  There is another thing that people didn't catch on to that started in P5 or P6, it was the "Gather" node, I'm sure you know what I mean, I can't look it up as I have a render going at the moment.  It was used to fake IDL ... Anyway.  As I said before, I don't know the math, but I want to help if I can.  Let me know if I'm being a pest who is clueless.

@Baggins
Surely they would add that if you asked them, so I hope you did.
Sounds very powerful!

if you could take 2nd deriv. of P as func. of U and V, then maybe 2nd deriv. < 0 in convex region and 2nd deriv > 0 in concave region.  

it would switch from concave to convex at 2nd deriv = 0.

for posersurface with centre (0,0,0) facing front.

gather caused colour to bleed between adjacent surfaces.  they left it in recent versions, but it was rather grainy and slow.

BB, if you like renderman, can you write python script that calls it from within poser?

   The gather node was introduced with P5, I think.  I started halfway through the P6 era.  I did some experimenting with it.  The gather node's results were crude and it really bogged down render times.

Good to know those pesky forum ebots are still snarked...

I downloaded Renderman the other week. Wonder if Nerd3d will be contemplating giving some priority to looking at better native support for it? The terms of Renderman's public release seem quite hobbyist-frendly, for one thing, don't they? ...and if there were to be any kind of animation tools renaissance within Poser's functionality... well, could work well?

@Baggins
As you said your notifications are screwed-up, just wanted to let you know that you have mail :-)

I did not get an email about your manual notification here that I have new site mail, for which I did get an email, though.

Well who'd have thought that then, eh? :-D
Cheers Baggins, glad I mentioned it then!

Hello, I was wondering if you had done any more work on this Bagginsbill, I'm rather interested in it and think it would be interesting to work with.