Jucika drawing test

Artwork Work in progress
1

image
image1902×2078 421 KB

This work in progress is 99% Inkscape and 1% Synfig, but I wanted to share a learning experience, and an interesting workflow, taking advantage of Inkscape.

  1. When you import an Inkscape SVG in Synfig, the “Move/Scale coordinate handle” of every object ends up very far, about 1 page below and to the right. I still don’t know how to prevent this.
  2. Groups in Inkscape, remain as groups when imported in Synfig. The groups also retain the names of your choosing. But the individual paths and fills do not retain the names. This can help in the bone linking phase.
  3. If you use “clipping” in Inkscape. The effect will not transfer to Synfig and the paths will end up un-clipped. You need to redo the clipping with blending modes, as shown in: https://www.youtube.com/watch?v=YgcLUHA-2JM. Then look at how I did the eyes irises.
  4. Fingers and limbs are not that hard in Inkscape, and the work will transfer to Synfig. In Inkscape, you can make filled paths with a black outline, leave the curve open and it will appear to have an “un-edged” side, which will make the colored areas appear to join together
  5. I just learnt that I can do the “invisible edge” technique in Synfig too. Next time I will try doing this work in Synfig… because relocating the origin of the scale/move axis might become unmanageable for many objects. On the other hand, I used Inkscape path effects to do the eyelashes and pearl necklace (and in general all the repetitive shapes).

jucika.sifz (55.1 KB)

5 Likes
Sonic the Hedgehog: Intro parody
2

Oh, I didn’t know Inkscape makes a custom way to label a path/fill.

I’ll add support to this labeling and it’ll probably be available in the next development release.

Masking and clipping is more annoying to add support; maybe I’ll try to do it, but I don’t promise it :face_with_tongue:

3

thank you :slight_smile:

When importing from avg, only the group names survive in Synfig, but the path names become “path”,

In my screenshot, there are two path objects with custom names, because I fixed manually after importing.

There’s already clipping im Synfig because of the “alpha over” and “straight onto” blending modes :slight_smile:

I just learnt that Inkscape can export to Synfig format… and the location offset problem is gone… but the grouping doesn’t survive the export.

I am trying something that might solve the offset issue in svg import

4

Offset “solution”:

In inkscape: move the drawing 284mm to the right, 417mm down. Make a circle to occupy a similar space in the page center.

image
image2028×2074 425 KB

Import it in Synfig, and the art will be in the center of the page. Erase the circle outside the page.

image
image1906×2082 507 KB

In my case, the extra objects were Clipping Masks used in Inkscape, which appear as loose objects in Synfig

1 Like
5

I know, but it is not that easy. First it would be “Alpha” blending mode. Then we need to read/study the SVG 1.1 and 2.0 specs about it, implement how to parse clipping paths, how to apply this effect for each case, check all (or the most important or used) XML attributes they case, check for corner cases or malformed SVGs (usually by manually created ones) to avoid crashing or freezing when loading SVG, check if Inkscape does something different/exotic/custom about it on saving a file with clip-path, etc. It is a whole new feature not implemented in the importer before, so it is a lot of work/care to do so.

Anyway, I’m currently implementing a draft for clipping support.

6

Thank you for your response :slight_smile:

Good luck with your clipping support script :+1:

I found there’s SVG importer python script here. I will try it too

7

I already know how to place the image object in the center of the canvas. Just open the file in Inkscape, edit the document properties, change the size for example to Full HD, and set the scale to 1. Then, on the main screen, move your image object to the center. You can watch the tutorial on YouTube: https://youtu.be/8QSYF6U6rk4

8

Why not just to use the grey handle (move origin) to move the origin (green handle) of the imported SVG layer, then use the blue handle for scale?

9

Thank you Zainal… I see that the Inkscape SVG loaded right for you :smiley:

I think I am missing something. I made my inkscape document as you suggested, but Synfig still shows it 4x the size

image
image1920×1039 290 KB

image
image1920×1040 205 KB

(dont worry about the unclipped parts… I was working in another non-synfig project)

When I applied scale=0.25,0.25 in the group, it was the correct size

image
image1920×1039 236 KB

The solution was to edit the image area to -16,16,-9,9, then the import was correctly sized :slight_smile:

image
image1920×1041 238 KB

10

I could scale everything in a group, but I need to import everything in the correct size without group scaling.

In my process, I would import all the Inkscape SVG document, then move the sub parts outside the group. If the whole design was fixed with group scaling, each part would lose that scaling, when I separate it from the group.

I need to break the group for skeleton reasons.

11

If I understand correctly, then yes — if the main (top-level) group is scaled and you place the bone layer above that scaled group layer, problems will occur once the bones start moving. The BLine positions will no longer match the bone positions.

The solution is to place the bone layer below the main (top-level) group layer. Also, don’t try to scale or offset other layers inside the main group, as that can cause issues later as well.

pos_group
pos_group1920×1080 216 KB

12

That’s absolutely true — this method can work as well. However, when I create a new bone, its position ends up outside the canvas or not centered on the canvas. For some users this may not be a problem, but for me it becomes inconvenient because I have to repeatedly move it back to the center whenever I create a bone layer, and the same thing happens with non-parented bones.

So in the end, it depends on which method the user prefers to use. Both approaches work, each with their own trade-offs

13

clipping
clipping1920×1080 289 KB

For this issue, I experimented in the svg_parser.cpp file and added several scripts. In the Inkscape SVG file, whenever there is a clip object, I create a group named clip. Inside this group are the layers that will later be placed inside the clip layer.

Then, during SVG import, if the importer finds the word clip, that layer is assigned blend_method = 13 (Onto).

This method works fairly well, although I believe there are more automatic and much better approaches by understanding how Inkscape SVG works internally. I just don’t yet know how to parse the file more deeply.

14

I like so much when there are harcoded values in code instead of using constants …
And 7 lines of code where 3 would be sufficient to make a better and more readable syntax.
It’s not like if we got paid per produced line of code!
:face_with_symbols_on_mouth:

15

I did implement the clip-path tag and attribute support for SVG importer.
I’m waiting for another SVG importer PR be merged to push it though (due to merge conflicts) :wink:

2 Likes
16

Of course, I can fix it without any cost

bool is_clip = label.find(“clip”) != std::string::npos;
build_integer(root->add_child(“param”),“blend_method”,is_clip ? 13 : 0);
root->set_attribute(“desc”,is_clip ? “cl” : label);

17

I was thinking more about this:

bool has_clip = label.find(“clip”) != std::string::npos;
int bm = has_clip ? Color::BLEND_ONTO : Color::BLEND_COMPOSITE;
build_integer(root->add_child(“param”),“blend_method”, bm);

Also, my bad, I thought that it was ALREADY in the current code.
I got some PTSD after all the horrors that I see often, costing hundreds of spaghetti lines.
And the harcoded 0 for Color::BLEND_COMPOSITE is from the time of Genete :stuck_out_tongue:

How many other issues have already been solved but still wander like damned souls in the limbo of PR beyond page 1…

aryjy3
aryjy3540×427 60.9 KB