利用者:Kevindietrich/OpenVDBParticleMesher

Particle Mesher Modifier

The current patch is available here: https://developer.blender.org/D1008.

Abstract

The Particle Mesher modifier generates a mesh from a given particle system. It is using OpenVDB to perform its various tasks.

Description

The Particle Mesher modifier will create a level set from the modified mesh's selected particle system. For each particle a sphere will be created and then unioned with the other generated spheres to create the surface of the level set.

The meshing operation is split into three phases:

• A conversion phase: the particles are used to create a level set.
• A filtering phase: various filters can be applied to alter the level set.
• A meshing phase: a mesh is created from the level set.

Although the Particle Mesher modifier is non-destructive for the particle system – one will still be able to use the particles for other purposes, the modified mesh will be replaced by the level set surface.

Implementation Details

To convert a particle system to an OpenVDB level set, we have to define a helper class (ParticleList) which implements the interface needed by VDB's many templated tools. The class itself contains a simple Particle struct with only three properties: position, radius and velocity. Each Blender particle will be converted to this representation which will then be put in an std::vector (also member of the ParticleList class).

Once converted to a level set, the artist will have the possibility to filter it using one of several level set filters (openvdb::tools::LevelSetFilter): Median, Laplacian, Gaussian, Offset (aka dilate/erode), Mean and Mean Curvature. In essence, these filters are similar in their use as your regular image filters. On Blender's side, they are defined as a simple doubly linked list, so one will have the possibility to add as many as they want.

After this, we are ready to extract a mesh from this level set. Optionally, we can use a separate mesh to define the area (or rather volume) of the level set to mesh (obviously, this mesh will have to be converted to a VDB level set first). Converting meshes to and from OpenVDB happens as follows:

OpenVDB doesn't really have a mesh primitive, rather, the tools(*) dealing with meshes either expects or outputs separate lists (std::vector) of vertexes and faces. In both cases, conversion from Blender's representation is very straightforward: vertexes are converted from float[3] to openvdb::Vec3s, whilst faces are converted from int[4] to openvdb::Vec4I, before being put in their respective std::vector. Et vice versa for converting back to Blender's representation. If triangles are present in the mesh to convert to a volume, they are treated as if they were quadrilaterals, with the fourth index being set to openvdb::INVALID_IDX; though, VDB will output triangles separately from the quadrilaterals (in case of adaptive meshing) in an std::vector of openvdb::Vec3I (that's just detail). Edges are to be interpolated on Blender's side from the vertexes and faces.

(*) for the time being, the used tools are openvdb::tools::VolumeToMesh and openvdb::tools::MeshToVolume

Modifier's Known Issues

As usual, software development does not come bug free:

• the masking scheme does not work as intended, this is mostly about getting world space/local space right on the OpenVDB side (not to mention voxel space...), and properly transforming object B local space to object A local space
• using masking with adaptive meshing gives bad artifacts
• all of the properties for the modifier are defined in the modifier system's DNA and RNA; there's a conflict between the modifiers' "type" (Array, Subsurface...) and the level set filters' "type". The only issue on this so far is that we can't automate some procedures like updating the name of a filter in the UI list based on its type as the RNA will try to get this information from the modifiers' type somehow. Ideally proper DNA/RNA for OpenVDB tools should be defined.
• the default size of the particles (0.05 Blender unit) is too small for the modifier to operate on and therefore we don't see anything in the viewport when first adding the modifier (though a message should appear in the console). Its default settings should be reconsidered. A workaround is to set the radius scale of the modifier to 2.5.

These issues are intended to be tackled once approval of the feature (in Blender's current paradigms) is received.