The design originated with the painting techniques of Seurat and Monet. Both paint using very small dots to take advantage of an effect called optical mixing. When you look at a distance the shapes appear to take on one color, but up close the small dots that compose the canvas become more individually separable. Their pieces have two completely different reads based on the distance at which you view them. I figured these varied dots could give us a watery and city vibe perfect for LA.

Achieving this look required a paint gun, so we ordered one. Paint guns are designed to spray smooth streams of air to create even coats of paint. The gun sips paint from a canister using a straw. Much like drinking from an empty juice box, if the straw takes in both air and paint, it’ll emit a choppy flow. The trick was to constantly adjust the angle of the gun to keep this effect going.

The paint needed some changes paint as well. To make my life simple, I used only blue and white paint as opposed to all three of the primary colors. Adding urethane thinned down the paint too, increasing the size of the splatter. By the time I had the right ratios, I ran out of uthreane, and had to resort to a poop mix of organic solvents - isopropyl alcohol, kerosene, acetone - to actually finish the car. This was a risky move as they evaporate much slower than urethane, but it turned out ok.

You can see the effect at play here. I painted with a thinner substrate on the lower layers and just kept the white and blue on the topmost layers thin.

I’m from Ohio and nothing reminds me of that fact like palm trees. They scream LA.

After the team saw them in a concept drawing, they encrouraged me in include them, so we sort of morphed the splatter ocean look into a starry night. The RW endplates, the side panels, and the nose cone were painted with the gun. The rest was with a plastic fork - literally cub scouts with sling shots. They distribute FAR less paint than the gun which, at times, feels like using flamethrower to light a candle. Below is the final iteration of the render done before painting (with some missing decals).

Instead of using vinyl, the black areas are bare carbon. Team areo works incredibly on not only the shaping of the parts for drag, downforce and so on, but also the quality of manufactured parts. In addition to the look being preferable it is a great way to show off their work.

The trick with the bare carbon “decals” this is that the positions have to be locked in before painting and they can’t be changed. I avoided using pure white for the sponsors because it is too strong and opted instead for a baby blue. The yellow is a summer lemon/mango color. On its own it is more Berkeley than UCLA, but because of is minimal usage it adds some much needed warm to the flood of blue.

We were also able to lock in a darker chassis color to basically get it out of the way (sorry Alex) and light blue suspension components to blend against the paint (sorry Parth).

Timeline

It took probably took a 8 multi hour days of work. I wish we kept better track but the guesstimate is 8 hours of work over 7 days. This includes the painting but also the sanding and cleaning and all of that. We started on the 23rd of May and crunched over the next 2.5 weeks. Not recommended. Had I been more forward with the design this probably could’ve been avoided a little bit, but we were able to paint in larger batches as more of areo came together (which save alotta time). Ideally it would be a 2/3 session deal, to paint each coat in one go (primer/base/clear) with 24hrs in between each.

Because our vinyl is quite thick, it basically needs to be recut by hand. This is an on par time commitment with the paint but many people can work on it. Kevin, Luke, and Matt were able to work on vinyl stuff a couple times on their own which was great. Next year I’m curious if different vinyl could help us in this regard.

I had a lot of support in making this. Thanks to the areo and the directors for being trusting and supportive and chassis and suspension for not making their parts pink. Special thanks to Luke, Matt, and Kevin for assisting with the design and manufacturing. This wouldn’t have been possible without all y’all.

Draftsmanship is classic. I previously thought that such effects would best be captured by screen-space image kernels and non-photorealistic shading. While effective, they fail to portray the precision I’m after. Having worked with a handful of CAD tools for robotics, I became curious if there was a better bridge between the visual language of engineering and the tools used for 3D content creation.

The trick is in the geometry.

Those who work with 3D content creation tools are generally familiar with meshes. They are the primary representation used throughout most media pipelines. Engineers, however, generally prefer a parametric representation called B-rep (boundary representation) as the canonical representation of a part. The unmistakable “CAD” look comes from this distinction. For each one of the faces, the boundary is rasterized in screen space as a black line with a constant width.

