Brushes
Using graphs as modular, non-destructive pieces for world-creation.
Last updated
Was this helpful?
Using graphs as modular, non-destructive pieces for world-creation.
Last updated
Was this helpful?
This article assumes basic knowledge about .
Any Voxel Graph can run any nodes, which means there are no preset graph types. But the way graphs are used in practice often does end up following a few common patterns.
One of these patterns is the 'brush' pattern, where a graph is used on a moveable object that doesn't output anything into the world - it only writes data into a channel. Another graph then reads back that channel, and produces a visible output from it.
Examples of this (which can be found in the ) are:
A graph writes a sphere into a FoliageDensity channel. This channel is queried in a second graph, which outputs foliage, where it is used as a mask. Foliage now no longer generates where the first graph is placed in the world.
A graph writes a voxelized mesh into a Surface channel. This channel is queried in a second graph which has a Generate Marching Cube Surface node, rendering the surface into the world, including the changes made by the first graph.
By default when registering to a channel, the previous state of the channel is completely ignored. Because brushes are generally used on top of other terrain elements, that's inconvenient and should be accounted for. This can be done by combining the brush' surface with the existing state of the channel using a Query Channel.
It is usually desirable to combine the brush surface with the current state of the channel the brush is about to write into. The result of that combination can then be written into the channel. This prevents brushes completely overriding others that come before them (and therefore making those previous brushes useless).
Image
The combining of surfaces can be done with one of a handful of nodes, all of which also take a Smoothness input (this is usually ), allowing clean blending of multiple surfaces. The following functions exist:
Smooth Union
This node adds the two surfaces together.
Smooth Intersection
This node returns the area that overlaps between two surfaces. Somewhat counter-intuitively, an increase in smoothness will make the returned overlap smaller.
Smooth Subtraction
This node subtracts the "surface to subtract" from another. With this operation, order is incredibly important, as A-B is not the same as B-A.
Images
The Register to Channel node takes a bounds input. When nothing is plugged into this pin, the brush will be registered with infite bounds, in turn meaning that this graph will be run for every voxel in the world. This is incredibly wasteful, as voxels a kilometer away obviously do not need to be affected by a small brush. While this does not matter too much when only a single brush is used, the total world generation time will increase rapidly as the amount of brushes grows, as each will affect every voxel in the world.
This can be addressed by assigning a sensible value to the Bounds pin. When using a node that creates a surface, this surface generally includes correct bounds, so a Get Surface Bounds node can be used on the surface pin, and this can be plugged into the channel's bounds pin.
When a surface is generated manually, for instance using a Make Volumetric Surface node, the math for the bounds will need to be done manually as well.
With the brush' bounds configured properly, the brush will only affect the world's generation within those bounds, making world generation significantly cheaper.
If you increase your smoothness a lot, you might start to notice holes in the voxel mesh:
This is because as the smoothness increases, the area affected by the brush increases as well, but the voxelized mesh bounds don't increase accordingly.
Plugging the same value as was used on the Smooth Union into the Channel's Smoothness pin will allow the plugin to account for this increase in bounds.
With the smoothness properly accounted for in the channel registration, the artifacts should now be resolved.
If accounting for smoothness does not fix holes in the surface, another likely culprit is an inconsistent distance field, leading to falsely failed distance checks. Read more about this issue and its workarounds here: Distance Fields & Distance Checks
The Register to Channel node has a Priority pin. This is used to sort brushes.
The brush with the highest priority will be queried first. If that brush calls Query Channel, the brush with the second highest priority will then be queried, and so on.
Brush priority can be useful to tune when dealing with smoothness: usually, you want to apply Smoothness after everything else has been computed. If a brush does not seem to be properly affected by its smoothness setting, the solution is often to adjust its priority.
In order to always have different priorities & make the sorting deterministic, brushes have an internal priority computed as follows:
Compare the Register to Channel Priority
If equal, fall back to a priority based on the path of the graph asset the node is in
If equal, fall back to a priority based on the path of the brush actor
If equal, fall back to a priority based on the node id hash
This is not usually very important, but it can be a source of problems if brushes are spawned at runtime. If that is the case, make sure all brush actor names are synchronized between clients & servers, and that the names of these actors are saved and loaded properly. Failure to do so will likely result in brushes being having inconsistent effects across game instances.
When you have a lot of parameters, sometimes you want to create templates for these parameters - just like material instances in the engine.
In order to do this, find the graph this instance should be based on, right-click it and select "Create Instance". This will create a Graph Instance object which inherits its logic from the parent, but allows you to override just the parameters.
By default, graphs don't generate any sort of collision, making them hard to select in the viewport. For brushes, a preview mesh can be generated using the Create Marching Cube Preview Mesh, which can then be used as collider so it can be selected. Additionally, this will help show which brushes are selected and what shapes they have.
By default, the preview mesh is a perfect match of the rendered mesh. This is not always desirable as it leads to Z-fighting and overlapping meshes.
This can be accounted for by using the Grow node on the surface plugged into the preview mesh node.
The Preview tab of a graph asset uses the same preview mesh and material as the editor viewport.
The Is Preview Scene node tells a graph whether it is being shown in the editor viewport, or in the graph editor scene. Using it, you can configure your graph to run different logic, or use a different material, between these two situations.
Be careful when controlling bounds manually, or using high smoothness. If you set bounds that are too small, or don't account for smoothness, you might start to get in the voxel mesh.
