[Bf-blender-npr] Feature/improvement idea for Freestyle

[Tamito KAJIYAMA]

Hi Terry,

Glad to hear you like the experimental result. For any further
independent testing, I have posted below the Python script I used for
the video clip:

http://freestyleintegration.wordpress.com/2014/04/09/experimental-variable-line-thickness-shaders/

 > The smooth surface issue may not be such a big deal for me. At least 
in the
 > case I was thinking of the line was already on a mesh edge. I could 
get it to
 > stay by making the crease angle extremely shallow, but then too many 
lines
 > would show up, so I was picking it up as a contour. (This can happen when
 > the model has bevels -- not so good for Freestyle).

Once I saw a blenderhead working on a robot model with lots of beveled
edges. Freestyle rendering of this model was done by disabling crease
line detection (with the Crease Angle set to zero) and flagging all
beveled edges manually with Freestyle edge marks.

 > Well, I don't know what your dev  priorities are exactly, but it 
would be very
 > useful if this became available as a style modifier.

I need more thoughts for careful planning, but I feel like this could be
a short-term goal because of its general usefulness.

 > In the meantime, I guess I'll have to learn how this is done in 
Python. Can
 > one write a new modifer in the Python API?  If so, I might attempt it.

No at the moment. But being able to write a new modifier in Python looks
a very nice addition to the Freestyle Python API. In fact, I have a plan
to integrate Python script into the interactive Freestyle GUI (like
Python expressions in drivers for animation). User-defined modifiers in
Python could be part of this scripting integration work.

Best regards,

-- 
KAJIYAMA, Tamito <rd6t-kjym at asahi-net.or.jp>


On 08/04/2014 22:01, Terry Hancock wrote:
>> I agree that what we like to have is a number quantifying how close to a
>> contour.
>>
>> [...]
>>
>> Reference:
>> http://gfx.cs.princeton.edu/proj/sg05lines/course7-5-linetypes.pdf
>
> (Yeah, that's the paper I remember reading. :-)).
>
>   > Radial curvatures are positive in convex areas, negative in concave
>> areas, and zero at inflection point. So the magnitude (absolute value)
>> of radial curvature could represent the closeness of a contour to an
>> inflection point.
>
> Yeah, it's from a dot product between the camera vector and the normal vector,
> I suppose.
>
>> In Freestyle, radial curvatures are computed at individual input mesh
>> vertices, only when the Face Smoothness option is enabled and mesh faces
>> are flagged as smooth shading. Radial curvatures are only available
>> through the Freestyle Python API at the moment.
>
> OK. I can see I should probably learn more about this API.
>
>> I did a quick test again: https://vimeo.com/91383521 .
>>
>> In the video clip, line thickness is a function of the magnitude of
>> radial curvatures. Since curvatures are computed at input mesh vertices,
>> the input mesh have to be very fine (I used subsurface division at the
>> maximum level 6). The high mesh resolution translates to a long view map
>> computation time. That is a downside of this solution. The upside is a
>> smooth transition of line thickness when the lines appear and disappear.
>>
>> What do you think?
>
> I think: "Hot damn! That's it!" :-)
>
> The smooth surface issue may not be such a big deal for me. At least in the
> case I was thinking of the line was already on a mesh edge. I could get it to
> stay by making the crease angle extremely shallow, but then too many lines
> would show up, so I was picking it up as a contour. (This can happen when
> the model has bevels -- not so good for Freestyle).
>
> I can see how it might be a problem in other situations.
>
>> Suggestive contours as in Freestyle for Blender tend to produce
>> unpredictable and noisy line results as you may have noticed. By noisy I
>> mean jagged, discontinuous pieces of line segments. I did not rely on
>> them this time, although these lines might be a starting point toward
>> what we like to have.
>
> Yeah, I've seen that problem all right. So this is not the same thing as a
> suggestive contour, then. Interesting, because I thought it had to be.
>
> Well, I don't know what your dev  priorities are exactly, but it would be very
> useful if this became available as a style modifier.
>
> In the meantime, I guess I'll have to learn how this is done in Python. Can
> one write a new modifer in the Python API?  If so, I might attempt it.
>
> Cheers,
> Terry