Page 1 of 3 123 LastLast
Results 1 to 15 of 31

Thread: X-Motion and Y-Motion-- what exactly are they?

  1. #1
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,732

    Question X-Motion and Y-Motion-- what exactly are they?

    You can easily output the X&Y Motion buffers using the LW Composite Buffers Export (which generates image streams, AFAICT, not layered/embedded image files).

    But, looking at the resulting files, I'm confused.

    http://www.youtube.com/watch?v=B_m9R...ature=youtu.be
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  2. #2
    Super Member realgray's Avatar
    Join Date
    Mar 2008
    Location
    South
    Posts
    731
    They are LW's way of exporting an Mblur pass. A lot of fusion artists have workflows that make use of these for Mblur.(there are threads about this) As an AE guy I can only hope that someday Lightwave has a Motion Vector export. (or use Modo)

  3. #3
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,732
    I know what they are. What I mean is: how is the data encoded into the two images? How do you translate the pixel value into a direction vector?

    I'm guessing it's something like :
    0=xmotion left
    127= no xmotion
    255= xmotion right

    Along those lines.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  4. #4
    Super Member Captain Obvious's Avatar
    Join Date
    Dec 2004
    Location
    London
    Posts
    4,502
    I think it's actually zero equals no motion, negative equals left/down motion and positive equals right/up motion. Not sure though.
    Are my spline guides showing?

  5. #5
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,732
    Quote Originally Posted by Captain Obvious View Post
    I think it's actually zero equals no motion, negative equals left/down motion and positive equals right/up motion. Not sure though.
    Pixels are 0-255. There is no negative in a non-float pixel.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  6. #6
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,613
    Quote Originally Posted by Captain Obvious View Post
    I think it's actually zero equals no motion, negative equals left/down motion and positive equals right/up motion. Not sure though.
    Precisely. The motion buffer contains the distance, measured in pixels, that the content of the specific pixel moves due to motion along the X and the Y image axes.
    Quote Originally Posted by jeric_synergy View Post
    Pixels are 0-255. There is no negative in a non-float pixel.
    Then either the exporter needs to squeeze them into the limited range of the file format or you lose the data. Which would be anything that moves in a negative direction (all negative numbers) and any distance further than 1.0 along positive X and Y (remember 1.0 float is mapped to full white in LDR images).

    Cheers,
    Mike

  7. #7
    Registered User
    Join Date
    Oct 2005
    Location
    USA
    Posts
    1,243
    Quote Originally Posted by jeric_synergy View Post
    Pixels are 0-255. There is no negative in a non-float pixel.
    Then I guess normal maps must be some sort of black magic since they need to be able to encode normalized vectors :-)

    It is quite easy - it all depends how you encode and decode these values and as long as you understand various precision issues, you can come up with anything you want.
    http://en.wikipedia.org/wiki/Quantiz...al_processing)

  8. #8
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,732

    Thumbs down

    Quote Originally Posted by warmiak View Post
    Then I guess normal maps must be some sort of black magic since they need to be able to encode normalized vectors :-)
    Normal maps have an encoding, now where have I seen that word before? Oh yeah:
    Quote Originally Posted by jeric_synergy View Post
    how is the data encoded into the two images? How do you translate the pixel value into a direction vector?
    Last edited by jeric_synergy; 05-01-2012 at 07:37 PM.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  9. #9
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,732
    Quote Originally Posted by Lightwolf View Post
    Precisely. The motion buffer contains the distance, measured in pixels, that the content of the specific pixel moves due to motion along the X and the Y image axes.

    Then either the exporter needs to squeeze them into the limited range of the file format or you lose the data. Which would be anything that moves in a negative direction (all negative numbers) and any distance further than 1.0 along positive X and Y (remember 1.0 float is mapped to full white in LDR images).
    It appears that Composite Buffer Export doesn't do that with non-float formats, so the moral of the story is "Use float formats".
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  10. #10
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,613
    Quote Originally Posted by warmiak View Post
    Then I guess normal maps must be some sort of black magic since they need to be able to encode normalized vectors :-)
    And they do. A mechanism quite close to what RSMB expects as vector motion data.
    O.k., so it's more like grey magic at best...
    Quote Originally Posted by warmiak View Post
    It is quite easy - it all depends how you encode and decode these values and as long as you understand various precision issues, you can come up with anything you want.
    http://en.wikipedia.org/wiki/Quantiz...al_processing)
    While Quantisation plays a part in it, it's not the deciding factor. Just saying, it's a bit of a red herring in this context.

    Cheers,
    Mike

  11. #11
    Registered User
    Join Date
    Oct 2005
    Location
    USA
    Posts
    1,243
    Quote Originally Posted by Lightwolf View Post
    And they do. A mechanism quite close to what RSMB expects as vector motion data.
    O.k., so it's more like grey magic at best...

    While Quantisation plays a part in it, it's not the deciding factor. Just saying, it's a bit of a red herring in this context.

    Cheers,
    Mike
    Actually it is .. at least if you limit yourself to 24 bit RGB images.

  12. #12
    Super Member Captain Obvious's Avatar
    Join Date
    Dec 2004
    Location
    London
    Posts
    4,502
    Quote Originally Posted by jeric_synergy View Post
    It appears that Composite Buffer Export doesn't do that with non-float formats, so the moral of the story is "Use float formats".
    When it comes to 3D rendering, isn't that always the moral of the story?

    OpenEXR will make your life easier. Just get used to it.
    Are my spline guides showing?

  13. #13
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,613
    Quote Originally Posted by warmiak View Post
    Actually it is .. at least if you limit yourself to 24 bit RGB images.
    Quantisation is related to the degree of how well a certain range of values can be represented with a limited numeric precision. It affects all bit formats.

    However, the main problem here is the fact that LDR image representations (regardless of the bit depth) don't even cover the range to start with.

    Cheers,
    Mike

  14. #14
    Registered User
    Join Date
    Oct 2005
    Location
    USA
    Posts
    1,243
    Quote Originally Posted by Lightwolf View Post
    Quantisation is related to the degree of how well a certain range of values can be represented with a limited numeric precision. It affects all bit formats.

    However, the main problem here is the fact that LDR image representations (regardless of the bit depth) don't even cover the range to start with.

    Cheers,
    Mike
    Of course it does - it is just a matter of how little precision you can get away with it.
    You just drop your precision by half and you can encode -127 ... 128 ranges.

  15. #15
    obfuscated SDK hacker Lightwolf's Avatar
    Join Date
    Feb 2003
    Location
    Stuttgart, Germany
    Posts
    13,613
    Quote Originally Posted by warmiak View Post
    Of course it does - it is just a matter of how little precision you can get away with it.
    You just drop your precision by half and you can encode -127 ... 128 ranges.
    And even then you need to change the range of representation (and interpretation for that matter, as 8-bit file formats always imply unsigned bytes).
    Which is the issue here. Precision isn't, that's the next step.

    Cheers,
    Mike

Page 1 of 3 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •