Indigo Ray
![]() |
I understand what it does, but why can't the filter editor adjust the input automatically when connected to specific components like the bomber? Instead, we now have to put in an extra component.
|
|||||
Posted: April 29, 2011 6:23 pm | ||||||
Vladimir Golovin
Administrator |
Consider a situation when a size-independent component, for example Image, is connected to multiple inputs, one of which is Bomber's Particle input and others aren't. In such situations, we'd have to decide which input requirements are dominant.
If we force Image to conform to Bomber's requirement (i.e. make it size-dependent), this will mess up the output that goes to the other target inputs. And vice versa, if we chose non-bomber requirements as dominant, we get particle clipping problem in the bomber. Consider another situation, where the output of two components, one size-independent and other normal, is blended together via, say, the Blend component. It is impossible to untangle such signal and remove or impose size-independence upon any of its predecessors. The size decompensation must be done before two signals are mixed -- and having Particle Adapter as a separate component allows you to do exactly that. One example of such situation is an image-based particle with some noise overlaid on top of it. |
|||||
Posted: May 4, 2011 7:15 am | ||||||
Sphinx.
![]() |
The adapter as component seems somewhat overkill to me - can't you just make a special case remapper?
|
|||||
Posted: May 4, 2011 7:17 am | ||||||
Vladimir Golovin
Administrator |
The previous version of Filter Forge had a Mode parameter in the Image component, that allowed you to turn size-independence for Image on or off. However, this provided no solution for size-independence of other components, e.g. Frame.
Furthermore, the introduction of new Color and Grayscale controls made the above solution even more unacceptable. In FF2.0 when you needed two Image components with different scaling methods, you can just create two copies of Image (their output is identical by design) and adjust Mode separately for each of them. With the new Color and Grayscale controls the cloning method described above wouldn't make sense -- cloning a control component creates a redundant filter control in its interface, plus you'd have to manually load identical images into both copies of controls. Having Particle Adapter as a separate component lets you remove size independence at any point of the filter's connection flow. |
|||||
Posted: May 4, 2011 7:22 am | ||||||
Vladimir Golovin
Administrator |
Yes, having to use a whole component is cumbersome. We discussed the idea with remappers when we designed Particle Adapter. At the moment we have no infrastructure for green remappers (i.e. they must have previews, which should be lockable etc etc), but this remains a possibility for future versions. |
|||||
Posted: May 4, 2011 7:24 am | ||||||
inujima
![]() |
||||||
Posted: July 1, 2011 6:12 am | ||||||
inujima
![]() |
Another. It seem not to be in the particle adaptor of FF3 though AAZone divided in detail is generated in the particle mode of FF2.
There is a possibility of a problem when that is connected with components (e.g. Lookup, Scale, and Offset) other than Bomber component. Especially,for the image source of the color input component, we do not have the means to anti-alias except that an extra component is arranged. |
|||||
Posted: July 1, 2011 8:35 am | ||||||
GMM
Moderator
Posts: 3491 |
I can't notice any discrepancies (plz see the attached filter).
You should never have a need for that. ParticleAdapter.ffxml |
|||||
Posted: July 1, 2011 9:02 am | ||||||
inujima
![]() |
||||||
Posted: July 1, 2011 9:34 am | ||||||
Vladimir Golovin
Administrator |
No - this is not a bug. The difference is caused by different behavior of Particle Adapter and the old Image component in Particle mode -- the latter doesn't repeat the image beyond its borders, but the former does (or rather, it doesn't force areas beyond 'particle' borders to full transparency).
(Yes, Particle Adapter is not a perfect solution, but unfortunately we can't have a proper solution until Filter Forge has infrastructure for proper handling of image bounds, so that components can be aware of them.) |
|||||
Posted: July 8, 2011 3:43 am |
Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!
33,712 Registered Users
+19 new in 30 days!
153,534 Posts
+31 new in 30 days!
15,348 Topics
+72 new in year!
6 unregistered users.