This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
private:exrtrader2017:available_buffers [2017/06/26 13:40] – lightwolf | exrtrader2018:available_buffers [2017/12/27 10:38] (current) – ↷ Page moved from private:exrtrader2017:available_buffers to exrtrader2018:available_buffers lightwolf | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Notes about Buffers ====== | ====== Notes about Buffers ====== | ||
- | LightWave | + | LightWave |
- | exrTrader | + | exrTrader |
- | + | ||
- | **exrTrader 2017 does not support light groups**, since LightWave 2017 does not expose them for third parties. | + | |
Please refer to the LightWave documentation for a full list of buffers supplied by LightWave. | Please refer to the LightWave documentation for a full list of buffers supplied by LightWave. | ||
- | Some buffers will get special treatment by exrTrader | + | Some buffers will get special treatment by exrTrader |
^Buffer Name^Description^Channels ((RGBA are four float channels, RGB/XYZ three, XY/UV two, Y is one float channel. \\ I is a single luminance channel)) ^ | ^Buffer Name^Description^Channels ((RGBA are four float channels, RGB/XYZ three, XY/UV two, Y is one float channel. \\ I is a single luminance channel)) ^ | ||
^Final Render|This buffer contains the final, rendered image. This is identical to the image save by using the LightWave 3D render globals.|RGBA| | ^Final Render|This buffer contains the final, rendered image. This is identical to the image save by using the LightWave 3D render globals.|RGBA| | ||
- | ^Special|The special buffer is quite ... “special” indeed (( Yes, sorry, I couldn' | + | ^Special|The special buffer is quite ... “special” indeed (( Yes, sorry, I couldn' |
^Depth|This buffer stores the distance of a surface from the camera. \\ Due to the fact that the depth is stored as a proper float image and the pixels represent the distance to the camera in metres, there' | ^Depth|This buffer stores the distance of a surface from the camera. \\ Due to the fact that the depth is stored as a proper float image and the pixels represent the distance to the camera in metres, there' | ||
^Motion|This buffer stores the motion of a pixel during the current frame in screen space. The motion is encoded in the R and B channel. \\ Since LightWave 3D creates float channels, the values represent the movement in pixels. This implies that the values may actually be negative as well, depending on the direction of movement. \\ If the compositing package can deal with floating point motion buffers this is the best way to export them. \\ Some plugins require the motion vectors to be normalized into values from 0.0 to 1.0, where 0.5 is equivalent to no motion at all. \\ The **Offset** and **Scale** processing options allow you to change the motion buffer to be acceptable by such plugins ((However, you may be able to edit it in your compositing package prior to sending it to those plugins as well. This would be a little less dangerous and more flexible. )) - as a downside one needs to estimate how far the any of the pixels actually travel (in pixels) – or use an arbitrary value, such as the largest dimension of the image in pixels. \\ As an example, using 1920 as the largest distance an pixel could travel: \\ The **Offset** would need to be 1920 - to basically push the negative values into the positive range. \\ The **Scale** would need to be 1 / (1920 * 2) (roughly 0.00026) – to compress the values into a range from 0 to 1.0.|XY| | ^Motion|This buffer stores the motion of a pixel during the current frame in screen space. The motion is encoded in the R and B channel. \\ Since LightWave 3D creates float channels, the values represent the movement in pixels. This implies that the values may actually be negative as well, depending on the direction of movement. \\ If the compositing package can deal with floating point motion buffers this is the best way to export them. \\ Some plugins require the motion vectors to be normalized into values from 0.0 to 1.0, where 0.5 is equivalent to no motion at all. \\ The **Offset** and **Scale** processing options allow you to change the motion buffer to be acceptable by such plugins ((However, you may be able to edit it in your compositing package prior to sending it to those plugins as well. This would be a little less dangerous and more flexible. )) - as a downside one needs to estimate how far the any of the pixels actually travel (in pixels) – or use an arbitrary value, such as the largest dimension of the image in pixels. \\ As an example, using 1920 as the largest distance an pixel could travel: \\ The **Offset** would need to be 1920 - to basically push the negative values into the positive range. \\ The **Scale** would need to be 1 / (1920 * 2) (roughly 0.00026) – to compress the values into a range from 0 to 1.0.|XY| | ||
Line 19: | Line 17: | ||
^Object ID|This buffers contains a unique number for every object in the scene. \\ To get a better view on the values stored in this buffer you should normalize the preview.|ID| | ^Object ID|This buffers contains a unique number for every object in the scene. \\ To get a better view on the values stored in this buffer you should normalize the preview.|ID| | ||
- | <-^|^|^-> | + | <-supported_metadata|^|^network_rendering|-> |