From p387 of the PP2014 Reference Manual:

*"The dPdu node represents a varying point surface shader variable. It is a vector perpendicular to the surface normal in the ‘U’ direction. Specifically, it indicates the derivative of the surface position along ‘U’. It has no user-definable attributes."*

The direction of the vector is fairly clear from that (e.g. the first diagram in post #46 of the CGbytes thread), but the magnitude (and thus the values of the individual X, Y, and Z components) isn't. At least not to me.

**Some Simple Tests To See What Sort Of Magnitudes We Get**

I did a couple of tests with a similar setup to my "Material Room Du Node Strange Behaviour (PP2014/Poser 9 Firefly) ?" thread.

Create a 1 PNU square 4 vertex/1 face prop with its centre at the origin oriented so that you'll see it face on from Poser's front camera.

Import it into Poser (I used PP2014)

Apply my http://www.sharecg.com/v/85287/gallery/11/Poser/Signed-10-Digit-Integer-Visualizer-MT5 shader.

Plug a dPdu node into it and set the multipler to one million

Set all Front Camera scale values to 100% and dolly values to 0.0

Set render size to 500x500.

Render - note the value displayed on the square in the render

Change a setting and re-render. Repeat as necessary.

**Here are my first test results:**

Front Camera 'Scale' value ... (1000000 x dPdu)

100% ... 6046874

200% ... 12093749

400% ... 24187498

800% ... 48374995 (very small text, so I might have misread it)

That's almost perfect doubling each time. I'd expect dPdu and dPdv to be the same for this test, and I get the exact same values if I use dPdv instead of dPdu.

**Do those values make any sense?**

The square is 1 PNU wide, which is 103.2", which is 1032 'P' units (the P node output is in 0.1" units)

The first render (scale 100%) is about 500 pixels wide.

1032 'P' units across 500 pixels gives 2.064 'P' units per pixel

The dPdu value I got is 6.046874, just under three times this.

The second render (scale 200%) is about 250 pixels wide.

1032 'P' units across 250 pixels gives 4.128

The dPdu value I got is 12.093749, just under three times this.

Etc

I recall (e.g. here) that if you want to extract just the X, Y, or Z value from a P node you need to multiply the value by 3. The output of the dPdu is a vector, so I'm thinking that the same may apply ?

**Tentative first guess at the equation:**

If that's true, then for this very simple test case:

dPdu = 3 x (10 x square width in inches) / (square width in pixels on the render)

dPdv = 3 x (10 x square height in inches) / (square height in pixels on the render)

That' seems a good starting theory - next step would be to do something slightly different with the test and see if the results match what the equation gives us.

*(Note: I was surprised that the rendered size of the square seems to be involved...)*

From p387 of the PP2014 Reference Manual:

*"The dPdu node represents a varying point surface shader variable. It is a vector perpendicular to the surface normal in the ‘U’ direction. Specifically, it indicates the derivative of the surface position along ‘U’. It has no user-definable attributes."*

The direction of the vector is fairly clear from that (e.g. the first diagram in post #46 of the CGbytes thread), but the magnitude (and thus the values of the individual X, Y, and Z components) isn't. At least not to me.

**Some Simple Tests To See What Sort Of Magnitudes We Get**

I did a couple of tests with a similar setup to my "Material Room Du Node Strange Behaviour (PP2014/Poser 9 Firefly) ?" thread.

Create a 1 PNU square 4 vertex/1 face prop with its centre at the origin oriented so that you'll see it face on from Poser's front camera.

Import it into Poser (I used PP2014)

Apply my http://www.sharecg.com/v/85287/gallery/11/Poser/Signed-10-Digit-Integer-Visualizer-MT5 shader.

Plug a dPdu node into it and set the multipler to one million

Set all Front Camera scale values to 100% and dolly values to 0.0

Set render size to 500x500.

Render - note the value displayed on the square in the render

Change a setting and re-render. Repeat as necessary.

**Here are my first test results:**

Front Camera 'Scale' value ... (1000000 x dPdu)

100% ... 6046874

200% ... 12093749

400% ... 24187498

800% ... 48374995 (very small text, so I might have misread it)

That's almost perfect doubling each time. I'd expect dPdu and dPdv to be the same for this test, and I get the exact same values if I use dPdv instead of dPdu.

**Do those values make any sense?**

The square is 1 PNU wide, which is 103.2", which is 1032 'P' units (the P node output is in 0.1" units)

