Now it is time to prepare all necessary docs for application.
This year I am volunteer to participate as an Admin. I can also act as Backup Mentor, if such need arise.
Questions we should answer first:
Who is willing to participate as mentor? It would be nice if you provide a project ideas that you are willing to mentor. If you have potential student who can carry the project - please mention that too.
Prepare list of simple issues to test skills of aspiring students. We need to examine list of existing issues in our tracker and mark some of them with “good-first-issue”, “help-wanted” and “Easy” labels. Adding simple issues is also appreciated.
Change the layout of the builded files inside the cmake-build directory:
a) Create a subfolder with assembly type (Debug / Release)
b) Inside it, create a folder tree that matches the structure that Synfig expects (bin / etc / lib / share);
Finish the make_images cmake target. Because the paths will already coincide with what Synfig expects, then everything should be works fine. As for now this target fails because Synfig can’t load needed libraries (for that step we will use the SYNFIG_ROOT_DIR environment variabe as a temporarily hack);
Fix algorithms for searching libraries in Synfig, relative to the called binary, and remove the SYNFIG_ROOT_DIR hack in step 3 (as for now part of Synfig paths is hardcoded so this part needs to be rewritten);
Add the ability to disable any optional module or all of them, this will allow building on Debian systems (there is a problem with libmng on Debian-based systems). Also maybe add a custom CMake search for libmng?;
Try to build Synfig using vcpkg (https://github.com/microsoft/vcpkg) - they do not have some libraries which Synfig depends, but after disabling all the optional dependencies, maybe this will be enough for us. In case something critical is missing - add issue with a request to add missing library. This will allow us to build Synfig using MSVC on Windows;
Start implementing CPack to prepare .deb and .nsis files.
@ice0 That’s cool! I like the fact that there is a specific plan on CMake improvements project. And also it’s starts with some short tasks, so incoming students can proof their skills before the actual coding period starts.
BTW, that reminds me about one more item for our TODO list.
We need to prepare for incoming flow of aspiring students - make a collection of simple/good-first issues, so they can start diving into Synfig code.
After a discussion with @KonstantinDmitriev, we have decided to extend the Lottie export project which was my GSoC project last year.
Here I am sharing of what is expected from you to implement in this project this year[Will keep on updating this, keep an eye]
Export outlines without variable widths (that way we get native Lottie outlines and will make animation playback much faster)
Export of following layers (Will need proof of the existence of the following layers)
Advanced outline layer
Gradients
Duplicate layer
Bones (Add support for handling group transformations)
Text Layer
Blur Layer
Motion blur layer
Radial blur layer
Color correct layer
Luma key layer
Curve warp layer
Noise distort layer
Spherize layer
Twirl layer
Bevel layer
Stroboscope layer
Julia set layer
Mandelbrot set layer
Shade layer
Add animation to the addition/deletion of bline points
Use winding (in adobe AE) instead of masks to generate all the shape layers, this way we will be able to support even/odd winding.
Hi everyone, I’m student hoping to participate in gsoc this year.
I was reading the code structure and it said the opengl rendering is as of now broken. How much of it is broken? Are there parts in the opengl renderer that have not been implemented?
I am a student hoping to participate in GSOC in 2020, so what do you guys as developers suggest for things i can contribute right now to synfig, so as to increase my chances of getting selected by your organisation.
Hi @Jedi18! Thank you for your interest! Right now we have rewriting of software renderer in progress, so it is a bit early to do OpenGL fixing/developmentŃŽ
get rid of deprecated Gtk::StockId (since before 2013)
convert deprecated Gtk::Action to Gio::Action (since 2016)
convert/get rid of deprecated Gtk::UIManager to Gtk::Builder (since 2013)
a python/ruby/lua interactive console for plugin coding/testing : it can be used for synfig document handling and;or GUI-related. It would be an alternative to call python binary.
Also @KonstantinDmitriev, could you look into project ideas and check what all needs to be updated because most of the ideas are from the previous year.
I think this is great addition, but I am afraid this could be too big task to be handled in 3 months (I think we should carefully plan API here, taking in account examples how this done in other products - Blender, Krita, GIMP, and commercial ones).
I like this, but leaving the final decision about this to @ice0.
Synfigapp is already an API. Maybe restrict the plugin approach to execute synfigapp::Actions? It would be just a matter to “port” a simplified version of basic data structures (layer, canvas, params, keyframe, valuebase).
With SWIG, it relatively easy to build the bridge C++ ↔ Python/Lua.
Another alternative is to implement frame-by-frame animation “tools”, such as improving Switch layer handling.
Example:
“Auto-switch” tool:
User clicks on a Switch layer, then press this (toggle? radio?) tool button.
Now, when user clicks on a timeline frame, it automatically creates a new waypoint that changes/animates the “Active Layer Name” or “Active Layer Depth” parameter of the selected Switch layer. The name or depth value changes follow the tree hierarchy order.
User keeps clicking on different frames (step 2) to add new waypoint with different value. Process stops when user selects a not-inner layer of the Switch layer or selects none (or toggle back this toolbutton).
“Manual switch” tool:
User clicks on a Switch layer, then press this (toggle? radio?) tool button.
Now, the user clicks on a timeline frame, and then on a inner layer of the selected Switch layer.
Synfig then automatically creates a new waypoint that changes/animates the “Active Layer Name” or “Active Layer Depth” parameter in order to refers the selected layer contained in the Switch layer.
User repeats steps 2-3 to place new waypoints. Process stops when user selects a not-inner layer of the Switch layer or selects none (or toggle back this toolbutton).
This was suggested by Ricardo Graça, a professional animator that previously used Synfig a lot, but now switched to Blender for 2D animations… He gave me a few more ideas, but I’m still talking to him to better understanding. https://br.linkedin.com/in/rico-graca
Yes, that could be a way to go. If we select this idea, then we will need someone who is willing to mentor this project (in case if there will be a good student for it).
@AnishG I suggest to formulate the Lottie improvement idea a bit differently - how about this “Add support for exporting Skeletons to Lottie”. That makes the project more focused and easier to understand. And I think adding a skeleton export is already a big task. The addition of other layers could be a part of it, or part of proof-of-skill tasks for aspiring students.