Your Computer Have Limits

It's important to have appropriate expectations over what your software and computer are capable of!

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 expectation if this is the case! Performances are heavily dependent on your utilization and on the software & hardware you are using.

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 /inconvenient workflow.

Blender (& its 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.

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 is using game-engine-like optimization tricks!

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.

The best and 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.

Identifying Slowdowns

When starting in 3D it can be tricky to identify slowdowns that may occur while working, as we will learn below, the Scatter5 plugin proposes powerful features to avoid them, however, it is still important to identify the problem in order to solve it! Here are some walls you may face when working on a heavy scene..

Rasterization Slowdowns

The viewports (more precisely "solid"/ "wireframe"/ "material"/ "overlay" options) of blender is 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 CyclesX 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 cg geek demo) however, ray tracers are not a viable solution for working in the viewport yet (except in ClarisseIFX for example) 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 ). CyclesX ray-traced rendered view will just do fine!

Pro-Tip: Be aware that enabling the viewport overlay effect has an impact on the performance as it is doing rasterization in the background. Also, note that the viewport shadows or ambient occlusion options make blender considerably slower!

Scatter-Engine Slowdowns


As you may know already, Scatter5 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 a slider 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.


Pro-Tip: Note that using a dedicated empty emitter will make things faster to compute on big scenes for blender when tweaking slider.

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 Scatter5.

High Poly Surfaces Slowdowns

Scatter is quite forgiving regarding your chosen surfaces 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.

Hide From Viewport

What you see, is not what you get

Hide What You do not Use

When working on a large sceneries with a lot of scatter-systems, it is a good practice to hide what you do not need to visualize in real time by turning off the viewport display (screen icon). The system will always appear on the final render if the render toggle is enabled.

Reminder:
There's a handy shortcut to quickly isolate a scatter-layer: holding ALT when clicking in the system list.

Consider Security Warnings

If you ever recieved a message warning you that you have created millions of instances and that Scatter5 automatically hid the scatter-system for your own safety, perhaps it's best to be careful! Accidentally un-hiding such a system could freeze your computer! Best would be to enable the max amount feature just in case.

Preview Area

When working on large environments, it will be hard to visualize all the scatter layers simultaneously on the full surface of the terrain.

We can use the preview area feature to sample some selected faces.
the final render will not be affected, except if you want it to (see visibility features below).

Maximal Amount

Since Scatter 5.3 we introduced a new "Max Amount" feature directly integrated per scatter-system(s). If you'd like to have an extra layer of real-time security while working on larger scenes, please enable this feature in order to guarantee that your instance count will never exceed the chosen threshold.

Density Reduction

In the visibility category, a removal rate slider is available to reduce what's visible within the viewport. The final render will not be affected, except if you want it to (see visibility features below).

Camera Optimization

Frustum Culling

The frustum culling feature will remove instances not contained within the given FOV range. The FOV will be calculated automatically if the "per camera setting" toggle is activated.

Distance Culling

This optimization feature will create a culling transition from the given distance range with your active camera.

Reminder:
These features are to be activated per scatter-system, this grants you the ability to selectively choose the level of optimization. Remember, If you'd like to batch-apply settings on all the selected scatter-systems, the ALT-for-batch behavior is here for you.

Camera Update Dependencies

One of the inconveniences of the camera clipping/culling feature is the recalculation of the scattered point for each camera move. This recalculation might become sluggish in some scenes. If you start hitting such a slowdown, you can change the camera update behavior.

In the example hereby, the update method is set on 'Halt' mode, the update will only trigger when the camera has stopped moving.

Occlusion Culling

The occlusion culling option let you hide points located in areas unseen by the camera. Optionally choose a collection of occluding objects.

Display As

Disguised your instances

The "Display As" feature will let you represent your high poly instance with a more efficient drawing solution, there are multiple methods available at your disposal, and some are more efficient than others:

  • Bounding Box: Will display the solid bounding box of your instances.

  • Convex Hull: Will display the convex-hull geometry of your instances. Be aware that this option is heavier to calculate!

  • Placeholder: Replace your instances with one object available in a predefined list. Note that some placeholders in this list are handy for visualizing rotation and alignment settings.

  • Custom Placeholder: Replace your instances with the given object.

  • Single Point: Replace your instances with a single point at its origin. Points are extremely fast to rasterize, blender can display millions of them with no slowdown in the viewport.

  • Point-Cloud: Replace your instances with a generated group of points, ideal to have a good representation of the final render-shape. this display method is quite promising, however, T93245 & T92963 are important issues that need to be solved, right now this display option is not as fast as it should be.

Real Geometry while Rendering

This feature visibility is tweakable, it's possible to define if the display effect takes place only within the viewport, turns off during render, or rendered view. By default, it will turn off during any rendering state.

Reveal Near Camera

The reveal near camera option will reveal the real geometry of the instance when the camera is closeby. Using this feature in combination with point display and camera clipping/culling is one of the best real-time viewport optimization tricks you can get in Scatter5!

Moving the camera will trigger a recalculation of the scattering, as explained above, update dependencies linked to camera can be tweaked.

Object Display Color Representation

Here's a tip! In the header popover menu of the display feature, click on "show systems colors" to have an accurate representation of your scatter-system assigned color within the viewport! This operator will simply put the shading on "solid", and set the shading color on "object".

Known Issue:
'points' drawing methods may produce unstable colors T93245

Inaccurate Render Color?

If your rendered object color is not the same once scattered, that's probably because your object (that you probably bought online?) is using the 'display color' property as a color influence in its materials shader, meaning that the display color is not used only for viewport display purpose but will also have an impact in the render. If you have this problem, simply change the display color in Scatter5 system list are.

Display As & Biomes

This feature can be encoded within a biome file. Thanks to this implementation, you can activate the display feature when scattering a biome, this option is located in the biome manager Header>Option menu.

Features Visibility

All optimization features presented above are active/inactive depending on your render state. It's possible to define when the effect takes place during the rendering process. Please enable the solid/rendered/render icon to change the visibility states.

Known Issue:
Unfortunately, having multiple 3D viewports in your scene is problematic for rendered view feature, it is impossible for us to enable a feature only for N viewport space.

Wireboxes Everywhere?

The bounding box display is a native per-object setting located in Object Properties > Viewport Display > Display As. Sometimes the object you are scattering may have the bounding-box display enabled, either because the scattered object has this setting active, or because an operator security feature is protecting you from scattering highpoly assets.

Reminder:
In the instance list, you have quick access to the object by clicking on the select icon, this button will select the item in your scene, then you will be able to change the option in the object property. However, be warned, it might be displayed as such for a reason!

Slider Reactivity

Tweaking sliders in blender can be slow, in that case, it is advised to manually input a number and press enter instead of doing mouse-sliding gestures.

In the extra panel, it is possible to tweak your settings update behavior, by default the blender will try to send update signals on each mouse move which can be slow. You can change this update behavior for our plugin settings.

Pro-Tip:
In order to fully benefit from these options, make sure that you are using a dedicated emitter-object.