ThreeDee
Lost in Space

|
I plugged the Randomizer to the Size input for Bomber+.
Changing the variation of the Randomizer has no effect. On the other hand, changing the Preview setting has the effect of changing the Randomizer output lighter: Preview setting 0 subtracts .5 from the randomizer values and 10 adds .5 to the Randomizer values and others by values in-between.
|
Posted: November 20, 2015 10:00 am |
Details
E-Mail
|
GMM
Moderator
Filter Forge, Inc
Posts: 3491
|
Quote |
---|
ThreeDee wrote:
I plugged the Randomizer to the Size input for Bomber+. |
This is intended: only the Particle input accepts meaningful connection from slaves. We'll make connection warning for other inputs.
|
Posted: November 20, 2015 10:09 am |
Details
E-Mail
|
ThreeDee
Lost in Space

|
I see. So it is not useful to plug the Bomber+ slaves, directly or indirectly, to any other of their master's inputs besides the Particle in any situation?
Of course, I could have read the instructions first
|
Posted: November 20, 2015 10:16 am |
Details
E-Mail
|
ThreeDee
Lost in Space

|
Let me see if I understood this correctly:
1) The Master outputs Slave values after it's own "prepare" step for a specific particle, randomizing etc. in preparation for receiving a particle.
2) The master then reads the Particle input, that can be modified by the Slave values of (1) above.
3) Only then does the Master render this specific particle.
Thus, in effect, it is a Master (prepare)-Slaves (output)-Particle (Input)-Master (render) cycle for every particle? Or, rather, in parallel for all particles.
|
Posted: November 20, 2015 10:29 am |
Details
E-Mail
|
Vladimir Golovin
Administrator
|
Quote |
---|
ThreeDee wrote:
Of course, I could have read the instructions first |
Sorry, but the help article in the current release is a horrible mess. We rewrote them completely, they'll be available in the next release.
Quote |
---|
ThreeDee wrote:
1) The Master outputs Slave values after it's own "prepare" step for a specific particle, randomizing etc. in preparation for receiving a particle.
2) The master then reads the Particle input, that can be modified by the Slave values of (1) above.
3) Only then does the Master render this specific particle.
Thus, in effect, it is a Master (prepare)-Slaves (output)-Particle (Input)-Master (render) cycle for every particle? Or, rather, in parallel for all particles. |
1) Sort of. The Master outputs values for slaves during sampling its slave-accepting inputs. In case of Bomber Plus, there's only one slave-accepting input, namely Particle. Technically, it includes the data package for slaves as an additional argument: Code |
---|
Particle.get_sample(x, y, additionaldata) |
2) Yes.
3) Yes.
I explain all this in the new help articles, to be released in the next update. I added slave-related sections to articles on Bitmap-Based Components, Filter Forge's Sample-Based Architecture, plus there will be a separate article explaining slave components, and sections on using slave components in the help article for every master component and every slave.
|
Posted: November 24, 2015 11:15 am |
Details
E-Mail
|
Vladimir Golovin
Administrator
|
Also, I plan to include some GUI aids to help users figure out what inputs work with slaves. We haven't yet started working on these because we'll need to deal with the post-release fallout first.
|
Posted: November 24, 2015 11:17 am |
Details
E-Mail
|
LexArt
LexArt

Posts: 256
|
Quote |
---|
Vladimir Golovin wrote:
Sorry, but the help article in the current release is a horrible mess. We rewrote them completely, they'll be available in the next release. |
In the next release is in reference to FF 5.07?
Yes, giving more explanations on how to use the new features as is not easy to understand
Thanks
|
Posted: December 8, 2015 11:43 am |
Details
E-Mail
|
GMM
Moderator
Filter Forge, Inc
Posts: 3491
|
Quote |
---|
LexArt wrote:
In the next release is in reference to FF 5.07? |
Yes, help for new components has been improved in 5.007.
|
Posted: December 9, 2015 4:55 am |
Details
E-Mail
|