wyegelwel / snow

snow

Take a look at the project site: http://wyegelwel.github.io/snow

Project dependencies:

• Cuda (at least compute capacity 2.1)
• glm
• OpenGL (probably works if cuda does...)
• GLEW
• QtCreator

To build the project, open project/snow.pro in QtCreator and then look at the file. You will likely need to change the path of a few of the dependencies. Then run build. If all goes well, you should be able to run.

Take a look at snow_math.pdf and snow_implicit_math.pdf for a sense of the implementation.

We implemented some features that may be of interest to people not interested in snow. These include:

• A 3x3 svd solver for cuda (device) which as been snow tested, you can checkout the standalone implementation at: https://github.com/ericjang/svd3
• A vec3 and mat3 class with most features you would expect

snow's Issues

Missing collider .obj files

Hey there,

I found this implementation of the Disney paper on the internet and wanted to take a look. :) I've got it to build under Windows and VS2013 (see my fork), but there seems to be a data subdirectory that's missing from the repo. There are two hardcoded paths:

  D:\projects\snow\project\scene\scenecollider.cpp(86):        OBJParser::load( PROJECT_PATH "/data/models/sphereCol.obj", colliderMeshes );
  D:\projects\snow\project\scene\scenecollider.cpp(89):        OBJParser::load( PROJECT_PATH "/data/models/plane.obj", colliderMeshes );

These files can't be big, so it'd be cool if you could upload them. That is, if you still have them – I know what it's like with these university projects. ;)

Regards,

Leszek

Realtime woes

So up until now I've been naively thinking that we would require 24 updates per second for the simulation, i.e. packing each iteration into 41 ms.

That was silly of me - one second of simulated snow is actually 10,000 FPS (for dt ~ 10^-5 explicit integration). Even with semi-implicit integration (dt ~ .5 * 10^-3) that means we'd have to pack all our computation into half a msec (2000 FPS).

Granted, we don't have to draw on every iteration but I remember running the expanding-contracting teapot point cloud and the FPS fluctuated from 30-60 during interaction.

will this be a problem?

exporting: conventions for scenenodes and renderables

Hi all,

couple ideas :