The first render (scale 100%) is about 500 pixels wide.

1032 'P' units across 500 pixels gives 2.064 'P' units per pixel

The dPdu value I got is 6.046874, just under three times this.

The second render (scale 200%) is about 250 pixels wide.

1032 'P' units across 250 pixels gives 4.128

The dPdu value I got is 12.093749, just under three times this.

Etc

I recall (e.g. here) that if you want to extract just the X, Y, or Z value from a P node you need to multiply the value by 3. The output of the dPdu is a vector, so I'm thinking that the same may apply ?

**Tentative first guess at the equation:**

If that's true, then for this very simple test case:

dPdu = 3 x (10 x square width in inches) / (square width in pixels on the render)

dPdv = 3 x (10 x square height in inches) / (square height in pixels on the render)

That' seems a good starting theory - next step would be to do something slightly different with the test and see if the results match what the equation gives us.

*(Note: I was surprised that the rendered size of the square seems to be involved...)*

Here's the numbers from those render screenshots

**yRot ... 1000000 x dPdu**

-60 ... +33037170

0 ... +12093749

+60 ... -885324

I'm totally stumped trying to think of an explanation for this !

]]>**xRot ... 1000000 x dPdv**

+60 ... +18355968

0 ... +12093749

-60 ... -8856812

I'd expect the +-60 dPdu and dPdv values to all be the same, around 24000000.

But all four values (this post and the previous) are different. Very different.

*(Yes, it could be my shader. But I don't think so.)*

Since I'm using a similar test setup now (as described in the OP of this thread), I tried to see if I could reproduce these dPdu steps using my current setup by simply increasing Front Camera Scale from 100% to 420% in 10% steps, and plotting the rendered numeric values and values derived from my tentative dPdu equation on the same graph.

Note: I didn't physically measure the pixel width each time - it's calculated as:

Pixel_Width = 500 / (Cam_Scale / 100)

The 'Calculated' value uses:

Calculated =3 x (10 x 100.32) / (Pixel_Width)

*(if you saw a note about an extra factor of 10 here - I looked at the wrong spreadsheet!)*

Regarding the unexpected values I got when I did the yRot & dPdu and xRot & dPdv tests a couple of posts back, I just realized while doing a series of test Z rotating the square in 10 degree steps that when I plug dPdu into my shader it's converting a vector to a scalar.

When the square is perpendicular to my line of sight with it's bottom horizontal the Y and Z components of dPdu are zero, and the dPdu vector has **only** an X component.

But as soon as I rotate the square about **any** axis then the dPdu vector also has a non-zero Y and/or Z component as well.

Since I was assuming that the rendered numeric value was just the X component...

So I need to go away and redo thos rotation tests. In the meantime I posted the rendered numeric results of my 10 degree Z rotation step tests over in post #53 of the CGbytes thread - it's a nice 180 degree section of a horizontally offset sine curve.And the offset looks like -45 degrees ?

]]>(I've posted a zipped version of the PZ3 I'm using for these tests in post #56 of the CGbytes thread if anybody else wants to try)

**Rotating The Square About The Z Axis**

Perfect sin and cos curves.

**Rotating The Square About The Y Axis**

Clearly -sin and cos curves, but some points are off. That could be my shader, my reading of the values, or something else.

**Rotating The Square About The X Axis**

I expected fixed values, zero for Y and Z, non-zero for X. Not steps. And the steps are almost doubling each time, 36.28 -> 68.53 -> 133.03. That's similar to the large steps I saw as I increased camera scale here.

Concentrating on the more ragged red cosine curve in the previous post with the misplaced zero rotation value. Going in steps of 1 degree revealed not just a step down to the mid-thirties, but multiple steps up and down between the sixties and eighties! I Slightly more words in post #59 of the CGbytes thread.

]]>

I'm still hoping that somebody can come up with some sort of explanation for the out-of-place points in the graphs in the last few posts on this thread... ]]>