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



  • Ahem!

    Those last three posts were actually supposed to go on my 'thinking out loud' thread at CGbytes thread (I've duplicated them over there in posts [#42]http://www.cgbytes.com/community/forums.aspx?g=posts&m=126979#post126979), #43 and #44 of that thread).

    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?



  • 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'.

    0_1466060555334_Globe.jpg


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