Konstantin's weekly report #39


#1

Hello, everyone!

This weekly report #39 is kindly sponsored by Matija Nalis and this time I have something really yummy for you. :slight_smile:

BONE-DRIVEN IMAGE DISTORTION

First of all - I am happy to present a first demonstration of Bone-driven Image Distortion feature, which was developed by Ivan Mahonin during this month.
Check out a this video - http://youtu.be/YD3aK9SySZo

This is just an early demo, but as you can see it is already pretty much usable.

Here’s a brief list of missing pieces:

  • Grid size is hardcoded at the moment (should be defined as layer parameter)
  • The maximum deformation area is hardcoded too (should be defined as layer parameter and editable through handles)
  • We need an action to reset bones to initial pose
  • The feature not works correctly on Windows yet
  • Maybe we will give some fine-tuning to distortion algorythm

There are few tricks about rendering to mention here.

First thing you need to know - the rendering is made in software mode, without any hardware optimizations. By default Synfig uses tiled rendering and this makes Skeleton Distortion layer MUCH SLOWER. You can ensure by yourself by disabling the tiled rendering using “SYNFIG_DISABLE_TILE_RENDER=1” environment variable - this will boost rendering speed for 2 times at least.
Unfortunately, the rendering mode enabled by “SYNFIG_DISABLE_TILE_RENDER=1” variable is not working correctly when zoom level is > 100%.
So, the real solution will be to properly get rid of tiled rendering by re-writing non-tiled mode.

The second trick is about debug mode. If you build Synfig with debug symbols, then the speed will be 5-7 time slower comparing to clean non-debug build.

The demonstration video above was recorded in non-tiled and non-debug mode, that’s why redraw speed is around 0.09 sec for single image, which is pretty fine to work with.

I believe we can achieve even better speed by implementing the hardware-optimized OpenGL rendering. But it’s pretty clear that Ivan won’t be able to deliver OpenGL rendering within the remaining 3 days of this month. Also, it looks like that converting one single layer to OpenGL won’t give us a desirable speed advantage (because there will be time losses for uploading image as texture to video memory and downloading back the result - this will create a bottlenecks).
The real speed advantage will be achieved if we will implement a full OpenGL renderer for all layers together, so we won’t need to convert each layer back and forth during rendering. This is pretty much attractive perspective, especially considering that Ivan is already prepared the infrastructure for that (at the beginning of this month).

Well, but that’s just a possible plans and perspectives.
At the moment our fundraising campaign for May is at the final countdown and we still have around $600 to go, so it’s still undefined if we will be able to keep Ivan working in next month.

Anyway, right now I’m heading to prepare a binary snapshots to let you test the new feature by yourself. :slight_smile:

OTHER CONTRIBUTIONS

But the news aren’t over here! Last week we’ve had a lot of other cool contributions. :slight_smile:

Many of you probably noticed the issue whenthe Timetrack rows were misaligned with parameters (see illustration below).

This issue turned to be very annoying when working with animation.
Last week we’ve got an epic fix from Djay, who worked hard for a long time to resolve this issue. The fix is merged into master branch and will be available within the next development snapshots.

But that was not the only fix from Djay for the past week. Here are a few more:

  • #456 - Tooltip now shows current time when you drag keyframes
  • #458 (partially) - Allow to select a keyframe by clicking on the keyframe indicator of the keyframe widget. Then the keyframe panel should reflect the selection too. The inverse works too (when change selection on keyframe panel the keyframe widget shows it too).
  • #626 - When you drag a keyframe, its description is not erased anymore

Finally, we have another cool contribution form Yu Chen. This time he have implemented the option to change the interface language in Synfig Studio preferences.

Well, that’s all for today. :slight_smile:
All mentioned fixes and improvements will be delivered with the upcoming development snapshots.
Stay tuned!

.

.

.
synfig-deform-concept-4.png
synfig-deform-concept-3.png


Got a problem with skeleton deformation
Converting a bitmap image to a vector image for animation.
#2

Amazingly cool! It’s fantastic that Synfig finally is getting bone deformation! I’ve been waiting years for this! :slight_smile: Thank you!


#3

very yummy in did, i want to say ouaf-ouaf !


#4

Awesome!
Is it possible to share the happy dog image file? I would like to do a benchmarking comparison of image bone deformation of Synfig vs Anime Studio. This way you would fine tune and improve the bone influence function and the grid refinement.

Incredible work for the time it has been done!

-G


#5

Hello!
Sure, attaching here.


#6

I’ve been doing some tests with the image in Anime Studio and I have some conclusions:

First, I love by far away the behavior of Synfig Studio compared to Anime Studio in terms of how they treat the image distortion. In Anime Studio the region under the bone influence is hardly tied to the bone and produces a cut out of the region that I don’t like at all compared with Synfig Studio. In Synfig, the interpolation of the deformed areas is much more smooth and elastic, giving a more organic response.

See the comparison of the two skeleton and one simple deformation:

Captura de pantalla 2014-05-01 a la(s) 17.32.24.png

Captura de pantalla 2014-05-01 a la(s) 17.51.51.png

Captura de pantalla 2014-05-01 a la(s) 17.52.00.png

This makes me think how important is to allow the user to fine tune the influence region because it could allow better expression on the character.

Second I’ve noticed that in Anime Studio, the bones hierarchy determines how the regions are rendered when overlapping. I think that we don’t have that clear yet. See differences:

Captura de pantalla 2014-05-01 a la(s) 17.49.06.png

Captura de pantalla 2014-05-01 a la(s) 17.48.41.png

The render speed is mostly similar to what we have now to raster layers so it would be a great hit when the OpenGL implementation were done!!

I have one question, though, why do we have two skeleton layers, one for vector and other for raster? Couldn’t we use the same for both uses?

-G


#7

Congratulations on a successful campaign you might want to use prefundia before you start your next campaign also this guy might be able to help you indiegogo.com/projects/wuff … olf-year-2


#8

Absolutely agree. In the future we have to add a consideration for bone influence area (which is defined by bone width).

Have you tested with tile rendering off? It should give you much faster results.

At the moment we have no plans to merge Skeleton and Skeleton Deformation layers into one, because they are conceptually (and functionally) different.