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


  • Poser Ambassadors

    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 one-sided 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 / (S-space 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/4

    Import 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/Signed-10-Digit-Integer-Visualizer-MT5 ) 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% ... 4464

    The 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 correct-seeming 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 off-chance it's camera-related), 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.

    0_1466165239246_microsteps.png



  • ...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 sort-of 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.

    0_1466168486809_microsteps2.png



  • Looking at that last graph (with the pink steps) again, I'm now wondering if this is the answer ?

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

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

    (the important change is that I've replaced 'pixels' with 'micropolygons'. S-space and T-space 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.