4 Pages<1234>
Options
Go to last post Go to first unread
3dcheapskate  
#41 Posted : Monday, June 13, 2016 11:41:18 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)
I still can't make head or tail of these 'step functions' that seem to appear in Du (and dPdu), so I've posted the question about the step function in Du on the SM Poser forum here https://forum.smithmicro.com/topic/318/material-room-du-node-strange-behaviour-pp2014-poser-9-firefly


I've also realized that part of what it says in the Poser 9 Reference Manual about Du, dPdu and dNdu now makes some sort of sense to me, but a lot of it is still goobledigook*

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’.

The bit that makes sense now is in bold, i.e. the bit about dPdu being a vector perpendicular to the surface normal in the U direction. This is the conclusion I came to in post #33 back on page 2, so it's nice to see that I haven't got it totally wrong! :)

I've also added those definitions from the manual to the OP.


*the gobbledigook: confused

S space: I have a vague idea that 's' is related in some way to 'U', and 't' in some way to 'V'.

derivative: I know, sort-of, what a 'derivative' is. Slope of a curve/graph, rate of change, 'd something by d something else', and all that calculus-type stuff that I did in school decades back, but never really used since then.

varying point surface shader variable: isn't this just tautology ?

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

I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#42 Posted : Wednesday, June 15, 2016 10:19:31 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)
(This and the following 2 posts were originally posted on the SM thread)

Quick Verification That Du Is Related To U Mapping Direction And NOT Screen/Render Horizontal Axis

(I know that nobody else thought it was, but I'm odd... ;o)

(I'm just thinking out loud for this post...) With regard to S (and T) p386 of the PP2014 Poser Reference has:

-U Texture Coordinate - The U node returns the S coordinate in texture space of the pixel currently being rendered. It has no user-definable attributes.

-V Texture Coordinate - The V node returns the T coordinate in texture space of the pixel currently being rendered. It has no user-definable attributes.

-Du - 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.

-Dv - The dV node defines the rate of change of surface parameters as pertains to the current pixel’s location in T space. The ‘d’ indicates a derivative of the ‘V’ parameter.


From U/V Texture Coordinate definitions ST is clearly a point in UV (texture) space - the point that represents the pixel being rendered, i.e. the values we use as a lookup into the texture map.

For the Du/Dv definitions S and T are the 'spaces' in which the rates of change of U and V respectively are being calculated. But even knowing that dU is the rate of change of U with respect to screen space I'm still having difficulty visualizing what this actually means, even if I just consider a flat plane perpendicular to the line of sight.

I applied my shader (now uploaded to ShareCG here) to the Poser ground (scaled at 100%) plugged Du x 1,000,000 into it, viewed from the top camera with scale around 800-900% and rendered 3 times with the ground rotated 0, 45, and 90 degrees. I got exactly the same numeric image each time.

So 'S space' seems to be tied to the U direction of the UV mapping of the prop, but mapped onto the output screen*

*that last bit was based on bagginsbill's observation on the SM thread here

Edited by user Thursday, June 16, 2016 8:41:41 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
rotationtest.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#43 Posted : Wednesday, June 15, 2016 10:21:27 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)
(This, the previous, and the next post were originally posted on the SM thread)

Realization Of What Unreadable Numbers From My Shader Actually Mean

Another thing just struck me about the numeric textures I'm seeing when I render. For the number to be clearly displayed the input value to the shader (the 'Value_To_Display' input of my compound node) must evaluate to exactly the same value for every pixel on the surface. And usually (at least for the bits that display green) it does.

The attached image shows a few top camera screenshots (different top cam scales) of 1,000,000 x Du driving my shader applied to the groundplane

In three of those it looks as if Du is being evaluated to at least two different numbers across the surface.

Of course, it could just be my ropey shader. But I think there's more to it...

Edited by user Wednesday, June 15, 2016 11:28:53 PM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
unclear.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#44 Posted : Wednesday, June 15, 2016 10:24:27 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)
(This and the previous 2 posts were originally posted on the SM thread)

Finally A Small Set Of Du Values That Make Some Sense !

I've finally got a small number of renders that seem to match what Du is supposed to be doing, and may help to make clear (to me!) exactly how Du is supposed to work.

1) PP2014 one-sided square with Du x 1,000,000 plugged into my shader, viewed from the front camera. Square renders to about 316x316 pixels. Du is 0.003040

UserPostedImage

2) Set xRot=60 for the square. It rotates 60 degrees about a horizontal axis through the world origin. The height of the square as viewed from the front camera is exactly half what it was but the height hasn't changed. The value of Du hasn't changed, still 0.003040 and is what I expected