For engineering applications, these edges aren’t particularly important once the model is converted for simulation or manufacturing, so most tools don’t make much effort to preserve them. In the “high-end” of rendering for VFX and animation, parametric geometry has largely become a legacy feature, with meshes and curves being the dominant representations.

Luckily, B-rep to mesh is a fairly standard operation in engineering. The harder problem is everything around it. CAD models are hierarchical, heavily instanced, and often carry metadata that is useful long after the geometry itself has been converted. If only there were a widely accepted format designed to ferry all of this information into a modern 3D application…

Enter OpenUSD! It is a blah, blah. I don’t need to introduce the benefits of this format. In a CAD context however, the only player in town that works with these files natively is omniverse. It only works with a nvidia-ized system which is less than ideal, and it doesn’t mesh the wireframe or the sketches. I’ve also found that it is flakey and no super undebuggable.

Step To USD

You can view the code here. This is the first serious CLI I’ve written and been forced to use. The goals were as follows:

• Novel geometry. The tool had to embed wireframes (and sketches time permiting), so we can get the classy CAD look.
• Fast and robust. Car assemblies are large and full of warts, so iteration is important. Given the trouble that I had with Omniverse, the iteration loop would have to be tight such that problematic assemblies could be pointpointed quickly. Also, during the look development process, this proved handy for remeshing parts with new parameters.
• Per Prim Overrides The CLI itself is minimal. All of the “options” are applied per prim and reside in a usd schema.

The user will start by writing a usd stage that looks something like:

#usda 1.0
(
    defaultPrim = "WonderfulModel"
    metersPerUnit = 0.001
    upAxis = "Z"
)

def StepTessellationOptions "DefaultOptions" {
    double step:mesh:angularDeflection = 0.1
    double step:mesh:linearDeflection = 0.1
    # other options...
}

def StepContainer "WonderfulModel" {
    asset step:sourceAsset = @../step/model.STEP@
    def StepPrototypes "Prototypes" {
        rel step:defaultParams = </DefaultOptions>
    }
}

The user feeds a CAD file into the CLI, which traverses the stage to find the StepContainer. From there, the tool generates two main prims: {MODEL_PATH}/Assembly and {MODEL_PATH}/Prototypes (MODEL_PATH is /WonderfulModel in this case).

(cg) duck@capote mk11 % stepmesh -h
 stepmesh -- Meshes all StepContainer prims in a Usd scene
 Options: 
    -i, --input <path>               Path to the input Usd file. 
    -p, --prim  <sdfPath>            Only tessellate the prim...
    -q, --quiet                      Suppress all output.
    -v, --verbose                    Prints like everything.
    -h, --help                       Prints this message.

    usage: stepmesh -i <path> [options] 

/Assembly is essentially a shell hierarchy that maintains the heirarchical structure of how the engineers originally authored the model. Leaf Xforms author reference arcs (with instanceable = true) back to the corresponding prototypes. This keeps the USD representation (mostly) renderer friendly and performant by just having a single level instance (see AOUSD forum on hydra instance flattening).

/Prototypes contains a flat list of each unique prototype. Each prototype then contains a sub-prim for each geometry representation we generate: the mesh, wireframe, and any other derived geometry. At a high level, the geometry lives entirely under */Prototypes, while */Assembly only describes how those pieces are arranged.

The prototype generation is then broken up into independent jobs and fed through TBB. Special care is taken to avoid stage recomposition by batching the geometry output writes in huge SdfChangeBlocks. Alongside caching the parsed .step document, MK11 is meshed in right around 90 seconds.

(cg) duck@capote mk11-model % stepmesh -i model-v3.usda                  
Loading cached XBF from /home/duck/mk11/mk11-model/step/model-v3.xbf
Working OCC length unit: 0.001000 m
Assembly tree built: 8659 nodes
  Assemblies:          2127
  Leaves:              6532
  Unique definitions:  1717
