animation for developer meeting minutes

Thanks for the response flokkievids. I did build the INSTALL and made the most recent patch changes, but still no luck. I am getting an error message in visual studio express 2013. Any ideas?

Here is a quick test result with a character model of mine. The preview raster image is based on a screen capture of Firefox showing the SVG output (no retouching except for cut-n-paste operations). The blurry effect is made of two line sets, one with a thin dark line color and the other with a thick light color.

@Paul McCollam (plender),
I am also using Visual Studio Express 2013 for Desktop and CMake, so the build process should work fine. I confirmed that the Debug build works as fine as the Release build.

@Folkert de Vries (flokkievids),
The support for round caps seems not working properly (see the screen capture below). In Freestyle round caps are implemented as a variable width stroke having extra vertices at both ends of the stroke. The stroke-linecap="round" property seems working fine, but the extra vertices make strokes longer than expected.

A solution could be to insert SVGPathShader in front of RoundCapShader and SquareCapShader in the list of stroke shaders.

@Folkert de Vries (flokkievids) I can build trunk fine, so I am only having problems with the patch build. I'm sure I'm doing something stupid because I'm new to all of this. Everything is up to date. Would the CMake config/generate log be helpful? Or the MVSE output log? Thanks again for taking the time to help me out.

@Tamito Kajiyama (kjym3) Do you have CMake 3.0.2 and are you building 64bit?

@Paul McCollam (plender),
I use CMake 2.8.12.2 and usually build 64-bit Release configuration.

that's really a great work!
I'm glad I could contribute a bit, although indirectly.
very nice indeed.
Francesco

First of all I'm super happy to see this happening, wasn't aware how far this has progressed already; Thanks so much! :)
So ... I'll try this out on a project I'm currently working on and provide you with some real production feedback! ... But I got a minor build problem first ;)

I applied the patch with arc and am getting this while building:

[ 93%] /home/simonrepp/blender-dev/blender/source/blender/makesrna/intern/rna_scene.c: In function ‘rna_def_scene_render_data’:
/home/simonrepp/blender-dev/blender/source/blender/makesrna/intern/rna_scene.c:4864:2: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
  static EnumPropertyItem freestyle_ui_svg_mode_items[] = {
  ^
cc1: some warnings being treated as errors

Doesn't look like a big deal, but still breaks the build process for me - I'm building on Fedora 20 with gcc 4.8.3 and all deps installed with the install_deps script. (Building trunk works fine). Should I fix this on my machine (compiler flags something) or does this call for actual changes in the code?

Perfect - builds fine now; Gave the exporter a super quick shot today too - magic! :)
Thanks a ton! I'll let you know my findings when I start experimenting with this in more detail in the next days!

@Folkert de Vries (flokkievids),
I agree with you that the patch is quite complete in terms of both functionality and coding style. The extension of filled polygons is a great plus!

One possible further revision if you like is to better support stand-alone style modules for the Python Scripting mode of Freestyle. Currently SVGPathShader depends on a line set and hence a line style. If I understand the code correctly, the line set is only necessary for its name (used to name an SVG group), whereas the line style is used for retrieving line stylization parameters. SVGPathShader could be independent of them, for instance by passing the line set name and the stylization parameters as arguments of the shader constructor. Then, a Python style module would be able to employ SVGPathShader by calling as follows:

shaders_list = [
    ...
    SVGPathShader(name = 'LineSet1',
                  attr = {'stroke': 'rgb(255, 0, 0)',
                          'stroke-opacity': 0.75,
                          'stroke-width': 5,
                          'stroke-linecap': 'round'}),
    ...]
Operator.create(TrueUP1D, shaders_list)

We can define some default values for all the input parameters so as to make them optional.

If you prefer to merge the patch as it is now, that is also fine to me. Any further improvements of the SVG exporter can be done later as you wish.

I finally found time to experiment with a first use-case: Building an interactive hoverable svg for web use, as directly as possible, and in this case overlayed above a rasterized freestyle render.

