Somewhat Realistic Camera Shake Tracks
category: code [glöplog]
Need a "shakycam" for your demo but the good old sin-cos-mess just doesn't cut it anymore? Today's your lucky day!
Somewhat Realistic Camera Shake Tracks is a public release of the camera shake data and code used in the demo A New World Awaits.
It's basically some animation data with C++ code to load it in and play it back.
Get it at https://peisik.untergrund.net/camera_shakes/
Nice :)
standard shadertoy textures coming in 3... 2....
cce: Nice, but could you maybe also share some info about how these datasets were created in the first place? Are they generated or captured?
Doh, you already explained that on the webpage, silly me.
There seems to be a problem with the CSV dumps, where delta_x and delta_y are always the same...?
Quote:
There seems to be a problem with the CSV dumps, where delta_x and delta_y are always the same...?
Sorry about that. They are fixed now.
Quote:
standard shadertoy textures coming in 3... 2....
What a brilliant idea. If every track was limited to 1024 frames you could pack them all in a neat 1024x4 RGBA texture. Just 8 bits per channel might be enough if encoded as XYM where M is the scale (think RGBM). Roll could be stuffed in the alpha channel and biased so that it could also be linearly interpolated. I'm definitely going to try this at some point.
After analyzing the data (just the x and y offsets, but I wouldn't be surprised if roll follows a similar pattern), a few observations can be made:
The X and Y offsets seems to be somewhat similar; we rarely see both large x-offsets and large y-offsets. It does happen, but much less often than large X and Y alone.
The DCT of the X and y offsets seems to have two signals:
One "ambient" that looks like noise modulated with an exponential falloff (exp(-x) style)
One spike around a given step frequency. This one seems like shifts a bit back and forth, but not much. It's also obviously missing from the still-standing dump.
Plotting the x and y offsets together shows what looks mostly like a brownian motion curve, that constantly gets pulled towards the center.
Strangely enough, both the x and y offsets seems to have a bias towards positive values. This seems like it might be just a problem with the relatively small datasets, or maybe an error in the measurements.
[/list]
What does this mean? Well, I suspect that it's possible to generate datasets that are indistinguishable from the real ones, and might allow more parameters. Yay, more sin/cos mess? :D
But I guess analyzing the roll data needs some work first.
What does this mean? Well, I suspect that it's possible to generate datasets that are indistinguishable from the real ones, and might allow more parameters. Yay, more sin/cos mess? :D
But I guess analyzing the roll data needs some work first.
float strength = 20.0; // Michael J. Fox mode
Thank you for your analysis, kusma. Synthesizing this kind of shake data shouldn't be that hard and I'd love to have a compact formula that looks good. Perhaps just having roughly the correct frequencies and some kind of roll component is real enough.
That last point about a positive bias is definitely bug. The new version 5 is now centered before processing which looks OK. Crossfade was also kinda broken so that's smoother now too. Note that the CSV files also have the crossfade applied to the final 30 frames which might subtly affect the frequency response.
---
I went and added that RGB texture version of the animation data. You can see in this live demo that it looks pretty OK. I just quantized the data without anything fancy and the absolute errors don't seem that bad:
The image tracks/1024.png is easy to decode in GLSL. There's also an "applyShake(dir, shake)" helper function just like in the C++ version. I've noticed that it's fun to boost the roll component to get a more dynamic movement :)
That last point about a positive bias is definitely bug. The new version 5 is now centered before processing which looks OK. Crossfade was also kinda broken so that's smoother now too. Note that the CSV files also have the crossfade applied to the final 30 frames which might subtly affect the frequency response.
---
I went and added that RGB texture version of the animation data. You can see in this live demo that it looks pretty OK. I just quantized the data without anything fancy and the absolute errors don't seem that bad:
Code:
max_x_error 0.586130 pixels
max_y_error 0.525709 pixels
max_roll_error 3.66937529786894e-08 degrees
mean_x_error 0.291821 pixels
mean_y_error 0.264604 pixels
mean_roll_error 7.474555236434156e-09 degrees
The image tracks/1024.png is easy to decode in GLSL. There's also an "applyShake(dir, shake)" helper function just like in the C++ version. I've noticed that it's fun to boost the roll component to get a more dynamic movement :)
