We all saw these very impressive unreal engine 5 demos where a gazillion triangles are being streamed into the viewport with absolutely no lag whatsoever! If you are new to 3D, you might assume that this level of performance can be achieved in any 3D app viewport, after all, 3D apps only use clay render, few billions of tris are easy to display. Right?

It is time to adjust your expectations if you assume it is the case! Performances are heavily dependent on your utilization and on the software & hardware you are using. Please remember, a 3D package, is not supposed to be a video-game-like experience.

While UE5 is a fantastic piece of technology, its sole purpose is being able to run in real-time, where stable performance is the key focus of developers, sometimes at the cost of creative "budgets", limitations, and time-consuming or inconvenient workflow.

Blender (& its 3D DCC siblings such as Max/ Maya/ Modo), is not a real-time application, it is a digital content creation tool (alias DCC), where rendering is done separately during a dedicated part of the process (when you click on F12 to execute your final render).

This in return gives us way more creative freedom as the final render can be computed during an indefinite amount of time, compared to being restrained to a stable framerate. But, as a tradeoff, we the artists, will need to be smart on how we preview and manage our heavy scenes when working in the viewport.

You might assume that the best solution to make Blender viewport faster uses game-engine-like optimization tricks, right?

I'm sorry to inform you that this is a common misconception. Distance-based LOD for example, is one of such technology quite demanded by Blender users. Implementing such an inconvenient trick does not make much sense in a non-real-time rendering app. Most likely, you'll experience slowdowns and more memory expenses.

The most optimal, and easy-to-use approach is to simply display a placeholder (a replacement object only meant for visual representation) in your viewport, and render the full-resolution asset only during the final render.

Rasterization Slowdowns

The viewports (more precisely "solid"/ "wireframe"/ "material"/ "overlay" options) of Blender are running on a rendering algorithm called "Rasterization". It's the same technology used by Eevee or games. This algorithm is extremely fast to compute, however, it does not scale well with high polycount. On the contrary, ray-tracers such as Cycles or Octane do not care about polycount that much. Such ray-tracing algorithms scale depending on the number of rays bouncing in the scene, they can handle renders with multiple billions of tris with ease (see this demo on youtube) however, ray tracers are not a viable solution for working in the viewport yet so we'll need to be careful about what we decide to display.

Let's talk about numbers. For reference, when scattering a 5.000 poly object with my 2080 GPU, my viewport will start to become laggy when displaying 100.000 instances, and become completely frozen around 500.000 instances. (Reminder: to get informed about your scene object-count, enable the statistics overlay in the viewport header -> overlay menu ). However, Cycles ray-traced rendered view will just do fine if we disable the overlay drawing option.

Scatter-Engine Slowdowns

As you may know already, Geo-Scatter is based on a geometry-node engine, it is currently the fastest method available for us, Blender plugin developers. Geometry-node is quite fast by nature! If you avoid hitting viewport rasterization slowdowns, by for example using the display as a point feature, the next logical slowdown you will be facing is the calculation done by the Scatter-Engine itself. Depending on your update dependencies and the feature you are using, around +-5.000.000 points are manageable when working live in the viewport.

What are update dependencies? Well, it is when an element in your scene or in the UI will trigger a recalculation, when for example, changing slider's values will trigger a recalculation of the scatter, and so does moving elements tied to a scatter-system such as an emitter, a chosen surface, camera, or an object inside a proximity feature collection for example.

Memory Limit?

If you want to scare a 3d artist, the best way to proceed is to display a message in his interface telling him he ran out of memory! However, this is unlikely to happen in a scattering workflow, because scattering is using a memory-efficient object duplication technique that I am sure you are familiar with, called "Instancing". Internally, the mesh & texture information of your object will be re-used in memory. So no worries with memory usage when working with Geo-Scatter.

Highpoly Slowdowns

Scatter is quite forgiving regarding your chosen surface polycount, but not Blender! Vertex color painting, weight painting, and texture painting will be slow when approaching 200.000 verts.

Fortunately, there's a way to avoid this, by using two distinct terrain objects instead of one: one invisible low-poly version you will use for scattering & painting, and another high-res version only used for the final render.

Be warned that it is not a good idea to use a subsurf modifier on your emitting surface as it may reset the seed of your scatter-system(s) and slow down your scene.

Instance Limit?

The brand new CyclesX also has limits, you'll be able to render up to 30 million instances before the initialization time, canceling time, and RAM consumption becomes too heavy. I believe this limit will be improved upon a later release, after all, CyclesX is still brand new (writing this in 2021).

Other rendering engines, such as Octane, might have a different limit. Note that the Scatter plugin and geometry node are compatible with external render engines of course.