Container prim path: /Mk11
[1717/1717] Writing prototypes  {LOD=low}...
[8659/8659] Writing Assembly...
[1717/1717] Writing prototypes  {LOD=high}...
[8659/8659] Writing Assembly...
[280/3434] Tessellating Geometry...
[ERROR] OCC exception on /Mk11/Prototypes/COMPOUND_1_step_1__98e6574f (def index 1075): Bnd_Box is void
[281/3434] Tessellating Geometry...
[ERROR] OCC exception on /Mk11/Prototypes/COMPOUND_1_step_1__98e6574f (def index 1075): Bnd_Box is void
[WARNING] ShapeFix_Shape for part /Mk11/Prototypes/HV11_PCB_04_Integration_V3_1__665858fc: operation timed out
[1347/3434] Tessellating Geometry...
[ERROR] OCC exception on /Mk11/Prototypes/Part5_AD11_FW_001_FW_TOP_ASSEMBLY_FDR_1__88817cd8 (def index 889): Bnd_Box is void
[1348/3434] Tessellating Geometry...
[ERROR] OCC exception on /Mk11/Prototypes/Part5_AD11_FW_001_FW_TOP_ASSEMBLY_FDR_1__88817cd8 (def index 889): Bnd_Box is void
[3434/3434] Writing geometry...
Total Time Taken: 82.046385 seconds

Engineers work like artists from the standpoint of the cleanliness of what they make, so error messages like these are really important. Mk11 had 1717 prototypes in total, all of which had to land in the final model. In one instance, the HV panel, a particularly feature-rich assembly, was resolving as one solid in the STEP document and proving to be troublesome. When I opened the stage, the car took 8 seconds to open. Too many prims? As it turns out, every edge on every surface-mounted electrical component was generating a curve prim with two vertices each, resulting in 200-ish thousand sub-prims for the prototype! Upon finding this out, I added an option to coalesce the curves of a given solid into one prim. After much trial and error, I was tremendously excited to see Mk10 in usdview!

But I had yet to sucessfully shove the car in a production path tracer. When I attempted RenderMan XPU, the generated curves didn’t fit within the new uint16 max vertex limit that RenderMan now expects. I had to change the coalescing to shard up to a user defined limit and alas, the car was rendering.

What is up with those lines? Well, initially they appear to asymptotically explode to infinity, so maybe there was a divide-by-zero somewhere? No. The model in Fusion 360 shows the same thing, so this was firmly a SolidWorks export problem. Okay, I should mention something. The tool takes in STEP files, but those aren’t modeled directly by the engineers. They use SolidWorks, which has its own format. I would’ve built the tool around the respresentation directly, but the provided C++ API is closed source and only works on DOS which makes it weird. Since the curves can be optionally split out into multiple prims, I deactivated the problematic curves one by one.

Future Directions

“There is always one more thing to do.”

Top of mind is a better meshing algorithm. Right now the alrogihm used is the default one included with opencascade. In addition to being slow the topology is poor. An alternate meshing scheme could go a long way in reducing potential rendering artifacts and triangle counts. Instant meshes or quadriflow would be a great starting point and are both open source. There is potentially a path towards a ‘BRep guided’ solution where the the smoothness energy and tangent fields are guided by sampling BRep topology instead of relying exclusively on one extracted from the mesh.

There are some others but that is the big one. Stay tuned for part two!

As the saying goes, a picture is worth a thousand words. On occasion, I’ll see a great data visualization that just blows me away. At the surface, the data is just reshaped to be useful, but often times a story is told that no one expected.

At times, modern web interfaces are kinda drab because they feel like databases. Not much in the design seperates the UI from the data layout. Espcially when it comes to picking films, there have been too many instances of me just sort of scrolling. “Thank you, next” as Ariana Grande might say.

I decided to to turn this into a realtime rendering problem. There are 65,000 ish films in the kaggle dataset, and I’d like to interactively render all of them in a force directed-graph. The goal is to make exploring the movies like wandering through a map.

But What is a Force Directed Graph

They’re very popular, I’ll have you know.

