ent

Something wrong with your log as well. Some words miss letters. Does it fail with any length projects and does it work fine on default maps?

I gotcha. And what I said is all you need - set value for mov_smoothQuat to 1 or more. Try value of 100 or 1000.

About DOF: Black - time line, gray - desired time, imaginary vertical axis is DOF values, red - key points and interpolated path. If you want to have certain DOF value at gray time then you have to add 2 key points a bit before and 2 key points a bit after the desired time. Key points 2 key points before and after will normalize value between 2 and 3 key points (as you see it is linear and the value doesn't change). Make time between those helper key points short. For now that's the only way to have the exact DOF value at exact time. About the tearing: is your camera position static and only angles change or your camera moved a bit? If it's moved then yes there is a problem with the tearing. Either don't move camera (just rotate) or make movements on higher distances. Btw, there is also a tricky way to set angles key points, position key points and fov key points separately of each other. If you are interested in that I can explain how to do that. I added a fix for that in q3mme but not in jaMME - need to move that code to jaMME as well. If your camera doesn't move then I have no idea what's wrong.

There is not other way, it merges all the captured blur frames - it takes time. If you want to make things go faster, higher frequency of your CPU. I'd suggest before capturing final footages that take time, capture everything in lower resolution, adjust settings if necessarily and when you are ready just leave everything for a night to capture with demolist.

Hi. About the DOF issue. The problem in the interpolation type that is used in DOF. I thought about that issue as well some time ago. It better be using linear interpolation instead of spline. In example above 1 is a current way with green highlights of the issues where the current interpolation system before speeding up has to slow down but it usually happens with time diff between key points is small. 2 is a manual fix where you add extra neighbor key points with the same value and negate jumps of acceleration/decceleration. 3 is a proper way with linear interpolation. It's not smooth but it won't be noticed much in DOF I think. I need to add that option. About the camera issue. Your guess in using those times in key frames are correct. The problem is in the interpolation again. ? Camera rotation itself is smooth using quaternion interpolation but the issue is it uses linear interpolation for time so when rotating from key point 1 to key point 2 it goes by one precalculated speed, then another precalculated speed for key points 2 and 3 and so on. The solution is using mov_smoothQuat, set 1 (or higher for higher precision, over 100 it eats much CPU for me) then it will also add some interpolation for time and you should see some accelerations and decelerations. For the last issue either add the neighbor points as described above or use linear interpolation for camera rotation - it exists fortunately. Enabled by using command camera smoothAngles 0. Good luck.

Hello. Good questions. 1. Every demo that gets loaded from demolist also loads its respectful project file as you may know. And every project file contains a bunch of cvars that was saved together. Those cvars then get loaded with their project file. Here is a list of cvars that are saved into a project file by default: https://github.com/entdark/jaMME/blob/master/codemp/cgame/cg_demos_capture.c#L184 What you can do to with all that. Remove all cvars from every project so the whole thing will only use cvars from your game config. Project files are simple XML files and could be edited in any text processor. Modify every project and set or replace data with needed cvars and needed values. Add mov_captureCvars into your game config with only needed cvars for saving into project files for future demos. Open every demo and load and save project in every and update them with current cvars. The cvar that messes up pipe and avi is mme_screenShotFormat. 2. There is no way to autoreset demolist values. But it sounds like a good addition to have. I will probably add that. 3. jaMME captures with r_customwidth and r_customheight values when it is loaded normally. It captures with mme_renderwidth and mme_renderheight when they are set to more than 0. That is the point of off-screen capturing to capturing in higher resulution. Demolist itself could be run on-screen if your desired resolution is less or equal your game resolution. As a side-answer modern kids don't accept anything below 4k60fps so go for it. But to be serious it does not matter much if the content delivers. For working with high bitrate videos your machine also has to be pretty high end - keep that in mind. If you are looking for a film look as you say then check out DOF feature and low FOV (cg_fov) when using DOF and slow camera movement. Pretty cinematic. But I am not an expert. Also as a side-information 1080p, 720p etc are video formats. Resolution formats are FullHD, HD etc. Good luck.