If it was discussed, please point me to right thread and close this one (i am not good and finding things, even if they’re not virtual ).
Now if we want fill object with image, gradient or something like that, we have to use blend modes. That’s perfectly OK and can be used for various interesting effects, so it should still be in place. But I’d like to see sometime in Synfig support for gradient/image fills in the way they work in Inkscape. As I said my intention isn’t to replace blendmodes, because they are sometime really needed, but rather offer other way for newcomers to make they animation making progress easier. I remember that I was overwhelmed by Synfig’s power and wondering why, the heck, this gradient overlaps everything on the screen.
If there are some builds with this feature, please point me to it.
Recently it has been added a new feature that adds a new blend mode to the defaults in the toolbox called “By Layer Default”. When this blend method is selected in the defaults, if a layer is created the blend method used for the that the new created layer is defined by the layer itself (currently hard coded but in the future it can be user customized). For certain layers the usual blend method (Composite) produces non satisfying results (i.e. the Composite blend method is not good for the Blur layer).
So it could be useful to define the default blend method defined by the layer itself for the gradient layers to be “Onto”, which is the blend method that makes a fill of the layers below.
It can be interesting to know the opinion of other regular users on this new situation. The change in the code is so easy so it is just a user preference.
-G
It’s a nice addition, but i think that it will be even more confusing for beginners. Since synfig needs popularity so badly, we should work to make it as userfriendly as possible. That means we should adjust the default behavior to common vector graphic programs. Mostly all of them supporting outlines and fill as one object/layer and let you define the “fill” for the outline and interior directly. Maybe synfig should adapt that. For very simple animations it can be quite handy, without restricting experienced users.
make lines and fills one object/layer and add a one or two parameters if the outline or fill is displayed.
make it possible to use gradients and other stuff as the filling for outlines and interior.
Thanks, niabot for the support. And since Synfig can change type of object’s parameter - why don’t make it even easier. Currently after conversion “Color” parameter to Gradient color apply only first color of it. Why don’t make it uses whole gradient? Of course it’ll need name change to e.g. Fill, but is doable.
I’m all for simplification (not less powerful, just easier to use).
Gradient fill and image fill modes would help in that direction. That doesn’t mean we have to remove Gradient fill layers. These could work as before.
Same with merging fill and outline. We could create a completely new layer that mixes them both. I see a usage for separate fill and outline layers, I often use them that way myself. Mixed could be default with an option to separate that into two layers, much like video editors do with audio/video, together in one clip as default but with possibility to split into separate.
I also propose more user settings where Synfig is set to an easier level as default with the option for the users to tweak the behaviour.
Why not start a workgroup which goes through Synfig and tries to find way to simplify it as much as possible without nagging on it’s powerful features? I’ve used it for quite a while and still find it confusing, having to use the reference manual a lot.
Perhaps just a discussion in the forum about it is sufficient.
No it isn’t. Well, unless the forum’s script can modify synfig’s sources and recompile it all by itself . I think we need support from Synfig’s programmers to make this happen. Otherwise we will just sit and talk like old grandpas and nothing will change.
Now that we have "By Layer Default" all thats really needed is a link option in the toolbox to auto link their origins that way the gradient would move with the shape when animated. :bulb:
The number coders of Synfig Project is quite limited (there are only two persons lately active only although some other ones are around). Lately I’m doing some sort of coordination of the development of the code deciding which is a priority to implement or which solution is better than other to implement at code level for a desired feature/bugfix or whatever. It doesn’t mean I would discover everything is needed to do according to the users desires/needs because I’m not a full production Synfig user (don’t have time for it although I would like to) but I have good knowledge of the application usage and start to have reasonable knowledge of its internals. Also it doesn’t mean that I (we) can achieve everything we want (at last in a reasonable cycle time and with the proper quality) because our general coding knowledge is limited and are short of time .
It means though, that any person that doesn’t have coding skills but have good knowledge of the animation workflow and is used to work with other applications, can (must) help us describing exactly which are the priorities to be developed/fixed in order to improve the usability and productivity of Synfig. Doing that will increase the enthusiasm and the dedication of this small developing team to initiate the work. This description has to be the most detailed possible thinking on the way to implement it. Sometimes I (we) can reject some kind of implementation because the application itself is thought to be developed in other direction and make that feature possible would become a huge task (or sometimes a completely rewrite of everything). Even sometimes, apparently small changes implies a lot of work and the effort should deserve the result. The user should think that small changes reusing the current state of art are always accomplished in a shorter time than big changes.
This coordination I do, of deciding which is first and how to do it, is not a dictatorial attitude. I’m fully open to learn, listen, discuss, accept and agree to make any of your proposals. Also I’m open to embrace any new incoming coder who want to work with us. Just send some interesting patches and demonstrate some intention of continuity and integration in the Synfig Team and I’ll give full access to the repository quickly.
Finally, considering the small amount of coders we have and that the critical mass of the Synfig community is not big enough yet, this forum is a good way to discuss features. Later if the critical mass of Synfig community grows we might use the Idea Torrent application to let the user community decide what to implement and let the coders concentrate in coding and other helpers coordinate the feature implementation. But at this team size (all in one team) the forum is enough.
Sorry for the speech but lately I feel that I have to carry on with everything
Rarely you would want to have the gradient in the origin of the layer where the gradient is applied to. In fact most of the time the gradient (in any of its types) should be in a certain position relative to the shape’s contour and unless you want to limit the movement of the shape to translation and rotation the movement of the shape is relative to the origin (that stays steady). That’s not the case of the curve gradient which has the option of link its bline to the region/outline that is created at the same time with the BLine Tool.
I do agree that Synfig needs work in terms of usability. Having a single object for outlines and fills does seem like a good idea. From an implementation standpoint, however, I have misgivings about modifying the fill parameter to allow gradients, images, etc. In the SVG format, gradient fills require a gradient to be defined in the definitions section (analogous to Synfig’s exported valuenodes), filling with something other than a gradient or image requires a completely different clip-to-path technique, and I imagine masking is a separate system as well – compare that with the Synfig’s simple concept of a blending.
That said, what I suggest is not redesigning Synfig’s architecture, but rather providing a user interface that sidelines some of the complexity.
In thinking about this, I came up with some possible implementations:
Creating a “Layer” valuenode, so that the fill of a shape can be set to a layer (including gradient layer, etc)
– I don’t think this is a good thing to do because it just increases Synfig’s complexity
Not changing Synfig, just providing a better UI
– When right-clicking on a fill layer, provide the options of “Convert to Outline” and “Convert to Gradient”, etc… Provide those same options when right-clicking on shapes in the canvas, and maybe some other things
Creating a new “Canvas” layer that hides all of its sub-layers and has a dynamic parameter list that exposes part of those layers’ parameters
– Imagine encapsulating a gradient blended on top of the fill. Then imagine replacing the Paste Canvas parameters with the parameters from the Fill layer as well as those from the gradient layer. For good measure, give this layer a “shape” icon and make the arrow expanding its sub-contents non-clickable. And if you right-click on this “shape” meta-layer, you get the options of adding an outline or changing the fill to be a solid color instead of a gradient.
I’ll call this the meta-layers approach. As a bonus, a meta-layers system might also be useful for people making templates (for example, a “box” meta-layer that draws a 3d box).
Make easy to newbies apply a gradient / image to a layer.
Combine the Region and Outline layers in only one.
MAKE GRADIENTS EASIER TO APPLY ONTO SOMETHING
What about include a toggle option in the Gradient Tool like this?:
Fill
Cover
Fill would produce a Onto Gradient Layer and Cover would produce a Composite one.
COMBINE REGION AND OUTLINE
I think that it is perfectly doable. I would need to know if there is needed additional modifications rather than just create a new layer that inherits from the two existing ones and depending on a new parameter (three states boolean parameter or similar) decides to render the fill and/or the outline. It would be needed to code that the common parameters are not duplicated (I have to look the current code to do that) except the color but I think it wouldn’t be a huge task.
A refining of the needed parameters how would it look and the pros and cons of join it is needed as feed back from you the user.
Initially I think on an extra parameter to allow place the outline over the region or vice-versa. Also the common render parameters z, depth, amount and blend mode has to be agreed to be used by both shapes so they acts like a whole.
You do a marvelous job Genete and I feel bad for letting you do so much all by yourself. I should do more but I’ve got too much other stuff already…
Good thinking, it should work this way but here’s another example of Synfig being a bit complex, your solution is great but it adds another set of terms for an existing feature. It will be confusing with fill meaning onto and cover meaning composite. There must be a solution that won’t introduce new terms for old features?
).
. I think we need support from Synfig’s programmers to make this happen. Otherwise we will just sit and talk like old grandpas and nothing will change.
