4 Pages123>»
Options
Go to last post Go to first unread
3dcheapskate  
#1 Posted : Tuesday, April 19, 2016 7:58:44 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
N.B. Feel free to dive in and post any comments, observations, experiments etc. This isn't intended to be a monologue - it's just that I happen to be in a inquisitive mood with time on my hands...

Edit 14 June 2016: Definitions From Poser 9 Reference Manual

I guess I should really have started by quoting these... :)

The dU node defines the rate of change of surface parameters as pertains to the current pixel’s location in S space. The ‘d’ indicates a derivative of the ‘U’ parameter.

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 dNdu node represents the derivative of the surface normal in the ‘U’ direction. In other words, it defines the rate of change of the surface normal along ‘U’.


Getting The Ball Rolling - Simplify! Consider ONLY The U-Direction (Variables dU, dNdu And dPdu)



There's a couple of threads about them (or at least mentioning them)...



- byro.br's 2007 "du, dv, dPdv etc.... does ANYBODY know ANYTHING?" thread( http://forum.runtimedna.com/showthre...-know-ANYTHING ) especially post #17

- bluearms 2008 "Curvature Calculation using dNdu,dNdv,dPdu,dPdv" thread relates to using these four nodes in Matmatic (2 pages, http://forum.runtimedna.com/showthre...dNdv-dPdu-dPdv )

- bagginsbill's 2015 "Bronze and Verdigris" thread ( https://www.renderosity.com/mod/forumpro/?thread_id=2889830 )



...but that's all, and after reading them and experimenting I still can't make head or tail of them, or get them to do anything useful.



I've been idly playing (in Poser 9) to try and get my head round them, and thought it might be worth sharing. From what I've read the UV mapping of the object is important - it seems fairly clear that anything in a shader that involves U or V (or du or dv) must be picking up something from the UV mapping. I decided to play with a half cylinder with a fairly intuitive UV mapping - i.e. simply uncurling it till it's flat and squashing it a bit to make it square.



I used four of these and plugged a simple shader network into the Ambient_Color of the PoserSurface for each (I'm only using ambient - there are no lights in the scene)



Anyway, they say that a picture speaks a thousand words, so here's three pictures. The first is the setup and a top camera render, the second is left/right camera renders, and the third is from the main camera.



The second half-cylinder (the first is the one next to Andy) looks different in the side, top and main camera renders. This seems to tie up with byro.br's comment in post 14 of the RDNA thread that dU (and dV) represent the rate of change of U (or V) with respect to screen coordinates.



Edit: Note: Poser 9 renders, Automatic settings at highest quality (i.e. one notch above 'Final') and Smooth Polys turned on.



The Math_Function plugged into Input_2 of each Color_Math Add is simply to give me an easy way to multiply the 'Colour' (which is probably a vector*) by any number I want. The numbers I ended up using were just values that seemed to give me nice colour representations (i.e. that seem to convert the X,Y,Z vector values to a 0.0 to 1.0 (or more accurately a -1.0 to 1.0) range.



*I know it's confusing !! There's a bit more on that later.

Edited by user Monday, June 13, 2016 11:34:48 PM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
1-u_dU_dPdu_dNdu_Test_pt1.jpg
2-sideViews.jpg
3-DifferentView.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#2 Posted : Tuesday, April 19, 2016 8:00:17 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Vectors And Colours - Negative Vectors Will Be Black When Converted To Coloyur Unless You Take The Absolute Value

Recalling that Firefly treats colours and vectors as the same thing, the RGB colours are probably XYZ vectors. Colour representation on the screen/render is limited to values of R, G, and B in the 0.0 to 1.0 range, whereas vectors can have X, Y, and Z values that are greater than 1.0 or less than zero (i.e. negative).

So the fact that I see green and yellow for the dPdu and dNdu half-cylinders from one side view, but red fading to black from the other is possibly because the green (Y) value on this side is negative. So adding an extra Abs Color_Math node should make it a visible colour - and it does.

Edited by user Saturday, April 23, 2016 5:12:37 AM(UTC)  | Reason: Corrected 'red(x)' to 'green (y)' and added link

3dcheapskate attached the following image(s):
5-Uagain,CheckAbs.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#3 Posted : Tuesday, April 19, 2016 8:17:15 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Rotating The Test Geometry - A Surprise ! But It Shouldn't Have Been - It's Totally Logical

I then rotated each half-cylinder 90 degrees anti-clockwise (when viewd from above) - i.e. yRotate = 90
I didn't expect to see any change in the dPdu and dNdU ones because the UV mapping hasn't changed
But I was wrong, so I've obviously misunderstood something.

Edit see posts 6 and 9 for explanation of what I misunderstood - the blue-cyan-green after rotating are exactly what I should have expected.

Edited by user Saturday, April 23, 2016 5:14:01 AM(UTC)  | Reason: Added note about explanation of what I got wrong

3dcheapskate attached the following image(s):
6-U,Abs,+Rot90degcCCW.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#4 Posted : Tuesday, April 19, 2016 8:22:45 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
A Brief Diversion To Look At The V Variables - Just A Test Render For Later Reference

Confused by that I decided to temporarily go back to the original four half-cylinders, without any Abs nodes, and just try swapping the U-based nodes for the V-based equivalents.

I.e.
'U_texture_coordinate' node changed to 'V_texture_coordinate' node
dU -> dV
dPdu -> dPdv
dNdu -> dNdv

This is what I got.

Edited by user Saturday, April 23, 2016 5:16:18 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
4_ChangeUtoV.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#5 Posted : Tuesday, April 19, 2016 8:40:51 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Conclusion So Far

For dPdu and dNdu it appears that:

- Red indicates the X component of whatever change it represents
- Green indicates the Y component of whatever change it represents
- Blue indicates the Z component of whatever change it represents

Edit: removed the 'I'm not sure about this' stuff, because I now know it's correct.



Edited by user Saturday, April 23, 2016 5:17:02 AM(UTC)  | Reason: Struckout the bits that I got wrong!

I'm still on Poser 9 and/or PP2014...
bagginsbill  
#6 Posted : Tuesday, April 19, 2016 12:24:13 PM(UTC)
bagginsbill

Rank: Advanced Member

Joined: 2/25/2016(UTC)
Posts: 76

Thanks: 1 times
Was thanked: 24 time(s) in 19 post(s)
Wow, you're wading into deep waters. Good job.

Originally Posted by: 3dcheapskate Go to Quoted Post
I then rotated each half-cylinder 90 degrees anti-clockwise (when viewd from above) - i.e. yRotate = 90
I didn't expect to see any change in the dPdu and dNdU ones because the UV mapping hasn't changed
But I was wrong, so I've obviously misunderstood something.


You missed something. dPdu is rate of change of the point with respect to change in u. Another way to say it is this is the ratio or density of 3D space coordinates to UV space coordinates along the U dimension. Clearly, if you ratate the objects in space, the 3D space coordinates change (in world coordinates) so dPdu will change as well. Perhaps you were thinking P is in model coordinates. It is not. The P node (and any related value) is in world coordinates.

Similarly, dNdu is rate of change of normal with respect to change in u. Another way to say it is this is the curvature of 3D space coordinates with respect to changes (movement) along the U dimension. As N is in world space, again, rotate the object will alter N which means altering dNdu.


Same holds for the V dimension cases.
bagginsbill  
#7 Posted : Tuesday, April 19, 2016 1:29:17 PM(UTC)
bagginsbill

Rank: Advanced Member

Joined: 2/25/2016(UTC)
Posts: 76

Thanks: 1 times
Was thanked: 24 time(s) in 19 post(s)

Originally Posted by: 3dcheapskate Go to Quoted Post

The Math_Function plugged into Input_2 of each Color_Math Add is simply to give me an easy way to multiply the 'Colour' (which is probably a vector*) by any number I want. The numbers I ended up using were just values that seemed to give me nice colour representations (i.e. that seem to convert the X,Y,Z vector values to a 0.0 to 1.0 (or more accurately a -1.0 to 1.0) range.


I collect useful functions like other people collect coins.

I know of several useful monotonic functions that map the domain -infinity..infinity onto the range 0..1. These are useful for visualizing arbitrary vectors as colors no matter how positive or negative they go. My favorite is

y = 1 /  ( 1 + k**x ) 

where k is a number between 0 and 1, typically .5. The smaller you make it, the more sensitive the mapping is to changes in values around 0. With k = .001 it is very nearly a step function at 0.

Note - I tried 5 times to write k to the power x using superscript. The editor showed it right, but the page did not.

I hate UI software engineers. They are almost uniformly incompetent.

I had to use double astersk ... k ** x means k to the power x.


 

Edited by user Tuesday, April 19, 2016 1:31:20 PM(UTC)  | Reason: Not specified

bagginsbill  
#8 Posted : Tuesday, April 19, 2016 1:45:17 PM(UTC)
bagginsbill

Rank: Advanced Member

Joined: 2/25/2016(UTC)
Posts: 76

Thanks: 1 times
Was thanked: 24 time(s) in 19 post(s)
I also know that when visualizing colors but trying to imagine them as numbers, our visual system (which is closer to logarithmic in sensitivity) misleads us.

A common trick I use is to square the color - this makes the perception of low vs. high more uniform.

For the purpose of visualizing vectors as colors, sometimes they're not huge, but rather just -1 to 1. (Such as unit vectors found in normals.) In such cases we like k to be very small. I find it convenient to set up k as a pow node using k = .5 ** S, where S is some sensitivity I want like 1 or 5 or 10 or 100.

Here's a fully assembled unit vector visualizer with sensitivity set to 5 and then again set to 20. I'm using it to visualize normal vectors on a sphere.




bagginsbill attached the following image(s):
sensor 5.png
sensor 20.png
3dcheapskate  
#9 Posted : Tuesday, April 19, 2016 10:20:14 PM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Explanation Of The Surprise Result In Post 3

Originally Posted by: bagginsbill Go to Quoted Post
Wow, you're wading into deep waters. Good job.

Originally Posted by: 3dcheapskate Go to Quoted Post
I then rotated each half-cylinder 90 degrees anti-clockwise (when viewd from above) - i.e. yRotate = 90
I didn't expect to see any change in the dPdu and dNdU ones because the UV mapping hasn't changed
But I was wrong, so I've obviously misunderstood something.


You missed something. dPdu is rate of change of the point with respect to change in u. Another way to say it is this is the ratio or density of 3D space coordinates to UV space coordinates along the U dimension. Clearly, if you ratate the objects in space, the 3D space coordinates change (in world coordinates) so dPdu will change as well. Perhaps you were thinking P is in model coordinates. It is not. The P node (and any related value) is in world coordinates.

Similarly, dNdu is rate of change of normal with respect to change in u. Another way to say it is this is the curvature of 3D space coordinates with respect to changes (movement) along the U dimension. As N is in world space, again, rotate the object will alter N which means altering dNdu.

Same holds for the V dimension cases.


Yes, I think I've missed a few things. The last time I knowingly did any calculus was probably over 30 years ago. Overnight a few very basic recollections surfaced - this is differentiation (which I recall being the calculation of the slope of a graph) and the dPdu variable is what we would have written in our maths lessons as dP/du, the rate of change of P with respect to u

Of course, when I rotated my half-cylinders by 90 degrees the U direction of the mapping was also rotated with respect to the world axes. So along with the fact that dPdu and dNdu are in world space, I think I can now make sense of the colour change when I rotated.


If I took points on the dPdu and dNdu half-cylinders with (U,V) coordinates of (0,0.5) and then traced lines from those points as I increased the U coordinates from 0 to 0.5, I'd end up with the white arrows shown in the attached picture (an annotated version of the earlier picture). These are the lines along which the 'slopes' dP/du and dN/du are calculated.

Andy is standing at the origin, and I've drawn the world space axes using the red=x, green=y, blue=z colour/vector correlation.

From the attached image it's now clear to me that:
- for the left hand render (unrotated) the Z components of dPdu and dNdu are zero, so there will be no blue.
- for the right hand render (rotated 90 degrees) the X components of dPdu and dNdu are zero, so there will be no red.

Edited by user Saturday, April 23, 2016 11:18:57 AM(UTC)  | Reason: highlighted what I overlooked

3dcheapskate attached the following image(s):
6-U,Abs,+Rot90degcCCW-Annotated.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#10 Posted : Wednesday, April 20, 2016 12:04:49 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Originally Posted by: bagginsbill Go to Quoted Post
...I know of several useful monotonic functions that map the domain -infinity..infinity onto the range 0..1. These are useful for visualizing arbitrary vectors as colors no matter how positive or negative they go. My favorite is

y = 1 /  ( 1 + k**x ) 

where k is a number between 0 and 1, typically .5. The smaller you make it, the more sensitive the mapping is to changes in values around 0. With k = .001 it is very nearly a step function at 0...



That sounds rather useful - I think I'll have to set up a wacro to add the required nodes.

(Edit: I decided not to use this for the present because I had a feeling that there was some meaning to the multiplers. Posts 15 and 16 provide an explanation for the factor of 100 difference in the multipliers for dPdu and dNdu, but there's still an unexplained factor of 15 in the dNdu...)

Edited by user Thursday, April 21, 2016 4:48:54 AM(UTC)  | Reason: Not specified

I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#11 Posted : Wednesday, April 20, 2016 12:31:26 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Failed Attempt At Finding A Simple Equation (Or Units) For Du

(I apologize for leaping all over the place, but I'm posting things as and when I try them - and I don't often think in straight lines!)

It's dawned on me that Du (and Dv) seem to be numbers, not vectors - in all the renders I've done the second half-cylinder away from Andy, the Du one, is always greyscale, not color.

I'm assuming that the 'units' of Du are something like '(fraction of full UV map width) per (pixel of the final render)'. On that basis I thought up an easy test.

I created a flat square 50x50 mesh with the simplest possible UV-mapping, placed that in my test scene at Andy's feet, applied the Du x 100 shader to its ambient and rendered from the top camera three times, moving the camera closer each time.

I then measured the square dimensions in pixels on the resultant renders, and noted the colour that the square had been rendered.

I guess I was hoping for a linear relationship between the width of the square and the colour (or the inverted colour). But it's not there - here's the simple calculations I did:

(U dimension in pixels) / (greyscale value 0 to 255)
98/127 = 0.77
197/63 = 3.13
375/31 = 12.09

(U dimension in pixels) / (256 - (greyscale value 0 to 255))
98/(256-127) = 0.76
197/(256-63) = 1.02
375/(256-31) = 1.67

Also I was surprised that the three colours I got were 1/2, 1/4 and 1/8th of full white (i.e. 127, 63, and 31) - looks like some sort of quantization is going on?

Edit: It's possible that I did this test in PP2014 with GC, which will have screwed it up. Off to retry. Oh dear, even in Poser 9 I discovered that simply changing the slider for 'Automatic' render settings resulted in big changes to the grey colour for a given render, even with no lights; and higher quality even caused artefacts. So what seemed like an easy test now looks useless.

Edited by user Saturday, April 23, 2016 11:20:47 AM(UTC)  | Reason: Did I do this test in PP2014 - with GC ?

3dcheapskate attached the following image(s):
Du+FlatPlane.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#12 Posted : Wednesday, April 20, 2016 2:03:57 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)

Looking At The Normals On My Half Cylinders - Later Realization That This Special Case Gives Sine And Cosine Curves For N And dNdu

I started drawing a diagram of the normals as viewed from the front camera, and I realized that it was easy to draw separate (very bad!) graphs of the X, Y and Z components of the normal with respect to U.

Unless I'm mistaken the slope of each of these graphs at any point is the X, Y, and Z component of dNdu ?

If that's correct then thinking NOT in terms of dNdu itself, but more in terms of the individual X, Y and Z components of dNdu, may be the way for me to get my head round this.

The +0.707 +0.707 0.0 figures on the diagram are the normals at specifc U values expressed as unit vectors in (X,Y,Z) form

EDIT: IMPORTANT ADDITIONAL OBSERVATIONS

Looking at my badly drawn graphs again it's clear that the red one is a cosine curve and the green one is a sine curve. My graphs of Nx and Ny (the X and Y components of the normal) against U are simply plotting the following curves (multiplying U by pi gives me the reguired angle in radians):

Nx = cos ( U × π )
Ny = sin ( U × π )


This maths blog link http://www.intmath.com/blog/mathematics/explore-the-slope-of-the-cos-curve-5301 reminded* me that the slope of the cos(x) curve is -sin(x), and the slope of the sin(x) curve is cos(x)

So for my fourth half cylinder (the dNdu one,furthest away from Andy) I think I can say that:

The X component of dNdu = - sin ( U × π )

The Y component of dNdu = cos ( U × π )

Also I know that the values of sin and cos are always in the range -1.0 to +1.0. So I'm rather puzzled that my multiplier of 33.3** gives be an apparently correct colour for the dNdu - I would expect a multiplier of 1 to do that ?



*I'm sure that I knew that once - a long long time ago

**An even better value is 15 (explained in post 17) - but that's still fifteen times bigger than I expect.

Edited by user Saturday, April 23, 2016 11:27:08 AM(UTC)  | Reason: Added important additional observations

3dcheapskate attached the following image(s):
normals.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#13 Posted : Wednesday, April 20, 2016 2:34:56 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Discovery That N And dNdu Are Independent Of Scale, Whereas P and dPdu Vary With Scale

For my half-cylinders the values of dNdu should remain the same regardless of how I scale the prop (i.e. the normal at U=0.0 will still point in the +ve X direction, at U=0.5 in the +ve Y, and at U=1.0 in the -ve X). But the dPdu should change.

To test this I simply scaled the 3rd and 4th props to half size and rendered.

The fourth (dNdu) stays the same colours as expected.
The third (dPdu) half-cylinder has changed colours, as expected.

Edit: actually the colours on the half size dPdu half-cylinder look even better - at U=0.5 I want to see RGB(0.707,0.707,0) which is roughly this                                  as opposed to bright yellow RGB (1,1,0)

Edited by user Saturday, April 23, 2016 11:25:40 AM(UTC)  | Reason: added note about RGB(0.707,0.707,0)

3dcheapskate attached the following image(s):
halfsize.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#14 Posted : Wednesday, April 20, 2016 4:23:53 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Looking At The Points On My Half Cylinders - Later Realization That This Special Case Gives Sine And Cosine Curves For P And dPdu

Front camera view again, this time annotated with Points (P), graphs of the X and Y components of P against U, and the slopes of these graphs which I think are what the X and Y components of dPdu actually represent.  I could have also drawn a graph of the Z component of P against U, but since they all have the same value I didn't bother.

Edit: Similar to the Nx and Ny graphs in the post before last (post 12), Px and Py appear to be cos and sin curves respectively, so their slopes would be -sin and cos curves respectively.

The X component of dPdu = - sin ( U × π )

The Y component of dPdu = cos ( U × π )

As before cos and sin only give values in the range -1.0 to +1.0, but I used a multiplier of 0.333 to get my reasonable colours. Same question - why didn't 1.0 work ?

But more curious to me is the fact that in the previous post (post 13) I said that I expected the colours of the dPdu half-cylinder to change if I changed the size of the half-cylinder. I think I was imagining extending the red dotted line and making it the hypoteneuse of a triangle - the horizontal edge being the full length of the U axis from 0.0 to 1.0, and the vertical edge being a section of the X-axis. The length of the horizontal edge would thus be a fixed 1.0 (no units), while the length of the vertical edge would be in whatever units I'd measured the radius of the half-cylinder and would be a fixed multiple of the radius.

The flaw in my logic was that I forgot that although the shape of the Px and Py curves are sin and cos curves, the magnitude of the curves is multiplied by the radius of the cylinder. And I think this also applies to the resulting dPdu X/Y component curves. I was half-aware of this, which is why I expected the scaling of the cylinder to change the dPdu



Edited by user Saturday, April 23, 2016 11:32:14 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
P and dPdu.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#15 Posted : Wednesday, April 20, 2016 8:14:46 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Re-evaluation Of The Latest Results, And Corrections To Posts 12 To 14

Looking through everything I've posted so far, something suddenly struck me about the dNdu results for my half-cylinder.

I've added some important additional observations to post 12, and added similar observations to post 14.


Time to let my subconcious work on this for another night.

Edited by user Saturday, April 23, 2016 11:34:29 AM(UTC)  | Reason: Not specified

I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#16 Posted : Wednesday, April 20, 2016 10:32:49 PM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Further Re-evaluation And Corrections. Explanation For The Factor Of 100 Difference In My dNdu And dPdu Multipliers

After sleeping on the problem I see an obvious answer to part of the question raised by the previous post.

I was correct that the curves for the X and Y components of P, dPdu, N and dNdu are sin and cos curves for my half-cylinder example.

Yes, the range of the X and Y components of N is -1.0 to +1.0, and thus the range of the X and Y components of dNdu will also be  -1.0 to +1.0

However, the range of the X and Y components of P depends on the size of the half-cylinder. My half-cylinder was created in Blender with a radius of 1 unit, so when it's imported into Poser it has a radius of 1 Poser Unit (103.12 inches)*. I scaled each half-cylinder to 10%, so the actual radius is 10.312 inches.

The range of the X and Y components of P is thus (-1.0 to +1.0) multiplied by this radius. But another important point is that the units of the P node are tenths of inches, not inches. So I should multiply Px and Py by 103.12, not 10.312. And the range will be  -103.12 to +103.12

I think this means that the range of the X and Y components of dPdu will also be  -103.12 to +103.12

So for my half-cylinder example the range of dPdu is 103.12 times larger than the range of dNdu.

So I would expect my multiplier for dNdu to be 103.12 times the multiplier for dPdu, and it's damn close - I'm actually using 100

These are the multipliers I would expect to use:
dNdu x 1.0
dPdu x 0.00969

These are the actual values I'm using:
dNdu x 33.3
dPdu x 0.333

So the remaining question is why are the multipliers I'm using around 30 times greater than the figures I expect ?
(Edit: I've now got better values for the multipliers, and they're only 15 times greater than expected - see post 17)



*Prove it to yourself. Ensure your display units are inches. Go to the material room advanced tab, plug any node into bump, and ensure that the bump value in PoserSurface is 1.0. Change your display units to Poser units. Make sure the material room updates (I usually go to the Pose room and then back to the material room. The Bump value on the PoserSurface is now 0.00969. So that's telling you that 1 inch is 0.00969 Poser units. 1 / 0.00969 = 103.12

Edited by user Saturday, April 23, 2016 11:37:05 AM(UTC)  | Reason: Not specified

I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#17 Posted : Thursday, April 21, 2016 1:52:44 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
More Re-evaluation, And Corrections To Post 11 And 13

Also just discovered that my simple Du tests in post 11 won't work, because the grey colour of the square for a fixed top camera position varies with render setting - even though I'm using just ambient and no lights.

This effect is also apparent in my main test renders, generally making the colours appear darker with higher render quality. But since I'm only looking at overall colour and trying to determine whether the numbers I'm feeding in as RGB are being cut off at +1 it's not so important.

But I also added a note to post 13 because the half size dPdu cylinder seems to have the most accurate colours, based on what I'm expecting to see. Based on that I have new best guess multipliers for dNdu and dPdu to convert the values I'm getting from my 10.312" radius half-cylinders to the range -1 to +1, i.e.

dNdu x 15
dPdu x 0.15

So it's now a factor of around 15 for dNdu, as opposed to the factor of 1 that I'm expecting. getting closer...

Edited by user Saturday, April 23, 2016 11:38:21 AM(UTC)  | Reason: Not specified

I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#18 Posted : Thursday, April 21, 2016 9:27:23 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Slight Sidetrack - Just Confirming Whether The N Node Returns A Unit Vector. Yes It Does.

I decided to take a look at the N node. This represents the surface normal (in world axes) at the current point. Being a 'normal', I'm expecting it to be a unit vector - e.g. (0,0,1) if it's pointing along the +ve Z-axis, (0.707,0.707,0) if it's pointing halfway between the +ve X-axis and +ve Y-axis, etc.

This is easy to test. Plug an N node into the ambient colour and render with all lights off. I actually added the same Color_Math:Multiply (using a multiplier of 1) and Color_Math:Abs nodes as I've been using in my tests. I also used a couple of Poser 9 props just for a change. My render settings were automatic, halfway between draft and final, with smooth polys off.


The colours I get in the render seem to indicate that the N node does indeed return a unit vector.
3dcheapskate attached the following image(s):
right.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#19 Posted : Thursday, April 21, 2016 9:42:15 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Test On A More Generic Scene To See What Sort Of Range To Expect For dNdu

With my half-cylinder the rate of change of normal with respect to U was constant if you consider it in terms of an angular rate - i.e. 1° for every 1/180th of the width of the UV map.

But with this new scene (Andy, tree, mushroom) the rate of change of surface normal will vary wildly. And that's before we even consider the UV mapping, which addsanother layer of complexity and confusion.

Let's try just plugging (dNdu x 1) into ambient. From my half-cylinder tests I know that I needed to use a multiplier of around 15 to get good colours. So my guess is that this will be too dark - and it is.



Edited by user Saturday, April 23, 2016 11:41:10 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
dndux1.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#20 Posted : Thursday, April 21, 2016 9:57:47 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Test On A More Generic Scene To See What Sort Of Range To Expect For dNdu (Continued)

So I tried using my dNdu x 15

Because of the wildly varying rate of change of surface normal with respect to the U of the UV mappings I expect to get values above 1.0, and thus some very bright white areas. I also imagine that there'll be areas where the rate of change is near zero, so I expect to see patches of black.

The patchwork effect that I ended up withsurprised me a bit, but I reckoned that was due to low render quality and the fact that smooth polys wasoff. So I cranked the render quality up to one notch above final, turned smooth polys on, checked that Andy and the props were using smoothing,and rerendered.



Edited by user Saturday, April 23, 2016 11:42:28 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
dNdux15.jpg
I'm still on Poser 9 and/or PP2014...
Users browsing this topic
Guest
4 Pages123>»
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Notification

Icon
Error