I think it'd be easier if you'd tell SrcDemoČ the game location (e.g. steam/steamapps/sourcemods/garrysmod), then you'd type a directory like render/superdupervideo/ and it'd create/mount the directory itself. would be easier IMO
I love you
I've installed Java and Dokan, but when I try to open SrcDemo the window pops up telling me that Dokan is not installed.
What to do?
Dependency Walker and use it to open "JDokan.dll" in "C:\Program Files\SrcDemo2\lib". It will list all the .dll files that JDokan.dll requires, and it will tell you if you're missing any, and which you are missing.
I have no idea why it would need MSVCR100.DLL... But that should come with the Visual C++ redistributable package. So try installing that, if you don't mind installing yet other stuff. As for MSJAVA.DLL, I don't have that dll either and the program runs fine, so maybe it'll work without it and only MSVCR100.DLL is the missing component.
If installing the Visual C++ redistributable package doesn't work, try simply googling the name of the .dll and you should be able to find a direct download. Put the .dll right next to JDokan.dll (or maybe next to SrcDemo2.exe, try both) and see what happens.
Thank you for helping us help you help us all.
Such a shame that the catmull-rom cameras don't work across saves and demos.
Made a test video with SrcDemo2 a few days ago:
is there any way you could incorporate sourcemod into this and force host_framerate with the cvar function in games that don't have it (l4d)?
It keeps producing jumpy physics and NPCs. (On both Gmod and Ep2)
Released a new build today. You can download it from http://code.google.com/p/srcdemo2/downloads/list as usual.
- Bundled an extra .dll file that should allow Dokan to be detected properly on 32-bit systems (@ory25, you probably want this).
- Use of a single PNG saving thread (PNG saving tasks are still done in the background and queued up, but now there's just one thread handling them and being reused rather than a lot of threads being re-recreated, so it's faster).
- Added new debugging command-line switch: --dokan-debug, to debug the Dokan layer of things (warning: very verbose).
- Added new not-so-much-debugging command-line switch: --srcdemo-hide-files, which makes the mountpoint display a completely empty directory. This has the advantage of not being memory-hungry for some people (someone on the Steam forums had problems with it), but has the disadvantage of you not being able to see your files in the mountpoint (though they're still in the output folder, of course). It makes things slightly faster, but not significantly so.
- Fixed "Quit" button saying "Deactivate" on Dokan error message dialog.
Oh man, I like this idea a lot. Thanks! I'll play around with it in TF2 later on. :)
60 looks great
It basically takes alot of screenshot at a high FPS and blends them down, it needs to have a high FPS to work properly, and I doubt 60 is a large enough sample pool.
EDIT: This has been moved to http://code.google.com/p/srcdemo2/wiki/ShutterAngle.
I think I should take a moment and explain what the shutter angle really is, as it seems it is not a clear notion to some people.
To kick things off and give people a reason to read this wall of text, here's a striking example of how important getting the right shutter angle is. This is the same scene, recorded at multiple shutter angles:
Interested? Good, let's begin.
This is a camera with a 180° shutter angle:
As you can seem each physical frame of the film is only exposed 50% of the time.
For a 30 frames per second video, a new physical frame is made every 1/30th of a second.
However, since it is only exposed half of the time, only 1/60th of a second's worth of exposure has gone onto the frame. The other 1/60th of a second is simply gone, not recorded.
As you can imagine, a higher shutter angle means a longer exposure time. For example, a 270° shutter angle, the frame would get 3/120th of a second's worth of exposure, and 1/120th of a second would be gone. With a 360° shutter angle, the frame will get the full 1/30th worth of exposure, and nothing will be lost.
Now you may wonder: "I don't like data loss! Why not always use 360°? And why is 180° the default?"
The reason for that is because of the human brain. Unlike computers, where the "more data == better" applies, the brain doesn't see animation as such. The eye sees a series of still images, which the brain intuitively and subconsciously interprets and computes motion between the frames. This final "moving" scene is then what you see. The perception of motion is only due to your brain doing some pretty intensive work (that computers take ages to do!) just for you.
The brain is very good at this; even from a low-framerate video, you can usually easily tell what is moving where, and how fast it is moving, without too much conscious brain effort.
However, it is true that if you artificially feed the brain more frames than it needs in order to perceive motion, the overall work will appear smoother.
Thus, higher shutter angle means more frames means smoother motion, right? No.
Despite the fact that feeding more frames helps, the brain still knows that images arrive at a constant rate, thus that there is a delay between each frame. It is used to that delay. If you use a 360° shutter angle, the perceived delay between frame n-1 and frame n is much smaller than what the brain expects, because the last blended frame in frame n-1 is much closer temporally to the first blended frame in frame n.
As a result, the brain will get confused and will make you feel like things are moving too fast, making you disoriented a bit.
This is why a too high shutter angle is a bad thing.
Wanna see how much of a difference it makes? Here's an example, though it is not the clearest one:
As you can see, the higher the exposure time (higher shutter angle), the smoother the water movement looks, but when you go too low (1/30, which is 360° shutter angle), it looks blurry and kinda crappy.
Another good way to see this is simply to look at existing videos made by the TF2 replay renderer! It uses 360° degrees (which means it doesn't care about shutter angle at all, just records and blends all frames).
Here is a sample one (not my replay, not trying to get anyone a Frontline Field Recorder, just thought this replay demonstrates nicely how sickening the motion blur on TF2 replay is):
Watch in fullscreen to get a better feel. If you don't feel it, try looking at the sides/corners of the screen especially. If you still don't feel it, you've probably watched too many replays by now and are immune to the effect or something D:
As you can see, while the video does look very, very smooth, it looks smooth to the point of being sickeningly blurry.
And that, my friends, is why you will Learn, Live, and Love the 180° shutter angle. It is still not a completely natural effect, but the inter-frame time is much closer to what the brain expects, and the motion blur quality is optimal. It is what is used on film too, and even though today's cameras obviously don't use rotary shutters anymore, they still do use shutter angle simulation, because that's simply what people are used to and find comfortable. This is also why, for once, loss of data (in this case, half of the frames) is a good thing.
I hope this was clear It is not a very easy-to-explain concept, but it does affect the output of SrcDemoČ a lot, so I thought I'd define it more clearly.
Also wouldn't it be apparent that the lower your shutter angle, the higher frame samples you need, or you will start seeing Ghost frames because it no longer blurs them ?
Say you have an output FPS of 30 and a blendrate of 50 (effective FPS 1500).
- With a 360 degree angle, each output frame would be sampled from 50 game frames, spread over 1/30th of a second.
-> Each output frame represents 1/30th worth of movement with 50 blends, so each game frame has "lasted" (1/30)/50 = 1/1500th of a second (which is normal; that's the framerate we told the game to render at).
- With a 180 degree angle, each output frame would be sampled from 25 consecutive game frames out of the 50 frames the game provides, and the 25-frames sample would be spread over 1/60th of a second.
-> Each output frame represents 1/60th worth of movement with 25 blends, so each game frame has "lasted" (1/60)/25 = 1/1500th of a second (again we get the framerate we told the game to render at).
- With a 90 degree angle, each output frame would be sampled from 13 consecutive game frames out of the 50 frames the game provides, and the 13-frames sample would be spread over 1/120th of a second.
-> Each output frame represents 1/120th worth of movement with 13 blends, so each game frame has "lasted" (1/120)/13 = 1/1560th of a second (not exactly 1500, but pretty close; the small error is due to the fact that 50 is not divisible by 4).
As you can see, in all cases, each game frame effectively lasts the same time, so there is the same amount of movement between every game frame, no matter the shutter angle. So no, the shutter angle does not need to be adjusted to avoid "ghost frames".
But that's a very good question still!
To be clear: The sample of frames is always consecutive (otherwise it'd ruin the point; might as well just render at half the framerate). So basically, for 30fps/180 angle, it records 1/60th of a second, saves that to frame 0, then ignores the next 1/60th of a second, then records the next 1/60th of a second, saves that to frame 1, ignores the next 1/60th of a second, records the next 1/60th of a second, saves that as frame 2, etc.
thank you for for fixing the problem i was having it works fine now, its vary vary good :)
I have uploaded an unfinished build for those who are running into the out-of-memory issues (which seems to be no one at all in this thread, but pretty much everyone on the Steam forums. Coincidence...?). I'm also posting that here because I'd love to get feedback on it, as I'll be releasing that version (except finished, of course) soon.
On an unrelated note, I would appreciate it a lot if all videos made using SrcDemo2 uploaded on YouTube are tagged with the tag "srcdemo2". Just gives me an idea of how popular this utility is, and it gives people a cool way to find awesome-looking videos.
I ran the last demo in debug and I have the log it saved, TF2 stopped the movie with the error
Couldn't write movie snapshot to file rawfs/h3allowhoene2_159332.tga.
Stopped recording movie...
Here is the log. (Its a .txt compressed with .7z, the text file was 18~ MB)
But that looks like one of those out-of-memory errors that people in the Steam thread are complaining about. Can you try the same with --srcdemo-hide-files?
Nah, to be honest I'm not very comfortable with all those social networking thingies. (I know I have a Twitter link right there in my Facepunch profile, but I don't really use it regularly).
However, you can watch the "Downloads" RSS feed to get notifications of new releases, or watch the SVN changelog RSS feed to get notified of all changes. I guess that can be hooked into Twitter and all that stuff if necessary (read: if there is demand).
Anyway, new release incoming within the next few minutes.