Freestyle integration into Blender

Open Questions

– Should the ViewMap only contain visible lines or all lines?
(Currently all lines)

– If all lines, should we compute the Quantitative Invisibility or just a binary visibility?
(currently both are possible. Some technical styles depend on the QI information)

– What types of feature lines should be in the ViewMap?
Currently, there are Silhouettes (smooth or non smooth, depending on the vertices normals), crease edges
and suggestive contours. This choice has an impact on the complexity of the ViewMap and potentially its robustness.

– Should we support chaining ?
(Currently, yes. Makes it harder to potentially support a solution to temporal coherence).

[ Update – 05/07/2008 ]

– How to replace the swig dependency? One difficulty that occurred to me is that Freestyle heavily relies on the use of “directors” that allow cross-language polymorphism. For instance, the operators (eg select, chain etc… ) are implemented in C++ and take as argument various rules (eg predicates, shaders, …) whose base classes are defined in C++ but whose implementations can be either in C++ or in Python. Directors make possible a python implementation . The solution would be to either emulate a similar feature or to break the style module down in a way that doesn’t require cross-language polymorphism.

Advertisements

5 Comments »

  1. I think all lines should be the goal.

    Toon and NPR renderings will likely use only visible edges, but things like technical drawing need all. same thing for Quantitative visibility, but that may depends of the complexity.

    Imho, Creases and Silhouettes are mandatory. Suggestive contours should be added too if possible. Now, because we are in a complete 3D application, there is other things we want to include, like user marked edges and material boundaries. Balancing complexity of the viewmap is indeed a problem.

    About chaining, I’m a bit torn. Temporal coherence is important for animation, but on the other hand, due to animation itself, the edges in the view map will vary in any case. So we may not lost much by keeping chaining, and that allow more

    Comment by jean-luc — May 1, 2008 @ 6:37 PM

    • I think, as far as I understand it, chaining is essential to get good quality outlines on curved shapes. However, if this was problematic for temporal coherence in animation then all you would need is styles optimised for animation to not use it.

      Comment by Neil — December 3, 2010 @ 5:55 PM

  2. I am posting a question here because I don’t seem to be able to find a contact address for Tamito Kajiyama. I have never been on WordPress before (being locked behind the Great Firewall in Beijing most of the time), so if someone can tell me where they hide the contact information, please let me know.

    I have just finished a preliminary version of a patch to Blender+Freestyle, based on rev. 3239, which speeds up ViewMapBuilder::BuildViewMap by a factor of 40% (in the general case) to 2000% (for difficult scenes with approx. 1/2 million triangles). I would love to submit the patch, so if anyone has instructions on how to do so, please leave a comment.

    The reason for writing the patch is that I found Blender+Freestyle impossibly slow for large scenes, especially scenes where there are distant objects visible in the background, or where there is a lot of empty space between objects. It turns out that most of the time is spent on determining the visibility of the various edges in the ViewMap, and the visibility code optimization assumes that triangles are evenly distributed throughout a scene’s 3D bounding box. This may have been a good assumption for standalone Freestyle, but it does not hold well for local views of complex scenes such as arise frequently in Blender. The patch I have written eliminates the optimization’s dependency on even triangle distribution, and also makes no alterations to the ViewMap and Grid during visibility determination, which means that it can easily be made multi-threaded in a future version.

    The patch makes three fundamental changes to the original ViewMapBuilder code:

    1) Edges in the ViewMap are heuristically culled. Any ViewEdge that is visible in the render is retained in its entirety. Any ViewEdge’s that are entirely outside of the render are discarded. Only triangles that might cover a retained ViewEdge are retained. This retains the chaining and QI characteristics of visible ViewEdges without having to slow down Freestyle by calculating visibility for the non-visible ViewEdges.

    2) Lists of possible occluders store in OccludersSet containers have been replaced by iterators that return individual occluders on demand. The OccludersSet containers required copying many polygons again and again, which slowed ViewMapBuilder down. Using iteration instead of making a local copy of the occluders speeds up ViewMapBuilder by 40% in all cases.

    3) The camera-space Grid structure is replaced by a warped Grid structure in projected image space. This allows me to eliminate raycasting entirely, and discard the traditional Grid’s cell structure (which is often filled with empty cells). In addition it allows me to evaluate most occluders without resorting to expensive 3D geometry routines. Most of the speed up is due to this warped Grid structure.

    Scenes that used to take 7 minutes to render now take 20 seconds. I can almost use Freestyle for animation now!

    Where do I send this patch?

    Alex

    Comment by arbeels — December 6, 2010 @ 7:44 AM

  3. I have problems to compile freestyle blender on debia 64bits
    I try installing all ICU libraries but honestly i dont know how to solve this error
    Paste you error if you can help me
    http://www.pasteall.org/33632

    Comment by Santiago Andrade — July 11, 2012 @ 8:11 PM

  4. It would be nice to have Freestyle render on a separate reder pass for compositing. I am working on a cartoon and wanted to have this separately.

    Comment by Plinio — August 6, 2014 @ 8:11 PM


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: