Material Room Du Node Strange Behaviour (PP2014/Poser 9 Firefly) ?

I'm going to ask if those last four posts of mine can be deleted.
I think they're more appropriate on the CGbytes thread (which is my 'thinking out loud' scratchpad for this Du etc stuff).
I've already posted them over there  and over there I can edit them as my thoughts get clearer.
Once I've got things a bit clearer in my own mind I can post a short summary back here. And I think that would be far more appropriate for this thread.

@bagginsbill said in Material Room Du Node Strange Behaviour (PP2014/Poser 9 Firefly) ?:
The explanation of the problem makes perfect sense.
I don't have the source code so I can't even tell what it is SUPPOSED to do, let alone what it is doing.
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'.

Almost. The .96 isn't intrinsic to the math, it happens to be the width and height of the one sided square's UV coverage.
Like I said (or byro.br did in 2007), if you use a very limited geometry in limited situations it will come out exactly as delta_U / delta_Screen_space_pixels.
If you used a properly made "square" with U going from 0 to 1, then the delta_U would be 1 and you'd exactly get 1 / the rendered width of the square.

Thanks bagginsbill, I didn't even consider that. Just to be 100% certain I went and confirmed for myself (exporting, opening in UV mapper, exporting a map, and checking in GIMP) that the onesided square's UV mapping is about 97% of the full UV map.
At last I think Du and Dv are beginning to make some sort of sense to me.
Back to the original point of this thread  I think I can now come up with an easy to reproduce test case to demonstrate the strange step function behaviour I've noticed in Du and Dv.
The test is going to have to rely on that numeric visualizer shader, which may have its own problems. But I don't believe that any likely mistake in the shader would account for this step function effect...

Okay, here's a simple repeatable test to demonstrate the behaviour of Du.
It indicates that Du generally produces the correct value, i.e. Du = 1 / (Sspace width in pixels), for a simple square prop.
But it also indicates that Du doesn't change smoothly, but in small inconsistently sized steps.
However, I have not yet managed to reproduce the steps with totally incorrect values that I mentioned in the OP. I'm still trying to reproduce that.~ ~ ~ ~
Here's the repeatable demonstration:Create a single sided square UV mapped to the full square.
#OBJ file
mtllib UVsquare1PNU.mtl
o Plane
v 0.500000 0.500000 0.000000
v 0.500000 0.500000 0.000000
v 0.500000 0.500000 0.000000
v 0.500000 0.500000 0.000000
vt 0.0000 0.0000
vt 1.0000 0.0000
vt 1.0000 1.0000
vt 0.0000 1.0000
usemtl Preview
s off
f 1/1 2/2 4/3 3/4Import the OBJ into Poser (I used PP2014 64bit).
Make the Poser ground invisible and move/delete Andy (they get in the way)
Apply my shader ( http://www.sharecg.com/v/85287/gallery/11/Poser/Signed10DigitIntegerVisualizerMT5 ) to the square
Plug a Du node into the 'Value_To_Display' and set the multiplier to one million.Set Front Camera DollyX and DollyY to zero and Scale, xScale and yScale to 100%, and then go to Front Camera view.
Set render size to 500 x 500. (the square should just about fill the render area)
Render.
Note the number that's rendered on the square (which is 1,000,000 x Du)Increase the Scale setting of the Front Camera, render, and note the new value.
Repeat with various values of Front Camera Scale (keep it higher than 100% to ensure that the whole square appears in the render).Here are some results  Front Cam Scale first, then the number displayed on the render.
100% ... 1953
200% ... 3906
400% ... 7812
800% ... 15625
1600% ... (too small to make out the number)
That sequence is almost perfect doubling of the value each time, which is the correct, expected behaviour. Also 1/500 = 0.002, so our first render at 100% which gave Du = 0.001953 was pretty close to the calculated value I'd expect. (I didn't bother actually measuring the square's width in the render for any of these test)150% ... 3129
300% ... 6298
600% ... 12489
Once again almost perfect doubling (the last digit or two aren't clear)125% ... 2604
250% ... 5208
500% ... 10416
Doesn't get much more perfect doubling than that.At this point I began wondering if the problem was all in my head!
So I tried changing scale in 5% steps...170% ... 3472
175% ... 3472
180% ... 3906
185% ... 3906
190% ... 3906
195% ... 3906
200% ... 3906
205% ... 4166
210% ... 4166
215% ... 4464
220% ... 4464The value of Du is definitely increasing in steps, not smoothly. Du step sizes are 434, 260, and 298 (divided by a million) for that short sequence. It's possible that these steps are due to IEEE 754 rounding ?
With the tests I've done for this post all the Du values seem to be roughly correct  I haven't yet reproduced my original steps with hugely incorrect values.

I'm totally unable to reproduce that step function with hugely incorrect values in the OP.
I noticed that it occurred in my original graph between correctseeming Du values of 0.008928 and 0.011363
With my new test I need to set camera scale to between 450% and 550% to get the corresponding range, all other things being equal. Adjusting Front Cam scale in 10% steps from 450 to 550 I got rendered values in sensible steps going 8928 > 9615 > 10416 > 11363
I also tried the same test with the Top Camera (on the highly unlikely offchance it's camerarelated), and in Poser 9. Everything looks sensible. No sign of grossly incorrect values, just those gradual steps following the correct curve
The conclusion I've come to that might explain my OP is that I probably set an incorrect scale resulting in the 4615 reading. When I started taking more readings I was probably adjusting the scale on the wrong camera, thus having no effect. And if that's what I did, I must have done it twice! Once for the 4615 reading, and again for the 17369.
The gradual step size that I''m seeing seems to be inconsitent in magnitude, but always less than 1.1% of the Du (or Dv) value

(I meant 11%, not 1.1%, at the end of that last comment... :) Step size seem to be 6% to 11% of the Du or Dv value)

Remember that FireFly is a REYES renderer  that is, it is chopping your mesh in to a grid of micro polygons. The number of micro polygons created depends on the screen size of the original polygon and on the shading rate. Those steps you see happen every time the number of micro polygons in a grid changes.
To illustrate, it is not the same, but similar in idea to what is demonstrated in this video:

I had to look up Reyes rendering. After reading that I drew the following very simplistic diagram. It's inaccurate, but good enough to show what I'm thinking, and it could indeed explain those steps.
However, between a pair of steps my test indicates that Du evaluates to a fixed value, whereas I'd expect to see Du gradually changing  q.v. the sloping blue line between A and B on the picture.
So I'm sure that I'm missing/misunderstanding something else here.

...of course the number of polygons across the width of the square would be a fixed value between steps, and the step sizes being a fixed percentage of the value would sortof fit (in this picture each step is 200%, from 2 to 4 to 8).
I'm sure the answer is in what Stefan said, but I'm having a problem trying to visualize it.

Looking at that last graph (with the pink steps) again, I'm now wondering if this is the answer ?
Du = 1 / (Sspace 'width' in micropolygons)
Dv = 1 / (Tspace 'height' in micropolygons)
(the important change is that I've replaced 'pixels' with 'micropolygons'. Sspace and Tspace would still be as defined in this previous post. Assuming that the micropolygons are always one pixel (+6%) in size this might fit...)

That's pretty much what it is, yes. To calculate Du and Dv, FireFly looks at two neighboring micro polygons and takes the difference between their texture coordinates.