UserPostedImage

3) Set xRot back to zero and set yRot=60. The square rotates 60 degrees about a vertical axis through the world origin. The width of the square as viewed from the front camera is now exactly half what it was. The value of Du has doubled to 0.006081 and is what I expected

UserPostedImage

4) Set yRot back to zero, change the scale of the front camera so that the square renders at half it's original size, 158x158 pixels. Du is 0.006081 and is what I expected

UserPostedImage

5) Set xRot=60 so the height of the square as viewed from the front camera is exactly half what it was but the width hasn't changed The value of Du hasn't changed, still 0.006081 and is what I expected

UserPostedImage

6) Set xRot back to zero and set yRot=60 so the width of the square is now exactly half what it was. The value of Du has doubled to 0.012162 and is what I expected

UserPostedImage

The value of Du in these tests was inversely proportional to the width of the square in pixels on the render.

I also tried the same tests with Du and got appropriate results - the Dv value started at 0.003040 and doubled when the height halved.

Note that this set of results was rather lucky (at last!) - most things I tried gave me unreadable numbers (as per the previous post) or numbers that refused to change (the step function problem).

Edited by user Wednesday, June 15, 2016 11:29:58 PM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
1rot0.jpg
1rotx60.jpg
1roty60.jpg
2rot0.jpg
2rotx60.jpg
2roty60.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#45 Posted : Wednesday, June 15, 2016 11:25:23 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)
Possible Basic Eqations For Du And Dv ?
Regarding the way Du and Dv are supposed to behave I've made a comment on the SM thread here to say that it looks (for the specific test I did, and this may not be generally true) as if:

Du = 0.96 / (rendered width in pixels)
Dv = 0.96 / (rendered height in pixels)

The specific test I did used an orthographic camera with a 4 vertex/1 face plane scaled at 100% perpendicular to the line of sight and with it's U mappin g direction horizontal and V mapping direction vertical on the rendered image.



Here's the more wordy version that I posted on the SM thread earlier...

Here's a summary of what I think I've learnt from them regarding how Du and Dv should behave:

1 - from the test where I got doublings of the values of Du (and Dv) as the render dimensions in pixels halved
In the only test so far where I've got Du and Dv to behave in a way that could match what they're supposed to do, and with the following specific caveats based on that test...

a) It's for the specific mesh I was testing with (i.e. the Poser one-sided square, which has just 4 vertices and 1 face)
b) I was viewing from an orthographic camera with square perpendicular to the cameras line of sight.
c) The U mapping direction was horizontal (left to right) on the rendered image and the V mapping direction was vertical (up) on the rendered image

...then a fairly simple equation relates Du, Dv and object size in pixels in the render:

Du = 0.96 / horizontal pixels

Dv = 0.96 / vertical pixels