http://fdpl.foundation/svg-hover/

First verdict here is that it's not possible in a very direct way :) - which however is not a shortcoming of the SVG Exporter (which did it's job beautifully), but more because it's a very specific application for this rather general svg exporter. If this is something many people are interested in, it's probably more adequately placed in a seperate Add-on that could allow, for instance, mapping object names to path or group ids, etc.

One other, possibly more relevant aspect that I noticed myself starting to ponder is that, from an artist's perspective (or at least from my specific vector art workflow perspective), the "bonus functionality" of getting fills, might actually be far more interesting than getting the strokes from freestyle as such (which, without some of the modifier styling instantly feels much less useful to work with). Starting this train of thought - how to expand on fill exporting - however opens up a whole new world of questions, the scope of which clearly goes beyond the patch at hand here. Still this might be interesting to think about in the future, and possibly something to find artistic stakeholders for at some point in order to kick off a new module design process. ("Project BEER, Vector edition" if you will :))

It'll probably take some time until I get to do my next tests with this, blender conference coming up and all, but I'll keep you posted if I make some new discoveries here.

Meanwhile - Thanks so much! I think this should definitely go into 2.73, cause it rawks. :)

Hi @Folkert de Vries (flokkievids),
Thanks for the updates. The revision was really quick! I think the patch is quite ready to land. I noted a minor comment below that could be a final one. Could you please address it?

The patch has just been pushed to Git master (rB61a330baca0f). This functionality will provide Blender/Freestyle with a killer application benefiting a wide spectrum of 2D/3D line art!

Here is another test result with the SVG exporter:

@Folkert de Vries (flokkievids),
Would you like to write up a section of Blender 2.73 release notes to introduce the SVG exporter?
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.73/Freestyle

@Tamito Kajiyama (kjym3)

Thanks! I'll hopefully have time to write some documentation about the exporter this week.

@prout reprout (all) other subscribers

thanks for the feedback here.

@Folkert de Vries (flokkievids) and @Campbell Barton (campbellbarton),
I have filed patch D839 to propose a set of hooks for Freestyle-specific callback procedures to modify the Freestyle line rendering process.
The hooks have been implemented locally within the implementation of the Freestyle Parameter Editor, since there is no reason to expose these Freestyle-specific hooks as part of the general callback mechanism in Blender.
Still the SVG exporter will have to rely on the global pre/post render callbacks for file I/O.
Hope this helps.

Updated the patch (branch temp-freestyle-svg)
was preparing to commit to push to master, but saving animation fails, I get the exception.

File "/usr/lib/python3.4/xml/etree/ElementTree.py", line 587, in parse
  source = open(source, "rb")
   FileNotFoundError: [Errno 2] No such file or directory: '/tmp/0004.svg'

The issue seems to happen when you render an animation, but have the freestyle settings configured to Frame.

@Campbell Barton (campbellbarton),
Is there a way for add-ons to check if the currently running rendering process is for animation?
I think the Frame/Animation switch of the exporter is redundant and can be removed if such a check is possible.
It looks like (re->flag & R_ANIMATION) is the C expression to check if animation rendering is ongoing, but I couldn't find if the same checking can be done from within Python.

Campbell, could you please apply the following patch to the temp-freestyle-svg branch?
It looks like that I don't have a write access to /blender-addons.git.

@Tamito Kajiyama (kjym3), committed & added you to the @addons project (you should be able to commit now)

@Campbell Barton (campbellbarton), thanks for the commit and the write access to the addon repo.

Any idea on a way for add-ons to check if the currently running rendering process is for animation? If there is such a way, then the reported file I/O issue could be addressed to get the SVG add-on done.

@Campbell Barton (campbellbarton) and @Folkert de Vries (flokkievids),
Could you two please review the following patches intended to address the SVG animation saving issue?

The first patch introduces a way for Freestyle add-ons to test rendering conditions (specifically, to check if animation rendering is ongoing).

