Aestus

Progress Report

Nick Toothman -

Code status

I've migrated Sketch away from Hg to a new git repository on Bitbucket. The URL is here, although it's not a public repo. The main reason for the change is that the old codebase, along with hg, were starting to smell. This prompted a refactoring in the project structure to make distributing built versions easier. I also upgraded the project to Visual Studio 2015 and expect to incorporate CUDA 8.0 when it's released in August (finally!). Meanwhile, I've started adding OpenVR support to the project to be used with the HTC Vive.

The platform changes and upgrades warranted a fresh name for the project, and so I chose Aestus.

Skinning status

I've been using as-rigid-as-possible as a skinning post-processing step. So I'll skin the mesh on the GPU first, then use that as input to the ARAP linear system solver. The positions-based ARAP does not seem to work properly unless you compute the mesh's center of mass first, then perform the computations for every vertex relative to the CoM. Radial scale ARAP does not have this problem as much; instead of directly solving for mesh positions, it solves for the vector between a vertex position and its attachment point on the skeleton.

Sparse linear system solving can be done quite quickly with the right libraries, but I'm especially interested in whether it's viable to perform on the GPU. I believe CUDA 7.5 has runtimes for solving certain sparse linear systems, but I'm unsure how they perform in practice. My last attempts at using them to solve for mesh deformations were unsuccessful and resulted in garbage data. That could be my fault (improper choice of solver, data not formatted properly, etc.), but I followed along with the CUDA examples and the cuSolverSP intro. Hoping I have better luck with 8.0.

A simpler idea I've yet to try is to use a compute shader that performs Laplacian smoothing on the scale directions. So for every vertex scale direction $s_i$, compute

$$
\begin{equation}
s_i' = \frac{1}{N_i} \sum_{N_i} s_j ,
\end{equation}
\label{eq:laplaciansmooth}
$$

Repeat that until some threshold of convergence is met and see how it looks.

Besides that, there's the problem of how to address self-intersection

QE prep

The unifying theme of my dissertation is to make skeleton-based character animation work seamlessly with surface-based mesh deformation. In order to present this for my qualifying exams, I will discuss the following topics

  • Skinning techniques
  • Classic (LBS, DQS) vs. Modern (STB, implicit skinning)
  • Surface deformation techniques
  • Laplacian surface editing, linear subspaces, as-rigid-as-possible
  • Incremental rotations as a skinning concept
  • Shared deformation for skeleton and surface edits
  • Applying both at once and making it look good
  • Human-computer interaction
  • Authoring deformations
  • Framework for exploration and creativity
    • Lessons from Sandbox and Play the Knave
  • Implementation techniques
  • Leveraging GPU compute capabilities
  • Extending the graphics pipeline
  • Handling collision detection
  • Solving for deformations

SIGGRAPH Prep

Lots I want to have done in time for SIGGRAPH! So begins the list:

  • Have a working system for applying surface deformations to any mesh for any skinning technique (lbs, dqs, STB). Currently this works best with incremental rotation skinning because it's a fundamental part of the process. We can/should incorporate the same technique with other methods. That could either demonstrate where they are lacking or reveal that our surface editing technique is quite extensible to existing systems.
  • Fix (what I think are) the implementation bugs in ARAP as mentioned earlier.
  • Polish rendering scripts using Lance and Kalin's code
  • Compare options for post-processing:
  • ARAP (positions vs. direction vectors)
  • Laplacian smoothing
  • Performed with or without weighted handle vertices
  • If necessary or time permitting:
  • Accelerated solving with the previous mesh's input.
  • VR tools for animation