Basically, it is a particle simulation. Every particle is a node. The nodes repel like electrons (all to all). Linked nodes are treated as springs and attract each other. This is a textbook example of an $ O(N^2) $ problem commonly used in computer science school. There is a high degree of implicit parallelism for both repulsion and attraction, but their differences dictate seperate treatment.

Current Performance Optimizations

Just to get a felling of cost, with an $ O(N^2) $ algorithm disappear 65,000 bodies each computing pairwise forces against each other is billions of interactions each with thousands of instructions.

Barnes Hunt for Replusion

The repulsive force of one node is a sum of its repulsion against all other nodes. Barnes & Hunt propsed using a quadtree to compute forces on collections of neighboring particles rather than every one individually. The technique is very popular and relatively straightforward to impliment.

Given the goal of having it be realtime, it has to run on the gpu. One of the bains of gpu programming is branchy and recusive code. Modern gpus have a hard accelerated means of tree construction and traversal. Though these are for BVHs and ray tracing, recent research as explored their application in particle simulation. I may impliment this at a future date but for now I’m opting for a gpu implimentation of the original algorithm with a quadtree.

Brute Force for Attraction

For attractive forces, things get a little tricky. Unlike the all to all nature of replusion, attractive forces are inheritly sparse and irregular. For simplicity sake, I’ve opted to basically

Right now I’ve sped up vector operations using Swift’s built in SIMD api. Without knowing the knitty gritties of the computer stack, I’m fairly confident in saying that it is inefficient.

The more interesting optimizations come from thinking less like a programmer and more like the hardware.

A SIMD-Centric Design

Modern GPUs don’t really execute one thread at a time. They execute groups of threads together in lockstep. On Apple Silicon GPUs that group consists of 32 lanes, called a SIMD-group (a warp on Nvidia). Normally, hard coding constants is considered bad practice. This is one of the few places where I think it’s justified. Instead of pretending each thread is an independent worker, I structured much of both the simulation and rendering around these groups.

For the particle simulation, this mostly shows up in reductions and broadcasts. Computing the bounding box, for example, doesn’t have every thread writing into shared memory. Each lane computes a local minimum and maximum before the entire SIMD-group reduces those values using simd_min() and simd_max(). Only lane zero performs the final write back to memory.

topLeftX = simd_min(topLeftX);
topLeftY = simd_max(topLeftY);
bottomRightX = simd_max(bottomRightX);
bottomRightY = simd_min(bottomRightY);

if (simd_lane_id == 0) {
    topLeft.data[0].x = -0.99f;
    topLeft.data[0].y = 0.99f;
    bottomRight.data[0].x = 0.99f;
    bottomRight.data[0].y = -0.99f;
}

The same pattern appears when computing the center of mass for each Barnes-Hut node. Every lane accumulates mass for a subset of particles, then the SIMD-group combines the partial sums before a single lane writes the result back to memory.

M = simd_sum(M);
R.x = simd_sum(R.x);
R.y = simd_sum(R.y);

if (simd_lane_id == 0 && M > 0.0f) {
    R /= M;
    totalMass.data[nodeIndex] = M;
    centerOfMass.data[nodeIndex] = R;
}

The rendering pipeline leans even harder into this idea.

Instead of asking “How does this edge generate its geometry?” it’s better to ask “How do 32 edges generate their geometry together?”

I wanted the graph to have a neuron-like appearance. Every edge has to blend smoothly into the previous and next edge around a node, so each thread needs information about its neighbors. A traditional vertex shader is a poor fit for this problem because every vertex is processed independently. Recovering neighboring information would require additional memory reads, often loading the same data multiple times.

Object and mesh shaders offer a much more data-centric programming model. Rather than treating vertices as the fundamental unit of work, an entire threadgroup cooperates to generate a small piece of the graph. Each thread is responsible for constructing the geometry for a single half-edge. Interestingly the threadgroup is responsible for lanuching the mesh shader kernel with some magic handled by the scheduler.