• The ImplicitColliders currently have their own center member variable, because we agreed on having them be axis-aligned. When interacting with the collider in the modeler interface or reading/exporting, extra code would have to be written to deal with the collider's special center attribute and push it onto CTM, etc. I propose manipulating the CTM of the collider and at the start of simulation, simply copy over the d,h,l terms of the CTM as the center when copying to the GPU. Not sure if Wil already thought of this but I thought I'd mention it.
• In our current implementation, the distinction between SceneNodes`` andRenderables``` get's a little fuzzy when it comes to which class "owns" an OBJ file. With colliders, it is possible to have a one-to-one mapping between renderables and obj files (i.e. a sceneNode containing multiple ImplicitColliders as renderables, each with it's own obj). However, with snow containers, the relationship between renderables to obj files is many-to-one (obj can contain multiple meshes). When exporting, it get's complicated having to export from objs associated with SceneNodes or objs associated with Renderables. My proposed solution is that each sceneNode is associated with exactly one obj filename (which makes the offline rendering pipeline easier to deal with).

The practical consideration is this: only add one collider per sceneNode! And each sceneNode should specify an OBJ file path, since we only have colliders and snow containers, and both of them are drawn with OBJs.

It's pretty easy for me to implement this, but I'll put it in place after the delicate pipeline is mostly done. Let me know if there are any objections!

:)

Some Collider-Sim bugginess

I've tested the collider centers and parameters pretty thoroughly and they look like I expect them to be. For instance, I have a sphere collider that should be at center (0,0,0) and has a radius .05, which it looks like it does. However, during the particles seem to collide with it a little too early. Here's a picture.

I'll keep looking into it, just thought I'd bring this up now though.

No such file or directory: snow_cuda.o etc.

When I build snow.pro with Qt Creator 4.2.0 on OSX 10.11.6, I got

no such file or directory: snow_cuda.o
no such file or directory: mesh_cuda.o
no such file or directory: simulation_cuda.o
no such file or directory: cr_test_cuda.o
no such file or directory: mem_tests_cuda.o

What should I do?

Code Backup

Just now I had to do some scary filter-branch --force stuff to get rid of an executable that ended up in the git tree (not sure how it got there, it was probably me).

That made me think long and hard about my life choices and I ended up making a copy of the latest compiling-and-working code as spike suggested.

Just mentioning this in case something worse happens in the near future.

Added symbolic links to contrib executables into /contrib/bin

Turns out the contrib-link util requires absolute paths. After I learned this today I went town wtih this and added the following commands are now available in /contrib/bin so you should be able to launch these from command line without setting paths etc.

CUDA-related
bin2c
cuda-gdb
cuda-memchcek
cudafe
cudafe++
cuobjdump
fatbin
fatbinary
filehash
nsight
nvcc
nvlink
nvprof
nvvp
ptax

Mitsuba-related
mitsuba
mtsgui
mtssrv
mtsutil

exrtools
all the exrtools are installed (exrtopng being the useful one here)

testing workflow & main.cpp

this might be a non-issue, but better safe than sorry to mention it. Right now I'm borrowing Tim's Test.cpp class to run my tests without the GUI.

However it involves modifying 1 line of the main.cpp file at a time to call the appropriate function (runTimTests(), runEricTests(), etc.), and if main.cpp is modified, it might disrupt other's workflows. I've modified it slightly so the executable's "-test" flag also takes in the name of the person to run tests for.

i.e. to run Tests::runTimTests(), pass the following arguments into the executable:
"-test tim"

not modifying main.cpp as much as possible will prevent small merge errors from slipping under our noses.

I'll close this issue tomorrow once everyone has had a look. If there is a cleaner way to do all this, let me know. I was thinking about using different main_user.cpp files (build configurations), but that's messy because it involves the .pro file.

Cuda supports function pointers

Just a heads up, Cuda supports function pointers in 2.x architectures as of Cuda 3.2. Thought you might like to know. Here is a nice forum post that explains how to use them:
https://devtalk.nvidia.com/default/topic/457094/how-can-i-use-device-function-%20pointer-in-cuda-/

NVIDIA Driver Update

Eric and I were dismayed to find our program crashing on startup during OpenGL function calls. It looks like the NVIDIA drivers were updated, but not reloaded onto the graphics cards, so a reboot fixed it.

Program Crashes When Adding Collider During Sim

I'm trying to figure it out, but just in case I don't before I go to sleep I figured I'd make it a new issue.

Parallel Cumulative Sum

Here's a possible optimization of our pipeline if we need it: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch39.html

mass squashing & volume rendering strangeness

I spent the better part of today and yesterday on this but my mind is feeble and I haven't come across the solution yet. In the meantime I'll describe the problem here.

The problem doesn't seem to be a matter of converting our grid indexing system to the z-major / x-minor format that Mitsuba uses. I did some basic tests of drawing implicit spheres and wavy patterns (in terms of our grid coordinates) and they show up nicely and exactly as expected now.
See commit b1b0d09

When rendering the teapot though, the volume is recognizable but it's been fragmented. Furthermore dropping the teapot appears to squash this representation of mass in place, rather than translate it.

frame 0000

frame 0015

frame 0024 (1 sec)

This appears to be problems with indexing but that leaves me confused as to why creating a simple sphere implicitly using the grid indices works (I double-checked the getGridIndex function in simulation.cu). Wil, Max, you guys are more familiar with the grid mass transfer code. Do you have time sometime tomorrow to sit with me and rubber-duck debug this?

Calibrating Scene Scales

I'm not sure if this will work, but here's a suggestion for calibrating the scene size to match what Disney did:

In figure 8 of the paper (video of it is here http://youtu.be/O0kyDKu8K-k?t=1m28s ) they show the snow behavior under different hardening/Young modulus/critical stretch/compression parameters. They didn't say how big the grid / number of particles was for this "wedge" scene but ideally there should be a sweet spot where all those parameters manifest the way they do in the paper.

Thrust!!! (& scanline mesh filling)

There seems to be a bug right now with the obj mesh filling code, especially for objs with axis-aligned faces.

This was presenting problems with filling castle crenellations and while there are workarounds (like building the castle from simple primitives and filling once at a time), it'd be nice to have mesh filling work for more arbitrary meshes. I'm going to try my hand at a more naive scanline filling algorithm which doesn't require voxelizing the mesh.

http://www.cs.ucdavis.edu/~ma/ECS175_S00/Notes/0411_b.pdf

It does require a sorting step for mesh intersections, but it turns out that the CUDA toolkit already comes with Thrust installed, and it has both host-and-device-compatible algorithms. The following lines become extremely useful:

#include <thrust/sort.h>
const int N = 6; 
int A[N] = {1, 4, 2, 8, 5, 7}; 
thrust::sort(A, A + N); // A is now {1, 2, 4, 5, 7, 8}

This also might be a bit too late but I thought I'd also mention that Thrust algorithms have reduction/prefix-sums that are device-compatible. oops
http://docs.nvidia.com/cuda/thrust/#algorithms

Finally, using the XZ plane to perform the intersection, as most kinds of geometry tend to have fewer overlapping layers looking top-down.
Will try to implement this by tomorrow afternoon. cheers

comparison utility for glm types

glm has epsilonEqual, epsilonNotEqual functions for comparing glm types. I find these useful for checking that math matches up with numbers computed in MATLAB
http://glm.g-truc.net/0.9.5/api/a00172.html

grid positions are at the corners

Just as we speculated earlier, the grid seems to track its particles at it's corners.

I just noticed that in the weighting function,
N((x_p-ih)/h)N((y_p-jh))N((z_p-kh))

where the particle position is (x_p,y_p,z_p). This implies that the grid locations correspond to (i_h,j_h,k*h) for (X,Y,Z) respectively.

This may have been obvious to you guys already but I'll leave this as a note to myself.