Freestyle integration into Blender

February 1, 2010

Weekly update January 25-31

Filed under: Update — The dev team @ 1:10 AM

In the previous blog article, we reported a crash in rendering complex scenes.  The problem turned to be the consequence of an “out of memory” error during stroke rendering.  When objects exist out of the view frustum and near the near clipping plane, feature edges in the 3D camera coordinate system are projected to an extremely far location out of the camera view in the 2D image space.  These feature edges result in very long strokes with a large number of stroke vertices, which temporarily require a significant memory storage, possibly causing a fatal “out of memory” error.  This problem was partially addressed by omitting unnecessary stroke vertices just before the stroke rendering.  There is no user-visible negative side effect.  Further memory usage improvements are possible on the users’ side (i.e., in a style module) by explicitly selecting feature edges within the camera view.  This can be done by applying a custom edge selection predicate as follows:


import Freestyle

scene = Freestyle.getCurrentScene()
w = scene.render_data.resolution_x
h = scene.render_data.resolution_y

class WithinCameraViewUP1D(UnaryPredicate1D):
    def getName(self):
        return "WithinCameraViewUP1D"
    def __call__(self, inter):
        for v in [inter.A(), inter.B()]:
            x = v.getProjectedX()
            y = v.getProjectedY()
            if 0 <= x <= w and 0 <= y <= h:
                return 1
        return 0

Operators.select(AndUP1D(WithinCameraViewUP1D(),
                         QuantitativeInvisibilityUP1D(0)))

If you have got a number of “strip vertex 0 non valid” warning messages followed by a crash, then try using the WithinCameraViewUP1D predicate to exclude those feature edges that do not appear in the rendering result.  User-side memory consumption contol of this kind should substantially improve the stability of the renderer.

We then moved on to improvements of mesh importing.  Now the Freestyle renderer can deal with mesh deforming modifiers including Curve, Mesh Deform, Cloth and Soft Body.  Previously, mesh vertices imported from vlak nodes were transformed from the camera coordinate system to the object local coordinate system.  This causes a difficulty in recovering mesh vertices in the object local coordinate system when mesh deforming modifiers have been applied.  Now the view map creation is carried out based on mesh vertices in the camera coordinate system.  This approach requires less transformation matrix operations and thus is faster and less affected by numerical errors.

We also fixed a bug in the handling of aspect ratio settings.  The bug caused a strange Y-direction offset of strokes.  Now the aspect ratio settings are properly respected.

Finally, we worked on orthographic camera support.  Silhouette edge detection and view map creation have been enhanced, and now both perspective and orthographic cameras are supported.  The following image is a test render for a comparison of the two camera modes.

Comments, problem reports, and any kind of feedback are welcome as usual.  Have fun!

About these ads

10 Comments »

  1. [...] here: Weekly update January 25-31 « Freestyle integration into Blender Posted in freestyle | Tags: 106 and park countdown, body, camera-coordinate, curve, deform, [...]

    Pingback by Weekly update January 25-31 « Freestyle integration into Blender | Daily Hot Topic — February 1, 2010 @ 7:23 AM

  2. Thanks for the weekly updates. You really seem to progress fast!
    you do great work!

    Comment by Marcus — February 2, 2010 @ 6:50 PM

  3. Orthographic rendering finally, I can now turn down the angle on my camera lens and setup some of my scenes more favorably for freestyle.
    Thank you for the fast pace of development.

    Comment by Blenderificus — February 3, 2010 @ 2:04 AM

  4. thanks so much for your work on freestyle in blender!

    Comment by tkroo — February 3, 2010 @ 3:15 AM

  5. always great news! thankyou

    just a question, with new bmesh system, do you think averything works fine?

    Comment by Max Puliero — February 8, 2010 @ 3:44 AM

  6. Hey guys, I’ve been building the Freestyle branch and posting in on Graphicall.org whenever I see you’ve done an update.
    I’ve been posting two builds for Windows, one optimized and one not.
    I can’t seem to build it on Linux though. I get errors when I try to build it like I do with the trunk. I use scons and python 2.6 per the instructions here: http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/2.5/Linux

    Can you help me out? I’d love to give the Linux community a build. Well, I’d also like a Linux build for my Ubuntu machines too!
    Thanks for any feedback, you can comment here or give me an email at loopduplicate@burningtoken.com. My email is hosted on my server so I promise you won’t get spammed or anything. My company and phone number are on my website too, burningtoken.com just to reassure you.

    Sincerly,
    Jeff

    Comment by Loop Duplicate — February 8, 2010 @ 2:55 PM

  7. Max,
    I have never tried the bmesh branch, so I have no idea on bmesh compatibility with Freestyle.
    I guess it solely depends on the way how meshes are exposed to the renderer. Af far as the
    meshes are internally represented with triangles, Freestyle should work fine with bmesh.

    Jeff,
    Thank for for taking care of Freestyle builds. Maybe the BA Freestyle thread would be a
    better place to discuss that kind of stuff than doing so here through blog comments. I am
    also a user of Ubuntu, so I hope I am able to help you.

    Comment by The dev team — February 8, 2010 @ 8:13 PM

  8. thankyou!

    Comment by Max Puliero — February 9, 2010 @ 2:53 AM

  9. Thanks for your advice on checking the BA freestyle thread. I think you mean blenderartists.org so I will check there first.

    I figured out my problem. It was related to glut. I had freeglut installed but not glutg3, I think. Anyway, by looking at your readme files in the source, analysing the output from scons to see where the errors were happening, and getting the necessary dependencies, I was able to build it. Now I just run a script that deletes my old installation, updates from svn, and recompiles. All the work required to rebuild it is done in a matter of seconds so I’ll post a new version on Graphicall whenever you update the code (I assume that when you post a revision that says “merged with trunk” that means that you’ve updated the code and we get new features. I am still new at programming so I’m not sure if I’m right.)

    And from now on I will post at blenderartists as I already have an account there anyway. Cheers from California!
    Loop Duplicate

    Comment by loopduplicate — February 10, 2010 @ 11:13 PM

  10. I really appreciate your effort on the builds of the Freestyle branch.

    Concerning revision logs, your understanding is correct. The Freestyle
    branch is a copy of the trunk plus some additions. When the trunk has
    been updated, the branch needs to manually incorporate changes in the
    trunk into the branch. A commit log saying “merged with trunk” states
    the fact that new features and bug fixes in the trunk got incorporated
    into the Freestyle branch.

    Comment by The dev team — February 11, 2010 @ 12:40 AM


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

The WordPress Classic Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 57 other followers

%d bloggers like this: