Indigo Ray
![]() |
Not really a bug, just an inconsistency.
The warning ![]() It arises from the "position" slave component inputting into the rotation just before the motion blur. Spin and Smudge.ffxml |
|||||
Posted: April 12, 2013 8:13 pm | ||||||
Vladimir Golovin
Administrator |
||||||
Posted: April 15, 2013 9:07 am | ||||||
Indigo Ray
![]() |
||||||
Posted: April 15, 2013 1:48 pm | ||||||
Indigo Ray
![]() |
I downloaded the hotfix (build release April 10), and now it does NOT render (like in your screenshot, Vlad). Wouldn't call that a "fix"...
![]() So this IS a bug, now. If you disconnect the negate-to-rotate connection, the loop renders (the motion blur is no longer part of the loop via the position slave component), though this is not the result I was looking for... |
|||||
Posted: April 15, 2013 6:30 pm | ||||||
Skybase
![]() |
Isn't it because the motion blur component is a bitmap component? I thought all bitmap components weren't usable??
|
|||||
Posted: April 15, 2013 10:29 pm | ||||||
Vladimir Golovin
Administrator |
This is the expected behavior. As you correctly noted, Motion Blur is now outside the loop, it now provides a 'static' result that doesn't depend from loop iteration, and the rest of the loop works exactly as it should. Why do you think it's still a bug? What behavior would you expect? |
|||||
Posted: April 16, 2013 7:08 am | ||||||
Vladimir Golovin
Administrator |
Yes, and yes. |
|||||
Posted: April 16, 2013 7:10 am | ||||||
Indigo Ray
![]() |
Vlad, I wanted the direction of motion blur to be a function of iteration (via the position component). Since "direction" is a gray input and "position" is green, I used a workaround: Rotate => motion blur (fixed direction) => opposite rotation. Take out one of the rotations, and it's not the same.
The reason this is a bug is because in the March 18 build, the filter DID RENDER, even though the motion blur was inside the loop! Look closely at my screenshot. Follow "position" to "negate" to "rotate" to "motion blur"... yet the filter renders. Now I downloaded a newer version of the beta and this filter STOPPED WORKING. That's why I'm bothered. Isn't there a difference between a blur between "position" and "loop" and a blur between "accumulated" and "loop"? |
|||||
Posted: April 16, 2013 4:18 pm | ||||||
Vladimir Golovin
Administrator |
Alas, impossible, due to Motion Blur being a bitmap-based component.
I'm sure it didn't render correctly. Perhaps Motion Blur was using the input / output cache it calculated for the first iteration, or something like that. The correct behavior you'd expect is simply not possible because we don't recalculate bitmap caches for every Loop iteration. As long as there is a rendered cache block, Motion Blur will return it to the output without recalculating anything (and, consequently, without taking its inputs into account). The assumption that the values on component's inputs don't change during the sampling process was true in old times, before the Loops era, but it isn't true now. So any component that caches its output into bitmap blocks and doesn't look at inputs again after a block has been rendered simply does not fit into the new scheme of things. |
|||||
Posted: April 19, 2013 6:27 am | ||||||
Vladimir Golovin
Administrator |
(BTW, you can fake the 'proper' motion blur using a nested Loop and compare your screenshot above with the correct expected behavior).
|
|||||
Posted: April 19, 2013 6:39 am | ||||||
Indigo Ray
![]() |
Thank you for explaining, I understand the gist of it. No wonder the filter rendered unusually fast...the motion blur only processed once! I'll try faking motion blur with a nested loop.
|
|||||
Posted: April 19, 2013 4:37 pm |
Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!
33,717 Registered Users
+5 new last day!
153,539 Posts
+8 new in 7 days!
15,348 Topics
+72 new in year!
14 unregistered users.