Konstantin's weekly report #22

Development Development reports
1

So, this is my last report of 2013. To be honest, it’s awesome we got that far. :slight_smile:

Here’s a list of improvements made by Ivan for the past week:

  • Now you can manipulate vertices when they attached to the bone. Unfortunately, you can’t do that in animation mode yet. This is planned to be fixed in the future.
  • Finished fixing bugs in software renderer. Thus, all interface icons are back in place!
  • Re-implemented feature to adjust the origin. Hold the spacebar and drag transformation center to set the origin. Notice the group keeps its position regardless of already applied rotation/scale.
  • Transformation widget now always displayed with fixed size, regardless of group scale or zoom.

Watch those changes demonstrated in the single video:
http://youtu.be/9yCLR-broWA

You can try mentioned features by downloading and installing development snapshots - synfig.org/cms/en/download/development

This time the snapshots are not that dangerous to use - we’re pretty much done with the essential internals, so it’s quite unlikely your files get broken/incompatible with the future builds, But you still using those snapshots at your own risk. :slight_smile:

By this moment we got pretty far with the bones feature. To illustrate the work done and the pending tasks, here’s how our bones roadmap looks now:

That’s not all news. Last week we’ve got a nice addition from Djay, which synchronizes selection of keyframes on the Timeline with Keyframes Panel. These changes aren’t merged into the master branch yet, I hope to get look at them this week.

Finally, some words about our fundraising campaign. The time before its deadline is measured by hours now. So, will we will be able to keep our full-time developer working on Synfig in January? We’ll see that soon… :slight_smile:

By-the-way, in the last days of campaign LibreGraphicsWorld published a nice article about us - http://libregraphicsworld.org/blog/entry/crowdfunding-for-sustainability-synfig-project
Check it out and share with your friends - this might help us to get the word out.

That’s all for today. Sorry for a long report and Happy New Year to everyone! :slight_smile:

2

Yay! We are so close to bet bones fully usable! Delicious work Konstantin and Ivan!

Happy (sure it will be) 2014!
-G

3

I can’t believe that Synfig Studio reaches the stage in a such short period: single-window mode ui, bones etc… Congratulations!

4

Played with the new Group transformation widget, I don’t think this is the right way to go, or we have to take care of this implementation.

When we are talking about transformation, we are talking about: transform, scale, rotate, skew. The “keep same size” completely differs with traditional design, for example, the star layer’s inner/outer radius and the rotation widgets. the widgets’ size/angle for all of them are connecting to layer’s corresponding parameters. Further, the transformation of new Group layer widgets are using two different/conflicted implementation, Rotate and Skew are in “Transitional” way, and the Scale is in “New” way.

I know, most 3D animation software is using this kind of design for position/scale/rotate/skew widgets, but we have to see they all are easy to distinguished/guessed by user. see attached screenshot.
transifomation widgets in blender.png

There is another issue, these two handles are position too close, when playing with new layer transformation widget, I was always assuming there is something wrong and trying to correct them by drag one of them.
synfig group transformation widgets .png

I can understand the lack of manpower, but I hope, the new features can be polished not only the functionality but also the interactive design(UI part).

5

Yes, I am understand that such step breaks some Synfig concepts. Because the handle usually represents particular value on the canvas (which can be linked to another value). So, the relative representation of scale handles will break linking in some aspect. But this is a sacrifice for the sake of better user experience and usability. I believe this is a right step to go towards introduced the new type of handles. It would be nice to make the new handles have a different shape. :slight_smile:

BTW, rotation handle doesn’t break any concept, because angle value is preserved and doesn’t depend on scale. I expect all rotation handles to get migrated to the relative representation.

6

quick bones report :

  • Copy & Paste bone (a group with a shape linked to a bones) make then linked and hard to unlink. : Good point, it’s an interesting feature to multiply same mouvement (even delaying them), Bad point, it’s frustrating to multiply same bones setup inside a scene.
  • Copy and paste a shape (copy a region , having outline) linked to a bones, seems to record links even using “disconnect”
  • Software render do not support two bones layer, only the first one is rendered.

Transformation widget fixed size : The traditional design of synfig a kind of wysiwyg of handle animation, and bones implementation is in the strait line of this design. I do’nt feel that a good idea to break that design.

does i need again to say Yeah ?

Yeah !

7 
[DONE] Transformation widget: Always keep the same size on the screen

I am kind of divided with this matter.

On one side there are advantages of have a widget the same relative size on the screen. If you’re working with the canvas zoom so big or so small then it is difficult to grab the handles to produce the transformation without zoom out or zoom in to make them visible.

On the other side, the fact that the handle is the representation of a value on the canvas window, implies from the usual point of view of the user that the handle scales with the canvas zoom. With fixed relative size it is difficult to know what’s the scale of one group relative to other and you never know if the scale is negative or not.

For example, speaking on deforming a shape, usually you’re zooming out to grab all the handles of the shape and perform some sort of transformation with all them together (nobody would use the Smooth move tool selecting all the handles and transforming them meanwhile the canvas is in a deep zoom). And on contrary, when you want to do a detailed deformation (you need to fine tune the deformation with small movements) you usually zoom in and perform the deformation locally because you know that an average displacement with a big zoom implies a small movement in the final frame.

Besides that, the current implementation has also some troubles. Three of the transformation values have, by its nature, one dead point: The origin. If a vector is at the origin of transformation, the scale, rotation and skew are immune to it. There is not problem with that if only one or some vector values are at the origin. But what happen if all the vector values goes to the origin (becomes zero after transformed)? Then it happens that the cannot get out from the zero value if you use the handles. When for some reason the scale is zero, the transformation widget becomes unusable.