(Note: The actual value I got isn't precisely 0.96, but between about 0.96064 and 0.96079. My measurements of pixel size are probably not quite right, maybe +/- 1 or 2 pixels, so around 1% error maximum - making the correct figure probably somewhere between 0.95 and 0.97... but unfortunately not a nice round 1.00!)

2 - from the test with the square rotated 0, 45, and 90 degrees around an axis parallel to the camera's line of sight
I have difficulty putting this into words, but Du is related not to actual 'pixels' (which are a grid with horizontal and vertical axes), but to point-to-point distances on the rendered image measured in pixels. Does that make sense? Can somebodty express it in better words?

Edited by user Thursday, June 16, 2016 12:06:45 AM(UTC)  | Reason: Not specified

I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#46 Posted : Wednesday, June 15, 2016 11:40:18 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)
Tentative Idea Of What Du And Dv Might Represent In A More General Case

I was looking through this thread again and the last image from post #33 struck me, specifically the words "If the flattened UV map is placed tangential to the surface at point Q (with U and V oriented appropriately)..." and the semi-transparent UV map (positioned as noted) as it appears on the rendered image.

Here's the image again:

Last image from post #33

And here it is with some additional yellow and green annotation. My latest guess is that 'S space' and 'T space' (as referred to in the manual in the defintions of the Du and Dv nodes) are simply a two-axis coordinate system on the rendered image, whose origin is at the point currently being rendered, and who are not necessarilly perpendicular to each other. I'd also guess that the 'width/height in pixels' required to calculate Du and Dv would be the lengths of the green arrows if you extended them to the the edges of the yellow rhomboid.



.

Edited by user Thursday, June 16, 2016 1:13:23 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
IsThisIt.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#47 Posted : Thursday, June 16, 2016 2:03:55 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)
...And A Hopefully Clearer Diagram To Show What I'm Thinking

(duplicate of SM thread post here)

The last couple of tests I've done, in conjunction with the near certainty that Du and Dv are something to do with rate of change of U and V coordinate mapping with respect to some sort of axis pair in screen (render) space, plus a sudden flash of inspiration from an image on the CGbytes thread (warning: my flashes of inspiration are often wrong!), and I've come up with this as a possible 'what Du and Dv are supposed to be'.

Edit: bagginsbill just pointed out over on the SM thread that the UV mapping of the Poser one-sided square doesn't cover the full UV map area. I just checked and found that it only covers about 97% of both the width and height, leaving a small border all around. So it seems that it isn't 0.96 that I should be using, but 1.00 which is much more logical.
It's now only the scaling of this imaginary 'flattened UV map' that I need to find.
And of course this odd step function effect problem.

Edited by user Tuesday, June 21, 2016 2:14:30 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
Globe.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#48 Posted : Thursday, June 16, 2016 2:26:01 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)
Effect Of Mesh Density On Du And Dv

This is just a quick test, and clearly shows that subdividing the mesh (I exported the 4 vertex/1 face one-sided plane as an OBJ, subD'd it once and twice in Blender and reimported both into Poser) doesn't halve/double the value of Du.

However, it does seem to have a small effect, which I find very odd.
3dcheapskate attached the following image(s):
meshdensity.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#49 Posted : Thursday, June 16, 2016 8:21:30 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)
Minor Correction To Equations For Du And Dv

After bagginsbill's correction my equations for Du and Dv are now:

Du = 1 / (length of green S-space axis)
Dv = 1 / (length of green T-space axis)


Going back to the results I got in my first numeric Du tests back in post #36 I can now add a 'Calculated Du' column

HtWdthPixels Du x 1M Calculated Du
170 5952 5882 (+1.01%)
206 5208 4854 (+1.07%)
278 3676 3597 (+1.02%)
319 3125 3134 (-1.00%)
380 2840 2631 (+1.07%)
533 1953 1876 (+1.04%)

The number in brackets is the difference between the reading I took and the calculated value (1 / HtWdthPixels). It now looks as if all those numbers were actually all pretty close !

Edited by user Monday, June 20, 2016 3:53:14 AM(UTC)  | Reason: Not specified

I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#50 Posted : Monday, June 20, 2016 4:21:00 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)
Du And Dv - Apparently The Number Of Micropolygons Is Causing The Small Steps...

Stefan posted on the SM thread to say that the small steps I'm seeing are due to the Reyes renderer's chopping of polygons into micropolygons - every time the number of micropolygons in the grid changes there'll be a step.

I'm still trying to work out exactly how that fits back into my equation...

Edit (21 June 2016): after Stefan's comment I made a couple more posts on the SM thread, just thinking out loud as usual. I posted two rough sketches (attached - remember, they're just to give an idea of what I was thinking. There's a little bit more info about that in the SM thread), and after a bit more thought wondered whether simply replaced 'pixels' with 'number of micropolygons' in my latest equations for Du and Dv would fit the results I'm seeing ? Assuming that the micropolygon is about a pixel (with a+- 6 to 11% tolerance) it seems possible. Here's the newest equations for Du and Dv:

Du = 1 / (S-space 'width' in micropolygons)

Dv = 1 / (T-space 'height' in micropolygons)

...But The Big Steps Were Most Likely A Stupid Mistake On My Part!

Since coming up with the latest equations for Du and Dv, every test I've done with my basic 4-vertex/1-face square and my numeric shader gives me an answer pretty close to what the equations give me.

I've been totally unable to duplicate the weird steps I saw in post #40, so I reckon I made some stupid mistake when I was testing. Twice!

Edited by user Tuesday, June 21, 2016 12:39:59 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
1466165237863-microsteps.png
1466168485715-microsteps2.png
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#51 Posted : Monday, June 20, 2016 11:52:41 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)
Back To dPdu (And dPdv) - I Should Double-Check The 'Steps'...

Because the big, totally incorrect steps that I spotted in Du seem to have been user error on my part, it would seem wise to double-check the apparent step function that I saw in dPdu back in post #37. Is this also user error on my part?

Using a tentative equation for dPdu that I posted in the OP of a new "What Exactly Is The Magnitude Of The Output Of The dPdu Node ?" thread on the SM forum, which is this...

dPdu = 3 x (10 x square width in inches) / (square width in pixels on the render)
(N.B. this equation only seems to work if I view a flat square that is perpendicular to the line of sight of my orthogonal camera)

...I plugged the values I got back in post 37 into this equation and plotted both the calculated results and the rendered numeric values on the same graph.

My interpretation of the graph is that the equation seems to be producing the correct result, and there is indeed an odd step function in the output of the dPdu node.

If the steps in Du are somehow caused by the chopping into micropolygons, maybe something similar is happening here with dPdu too ?

(as always, this step function could be due in whole/part to an error in my shader, but I really don't think so. Could the steps be something to do with the chopping into micropolygons, like Stefan suggested for Du on the Du-related SM thread ? )

Edited by user Tuesday, June 21, 2016 12:43:59 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
Post37CalcVRender.png
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#52 Posted : Tuesday, June 21, 2016 2:07:06 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)
...And The dPdu Steps Are Definitely There

I just reproduced the dPdu steps using a new, repeatable setup - details in this post of the SM dPdu thread.

Results shown in the attached image.

There seem to be both small steps (e.g. between Cam_Scale 320% and 330%) and huge steps where the output of the dPdu node just about doubles (e.g. between Cam_Scale 400% and 410%).

Edited by user Tuesday, June 21, 2016 2:26:35 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
dPduRetest.png
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#53 Posted : Tuesday, June 21, 2016 6:11:59 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)
Odd Behaviour Of dPdu When I Rotate My Square - Maybe Not So Odd...

I like graphs ! Since that last graph seems to confirm that there is a step function in dPdu when I change the scale of the front camera, I wondered whether taking a bunch of readings at a fixed front camera scale (I chose 200%) but adjusting the rotation of my 1 PNU square by 10 degrees each time, and then plotting that might be useful.

I decided to do the Z rotation of the square in 10 degree steps from -90 to +90, so the square is rotating about the line of sight of the front camera.While I was taking the readings I realized that the output of dPdu (which is a vector) is being converted to a scalar quantity when I plug it int didn't get doubling of the value with my simple xRot with dPdv test and yRot with dPdu test over on the SM thread. Since I was over halfway through taking my new readings when that struck me I decided to continue and just plot the rendered numeric values.

Now that's 180 degrees worth of a cos (or sin) function with a horizontal offset isn't it ? And that offset looks very much like -45 degrees.

Edit (after a good night's sleep): a sine curve with a -45 degree offset is simply ( N x ( sin(A) + cos(A) ) ), so this now that makes sense!

Edited by user Tuesday, June 21, 2016 9:18:28 PM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
zRotSquare.png
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#54 Posted : Tuesday, June 21, 2016 6:53:38 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)
X Component Of dPdu Now Makes Sense For +-60 Degree Z Rotation Of Square...

A simple correction to what I'm plugging into my shader (not dPdu, but the X component of dPdu) and the rendered numeric value when my square is Z-rotated by +-60 degrees now makes sense.

Note: instead of 6.046874 when I render with Front Cam Scale=100% and no rotation, thus getting a 500 pixel wide rendered square, I now get triple this value, i.e. 18.140624.

That's because when you plug a vector (or colour) output (e.g. dPdu) into a scalar (numeric) input the three values are averaged by adding and dividing by three. The Component node just takes the single value you select.

Edited by user Tuesday, June 21, 2016 7:58:19 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
better.jpg.png
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#55 Posted : Tuesday, June 21, 2016 7:16:54 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)
...But Not For X-Rotation Or Y-Rotation

...but if instead of Z-Rotating my square I Y-Rotate or X-Rotate by 60 degrees (which makes the rendered width or height respectively of the square exactly half of what it was with zero rotation) then I don't get what I expect (i.e. doubling of the dPdu X value for Y rotation, no change for X rotation)

Hmmm... maybe it's because the 'u' direction in dPdu (rate of change of 'P' with respect to 'u') was still parallel to the screen (or render) plane when I Z rotated the square, but for X or Y rotation it isn't ?

If I take the X component of dPdv (instead of dPdu) I get a black square for all five renders (that's my shader's way of representing zero... :oS) which makes sense I think - the 'v' direction in dPdv will be in the World ZY plane, and there can be no change of X in this plane.

I can sense smoke coming out of my brain, so I'd better stop at that for now... ;o)

Edited by user Tuesday, June 21, 2016 7:47:07 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
dPdu xyrot.png
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#56 Posted : Tuesday, June 21, 2016 10:15:44 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)
I Now See That X, Y, And Z Components Of dPdu Change Logically When Z Rotating My 1 PNU Square

Graph of my results attached.

Going back to my tentative equation for dPdu in the OP of the SM thread (i.e. dPdu = 3 x (10 x square width in inches) / (square width in pixels on the render) ) this now needs to be modified and split into X, Y and Z components. Here's what I think the X and Y component equations look like for this Z rotation test:

dPdu X = 8.789 * ( (10 * square width in inches) / (square width in pixels on the render) ) * cos(zRot)
dPdu Y = 8.789 * ( (10 * square width in inches) / (square width in pixels on the render) ) * sin(zRot)


The 8.789 has me stumped - I thought that the multiplying factor of 3 I put into the original equation (OP of SM thread) would cancel out with the factor of 3 I realized I was introduced by plugging a vector output into a scalar input). But 8.789 is more like 3 * 3 than 3/3



I think it's probably worth doing the same sort of graph for X and/or Y rotation of my square, and put this factor of 8.789 aside for the time being (along with the dPdu step function when I change camera scale)

N.B. I've also attached a zipped up PZ3 to this post 'dPdu Y (zRot -90 to +90).zip' - unzip it and you'll find 'dPdu Y (zRot -90 to +90)pz3' which is the PP2014 test scene I used here. It's the default PP2014 scene with Andy removed, ground invisible, all lights deleted and one infinite added back, my 1 PNU square loaded with my (100 * Y component of dPdu) plugged into my shader, front cam set to 200%, and a 19 frame animation set up to render square Z rotations from -90 to +90 in 10 degree steps. Use the Make Movie option to render a series of single frames - makes it much easier !

Edited by user Wednesday, June 22, 2016 1:57:08 AM(UTC)  | Reason: Not specified

File Attachment(s):
dPdu Y (zRot -90 to +90).zip (19kb) downloaded 6 time(s).
3dcheapskate attached the following image(s):
dPdu XYZ for zRot.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#57 Posted : Wednesday, June 22, 2016 12:21:58 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)
Y Rotation Of My 1 PNU Also Seems To Gives Sensible Results, But With Some Incorrect Values...

(N.B. This test is Y rotation - the labels on the graph that say X rotation are wrong ! Graph corrected)

Similar test with FrontCameraScale=200%, but rotating my 1 PNU square around the Y axis only from -180 to +180 in 10 degree steps.

At Y rotations of -90 and +90 the square is side-on, and as the Y rotation approaches these values the rendered width of the square makes it impossible to read the rendered values.

I originally tried a -90 to +90 range, but because of the readability problem at both ends of this range I could only get readings for -70 to +70 and the 'dPdu Z' (green) curve/line wasn't clear. So I extended the range of my readings to -180 to +180 to be certain that I was getting circular function curves. Note that the rendered values for Y rotations between -90 and -180, and between +90 and +180 will be back to front since we're viewing the square from the back !

Readings marked with a '-' were unreadable because of the rotation, readings with a grey background indicate that the digits to the left of the decimal point weren't clear.

The red dPdu X curves is clearly '(about 68) * cos(X_Rotation)' but with occasional points that seem way off (these may be due to errors in my reading of the rendered values, or errors in my shader, or errors in something else) (post #59 has more detail of this red curve around -20 to +20 Y rotation - it gets weirder !)

The green dPdu Z curve is clearly '(about 73) * -sin(X_Rotation)', also with occasional points that seem way off (same explanations for them)

Edited by user Wednesday, June 22, 2016 3:11:39 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
dPdu XYZ with Y rot.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#58 Posted : Wednesday, June 22, 2016 1:24:30 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)
X Rotation Of My 1 PNU Square - Not Quite The Expected Behaviour ?

Since X rotation of the square has no effect at all on the rendered width of the square, I'd expect the X component of dPdu to remain at a fixed value, and the Y and Z components of dPdu to remain at zero.

I see steps again...
3dcheapskate attached the following image(s):
dPdu XYZ with X rot.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#59 Posted : Wednesday, June 22, 2016 2:59: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)
More Detail For X Component Of dPdu With Y Rotation Between -20 And +20

I wanted to see if the 'way off' point at zero Y rotation for the red line in the post #57 graph was just me.

So I did 1 degree steps from -20 to +20. At around -7 degrees and + 7 degrees there's are definite step in the dPdu X component value between sixty/eighty-something and the thirty-something

I wondered whether the values in the eighties were simply me misreading unclear sixties values, but I did a few additional readings (not recorded here) at 0.1 degree steps either side of some values. The eighty-something values are NOT misreadings - there are very clearly several steps up and down between sixty-something and eighty-something !

Edited by user Thursday, June 23, 2016 11:06:26 PM(UTC)  | Reason: Making the wording a bit clearer

3dcheapskate attached the following image(s):
MoreDteail.jpg
I'm still on Poser 9 and/or PP2014...
Erogenesis  
#60 Posted : Tuesday, December 5, 2017 3:25:02 PM(UTC)
Erogenesis

Rank: Advanced Member

Joined: 9/15/2012(UTC)
Posts: 1,995

Thanks: 141 times
Was thanked: 132 time(s) in 85 post(s)
holy crap! this is golden information!
______
"The fool is not the one that does something foolish, but the one that does nothing at all"
Users browsing this topic
Guest (5)
4 Pages<1234>
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