[[object]] void objectShader( 
  constant Buffer& terminations [[buffer(xxx)]], 
  ... 
  object_data Payload& payload [[payload]],
  mesh_grid_properties meshGridProperties, 
  ... 
  ushort tid [[thread_index_in_threadgroup]]) 
{
  compute_neuron_verticies(data, buffers...);
  initialize(&payload, data);

  // Dispatch logic
  // Number of intermediate sample points on the bezier curve 
  // (results in numCurveLines + 1 line segments for the curve)
  // Max value depends on mesh limits: must satisfy 
  // threads_per_threadgroup * (numCurveLines + 2) <= 256
  // With 32 threads: max numCurveLines = floor(256/32) - 6 = 8

  constexpr int lod = 6; // Should be based on zoom
  if (tid != 0) return;

  // Launches more threadgroups dynamcially based on the lod
  // More threadgroups, more triangles, more resolution!
  payload.numEdges = batchCount;
  payload.lod = lod;
  meshGridProperties.set_threadgroups_per_grid(uint3(lod, 1, 1)); 
}

Before rendering, a compute pass sorts the half-edges by their source node - two buffers each representing the source and target node.

• The source node buffer is grouped by index: A,A,A,A,B,C,C,C,C
• The target nodes are radix sorted by angle to go clockwise.

This means neighboring threads usually process neighboring edges in memory. The result is much better cache locality and, more importantly, it creates opportunities for threads to cooperate directly. Is there a better criterion for sorting? Maybe.

Each lane computes the geometry for its edge—its midpoint, tangent, and perpendicular offset. Instead of loading the previous or next edge from device memory, those values are exchanged directly between neighboring lanes using SIMD shuffle instructions (hence the angle sort pass). The data never leaves the SIMD-group and syronization primitives are avoided outright.

struct Payload {
    float2 origin[32];
    
    float2 prevIntersection[32];
    float2 nextIntersection[32];
    
    float2 prevMidpoint[32];
    float2 midpoint[32];
    float2 nextMidpoint[32];
    
    float2 prevJoint[32];
    float2 leftJoint[32];
    
    float2 rightJoint[32];
    float2 nextJoint[32];
    
    uint gid[32];
    uint numEdges;
    uint lod;
};

float2 prevMidpoint = simd_shuffle_up(midpoint, 1);
float2 nextMidpoint = simd_shuffle_down(midpoint, 1);

float2 prevJoint = simd_shuffle_up(joint, 1);
float2 nextJoint = simd_shuffle_down(joint, 1);

Of course, this only works while neighboring edges happen to live inside the same SIMD-group. Nodes with a very large degree naturally span multiple groups, while nodes with only a handful of edges leave unused lanes. Whenever a SIMD-group crosses one of these boundaries, the resultant seam demands that the missing neighbor be pulled from memory. Fortunately, as the number of nodes being rendered increases so does the coherency and ulitization.

What’s Next?

At the moment, the priority is getting everything running smoothly. I’ve heard that premature optimization is a dangerous game, and maybe I’ve focused too much effort at this stage.

With the particle simulation and object shaders starting to take shape, the next step is to take on the later stages of the rendering pipeline.

Writing is annoying enough already, so things on the backend shouldn’t make it more difficult. Jekyll seems reasonablly popular, so I using that. It allows me to pipe out some markdown and then have it magically become a webpage in a fashion of my choosing. Instead of using a theme I opted to hack together some html and css with this theme as a starting point. A lot of the high tech and animation jazz was removed in favor of a clean sheet of paper vibe. Hopefully it ages well.

Some rendering tests…

Code

#include <iostream>

int main(void) {
    std::cout << "Uhhh..." << std::endl;
}

import os

if __name__ == "__main__":
    print("Uhhh...")

#usda 1.0

def Sphere "Uhhh" {
    double radius = 1
}

Math

Some tests using MathJax.

Inline example: the slope of a line is $m = \frac{\Delta y}{\Delta x}$.

Inline: the derivative of $x^3$ is $\frac{d}{dx}(x^3)=3x^2$.

Inline: the integral $\int_0^1 x\,dx=\frac12$ gives the area under the line from 0 to 1.

Inline: at $x=2$, the slope of $f(x)=x^2$ is $f’(2)=4$.

Table

Chart

A chart using Chart.js.