The previous problem is not related to the relative size representation, because the lack of usability of the scale handle would happen too if the scale handle is represented at the right scale.

Values near zero are also a trouble. Say you want to make the grouped shapes so small to make them vanish in a point. Imagine that you make the scale to be (0.0001, 0.0001). To restore it to (1, 1) you need to pull several times the scale handle because each time it scales by an amount of say 3 (that’s the half of a span of a normal canvas). That’s tedious and frustrating, so finally you need to go to the parameter panel and enter the right value by hand.

Also, if you’re by a chance at scale (-0.0001, -0.0001) pulling the scale handle to the right top side would make it more negative, that becomes in more frustration because you want to make it grow to the positive side, not the negative.

A possible solution would be to use an exponential representation for the scale handle not centered on zero but at 1, so when the scale handle is at s=1 then the scale value is expo(s-1). This would make not possible to use the scale handle for negative values since exp function is always positive.

So what to do?

Using linear scales is not so bad for the troubles around zero. If you’re around zero just need to use the numerical values to get out from there.

So once assumed the zero point troubles, it is good or bad to have the handles with relative zoom?

I think that the benefits of having them the same relative size doesn’t justify the side effects that we have commented. Zoom in and out to reach the handles is a usual task that the user does continuously for the rest of handles.

Please, let us know if there are more benefits of have the handles with fixed size because I don’t find more obvious ones.

-G

8

Тоже тестил немножко и заметил ,что если я создал кривую окружность инструментом окружность, то после прикрепления этой кривой она себя ведёт не адекватно, при повороте кости может уехать в непредсказуемое
направление.

Так-же при перемешении всего объекта в режиме редактирования(без костей), некоторые рычаги тоже могут уехать неадекватно, восновном те, к которым применена операция то что я на картинке подчеркнул.
вообще убрать эти две операции вообще, хотя-бы пока.

И конечно очень хочется чтоб можно было в режиме записи анимации подправлять точки и вектора прикреплённых к костям.
И ещё вот я прикрепил точки к кости допустим лищние, а как их открепить? или допустим кость удалить?

[i]Testil too little and noticed that if I create a curve circle circle tool , after attachment of this curve is not behaving properly , turning the bone can go to unpredictable
direction .

Well as in a stirred the whole object in edit mode, some leverage , too, can leave inadequately vosnovnom those to which the operation is applied what I highlighted in the picture .
generally remove these two operations in general, though, would be yet.

And of course very desirable that it was possible to tinker with animation recording points and vectors attached to the bones .
And here I am stuck point to say lischnie bones and their undock ? or let the bone removed?[/i]

9

глючит,ошибочный пост.
buggy,erroneous post.
Synfig 32bit. Win7 64bit.

10

Can you provide a example file?

Sincerely I don’t understand a word. :unamused:

Animation mode is not fully developed yet for bones and the linked to bones items.

Deleting bones is not fully implemented yet. You need to remove the whole Skeleton layer and start it over.

-G

11 
(TODO) Allow to link vertices to a whole skeleton with consideration of bone influence

Konstantin, can you elaborate a little more how are you going to proceed with this? I can help with the maths of this if it is needed.

(TODO) Implement "Lock Scale" parameter for bone (and supplimentary behaviour of "Link to Bone")

I’m trying to understand what does that mean but I can’t. Can you reformulate the item with other words to let me understand?

Thanks!
-G

12

выделите всю пчелу, все рычаги, кроме скелета, и попробуйте ёё переместить.
и попробуйте повернуть кости глаз.

select the entire bee, all the levers except the skeleton, and try to move it.
and try to rotate the eye bone.
Povar.sifz (23 KB)

13

In that case, maybe we don’t have to choose.

In this sort of case I’d suggest having Synfig interface working consistently as Genete and d.ja.y. suggest by default. However, as the widget behaviour Zelgadis has implemented is so useful for him (and I’m sure it would be useful for many other artists too) it should be available as an option.

When you look at Blender, you see there are many options that change the program’s behaviour when you transform things.

14

for sure!

15

Will the transformation (Position, Rotation, Skew and Scale) be able to convert to composite ?

And it seems there is Skew value missing in parameters panel, the transformation only contains position, rotation and scale values:

group-transformation-parameter.png
group-transformation-parameter.png790×172 17.9 KB

Can I advise to split this composite transformation parameter to :

Name – Value – Type
Position( Pivot Point?) – 0.000u,0.000u – Vector
Rotation – 0.000o – Angle
Scale – 1.000, 1,000 – Vector
Skew – 5.000u, 5.000u – Vector

The above is more synfig style.

16

In the current master branch, you already can convert transformation to composite. More than that, all new groups have its transformation parameter converted to composite by default. :slight_smile:

17

In the current master branch, you already can convert transformation to composite. More than that, all new groups have its transformation parameter converted to composite by default. :slight_smile:

18

That’s awesome! (Sorry, forget to test the master branch before “complaining” :slight_smile:) But, still Skew is missed.

btw, if this composite functionality can be used to implement a grouping function for parameters?

19

Having worked using this for a while now I’m not convinced it is a good thing.

I’m just working with animating width around a shape. Before we had the width circles dispaying how large that width point was which made it very easy to visually see what you we’re doing and making tiny adjustments. Now with width handle snapping back we’ve lost this level of control. We only have the line itself as visual representation which when working with very fuzzy curve gradients has become utterly unuseful.
Not to mention that when working with large canvases the control handle is tiny making small adjustments virtually impossible.

For scale handles I really would like to have handles stay where I let go of them giving me visual representation of how much I scaled.

Overall I really dislike this new behaviour.

added: I see now that advance outlines works properly and this new behaviour is just with gradients.

20

This is obviously a bug. I have discovered it today as well.