Random adding motion blur to demo captures thread
category: offtopic [glöplog]
ryg - I didn't do that for the full length captures actually. Working on that in a bit.
Quote:
debris looks fantastic with motion blur (despite the shaky-camera scenes), especially the greetings part.
oh yeah!
(nice idea micksam)
LIFEFORCE
I don't know... with the blur the demos appear like watching them on a very old TFT display with a pretty high reaction time.
I'd really like to see more caps with motion blur, lifeforce would be great :) And just out of curiosity, I'd like to know how "the golden path" would look like.
what the hell is the point of adding motion blur to a demo that does not feature motion blur? has it something to do with the blending of the frames or something? framerate of the demo that it blends the frames together in a more smoothly fashion can be good but can someone please explain me why this should be so great for a vidcap? as long as it doesnt show the motionblur in the demo im fine with it as long as it doesnt take overhand.
rydi: because it allows using lower framerate in the final video, greatly reducing the video-size.
sure, if it is used in web-streaming or something i get it.
Bear in mind that demos tend to look best at 60fps. 60fps videos are rare... 30fps + motion blur can be better. Sometimes.
Well, when we put all of the mindcandy3 rejects/alternates on the website, they will be full 60p.
I think post-processing the demos is very fun to play with but I would never try to represent them that way. That's the same reason mindcandy3 is 720p -- it's not the highest res that can be done with blu-ray, but it is the highest progressive framerate (60fps). (I experimented with 1080 @ 30i and found that deinterlacing wasn't consistent across players/hardware so we dropped the idea.)
Ever since mpeg-4 encoders/muxers/players started to properly support 60p, I've been using it. (Wish they all did deinterlacing properly, but oh well.)
I think post-processing the demos is very fun to play with but I would never try to represent them that way. That's the same reason mindcandy3 is 720p -- it's not the highest res that can be done with blu-ray, but it is the highest progressive framerate (60fps). (I experimented with 1080 @ 30i and found that deinterlacing wasn't consistent across players/hardware so we dropped the idea.)
Ever since mpeg-4 encoders/muxers/players started to properly support 60p, I've been using it. (Wish they all did deinterlacing properly, but oh well.)
I happened to come across the same experiements while trying to make fast-moving demos look better at streaming-friendly framerates:
Lifeforce (youtube)
Scyphozoa (capped)
Both were recorded with a hacked version of kkapture at 960 fps, giving 32 sub-frames at 30 fps.
16 frames were blended and the others discarded, simulating a 1/60sec shutter.
Lifeforce (youtube)
Scyphozoa (capped)
Both were recorded with a hacked version of kkapture at 960 fps, giving 32 sub-frames at 30 fps.
16 frames were blended and the others discarded, simulating a 1/60sec shutter.
Man, motion blur really gives that "polished" look to a demo.
The zoomer in Stargazer looks especially nice!
I'll bet that YouShould would look stunning with motion blur -- it has a lot of fast camera changes and the like.
The zoomer in Stargazer looks especially nice!
I'll bet that YouShould would look stunning with motion blur -- it has a lot of fast camera changes and the like.
I really want to see one of my intros with that treatment, the problem is I'm sure the heavy post-processing may fuck up the result :/
hfr: MORE PLEASE
Hm, the motion blur of the latest videos is pretty much similar to the motion blur of my TFT. I barely can see the difference. :)
rez: I tried WHABYV but since most effects are rather slow-moving, the effect is barely noticable.
It looks pretty cool on the intro scene (the rapidly rotating logo) but the timing is wrong (the rotation stops quite abruptly).
I guess you're using some kind of damping factor to control the speed and apply it once per-frame ?
...which doesn't work so well when running at ~1000 instead of 60 fps ;)
But don't mind, the same problem appeared in Lifeforce and probably many other demos.
xernobyl: make a wish.
Salinga: It's not about adding fancy effects but improving motion perception.
It looks pretty cool on the intro scene (the rapidly rotating logo) but the timing is wrong (the rotation stops quite abruptly).
I guess you're using some kind of damping factor to control the speed and apply it once per-frame ?
...which doesn't work so well when running at ~1000 instead of 60 fps ;)
But don't mind, the same problem appeared in Lifeforce and probably many other demos.
xernobyl: make a wish.
Salinga: It's not about adding fancy effects but improving motion perception.
Wouldn't the motion perception be better if you didn't drop half the frames? My eyes don't have a shutter I think.
Good point.
The original idea was to get more motion-information into ~30fps, so I tried to emulate what we're used to from the movies and not what we actually see in reality.
And since the time-resolution of the human eye is 60..65hz, blending all frames of a 1/30 sec to a single picture can't be right, either.
But might be interesting to blend all the 960 frames down to 60hz...
The original idea was to get more motion-information into ~30fps, so I tried to emulate what we're used to from the movies and not what we actually see in reality.
And since the time-resolution of the human eye is 60..65hz, blending all frames of a 1/30 sec to a single picture can't be right, either.
But might be interesting to blend all the 960 frames down to 60hz...
Reviving this thread.
It happens, that I came across the same line of thought (real motion blur achieved via .kkapture wizardry and frame blending) not an awfully long time ago. Here are three results of my experiments.
1) Conspiracy - Chaos Theory.
Test attempt to capture the footage at 240fps revealed that the demo is hard capped (large amount of duplicate frames appearing periodically). Frame counting revealed that it was capped at 100fps. I captured it at 100fps and then blended it to 60fps, having rearranged the frames in 2-1-2 manner (in a triad of output frames, the first one is blended from two equally weighted frames, the second one is crisp and the third one is, again, blended from two equally weighted frames) to avoid "bleeding" of any of the source frames onto multiple output frames (thus unnecessarily blurring the output and decreasing the subjectively perceived kind of smoothness, corresponding to high fps).
Result can be seen here: http://www.mediafire.com/download/k56nc53nw98xqi6/chaostheory[100bto60fps(2-1-2)].mp4
This demo could be so much more without the cap.
For owners of 120hz monitors, the proper course of action would just be capturing (or watching live) the demo at its native 100fps, as there is simply nothing else that could be squeezed out of it. There is also a prospect of capturing an insanely supersampled version, but that's quite outside the topic of this thread.
2) ASD - Rupture (Rapture?).
Captured 1/3 (one third) of the demo at 960fps, non-aliased, and then blended each of the frames of the 60fps output video out of 16 respective equally weighted frames (not interested in emulating the camera shutter or any other such hardware limitations). Capture terminated due to lack of storage space: 1/3 of the demo at 720p Lagarinth-ed (RGB24) ended up being 85gb, and I simply didn't have another 170gb to make it through.
This demo is the most promising of the three, and it does indeed output any fps within the limits allowed by .kkapture without duplicates. The nature of motion and camera motion, however, seems quite funny: almost the whole demo appears to move in a series of "pushes" (with the period between "pushes" being close, but NOT exactly equal to, to 16 frames at this capture mode, closer to 18-19; the first 7-8 frames being rapid movement, then scaling back to almost no movement until the next push). In the captured segment of the demo, only a couple of episodes with noticeable rupturing(te-heee)/gradedness of motionblur trail (due objects moving more than a pixel between adjacent captured frames) were noticed, overall, 960 seems quite sufficient for acquiring properly motionblurred version of this demo.
After the blending, at the reencoding stage, the motionblurring of frames helps the size of the output file tremendously: output file seems to occupy less than a half of what it would occupy at the same quality and at the same framerate with every frame being crisp. I could've safely make it with quality of 8 instead of quality of 15 (which did produce some artifacting).
In any case, the end result so far can be seen here: http://www.mediafire.com/download/9rbhyzv73h3cz9r/rupture[test960bto60fps].mp4
3) Andromeda - Noumenon.
Captured the whole demo at 960fps (it actually ended up occupying the same 85gb), then blended to 60fps. This demo however ended up being a poor choice for the procedure, due to it being framerate-dependent. Both physics-based scenes got severely screwed due to all the initial linear speeds having been skyrocketed proportionally to fps, the coloring in the zoomer scene somehow also ended up being wrong, the camera "stuttering" and all the in-demo text do not look good due the there being random macroscopic steps between the adjacent frames (regardless of the framerate). Besides, several parts of the demo are way too rapid even for 960fps, producing severe rupturing of the trail (the evidence is most telling in the b&w "infinite cubes" scene), and even if one could hypothetically capture it at 6000fps, it would do nothing to smooth the scenes with the stochastic between-frame jumps, while screwing the physics-based scenes even more.
Regardless, the end result (not particularly impressive even at its best, when compared to Rupture video above; also used quality 8 instead of 15 here) can be seen here: http://www.mediafire.com/download/8ix3d97tv75yr74/noumenon[960bto60fps].mp4
I also happened to capture a part of the party version of heaven7 at 800x600 (it crashed on me near the end, and I didn't do a recap) but the end result ended up (despite at least some of the scenes clearly supporting 960fps output) looking not particularly impressive from the "motion softness" perspective. The demo is simply too slow, and there is simply no sense in utilizing this procedure on it.
At the end of this message, I want to copy here the contents of a message I emailed to ryg some time ago (and am yet to receive an answer - if at all), which is directly relevant to the subject of this thread:
".kkapture: Motion Blur?
Greetings.
I think I might have an interesting idea about a certain feature that might be implemented in .kkapture (and could not really be implemented in any other capturing software such as FRAPS and so on - well, not to such an extent anyway).
I am talking about the possibility of introducing the distinction between FPS as rendered in the demo itself - and the target FPS of that which gets consequently encoded - and blending the intermediate frames in order to achieve true (not simulated) motion blur similar to the way it is achieved on, say video cameras (well, this "digital" motion blur would necessarily be somewhat "graded" due to discrete nature of "motion" represented, but the "graded-ness" could be alleviated just by rendering the demo at higher FPS and consequently using more intermediate frames for each encoded one).
So, let's say, .kkapture renders a certain demo at 600 FPS (well, if the demo even supports this) with a target FPS being 60. It blends 10 frames together, constructing a mean frame out of them, then encodes this mean frame in the output video. Then it takes the next 10 frames, constructs a mean/average, encodes it, etc.
Of course, this could also be done without such a feature being present in .kkapture. One just captures the demo in 300 or 600 or 6000 fps and blends the frames together using, say, some AviSynth "magic". But that would, first, imply that every intermediate frame would need to be encoded in the output .kkapture video, which would take up a major amount of time. Second, the output .kkapture videos would, themselves, be proportionally tens or hundreds times larger, spanning tens and hundreds gigabytes respectively, which, as you can imagine, could be somewhat problematic and inconvenient. So, really, the most convenient place for blending the frames would be in .kkapture's pipeline, after all the input frames have been captured, but before the resulting one gets sent to the encoder.
There isn't even any need for supporting _arbitrary_ FPS rates for rendered and target options (thus unnecessarily complicating the math - not that it would be particularly complex anyway), just make the rendered FPS necessarily proportional to the target one, so that the end user can choose whether he/she wants to get motion blur at all, and then would just choose the multiplication rate (x7 or x10 or x100, x10 meaning that the demo is rendered at FPS 10 times higher compared to target one, and that 10 consecutive captured frames [say, frames 15340, 15341, 15342, 15343, 15344, 15345, 15346, 15347, 15348, 15349. produced by a demo/intro - starting from 0], after being blended, produce exactly one median frame which would get to output [and, in this case, would be frame 1534 of the output video - starting, again, from 0]) - and that would be perfectly enough.
What do you think about this matter?
Thank you for your attention and time,
Alex."
It happens, that I came across the same line of thought (real motion blur achieved via .kkapture wizardry and frame blending) not an awfully long time ago. Here are three results of my experiments.
1) Conspiracy - Chaos Theory.
Test attempt to capture the footage at 240fps revealed that the demo is hard capped (large amount of duplicate frames appearing periodically). Frame counting revealed that it was capped at 100fps. I captured it at 100fps and then blended it to 60fps, having rearranged the frames in 2-1-2 manner (in a triad of output frames, the first one is blended from two equally weighted frames, the second one is crisp and the third one is, again, blended from two equally weighted frames) to avoid "bleeding" of any of the source frames onto multiple output frames (thus unnecessarily blurring the output and decreasing the subjectively perceived kind of smoothness, corresponding to high fps).
Result can be seen here: http://www.mediafire.com/download/k56nc53nw98xqi6/chaostheory[100bto60fps(2-1-2)].mp4
This demo could be so much more without the cap.
For owners of 120hz monitors, the proper course of action would just be capturing (or watching live) the demo at its native 100fps, as there is simply nothing else that could be squeezed out of it. There is also a prospect of capturing an insanely supersampled version, but that's quite outside the topic of this thread.
2) ASD - Rupture (Rapture?).
Captured 1/3 (one third) of the demo at 960fps, non-aliased, and then blended each of the frames of the 60fps output video out of 16 respective equally weighted frames (not interested in emulating the camera shutter or any other such hardware limitations). Capture terminated due to lack of storage space: 1/3 of the demo at 720p Lagarinth-ed (RGB24) ended up being 85gb, and I simply didn't have another 170gb to make it through.
This demo is the most promising of the three, and it does indeed output any fps within the limits allowed by .kkapture without duplicates. The nature of motion and camera motion, however, seems quite funny: almost the whole demo appears to move in a series of "pushes" (with the period between "pushes" being close, but NOT exactly equal to, to 16 frames at this capture mode, closer to 18-19; the first 7-8 frames being rapid movement, then scaling back to almost no movement until the next push). In the captured segment of the demo, only a couple of episodes with noticeable rupturing(te-heee)/gradedness of motionblur trail (due objects moving more than a pixel between adjacent captured frames) were noticed, overall, 960 seems quite sufficient for acquiring properly motionblurred version of this demo.
After the blending, at the reencoding stage, the motionblurring of frames helps the size of the output file tremendously: output file seems to occupy less than a half of what it would occupy at the same quality and at the same framerate with every frame being crisp. I could've safely make it with quality of 8 instead of quality of 15 (which did produce some artifacting).
In any case, the end result so far can be seen here: http://www.mediafire.com/download/9rbhyzv73h3cz9r/rupture[test960bto60fps].mp4
3) Andromeda - Noumenon.
Captured the whole demo at 960fps (it actually ended up occupying the same 85gb), then blended to 60fps. This demo however ended up being a poor choice for the procedure, due to it being framerate-dependent. Both physics-based scenes got severely screwed due to all the initial linear speeds having been skyrocketed proportionally to fps, the coloring in the zoomer scene somehow also ended up being wrong, the camera "stuttering" and all the in-demo text do not look good due the there being random macroscopic steps between the adjacent frames (regardless of the framerate). Besides, several parts of the demo are way too rapid even for 960fps, producing severe rupturing of the trail (the evidence is most telling in the b&w "infinite cubes" scene), and even if one could hypothetically capture it at 6000fps, it would do nothing to smooth the scenes with the stochastic between-frame jumps, while screwing the physics-based scenes even more.
Regardless, the end result (not particularly impressive even at its best, when compared to Rupture video above; also used quality 8 instead of 15 here) can be seen here: http://www.mediafire.com/download/8ix3d97tv75yr74/noumenon[960bto60fps].mp4
I also happened to capture a part of the party version of heaven7 at 800x600 (it crashed on me near the end, and I didn't do a recap) but the end result ended up (despite at least some of the scenes clearly supporting 960fps output) looking not particularly impressive from the "motion softness" perspective. The demo is simply too slow, and there is simply no sense in utilizing this procedure on it.
At the end of this message, I want to copy here the contents of a message I emailed to ryg some time ago (and am yet to receive an answer - if at all), which is directly relevant to the subject of this thread:
".kkapture: Motion Blur?
Greetings.
I think I might have an interesting idea about a certain feature that might be implemented in .kkapture (and could not really be implemented in any other capturing software such as FRAPS and so on - well, not to such an extent anyway).
I am talking about the possibility of introducing the distinction between FPS as rendered in the demo itself - and the target FPS of that which gets consequently encoded - and blending the intermediate frames in order to achieve true (not simulated) motion blur similar to the way it is achieved on, say video cameras (well, this "digital" motion blur would necessarily be somewhat "graded" due to discrete nature of "motion" represented, but the "graded-ness" could be alleviated just by rendering the demo at higher FPS and consequently using more intermediate frames for each encoded one).
So, let's say, .kkapture renders a certain demo at 600 FPS (well, if the demo even supports this) with a target FPS being 60. It blends 10 frames together, constructing a mean frame out of them, then encodes this mean frame in the output video. Then it takes the next 10 frames, constructs a mean/average, encodes it, etc.
Of course, this could also be done without such a feature being present in .kkapture. One just captures the demo in 300 or 600 or 6000 fps and blends the frames together using, say, some AviSynth "magic". But that would, first, imply that every intermediate frame would need to be encoded in the output .kkapture video, which would take up a major amount of time. Second, the output .kkapture videos would, themselves, be proportionally tens or hundreds times larger, spanning tens and hundreds gigabytes respectively, which, as you can imagine, could be somewhat problematic and inconvenient. So, really, the most convenient place for blending the frames would be in .kkapture's pipeline, after all the input frames have been captured, but before the resulting one gets sent to the encoder.
There isn't even any need for supporting _arbitrary_ FPS rates for rendered and target options (thus unnecessarily complicating the math - not that it would be particularly complex anyway), just make the rendered FPS necessarily proportional to the target one, so that the end user can choose whether he/she wants to get motion blur at all, and then would just choose the multiplication rate (x7 or x10 or x100, x10 meaning that the demo is rendered at FPS 10 times higher compared to target one, and that 10 consecutive captured frames [say, frames 15340, 15341, 15342, 15343, 15344, 15345, 15346, 15347, 15348, 15349. produced by a demo/intro - starting from 0], after being blended, produce exactly one median frame which would get to output [and, in this case, would be frame 1534 of the output video - starting, again, from 0]) - and that would be perfectly enough.
What do you think about this matter?
Thank you for your attention and time,
Alex."
Just to say that I think I know why rupture looks like moving in "pushes". It must be the handheld camera effect, which is based on real data with a quantized resoltuion of around 25fps (varies through out the demo).
All Conspiracy products are capped at 100 fps, it's a tool level limitation.
I once did a kkapture of "Kasparov" by Elitegroup on Windows 7 at 120Hz for the hell of it. As far as I can tell it seems to scale fine with frame rate. A lot of the camera vibration set to the music becomes smooth sine wave motion at higher frame rates.
