YOUR ACCOUNT

Indigo Ray
Adam

Posts: 1442
Filters: 82
Not really a bug, just an inconsistency.

The warning smile:!: message about the loop not accepting bitmap components is present, but the loop still works (as it should).

It arises from the "position" slave component inputting into the rotation just before the motion blur.

Spin and Smudge.ffxml
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3446
Filters: 55
The screenshot below is what I see in our current development build (it's possible that it's not yet released as a hotfix). Blur and consequently the Loop aren't rendered at all:

  Details E-Mail
Indigo Ray
Adam

Posts: 1442
Filters: 82
Well this is what I see (Build release March 18). The blur and loop DOES render (you can see the warning icon next to the loop). I hope this functionality hasn't been lost.

I'll download the hotfix to see if anything changes...

  Details E-Mail
Indigo Ray
Adam

Posts: 1442
Filters: 82
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"... smile:(

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...
  Details E-Mail
Skybase
2D/3D Generalist

Posts: 4025
Filters: 76
Isn't it because the motion blur component is a bitmap component? I thought all bitmap components weren't usable??
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3446
Filters: 55
Quote
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...


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?
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3446
Filters: 55
Quote
Isn't it because the motion blur component is a bitmap component? I thought all bitmap components weren't usable??


Yes, and yes.
  Details E-Mail
Indigo Ray
Adam

Posts: 1442
Filters: 82
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"?
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3446
Filters: 55
Quote
Vlad, I wanted the direction of motion blur to be a function of iteration (via the position component)


Alas, impossible, due to Motion Blur being a bitmap-based component.

Quote
the filter DID RENDER, even though the motion blur was inside the loop! Look closely at my screenshot.


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.
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3446
Filters: 55
(BTW, you can fake the 'proper' motion blur using a nested Loop and compare your screenshot above with the correct expected behavior).
  Details E-Mail
Indigo Ray
Adam

Posts: 1442
Filters: 82
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.
  Details E-Mail

Join Our Community!

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!

Create an Account

Online Users Last minute:

14 unregistered users.