search

opentoonz / opentoonz_docs

OpenToonz User Manual
http://opentoonz.readthedocs.io
28 stars 26 forks source link

Vector fill bug #174

Open DarrenTAnims opened 5 years ago

DarrenTAnims commented 5 years ago

Issue Summary

There's an ongoing issue that fills don't always stay. I've had this in the past, but didn't have a reproducible file. I have now.

Screenshot or Video Reference

N.zip

Steps to Reproduce

Expected Results

The head should remain filled in after saving and reloading. This means that I have to fill in and export during the same session or I'll lose the fill. And there are other parts that lose the fill, which makes me not want to continue with this scene and this sort of things is helping to drive people `away from OpenToonz!! Not good.

System Information

I'm on Windows10, using the latest OTX.

RodneyBaker commented 5 years ago

After exploring a little I arrived at a Level that reproduced your issue but then after attempting to Ungroup all the Groups assigned I now get a level that has a corrupt second frame that will crash OpenToonz.

badfills_2ndframecrash.zip

Related? Unrelated? I'm not sure.

ghost commented 5 years ago

It happens to me too. You should always inspect the drawing because sometimes the color goes away or persists with the vector levels.

I also had strange things with shapes that were no fillable during the session but that became fillable after saving, closing and opening OT.

In some cases I noticed that Opentoonz added extra strokes, itself without asking for your opinion, so that the shape became refillable after a save.

I did not quite understand what happened. If it was me who had bugged. I put the file aside to try to understand later.

Yes, this inevitably has a negative impact on new users vectors based.

artisteacher commented 5 years ago

While filling has definitely improved, I still run into unexpected fill issues as well. Sometimes just moving a drawing with the select tool can somehow remove a fill. I’ve also transferred a zipped project between computers & found some of the fills missing upon opening on additional computers (the original project does not have that issue).

By any chance, does increasing the maximum gap value for the fill tool have any impact?

beeheemooth commented 5 years ago

I think I found the cause of the problem. This is one vertice on the top plane of the box. It can be moved, but you can not drag the handle. If you still try to edit it (for example, straighten it with Alt+click), then after saving the program will crash. I deleted the problem vertex and connected the ends. After saving the scene, fill is present.   Maybe someone will examine this vertice, and understand why this is happening? ezgif-1-8855519320ee

artisteacher commented 5 years ago

Converting the vertex to either a linear or non-linear control point (through the context menu) allows the fill to work as expected without any crashing. So weird...

DarrenTAnims commented 5 years ago

Hi all. Many thanks for all of your help looking into this for me. I've now got my scene working and the fills (on these broken frames, about 6 in total) all stay filled. So there's no need to work on a fix for this specific scene for me, but hopefully this drawing can be used by the developers to work out what went wrong and prevent it in the future.

I used @beeheemooth's technique of using the eraser on the corner to remove that point and then re-dragging the line to fit the gap. I did try right clicking on the corner and choosing a linear control point, but that didn't work. When I dragged over the animation, OpenToonz crashed. So there's 2 things come from this:

  1. If the developers can look into why the control point became broken, so that when it's saved, this can be repaired automatically, so that the scene loads as it was on running, that'd be good long term.
  2. I'm not sure how I could have tracked it down to the 1 vertex on my own and we obviously can't expect anyone else to do so.
RodneyBaker commented 1 year ago

I'm leaning toward closing this report as the original issue has long been worked around and targeting of the specific case here might not be the best use of a developers time when the user can resolve the problem locally. This however doesn't mean that similar issues might not still exist.

One question we might ask is how best can we capture the general problem in other reports that are still open related to vector graphics and color fills.