Hello,

Using Poser 8's Material Nodes, I would like to draw a line on a given surface. My goal is to have a tear roll slowly down a figure's cheek in a Poser 8 animation.
 
I want to specify the width, length, and direction of the line with Material Node parameters.

I plan to use a Blender node to add the drawn line on top of a bit-mapped texture, and eventually, I hope to use the Frame_Count node to lengthen the line within a P8 animation.

Is this feasible? I would appreciate a pointer to a tutorial or any helpful suggestions to get started.

Thanks,
Richard

 You may have this link ? Take a look in her webpage at [http://www.guile3d.com.br/vanessa.asp

](http://www.guile3d.com.br/vanessa.asp)

Thanks for the link, saibabameuk.

Vanessa looks good, and it's interesting to see a tear fall from a Poser character's eye.

I'm just guessing, but it looks like the tear may have been added in postwork.

Richard

the only way I can think of doing this would be to use a texture and use scaling and offset on the texture to animate it at rendertime.

Thanks for the reply, templargfx.

I have considered using a texture too, and then incrementing its U/V_Scale and U/V_Offset parameters during the animation. That might work well, despite the distortion of the texture.

Still, I really want to try a cleaner, procedural-only method, if only to learn how to do it.

Richard

With poser you never know, of course, but it shouldn't be that difficult. This is how I would try to tackle this:
1 - apply all morphs to get the crying face.
2 - spawn a prop of the head of the character you want to use and set the original head to be it's parent. With a magnet push everything above the eyes inward.
3 - apply a 'water' or 'glass'  texture to the face prop (with IOR), and open a displacement channel.
4 - in the displacement channel use an 'add' node with negative value (say -0.1) in the second input to ensure the 'water' surface is below the skin.
5 - In the first input add either
 - an image map with a black base and in the position of the eye corner a white spot and a gray smear up. Create a frame node and build a branch to connect this with the v-offset input of the image node in a way to make the v-offset increase (or decrease? I always forget poser's convention here) as frame number rises.  Tune height, scale and add modifiers to fit. Add a sine or cosine to the u-offset input to make a realistic 'trickle'. 

• if you're  math wizard create a spatial function in the (u, v, frame#) domain to do same.  A combination of a paraboloid for u and a trochoid for v, truncated in v,  will bring you a long way. 

Not tested, no guarantee.

Thank you, bagoas. You've suggested what appears to be a workable solution.

I'm especially interested in paragraph 5b: ''... create a spatial function in the (u, v, frame#) domain to do same.  A combination of a paraboloid for u and a trochoid for v, truncated in v, will bring you a long way."

I've found an example of a Poser procedural material that draws an indented grid using "P" nodes and Math_Functions: Multiply, Step, Sin, and Add.

I'm trying to reverse-engineer it now.

Richard

Attached Link: http://www.sharecg.com/v/16365/3D-Model/Tiled-Roof-Texture-for-Poser-5-and-up

Sorry I missed this post. I just saw your same question in the Node Cult.

Well I've made some progress on this. I'm doing a single "tear" on a square for the moment. Later I'll deal with integrating this into a skin shader.

I have to give some warnings before we delve into this.

I have a very powerful computer and yet it takes a looong time to load or update the shader. Loading or making any change in the material room causes Poser to crank for about 13 seconds. I don't know why because the shader is not as math intensive as many I've done before. It is currently 85 nodes and usually 85 nodes doesn't make Poser behave like this. I'm not sure what to do about it. If you don't have a strong computer, you may find loading the shader to be intolerable. Strangely, it takes less time to render than to load.

Second, while the basic line-segment algorithm is not very complicated, transforming that into a usable teardrop shape is a bit intense. Then how to use it to blend a skin and water shader adds more complications. I'll try to explain how in simple terms, but there is considerable math. The explanations will take hours to produce and I don't have a lot of time at the moment. So - it may take a few days to a week for me to explain it all.

As I have time, I'll add posts to this thread.

I'm going to build this shader with the assumption that we're dealing with a UV mapped surface, and that we want to produce a 2D function that uses the UV distance from the shaded point to a line segment to drive the whole thing.

How do you find the distance between a given point and a line segment? Rather than explain this myself, a perfectly good explanation is here:

http://local.wasp.uwa.edu.au/~pbourke/geometry/pointline/

Study that for a bit.

This is pretty straightforward. I changed the names of the variables, though, to match the way my brain works.

I define the line segment as going from point a to point b. I need 2D vector components, so point a will be held in ax, ay. Point b will be held in bx, by. The point being shaded will be point c, held in cx, cy.

I have attached the matmatic script, and it is commented, but I'll explain a little more here.

It begins with defining the function:

def LineSegmentClosestPoint(ax, ay, bx, by, cx, cy):

We'll be calling this with desired values for a, b, and c.

The first step is to calculate the x/y deltas from a to b.

 # Calculate a-to-b vector components
 abx = bx - ax
 aby = by - ay

The next step is to calculate the x/y deltas from a to c.
 # Calculate a-to-c vector components
 acx = cx - ax
 acy = cy - ay

In matmatic, these subtractions result in Math:Sub nodes, connected (or set) to whatever was passed in for ax, ay, bx, by, cx, and cy. So abx is the x distance from a to b. It might be a node or it might just be a constant. We don't care. Matmatic will take care of that for us. If, for example, bx = .5 and ax = .3, then abx will be .5 - .3 = .2. However, if either ax or bx is a node, then abx will be a Math:Sub node that calculates bx - ax. Similar logic is applied to the other three.

Now to solve the parametric equation of the line segment, we'll need the square of the distance from a to b.
 # Square of the distance a-to-b
 ab_distSquared = abx * abx + aby * aby

Then, using exactly the formula given in the linked page, the solution of the parametric value, t, for the closest point on the line (not the segment yet, but the whole line) is:

 # Solve for parametric value t which defines
 # the position of the closest point on the line
 t = (acx * abx + acy * aby) / ab_distSquared

So t is a node that holds the parameter value. If the closest point is actually in the line segment, t will be between 0 and 1 (inclusive). If the closest point is before the beginning of the line segment, t is less than 0. If the closest point is after the end of the line segment, t is greater than 1.

We don't want to deal with the infinite line. We want to only consider points within the segment. If t is less than 0, we want the line segment start point which is at t=0. If t is greater than 1, we want the line segment end point which is at t=1. In other words, we want to "Clamp" t. Super - there's a node for that.

 # Clamp it (limit it from 0 to 1) to to keep in the bounds of the segment
 ct = Clamp(t)

So now ct holds the parametric value that is closest to c, but still within the line segment.

To calculate the position of that point, we do:

 # Calculate point, p, that is closest to c, using the parametric equation
 # of the line segment.
 px = ax + ct * abx
 py = ay + ct * aby

We're going to be needing the x/y deltas between this point, p, and the point we're rendering.

 # Calculate p-to-c vector components
 pcx = cx - px
 pcy = cy - py

Finally, I need to return something. Being a generalist, I'm not yet sure how I'll be using all these values, so I'm going to return a bunch of them in a matmatic Parameters object.

 # return all the important info produced
 return Parameters(px=px, py=py, pcx=pcx, pcy=pcy, ct=ct)

That's the whole function. Pretty simple actually.

Turning that into a drop of water that left a twisty trail is going to be tricky, but this is a good start.

To test the math, I will make four parameter nodes that a user can manipulate experimentally in the material room.

Make user-adjustable shader parameter nodes for the input values.

The initial values are arbitrary.

ax = PM(.35, "AX")
ay = PM(.8, "AY")
bx = PM(.4, "BX")
by = PM(.15, "BY")

Now I must call the function to extract the information I want. I will use the U and V values as my point, c.

get info for current UV coordinate

seg = LineSegmentClosestPoint(ax, ay, bx, by, U, V)

The return value, seg, holds all the info produced by the function.

For this first test, I'm just going to calculate the distance to the segment

calculate the distance

d = Hypot(seg.pcx, seg.pcy)

And then as an easy visualization, I will draw this as a gradient, using a simple modulus arithmetic trick.

For previewing purposes, draw gradients of the distance, 10 per unit.

s = View(10 * d % 1)
 

When you load this, try changing the values of the parameters. It should be straighforward to understand how to move the two endpoints of the line segment.

What I'll do next is to produce a value, h, that defines a height map. This will be used to drive the displacement. The value of h is chosen so that it produces a bump that matches the line segment. The cross section of this bump is circular, at least mathematically it is at this point. How we use it later will result in an ellipse.

Calculate a value, h, for use in displacement.

The value of h is going to produce a circular cross section.

The radius of the cross section is defined by a distance, R.

We'll use a parameter node to define R.

R = PM(.1, "R")
rx = seg.pcx / R
ry = seg.pcy / R
h = Sqrt(Clamp(1 - (rx * rx) - (ry * ry)))

Then for testing purposes, I'll just draw h.

Draw it

s = View(h)

The script is attached.

Draw it as a displacement on a shiny orange surface

s = Surface(ORANGE, .8, 1, 1, .02)
s.Displacement = .3 * h
 

To facilitate this, we'll find it very handy to use a mask - a pattern of white and black (or 1 and 0) that defines being in-segment versus out of segment.

This is really easy. We just magnify the height map and clamp it. I'll then use it to pick one of two colors for the surface.

Make a mask to define the area occupied by the line segment.

m = Clamp(50 * h)

Draw it as a displacement on a shiny orange surface

but make the segment a different color

color = Blend(ORANGE, .5 * GREEN, m)
s = Surface(color, .8, 1, 1, .02)
s.Displacement = .3 * h
 

We're going to want to combine diffuse, specular, and reflection effects. For testing purposes, I'm using procedural colors and bumps - these will be replaced with maps from your figure later on.

Make some bump outside the segment

bump = .02 * Turbulence(.1, .1, .1) * (1-m)

Use a modulated Blinn node for specular.

Define a not-very-shiny value, but increase it by a lot for the segment.

shine = .4 + 1.6 * m
spec = Blinn(WHITE, (.96 ** (50 * shine)) * .7, .4, shine ** 2)

make a skin-like color pattern

color = Clouds(Blend(SKIN, RED, .2), SKIN, 1, 6, 0)

Set up the diffuse value.

Water focuses light on the surface underneath. A cheap hack

to deal with this is simply to increase the diffuse value inside

the segment.

dv = .8 + .03 * m + .1 * h

Handy trick for diffuse value respecting conservation of energy

dv = dv * Clamp(Sub(1, spec))

Define a diffuse node with

diff = Diffuse(color, dv)

Compute Fresnel reflection effect.

Water's IOR is really 1.33, but for "artistic" reasons I'm using more.

fresnel = TrueFresnel(1.5)

Reflection value will be modulated by the mask.

rv = fresnel * m
reflect = Reflect()
dr = Blend(diff, reflect, rv)

Combine all elements

output = dr + spec

s = View(output)
s.Displacement = disp
s.Bump = bump

First I modulate the radius. I modify the calculation of h as follows.

Calculate a value, h, for use in displacement.

The value of h is going to produce a circular cross section.

The radius of the cross section is defined by a distance, R.

We'll use a parameter node to define R.

R = PM(.1, "R")

Modulate the radius so it starts a little smaller and grows to full

size at the end of the segment.

mR = R * (.7 + .3 * Bias(seg.ct, .3))
rx = seg.pcx / mR
ry = seg.pcy / mR
h = Sqrt(Clamp(1 - (rx * rx) - (ry * ry)))

Here, I'll need the multiplier I used to modulate R earlier. So I go back and rewrite the earlier part so I can re-use the radius multiplier, modulated by ct.

Modulate the radius so it starts a little smaller and grows to full

size at the end of the segment.

ctm =  .7 + .3 * Bias(seg.ct, .3)
mR = R * ctm

Then I add this bit.

Use h for displacement

k = seg.ct ** 15
drop = 1.1 * k / (.1 + k)
drop = drop ** 2.8
hm = ctm + 3.5 * drop
disp = .3 * h * hm

How I come up with formulas like this is complicated. Just take it as a given that it works. The full details of this sort of thing are coming in my shader book. It literally takes pages and pages to explain how to combine exponential functions in interesting ways to intentionally produce specific curves. Designing curve functions is very tricky, but I have a framework that makes it a snap. Someday I'll finish the book...

Making the assumption that the tear is mostly going down (not horizontal) we can get by with simply wiggling the x value. I will use a low-frequency fractal sum node for this purpose. The exact scale of this will need tuning for any particular use, but the technique would be the same in all cases.

I want to maintain control of the exact start and end points, but I don't really care where the line goes in between. To do this, I need a function that starts at 0, goes to 1 in the middle, then back down to 0 at the end. I call this sort of function a "pulse". There are many functions that can be used, but my favorite is this one:

def pulse(x, k): return Gain(4 * x * (1 - x), k)

The k value is used to shift the pulse edges wider or narrower. But the middle is always 1 and the ends are always 0.

Using this formula, I modify the calculation of rx as follows:

add some wiggle in the x position - wx is the amount of wiggle

wx = .08

reduce the wiggle to 0 at start and end of segment so they don't move

wxm = wx * Gain((4 * seg.ct * (1 - seg.ct)), .8)
fs = 2

apply the wiggle

rx = (seg.pcx + wxm * (FractalSum(fs, fs, fs, 1, 0, .5, .93) - 1)) / mR

I think it's a fairly credible tear.

I have to stop now - I have a bunch of work to do. I'll come back to this topic in a few days.

Here it is. More work is needed on the skin but I think the tear looks pretty good.

bagginsbill,

You're right, the tear looks good. Very good. This is just what I was looking for.

I downloaded and installed matmatic, and will start playing with it and the scripts you've included here when an animation finishes rendering overnight.
 
Thank you for all of the excellent work you've done, and for the articulate, well-reasoned documentation too. This is tremendous.

Richard

bagginsbill,

Perhaps this isn't the right place to bring this up, but I'm having trouble getting started with matmatic.

I've followed the installation instructions, but when I click the Matmatic! button, I get this error in Poser 8 SR3 running on Windows XP x64:

Traceback (most recent call last):
  File "C:Program Files (x86)Smith MicroPoser 8RuntimePythonmatmaticcompile.py", line 12, in ?
    import matmatic.compiler
ImportError: No module named matmatic.compiler

I get the same error on a new PC I'm building with Windows 7 64-bit, again running Poser 8 SR3. I note that both machines have "(x86)" in their path, and wonder if that is the problem.

Also, even though I wasn't a Beta1 user, I downloaded the new version of compile.py from your free-stuff/matmatic page, but the same error message resulted.

Can you help?

Richard

Quote - I get the same error on a new PC I'm building with Windows 7 64-bit, again running Poser 8 SR3. I note that both machines have "(x86)" in their path, and wonder if that is the problem.

No that's nothing to do with it, because that's the path on BB's machine (this is just the way Python reports the source location for compiled files).

If you're actually installing under "Program Files" make sure that the files really are where you think they are.

I've put all of the matmatic files I've downloaded here:
C:Program Files (x86)Smith MicroPoser 8RuntimePythonMatmatic

I've attached a screen capture of the directory. Interestingly, I see compile.py has today's date.

Richard