With the above patch committed to Git master, the SVG animation saving issue can be fixed as indicated in the second patch below. The svg_export.mode option is no longer necessary and can be removed.

Copied the first patch to D921 to make code review easier. Thanks.

from my side this is looking good. it might however be an idea to expose the render context through bpy (instead of freestyle) because it may have more general applications.
creating freestyle.context for two properties that really have nothing to do specifically with freestyle may not be the best option.

@Tamito Kajiyama (kjym3), uploaded: D924

This means you can attach a callback to the render when it writes an image.

However this isnt a perfect fit for the addon. It could work this way.

• bpy.app.handlers.render_init - sets a module level variable to false (write-to-file = False)
• bpy.app.handlers.render_write - sets the variable to true.
• bpy.app.handlers.render_complete (and freestyle callbacks) - checks writing variable is set, if so, write SVG files.

@Campbell Barton (campbellbarton),

Thanks a lot for the code revision for the render_write handler. I believe the new handler is useful in general, but it addresses the animation saving issue only partly. Specifically, a callback for the render_init handler in the SVG add-on needs to know if animation rendering is ongoing, while that information is only available after the render_write hook is executed.

UPDATE: There seems a solution by deferring the file I/O to a later stage of the add-on execution. I will further look into it and come back with updates.

@Folkert de Vries (flokkievids),

I had the same thought that is_animation and is_preview flags are useful in general, but the proposed changes D921 took a different approach in line with rB79a389ee3711 that added the two flags to the RenderEngine class for representing external render engines (such as Cycles). I preferred the proposed apprach because the two flags that are states and not user options, and I could not find a good place to store state information. Note that Scene (scene) and RenderSettings (scene.render) store user options.

@Campbell Barton (campbellbarton),

Here is another attempt to fix the animation saving issue using the render_write hook. The patch is against the HEAD of the temp-freestyle-svg add-on branch.

@Folkert de Vries (flokkievids),

I took this opportunity to slightly change the meaning of the svg_export.mode option. Now an SVG animation file is created only when animation rendering is performed and the mode is set to ANIMATION. Otherwise, individual frames are written to separate SVG files. This way setting the mode to FRAME makes sense even for animation rendering. What do you think about this revision?

@Tamito Kajiyama (kjym3)

This seems a logical and intuitive change, thanks.

Generally fine, note

• is_animation May be set when rendering a still image. eg: bpy.ops.render.render(write_still=1), suggest to invert bool and call is_preview
• def render_animation(scene): sounds like it renders the animation, suggest call is_render_preview

also worth double checking...

• bpy.ops.render.render(write_still=1) saves a single svg
• rendering a video file correctly saves SVG's

Note:

return scene.render.frame_path(frame).split(".")[0] + ".svg"

Should be:

framepath = scene.render.frame_path(frame)
if scene.render.use_file_extension:
     framepath = framepath.rsplit(".", 1)[0]
 return framepath + ".svg"

@Campbell Barton (campbellbarton),

Thanks for the quick review. Here is an updated patch addressing all the suggested changes and tests.

The bool flag was inverted to is_preview and the test function was renamed to is_preview_render(). Both bpy.ops.render.render(write_still=1) and movie file formats were tested, confirming that the SVG export works fine.

It is remarked that SVG file names now depend only on the svg_export.mode option. Specifically, 0001.svg, 0002.svg and so on are created when the mode is set to FRAME, so as to allow for generating per-frame SVG files in both still and animation rendering. When the mode is set to ANIMATION, the output file is always like 0001-0250.svg, i.e., in line with the file naming convention for movie file formats in Blender.

@Tamito Kajiyama (kjym3), generally good.

Though Im not sure why you'd want to remove the file component from the SVG?

you might want to have /my/anim/test1_0001.png & /my/anim/test1_0001.svg, 0002 etc...

