RSS< Twitter< etc

<< Back To XMesh Index

XMesh Saver MX - Caching Frost Particle Mesher

 

Introduction

The Thinkbox FROST Particle Mesher can be used to convert large numbers of particles into a mesh and is very fast considering the amount of data it inputs and outputs. But once the tweaking of the parameters has been finished, it is a good idea to cache the resulting geometry to disk for even faster direct access.

In the following demonstation, we will look at the ability of XMesh MX to work with FROST data and capture both the viewport and the render meshes as a file sequence, store and reproduce the Vertex Color channel, and generate correct motion blur from the FROST geometry.

The Test Setup

In this demonstration, we will use a pre-saved PRT sequence which was generated using Exotic Matter's NAIAD fluid simulation software (data courtesy to Igor Zanic), but the general approach for using FROST and XMesh together applies to any supported 3ds Max particle system including Particle Flow and Thinking Particles.

The PRT sequence was loaded, scaled and rotated using a Krakatoa PRT Loader to match the 3ds Max coordinate system and units. The NAIAD data was saved in Meters and in a Y-up coordinate system. By rotating the PRT Loader at 90 degrees about the X axis and scaling it to 3937.01%, we convert it to Z-up space and Inches.

A Magma Modifier on top of the PRT Loader reads the Velocity channel of the PRT sequence, gets the Magnitude, scales it down to 0.15 and uses a Power of 2.0 to tweak the velocity curve. Then a Blend operator using the Velocity Magnitude as 3rd input blends a Blue and a White color to make fast particles white and slow ones blue.

Then a FROST object is used to convert the particles to a mesh using the Zhu/Bridson method. The Meshing is set to 2.0 in Renderer and 1.0 in the Viewports for performance reasons - the rendering settings will produce several million faces from the millions of particles passed as input.

The Particle Radius can be tweaked to match the particle density, in this case a value of 4.0 with a Variation of 40% by Particle ID is used. This ensures that each particle with a unique ID will always have the same size variation and won't flicker.

We can disable the viewport display of the PRT Loader to speed things up.

In order to see the Color generated by the Magma Modifier, we can enable the Vertex Color display of the FROST object under Object Properties, and enable the [Shaded] option to also calculate lighting in the viewports:

Meshing one frame with the viewport settings took 12.593 seconds on a Quad core i7 with HT enabled. The resulting mesh from 5.7 million particles on frame 100 has 364,916 faces.

Switching the viewport Mesh Resolution to 2.0 to match the Render Resolution produces a higher quality mesh with 1,540,660 faces in 22.58 seconds:

For the caching, we will use the Viewport Meshing of 1.0 and Render Meshing of 2.0 though.

Saving To XMesh

Using the XMesh Saver MX User Interface, we can now cache the resulting viewport and render meshes to disk.

In the sources drop-down list, we select Frost Objects Only and move the Frost object from the top into the bottom list as Object To Save.

We specify the Base Path to save next to the PRT sequence of the NAIAD simulation.

We disable the saving of a Material Library since we don't have a Material assigned to the FROST object and we don't care about its wireframe color at this point.

We enable >Save Proxy Sequence - this will save the viewport mesh of the FROST object to a separate XMesh sequence for viewport display, and the render-time mesh for the FROST object as the main XMesh sequence for rendering. FROST objects will never use the Optimization options, but still it is a good idea to explicitly disable that using DON'T Optimize Proxy Meshes.

Note that the last frame 189 of the Naiad simultion had 10 million particles and took 50 seconds to mesh at Render Meshing Resolution of 2.0, producing 2 million faces and one million vertices.

Obviously, caching both the viewport and the render mesh of this particular FROST object would take a significant amount of time.

Indeed, on the i7 machine mentioned above, it took 42 minutes to produce the Proxy XMesh sequence and 98 minutes for the Render sequence. Since the calculation of a Velocity channel requires the FROST to be built twice for each frame to determine the motion of the vertices, this time is about twice what would be expected from just measuring the single frame meshing. Still, the average per frame time for the Proxy was 13.2 seconds (42*60/190), and for the rendering sequence it was 30.94 seconds per frame on the average.

