Illogical Render Times using Freestyle

Support Technical Support
, ,
1

I’m a long time Blender user, but only recently tried Freestyle for the first time. And I am, of course, well aware of the fact that Freestyle is a resource-intensive process. That said, the render times that I’m getting seem all but logical to me, so I would like to ask for help…

In a nutshell (sorry, I can’t post a Blender file, as this is a client job): I’m currently working on an architectural scene that needs to be rendered in Eevee (for an NPR look) and should be overlaid with line drawings from Freestyle. Needless to say, the scene is pretty complex; and as I have been away from my office for a few days, I started working on this project on my notebook: a HP Spectre with an Intel Core i7 (4 Cores), 16GB of RAM and a not-too-spectacular graphics card (Integrated Intel UHD 620). So, I was kinda expecting higher render times…

And I was right: Rendering the base image in Eevee took about 15 seconds (which is totally fine), and then Freestyle took around 5 minutes and 30 seconds. Which is higher than expected, but alright for this notebook in my opinion.

Anyway, when I returned to my office, I loaded the exact same scene in one of my desktop machines: a HP Z820 with Intel Xeon CPUs (16 Cores), 64GB of RAM and an NVIDIA GTX 1080 graphics card. So, I was expecting significantly lower render times…

And, lo and behold, I was wrong: Rendering the base image in Eevee took about 3 seconds, but then Freestyle took around 7 minutes and 45 seconds!

After a few more experiments (GPU, CPU, hybrid rendering…) I’m now officially dumbfounded. Can anybody offer any explanation as to why this might be the case? Or, better yet, suggest some optimizations that I might look into?

Any help would be much appreciated.

1 Like
2

I know, of course, that nobody has any in-depth knowledge about my system. But I would be grateful about any suggestions that might explain the render times that I’m seeing. Does anybody happen to know, if the Freestyle renderer has any specific problems with, say, NVIDIA cards… or specific CPUs… or whatever?

Thanks in advance. :slight_smile:

3

Hi.
Less than 10min per frame for production isn’t really much.
About the times on the different machines, I have not done any tests but I can suspect that freestyle is perhaps a single thread CPU process, and it will work faster on that CPU with higher single thread performance, which is not necessarily the CPU with more threads .

Also, you should share or tell more about the .blend file scene so that users can get a better idea of what the problem may be. Do you have Hair or particle systems in the scene?

4

Ah, your suggestion about Freestyle perhaps being a single-thread process might indeed explain some of the differences. Frankly, I was expecting to see drastically lower render times with my desktop machine, but I was implicitly factoring in the fact that this PC has more cores, more RAM and a better GPU. But you are right in that the Xeon CPUs are a bit dated (E5-2670, 2.60GHz), while the i7 (8550U, 1.80GHz) is from 2019.

So, if Freestyle indeed uses only a single CPU thread, it’s reasonable to expect that - ironical as it may seem - it might indeed run faster on my weaker machine. Can anybody confirm that?

As to the .blend file: Nothing too fancy, really. No hair, no particles, no transparency, no volumes, no image textures. Just a lot of highly detailed objects (around 580.000 verts, around 1.100.000 tris) with a mixture of diffuse and glossy materials (all rendered in NPR shaders). (Oh, and I’m also making use of AO.)

1 Like
5

Freestyle is not able to handle big scenes. It was developed more than one decade ago, with the idea to render one model with stylized lines, not big scenes that are currently accessible to modern computers.
For each line, you ask to create. Freestyle creates a spline object.
So, thickness and style of spline is basically possible through dense meshing of this extruded curve.
If your scene has a million of tris, freestyle lines are probably corresponding to several other millions.

There is no optimizations settings for freestyle (except View Cache map option if you are only moving camera).
You can try to lower sampling in Geometry tab of Linestyle. But that would have an impact on style of lines.
Best practice is probably to divide your scene into several viewlayers to lower amount of lines rendered per viewlayer.

But if you don’t need stylized lines, you may be happy by using other techniques : OpenGL render of viewport in Wireframe mode, Wireframe modifier, conversion from mesh to grease pencil.

Grease Pencil will be used as basis for future LineArt rendering.
Tentative of fast NPR rendering on big scene: LANPR project was refactored to become a Grease Pencil object modifier.
It should be available in a future release of 2.9 series or 3 series.

1 Like
6

Thanks for the info. Unfortunately, yes, I need stylized lines for a toon-like NPR look, resembling organic strokes, so wireframe rendering won’t do. Thanks for the suggestion to split the scene into multiple layers, though. Will experiment with that.

Admittedly, I haven’t had a closer look into the Grease Pencil, yet. I’m afraid, a workflow involving the Grease Pencil would involve too much manual work. Which is why I’m hesitant to even try that, when Freestyle is actually giving me results that we are pretty happy with (apart from the render times). Or can the Grease Pencil somehow be automatized like Freestyle?

As to LANPR: I heard about that project only recently, but thought this was only in the early stages. Would you say that, at this time, waiting for LANPR to become usable in a production workflow would make sense (instead of creating the look based on Freestyle)?

7

LANPR was a GSOC project in 2018-2019.
At the end, focus changed from a direct render engine to an automatic way to produce Grease Pencil strokes.
This summer, developer of LANPR cleaned up UI of his previous work to end-up with a simple LineArt panel in Render Properties and a LineArt modifier for Grease Pencil Objects.

So, that should not take 2 more years to finish it and integrate it in an official release.

I did not take a look to addons but, maybe, somebody already did one without waiting for LineArt changes.
But, yes. Basically, wireframe of mesh is converted into Grease Pencil strokes.
You have to determine seams in mesh before conversion to limit it to seams.
Or you have to delete undesired GP strokes after conversion.
And you may encounter several problems related to occlusion.

LineArt is supposed to handle what lines to render according to point of view of camera, automatically.