Campbell, thanks for checking the code. The patch is actually supposed to save files like /my/anim/test1_0001.svg, /my/anim/test1_0002.svg, and so on. If this is considered okay, then I think the patch is done.

@Tamito Kajiyama (kjym3) - could you commit the changes to the branch? - I can double check and merge the addon.

Commit done in the temp-freestyle-svg branch: rBA7a331da7671a.

Checked and seems logic isn't right, simple F12 render with SVG addon enabled is writing files.

Oh is writing files upon simple F12 rendering considered wrong? Raster images can be saved by F3 after simple F12 rendering, but that cannot be done for SVG rendering results atm. Do you think SVG files should be written when rendering animation or when saving a raster image by F3?

@Tamito Kajiyama (kjym3) - I had the impression we would save SVG's from Blender, only when blender was saving images.
but this isn't really obvious whats ideal since F3 saving doesnt have a way to write the SVG.

So for now, think it can be left as is, and committed to master.

I've tested the addon, and it works very nicely.
the only remark is that it doesn't seem to use the "layer" groupmode in SVG for different kinds of entities (e.g. fills, frame lines), that would be a nice feature because Inkscape users could have the different entities already divided in layers when opening the resulting svg in Inkscape.
Also, when rendering an animation in a single svg, having the frames not separated in layers makes it quite difficult to use the resulting file for further elaboration in Inkscape.
For example, this is the layer structure in Inkscape of a file rendered with the old set of scripts I used to use:

@Campbell Barton (campbellbarton),
Thanks again for the code review. I will proceed with the merge. Would you like to separately keep commit logs of the temp-freestyle-svg branch?

@francesco fantoni (hva), @Folkert de Vries (flokkievids),
Francesco, thank you for the test and feedback. I just got to know that Inkscape supports nested layers. Since the SVG exporter does grouping a lot with the svg:g tag and inkscape:groupmode attribute, code revisions addressing the suggested layer fix are likely minimum. @Folkert de Vries (flokkievids), would you like to work on the fix? We will enter BCon4 this Sunday and hence code updates need to be quick.

@Tamito Kajiyama (kjym3). it can just go as one commit. dont think history so-far is interesting.

@francesco fantoni (hva)

thanks for the tests and comments. I hope I understand your suggestion correctly. What I've implemented is

<g frame>
  <g fills /> 
  <g strokes />
</>

below are the patch file and an example result.

@Tamito Kajiyama (kjym3)
I'll have a look at the release notes in the morning.

@Folkert de Vries (flokkievids),

Apparently Inkscape layers are svg:g elements at least having three attributes id="someName", inkscape:label="someName" and inkscape:groupmode="layer".

How about organizing layers as follows? This is for animation SVG files. For still renders strokes and fills could be top-level layers without Frame_nnnnnn imho.

<g Frame_000001>
    <g strokes>
        <g LineSet1>
        <g LineSet2>
          :
    <g fills>
<g Frame_000002>
   :

Below a manually modified SVG file based on yours is attached following the proposed layer organization.

Inkscape shows the layer hierarchy of the file as follows.

@Folkert de Vries (flokkievids)
I tried your modifications, but I guess Tamito is right: you have to set id="someName", inkscape:label="someName" and inkscape:groupmode="layer" in order to show groups as layers in Inkscape. Obviously Inkscape is not the only target for svg files, but I think is quite nice to have the possibility of managing frames and linesets as layers in Inkscape.

@francesco fantoni (hva) & @Tamito Kajiyama (kjym3)

I've revised the patch, and it now seems to work correctly in inkscape.

@Folkert de Vries (flokkievids) and @Tamito Kajiyama (kjym3)
looks fine to me, although I personally would rather have the 'frame' layers as parent layers containing linesets as nested layers, but I suppose that is really a matter of personal workflow habits.

hello,

i have this problem on chrome (animation):

and:
"SVG's SMIL animations (<animate>, <set>, etc.) are deprecated and will be removed. Please use CSS animations or Web animations instead."

cheers, van