In this situation, processing the sequence in parallel on multiple machines using Thinkbox' Deadline would be a really good idea.

The Render sequence required 3.99 GB of hard disk space, the Proxy sequence took 996 GB.

Playing Back The XMesh Sequence

Once both the Proxy and the Render sequences have been saved to disk, an XMesh Loader is created with both sequences plugged into its two source fields:

Now, instead of waiting several seconds for each frame to build a new FROST mesh, we can simply scrub at a speed of several Frames Per Second - the Viewport shows the Proxy sequence, and the Renderer would get the higher resolution one.

If the interaction is too slow, the XMesh Loader provides an option to show only the vertices. This requires only one binary data file to be loaded - the vertex list - and is of course significantly faster to display:

Interactive Performance 

The following screen recording shows the performance of 3ds Max showing the millions of particles in the PRT Loader, their dynamic meshing using FROST, and the performance increase when using the cached XMesh sequence in the XMesh Loader:

Retiming The XMesh Cache

The PRT sequence saved from NAIAD has a valid Velocity channel, as witnessed by the blue/white shading of the particles that is reflected by the Vertex Colors of both the FROST object and its XMesh cache.

This Velocity data is used by FROST to produce per-vertex Velocity. The FROST was set to "Frame Velocity Offset" mode. In this mode, a mesh is calculated on the full frame loaded from the PRT file, then the topology is kept consistent and the vertices are moved around according to the velocity of the particles influencing them. As result, FROST can successfully pass its data to renderers like V-Ray that expect unchanging topology within the motion blur interval.

When XMesh Saver caches a FROST object with these settings, it acquires exactly these vertex velocities by building the FROST mesh twice - once on the full frame to save and once half a frame later. The XMesh Loader also provides similar interpolation settings - default is also "Frame Velocity Offset" - and the vertices of the mesh are moved along the velocities when sub-sampling or retiming is requested.

The following video shows the sub-frame mesh interplation based on the Frame Vertex Positions and Velocities when scrubbing at TICKS level, and the retiming of the cache by slowing down the animation from frame 60 to 90 to play one or five frames within 30 frames (slowing down 30 and 6 times, respectively):

 

Copying Velocity Via Mapping Channels

As demonstrated in a previous Frost/Krakatoa tutorial, one way to increase the particle count of an existing simulation way beyond the original PRT file's count is to use a PRT Volume to fill a FROST volume. The FROST object provides an option to copy the Velocity channel of the particles into a Mapping Channel of the FROST mesh. Then this data is automatically propagated to the PRT Volume's Mapping Channel.

The XMesh Loader provides the exactly same option to copy Velocity To Map Channel, thus allowing the same workflow with cached FROST (or other objects') meshes.

For example, checking the option and setting the Map Channel to 2 will generate a Map Channel 2 with content representing the velocities of the XMesh vertices.

Creating a PRT Volume from the XMesh produces particles inside the volume that acquire both the Color (Mapping Channel 0) and the Velocity (Mapping Channel 2).

Adding a Magma modifier to the PRT Volume and setting it to output the Mapping Channel 2 into the Velocity channel transports the velocity of the original NAIAD simulation via the PRT sequence through the FROST mesh to the XMesh Loader and from there to the PRT Volume.

The same Mapping Channel 2 value divided by the Frame Rate and copied into the PRTViewportVector channel provides viewport display of the velocity vectors, scaled to frame length.

In the following example, the viewport uses a spacing of 3.0, producing only around 1 million particles (the original simulation contained 5.7 million on the same Frame 100). 

 

But rendering the PRT Volume with the Render Spacing value of 1.0 produces 27.9 million particles, or about 5 times more than the original simulation! Adding more particles per region can produce arbitrary high particle counts for any image output resolution.