4:40 : I hate motion blur because: 1) I play fast paced games where it's crucial to know the exact silhouette. 2) Looking around ingime is more like turning your entire head than head + eyes. You cant account for my eye wandering around and tracking things not just in front of me. Similarly why depth of field is annoying because you cant know what at any given moment im focusing on rather than just assuming that the stuff straight ahead is what im looking at. 3) I get more than enough blur from my monitor when looking around ingame. 4) Given the annoyances above it's not worth spending more GPU resources for me. It would have to give me FPS in order fo me to be worth it. EDIT: For racing games its crucial tho. And for that it seems like a very good one.
This is a very insightful laydown of issues, here's my answer to each one (take it with handfuls of salt): 1. you are right, turn it off at that point. 2. for that I plan to implement motion separation for camera movement and objects, and it should help with that, so only object's movement would get blurry, but not camera movement. 3. that is true, but at lower refresh rates, even at 60 hz, it really elevates the smoothness. If you have 144 hz screens, it can still help somewhat with smoothing very rapid movement, but if you care for performance, the change would be negligible. 4. yep, do your own considering and see what you prefer. I just aim to produce a better effect by default so you are not "forced" to turn it off hopefully. racing games and games that want to appear more cinematic. I think that at subtle levels it can also be in high fidelity shooter games like battlefield and COD. Up to developers at this point. Its really all about immersion an personal preferences.
Yeah I was playing rust, before disabling it, trying to jump to see over a fence I didn't enjoy my vision being covered in Vaseline when I'd have been able to see fine, jumping irl
@@runforitman You wouldn't see motion blur irl because our eyes do not have motion blur when moving. It only happens when objects move fast not the eyes. It is a thing that happens with *cameras* not eyes and the author did mention that. Google saccadic masking if you want this is how our brain cancels out motion blur.
I feel that _camera_ motion blur in first person games detracts from the experience, yes. However, I do enjoy _per-object_ motion blur in first person games. When a minigun is spinning in a characters hands, it's more visually appealing to have the barrels spin with some blur, and (especially when spinning up and not yet firing) a spinning minigun barrel is more obviously in motion with a bit of blur (granted, usually the character's stance&silhouette changes to indicate they are primed to fire, which is more visually obvious). Maybe the approach in the video could somehow use a velocity buffer that is not influenced by camera motion, or applies an inverse of the camera motion to eliminate its effect. After that, (if necessary) maybe a shader using this technique could only apply to objects with a "motion blurrable" tag enabled, as applied where deemed necessary between tech art and art teams. That said, I'm beyond my technical depth here, I might be missing a lot.
The issue with all artificial motion blur is that you can follow a fast moving object in real life with your eyes and then what is blurred in your field of vision inverts. Like if you’re looking at a car, the background should be blurred, but if you look at the background, the car should then blur. So artificial motion blur has to assume what you are in fact trying to focus on. I think this is what would contribute to motion sickness more than anything
@@sphynx_owner8224 thanks for the reply! I’m sure VR people have headaches about this when you start thinking about eye tracking vs head tracking (you can follow an object without moving your head), the fovea, etc etc…
This is why I always disable motion blur and depth of field in video games. I don't get motion sickness but nothing is worse than having stuff I'm trying to look at become a blurry mess.
@@sphynx_owner8224 It's a tricky problem to amplify motion without actually washing out the high frequency details that define an object in focus, quickly. As that is what's actually important to achieve with motion blur - bringing out the direction of an object through time, because you're stuck looking at a 2D projection of 3D space.
I expect it's more than a couple years away at the consumer level, but it would be really cool to see eye tracking used to shift the focus of motion blur. Perhaps the best motion blur algorithms will be the ones that are useful now, but also prepared to utilize such technology when it becomes available.
Goes to show that formal education needs an update. It needs to be more about promoting the joy of learning and teaching methods for sorting through information, and less about feeding kids data and testing how well they've memorized it. One teacher is all it takes to completely kill someone's potential interest in a given subject, and that's what school does a lot of the time by turning learning into a chore.
This is typical with tech professionals. There was a guy during crowdstrike who made a video saying he didn't know how to troubleshoot safe mode and read crash logs, not in that exact word, but basically argued those lines. I can easily run safe mode and pull up the program who crashed, which will tell me what the EXACT problem is. He's an idiot. I met a tech support at work who replaced some dead hard drives who said they used RAID 0. I seriously doubt that, and if true someone needs to be fired. This is most tech professionals in general today. This phenomenon is known, and I have heard that if the trend continues, we will reach a catastrophic event of failures because the people won't know how to fix anything. People are getting hired that don't deserve jobs, there's a system in place that rewards bad actors and keeps out talent, having ridiculous requirements of certification, experience, and personal connections, and it's not sustainable without causing a global crash. We maybe have 20 years without a correction. All the old talent is retiring, and we're left with idiots.
@@JohnDoe-ip3oq Not gonna lie, I'm a natural optimist, and my default position is it can't be all that bad, or correct thinking will prevail when its all said and done, but, based on recent events and personal experience, people be getting more and more idiotic as time goes by. Maybe we're just at that age when we start seeing it? On the other hand, my doctor's office just set up an automated online appointment system which doesn't let you send an appointment request outside office hours. IT'S AUTOMATED AND I ASSUME ASYNCHONOUS, WHY WOULD OPENING HOURS MATTER!?
Really nice work, this looks great. You know motion blur is good when the final image doesn't look like it's "motion blurred" (in the traditional video game sense), and it just looks a bit closer to photorealism
Very impressive. It doesn't matter that you don't have an academic background, you clearly have a natural talent for tech art. Talent like yours is scouted for all the time... In fact if I ever need a shader god one day, I'll know who to hire. Great job
This looks really fantastic, great work! I wonder if you'd be interested in giving a talk about this at GDC next March - talk submissions are opening shortly, and I think it'd be a great fit!
I played around with your demo (in godot 4.3, should've specified that. effect breaks in current release 4.2.2) and it looks really good. The centering did always bother me, so seeing someone create a version of the effect without that without compromising on performance is really nice. Good stuff.
Super impressive man, and it’s comforting to know you don’t have an academic background, I don’t have one myself but have been a programmer for 16 years. I have a number of projects that I have started upon, and then realised the amount of work rivals any degree course. Sometimes my projects lead me into areas I struggle to comprehend. I have also attempted to make motion blurring systems for Godot but could never quite produce something as realistic as this. Bravo!
This would not have been possible without the new compositor effect feature that was added to the beta, which exposes the render thread for you in engine and gives you access to velocity textures.
Best motion blur I've seen in a game was Quake 2 remaster. I don't know exactly what they did but it seemed like the blur amount was tied to an exposure duration of 1/350s instead of the framerate, so as the framerate fluctuates, the amount of blur stays constant. I have a suspicion that the reason why motion blur looks so wrong in a lot of games is because frame duration is not a constant in games which makes the length of the blur fluctuate from one frame to the next, in addition to being far too long. Interesting video!
frame independent blur is a feature that I have added recently, it may require a bit more attention though, and in my opinion goes against the whole "intuitiveness" thing. What I do agree is not letting the blur get smeared below a certain framerate, as to not be jarring.
I may be mistaken but I believe for Quake's case, because the basic game rendering is so cheap on modern hardware, they tell the engine to render at like 500fps internally and then composite all of those frames into a color accumulation buffer which gets presented at 60fps, which is the brute-force method of simulating how light from moving objects would actually collect on a camera or our retinas.
@@sphynx_owner8224 in cinema the exposure times generally never exceed 1/48th of a second (180° shutter angle), and many types of scenes call for much less yet.
Just want to congratulate on your effort regardless if its a new approach or not, it looks great! feels and plays great as well! The video is excellently executed as well. Congrats!
awesome work, I always wondered why game motion blur looked so different from cameras and raytraced 3D renders, its cool to see it visualized here. nice job on the paper and thanks for publishing it on github.
One of the problems with motion blur is that in real life if you track an object with your eyes, there is no motion blur, but a game assumes your eyes are locked at the center of your monitor and are never tracking objects.
True but camera based motion blur; which is how we capture the world, does look straight ahead. Therefore this method is the best you can hope for. Until all devices for gaming have eye tracking embedded in them and software authored to use it, this is gonna be as good as it gets.
Or instead of one camera we have two cameras one for each eyeball for stereoscopic vision, and write optional software for eye tracking hardware, when enabled you can independently track objects in the world with your eyes. DOF also needs this.
That's impressive. Motion blur done right shouldn't be obvious at all until it's paused and that's exactly what I experienced. When I first saw the final output my brain was like "what motion blur"? Well done, that looks perfect.
I'll never forget seeing the game Lost Planet, which was the first game I really remember noticing the motion blur in. I thought it looked so cinematic when the main character ran around. In my mind, it was the future of graphics right there. For the record, I'm sure it wasn't the first game to have it, but it was the first time I really noticed it. This video brings back some of that old excitement I had seeing motion blurring in a game. This is fantastic work, and I really appreciate that you shared so much information on how you came up with the solution. Super cool! Instant sub.
The big problem I see in game motion blur are the lack of arcs. Most of the time it looks like vector blur where stuff just blurs linearly, but when you're swinging a mouse around, the motion blur on a bright light or something should be curved like it would be in real life/a path traced engine like Cycles.
@@sphynx_owner8224 I've been into 3D, VFX and games forever, and I've never come across such a strong solution. Spent plenty of time thinking about it too! Short only of managing to include curve information for rendering wheels and such, this is the best realtime solution I've ever seen. I'll be dropping a personal invention in a similar spirit fairly soon, though it relates to colour, not motion blur. Keep showing them what's possible without a bloated budget!
@@sentinelav Its awesome to hear you have your own invention you can share with the world as well. As for the wheels, its an inherit limitation of having an instantaneous linear velocity buffer and not being able to sample it in infinitely small intervals, thus it is handled separately in any industry standard implementation. I am working on that as well with the focus of just getting it working well.
@@sphynx_owner8224 Yes, the instantaneous velocity aspect is definitely at the core of the problem. My thinking was that if you sample the current velocity and that of the previous frame, you could determine a curve to average across, instead of a linear path. The idea would be to project the vectors from the current frame to points on the previous frame. From these points, the *change in vector direction* would be determined. You'd be leveraging the fact that with two vectors, you'd essentially have enough information to draw a bezier curve. This is the concept, but in practice, I have no idea how to go about the implementation as I'm not *really* a shader programmer. I'd love to know your thoughts on the practicality of something like this!
I have given thought into that, and was able to extract things like curl coefficients into a texture, the problem is that my experience is rather limited with this, and it seems unrealistic to pursue currently. It WOULD be cool if I was able to take care of curves and wheels in the same blur, but it seems like radial blur for wheels is a safer approach.
This is a very cool break down! Each of the freeze frames in your demo look really great. It could be a cool experiment to make it respond to an area of focus (like gaze, but there probably isn't fast enough gaze tracking yet). Maybe if gaze tracking ever gets to that point in VR or something, the motion blur skeptics will be willing to keep it on.
This so so fascinating and well made, i started working on godot at the end of last year, but you are running laps around my head with the technical terms, great stuff, subbed maybe you will share more stuff to learn
I deeply appreciate your work. Motion blur that matches real life is my dream. BECAUSE, to me any frame rate above 30fps looks fake. There is a reason why 24fps is used for movies and that is because when they shifted to 60fps for TV, everyone thought it looked fake. Why? Motion blur. 24fps films are the most natural looking motion blurs and for this reason, we desperately need to emulate the motion blur that occurs in 24fps film. The end goal is reality and the pathway there is realistic motion blur.
There's no such thing as the perfect frame rate The same way there's no such thing as the perfect resolution Frame rate is just temporal resolution In general, the higher the better
The only reason why 24 FPS is the standard Is because back in the day of film we needed a way to record as much temporal resolution while still using the least amount of film per second 24 was just the sweet spot of extracting as many minutes out of a roll of film while still having relatively smooth motion
I, for one, love motion blur. I feel it makes the games I play look much more smooth and realistic. But I accept I'm not in the majority here. Even though I know almost nothing of computer rendering, I really liked your clear, concise and easy to grasp presentation here!
To me it really depends on the implementation. I like per object motion blue that emphasise fast movement of objects. It looks good. I hate motion blur that blurs the screen as I am looking around. I want clarity while looking around, not vaseline lens.
Hey, thanks for this! I haven't seen any games approach motion blur like you have, and to be frank I think you have the nicest looking motion blur to date. It manages to communicate fast motion without obscuring the image like most current motion blur does. I could definitely see myself using this in games if the option was available!
thank you. There is a full screen demo video I uploaded on my channel just before this one, but if you want you can do one better and try out the demo I have linked for yourself!
Hah this is a great solve for realtime motion blur! Back at uni I did my final year thesis on general motion blur (both in generating it algorithmically and performing velocity estimation from observed motion blur), and I would have been stoked if I'd come up with+refined anything as clever as this. Congrats
@@sphynx_owner8224 It could have been reddit and/or github. Not sure, but I definitely saw some of your other videos and posts there. Got yourself a sub 👍🏽
Great job! I was really impressed by your tenacity with this project and to bring it to completion must feel great. I’d love to talk to you about a project idea I’ve been thinking about for some time, but unable to find someone with the programming skills and interest to help me realise it.
Its not completed but getting it to a presentable state and showing it to the world had me shaking and crying in excitement. I would love to hear about that project idea of yours, but I cannot guarantee anything regarding being capable enough to pursue.
I could totally see this effect when combined with other camera artifacts like lenses distortion, grain, and light bokeh could lead to a very believable in-universe camera.
Thanks for sharing your work! It's very inspiring. I wonder if this technique could be extended for radial motion blur. That's probably much more complicated. For racing games, linear motion blur makes wheels look very strange, and I think it's important to make it look good for that genre.
Radial motion blur needs separate treatment all around (no pun intended), but I do have it on my sights regardless because its has to be added to the implementation that makes it to Godot. its is a rather confined effect that has a very specific use case, so ill just aim to getting it working well.
I think it's important to make a distinction between "camera motion blur" which applies to the velocity vectors of the environment when the camera is turned, versus "per-object motion blur" which applies instead to an object's animation. As others have pointed out, it's the disconnect between the parts of the environment that the player's eyes are tracking and the motion blur applied to those elements that causes this kind of motion sickness. The solution to this is to disable motion blur applied to the environment by changes to the camera or the velocity of the player character. But per-object motion blur applied to animations is hugely important for selling a naturalistic look and keeps things from looking like a hyperreal arcade game. Most games sadly offer only a single toggle to disable motion blur altogether for both the camera and object animations. I wish more developers understood this critical difference.
It is understood in this case, and in the future if i follow through, you would be able to select coefficients for each component of a velocity separately, that is the camera part of the velocity for the object and the object's world velocity. If that does not work worst case you would be able to turn them on and off separately.
This is really nice! You should clean the paper up a bit and put it on the arxiv! The approach is very interesting, you might get some traction there :)
@@sphynx_owner8224 The first part is to register! Sadly, you might need endorsement if you don't have an institutional affiliation (just write "independent researcher"), but it's worth trying :)
Definitely. Probably because it's so counter intuitive. But that's what makes it a great insight. The recent Radiance Cascades idea has a similar feel to me.
In unreal engine, it's obvious that thin foreground objects are not blurred outside their boundaries during camera rotation. This new method sounds promising. I'm not a fan of 'filmic' motion blur, but I like to use motion blur during fast camera rotation and disabling it with slower or no rotation, based on a curve. It's easy to implement and it could bridge polarized opinions. It's close to eye movement compensated motion blur, which is the perfect implementation because it blurs things that move in your eyes, rather than on screen only. I use backlight strobing with a high vertical total as well, together with perfect frame synchronization (v-sync & fps=hz=fps limit), so it looks even more like 1000 hz. I hope there will be sample and hold correction based on eye movement in the future. It uses an eye tracking device to update the position of each frame on screen as fast as the monitor is capable of. This minimizes sample and hold blur, more specifically the shifting of lower fps frames in your eyes when looking at moving objects (because your eyes don't stop moving 100 times per second to capture each frame sharply). If all of this sounds complicated and confusing, it is. Motion clarity is not simple to achieve, but it pays off in the end. The blurbusters website and the r/motionclarity subreddit are great recources on the topic.
This is also an idea i had. And one that is unintentionally present in my implementation, as the larger step size multiplier dictates the size of velocity in pixels that is required to be picked up by the dilation. I need to fix that, but i would still implement it as its own feature. A screen enthusiast like what i assume you are would probably not need this in all fairness, as 1000 hz is basically real life 🤣. Other techniques that were suggested and are on the agenda are center fade of the blur, to keep the center of the screen generally sharp, and all these solutions can coexist.
@@sphynx_owner8224 I just use a blueprint to calculate the camera rotation speed, make a threshold curve out of it and set the motion blur intensity with that. Another solution could be to do this per pixel on the GPU, to better discriminate still pixels from moving ones. Also, I do need the best motion blur that is available. I'm not rendering 1000 fps, just 100. Motion blur is one of the things that make it look like 1000 fps, but glitches are well visible at 100 fps and break the illusion.
Looks really nice, but I wish you had spent a bit of time comparing it to fast existing techniques in terms of performance. At least in the paper version. Brilliant work never the less, and thank you for releasing it under such a permissive license.
Great video! Really impressive stuff, even more so considering your background (or lack thereof?) Also, call me old, but I always turn motion blur off, because video games just look sharper and nicer without it, like they used to lmao
Nice. I'm not aware either of using JFA for motion blur, but it's been a while since I've looked. Jimenez motion blur for Call of Duty should still be among the state of the art. I'm not persuaded about the idea of "non-centered" motionblur and its effects on sickness, fwiw we've found that a good way to control motion sickness is to allow separate controls for camera motion blur versus object motion blur. Motionblur if you think about it physically, you should generate all intermediate images from the beginning to the end of the frame shutter time, and average them (in fact you can do exactly that, with brute-force sampling, to get a ground truth image easily) and so if an object is moving at a constant velocity during the exposure time, it will have a motion blur streak that starts from its position at the beginning and extends to its position at the end. The object appears "centered" in the image because at the center you have the most overlaps, while at the begin/end you didn't capture the object before that and after that, so there is no "trail" there. This is true only when you are simulating something that exposes into frames, e.g. film and so on, you can reason that eyes probably don't have a global shutter and so they work differently - maybe there is something there, perceptually might be better to motion blur in different ways, not sure. Lastly. I've skimmed your paper and watched the video, it's hard to tell whether or not this method ends up having more or less artefacts than the current state of the art - because in the end we always rely on heuristics of one kind or another, and the "devil" is exactly in these. You have to guess what direction is important, as most MB methods store only one (and there is room there for improvement!), and you have to hallucinate what is behind a moving object (disocclusions), as you have only one color buffer, and it's not easy to tell how your technique fares with these inherent problems of using one velocity and one color. The paper could use a few passes to make it more clear and readable in general, but if (IF!) you want to improve it, I'd suggest to focus a bit more on the heuristics. Good job!
There's a distinction that needs to be made between a symmetrical motion blur and Centered motion blur. A good motion blur would appear symmetrical around the core of a blurred object, but that center of the blurred object would be between where it is in the current frame and the past one. Centered motion blur does not average values in the past of an image, to heuristically get close to the average of all intermediate stages between the current frame and the last, but it does it half in the past, and half in the future, sort of extrapolating it beyond any potential path it may take. I think I do a pretty good job of laying it down in the video, but the final point is that it's center is around the object position in the current frame, where in reality it would be between the position in the current and the last frame, thus to my knowledge less accurate, and why I said what I said about it. I also laid out the reasons to have it from a technical motivation standpoint, which is not negligible. I hope to get close to any state of the art when it comes to robustness of the technique and quality of the final result, and while I'm presenting it here, I am still going to work on it a lot more as its very new still. The reason I even released all that I did about it is because I have to if I want it play-tested and eventually added to Godot, meaning it has to be public and under MIT. And since the video uploaded I have added to it quite a bit with the help of testers in the community. I appreciate the feedback regarding the video and paper. I at least suggest you watch the video in its fullest to get my point about centered blur, but I understand the lack of clarity, as I did not expect this to be on the same level as a proper academic video, and just do the job of communicating my very new discovery. You are correct to say that my motion blur is far from a perfect simulation of a real one, but compared to the state of the art, I believe I have found something special, which is why I even went to this length presenting it to the world. You are correct to assume that there are artifacts, but the fact of the matter is that for the artifacts you need to handle and tune out (and fix), you get an effect with an unmatched fidelity and resolution compared to the previous techniques that I have showcased, and with a complexity curve that is unheard of with those techniques either. As for the paper, I know its not perfect, but I'm also unsure where to improve it and solidify it, so I would accept any criticism/corrections and would change it accordingly. Especially since I come up with improvements to the technique very often.
@@sphynx_owner8224 So I agree that in practice MB does this slightly wrong thing of using a motion vector that is from this to last frame (backwards finite difference), and then interpreting that velocity as "half in the past half in the future". And that for the pragmatic reason that you know the motion blur should be "symmetrical" as you say, so it makes sense to "expand" the object color half/half, whilst it's impractical to determine the direction of that expansion using velocity that matching - half in the past, half in the future, as you'd need to compute and store an extra set of transforms (two to compute the velocity half/half and one to compute and render the "center" object position). Thinking of it - one could actually compute only two transforms - this frame and previous - and then render object color by averaging them, thus creating a color image that is "correctly" in-between. This would actually be very easy to do, conceptually, but a bit of a pain to patch everywhere transforms are passed in an engine I suspect, and most importantly, I doubt this is an important source of error. I might be wrong though! Might be fun to experiment, maybe making a quick prototype. I did watch the video, and I think I get (hopefully) the centered argument, it is very interesting indeed for a lot of other reasons too. Re: the paper - there are improvements that can be made simply to its wording used (eg I don't know what a "sharp" input buffer is - full resolution maybe?) and style (the code for example is quite ugly in its formatting and also relatively not optimal both in terms of performance and in terms of style), but these matter less... The thing that would imho matter the most is to explain clearly all the heuristics used with the motion vector JFA logic. E.g. "I use complex sets of conditiions that take depth and velocity directionality into account, some are non-continuous" - these would be nice to know more about (e.g. sample_fitness...). You talk of things like "perpendicular offset" and "parallel threshold" and then "perpendicular threshold" - none of these things are clear to me. Perhaps they would if I spent more time with the code - but those kinds of things are where I'd spend more time, maybe some illustrations etc. Good luck!
I solved the issue you mention at 4:00 in my reshade implementation (vort_Shaders) of the Guertin/McGuire/Jimenez motion blur by using prev frame color and depth. Thank you for bringing my attention to the issue. As far as I know, no other implementation of motion blur based on those papers has solved the issue, so maybe I'm first?
Amazing video, glad it appears on my feeds ! But now I want to test it on my end and see what's going on. I've seen the demo is under CC4 but I've also seen it was for proprietary use for Godot Engine in the paper. So I'm a bit confused about what I should do if I want to implement it in a personal project of mine (let's say a Game Engine for example) Aside from this, again, incredible work and research. Really mind opening
I do suggest that you wait a bit I'll be releasing a much better version very soon which would include a more robust and performant set of implementations for you to choose from
A zoomed in slow motion side by side with like 30, 60, 90 and 120fps would be great to judge of the quality of the effect with the same settings as well as the optimized number of passes for each. An other thing to look at is how it handles inconsistent framerate and frametime spikes, does it feel jarring then ? Does it play well with animation that are at a much lower frequency as the framerate, maybe the added smoothness of the frames with movement makes the frame in between. How does it handle jittery objects (like Bethesda physics) ? Having some control over the strength and distribution blur could be very interesting. Instead of only being a blur it could be used to create more of a smear effect, dilating the object more than distributing its light. If it looks good it could add a lot of artistic potential to Godot games that can't compete in the photorealism with other game engines.
Yay! Good real-time motion blur to go with! I personally don't understand people who turn off MB always. in all games. I can only relate if the implementation is awful. UE's implementation of MB is also somewhat interesting point of discussion, because i think in the majority of projects that utilise it, it instantly gives itself away that it's UE game with it's "UE look". It is somehow flawed i guess. Because if it would've been done right it wouldn't be obvious immediately and always. Thanks for sharing the method that you've researched and developed! I personally have been "researching"(impostor syndrome isn't taking it easy on me lol) emulation of halation effect that is present on photographic film, when a bright area is contrasted against a dark area, there's some subtle reddish-orange light that is spilling over to dark area from bright spot(it's very different to bloom). Imo it's quite PBR, it takes in Linear Rec709 framebuffer, so it has a realistic representation of what's bright and what's not. There's basically no info on how to emulate it, aside from tutorials for davinci-premiere-photoshop which are 1.for 8bit sRGB videos or images 2.completely non energy conserved 3.Most of them are just thriving for the "similar look" with no physical ground beneath it. Or there's also some proprietary solutions like davinci built-in halation, or dehancer plugin, they still work afaik only with sRGB. And also paid. Grasping inspiration from movies and images shot on film took this project far. I was really hooked when you mentioned about center or end motion blur, because 2 years ago i was playing around with blender cycles motion blur and was wondering, what would be the most accurate in respect to real cameras motion blur. I felt like default "center on frame" option might be not it, and default shutter curve might also be a bit inaccurate to what's happening in real camera. I stayed at default center on frame option(which after watching that vid seems to be incorrect), with shutter curve changed to triangle, with no actual testing being done, just "what felt right". What are your opinion on what would be the right settings? Thanks!
One of my problems with current motion blur implementations is that the vectors can only represent straight trajectories, causing incorrect blur on rotating objects or anything not moving in a straight line. Sometimes I try to think of a way to store "curved" motion vectors and solve this issue, but I can never come up with anything performant.
You dropped out of HS and wrote a paper? Damn that's really surprising and impressive! Despite being about to finish college I cant stand academia and writing paper and research. It's boring, I'm too hands on, too practical and impatient. Kudos!
Lovely work. If there is need for ground truth implementation for comparisons, I would suggest old good accumulation buffer. Render n images during the time shutter is open and average result. Can be used for AA and DoF as well. (As seen in Gran Turismo camera mode.)
I understand the distain that people have from motion blur effects, and its why I took such a stand on common practices in state of the art motion blur effects and avoided them such as centered blur. I hope and aim for my method and final product to stand out in its tolerability.
If its possible it would be nice if motion blur can be detached from the scene. As in, motion blur applies to everything except: enemies if there are enemies, anything beyond ~5 or 10 meters away from the camera, see through patterns/transparent materials like dirty windows and chain fences and camera movement that isn't forward (whip pans don't have motion blur but moving forward does) Project CARS 3 applies motion blur to everything close to the camera except the car body. Interestingly enough, doing a whip pan in third person and going into photo mode mid pan lets you explore the world with motion blur which is really cool and you can adjust the "shutter speed" motion blur amount while viewing the 3D motion blur.
Great work! People only notice motion blur when it's crappy and deduce 'all motion blur bad'. When it's good the they just deduce that the game looks good
Plenty of comments here make it clear to me that what people hate is camera motion blur, but they don't necessarily know what that it is or how it differs from object motion blur.
Seeing the greattl things you have achieved has renewed my inspiration. I too was a hughschool dropout, now trying my hardest to use godot ro the best of my abilities.
Hey S_O, great video--I loved the work that you demoed and your technique is super cool. The velocity channels were interesting but very had to watch for most of the video; it's data meant for a buffer not for viewing. That, and showing the 4 channels for most of the video meant that we couldn't really see the effect that you worked so hard on--even on my big monitor a quarter of the screen was just too small to see, let alone appreciate, the details. The clearest and cleanest example in your video was when you were pausing so we could actually inspect the motion blur effect you achieved. A side by side comparison of the action wih and without the effect would have gone a long way as well. I think what you made was really cool and I can't wait to learn more about it.
Thank you!! this video was not a showcase of the actual effect at its fullest, you are right. For that I have already released a video just before this one, and better yet, you can get the demo and experience it at full resolution!
here before viral ps: You should be proud of yourself, outstanding video, I understood most of it and im kinda slow 💀 so big ups to you and your channel 😁
I've heard so many weird arguments of gamers why they hate motion blur. My favorite "That's not how eyes work". Ignoring that motion blur doesn't try to simulate eyes but a moving object on a static screen between two frames. And that movement is happening, no matter if it's toonish, abstract or realism. I wonder how those people explain motion blur in videos and why objects are still blurry, no matter how hard they "track it with their eyes". The only real reasons to turn a quality motion blur off, are competitive fast shooter or games trying to fake a stop motion look. I think motion blur has gathered a bad reputation from PS2, up until a couple of years ago with low quality implementations, smearing it over multiple frames. Todays motion blurs are near perfect and your version looks great. I wouldn't even offer the option to turn it off :D
Because that's not how eyes work. If you're running 24fps - the frame rate of cinema, then yes, you need motion blur to not make it look rough, in cinema this is naturally achieved by the 1/48 shutter. 60fps content - i.e documentaries typically have a 1/125 shutter speed and thus far less blur, if any. Videogames ought to be run at 60fps + and don't simulate either documentary content or Cinema. They simulate live movement, which has no motion blur. Now a touch to smooth out the in-betweens at 60fps is down to taste, but it's absolutely not necessary and at higher frame rates is completely pointless.
I you watch "live movement" live on a screen, you'll get motion blur. As I said, "Everything that is happening between two frames. So of course, with higher fps, you'll get less drastic movement which needs less blur. And I won't disagree, that a couple of games overdid the effect. Looks especially bad if it stretches over multiple frames, resulting in a long blurry streak, even if the motion indicates that the blur should be curved. That wouldn't be the quality I'd advocate for. But motion blur itself is still important. I've seen streamers disabling motion blur. Just because chat said so. But they enable sharpening, play in 4K and then complain that their eyes hurt. Probably because of all the fast paced, crisp detail the game throws at them.
@@florianschmoldt8659 The blur isn't introduced between frames though, it's on the frame. My point is that on 60+ FPS blurring isn't necessary because the frame transitions are for most people nearly imperceptible or very easy to get used to. In regards to it not being how eyes work - blur on objects is one thing and fine, particularly when used for stylistic effect (e.g cars going fast). But blur on camera movement is where people have issues, when you pan your eyes across a scene in reality you don't do it smoothly, you skip between clear, static points. Motion blur on camera movement makes this impossible and itself causes eyestrain and motion sickness for some.
@@nebky What I was trying to say is that motion blur fakes the movement happening between frames. I'm mixed on camera motion blur. On one side, I don't see why I would have any other expectation how cameras work in games than real cameras. If I want my UE5 character to see, I give him a camera object and not "eyes" for a reason. The problem I see with camera motion blur is a technical one. If I spin my character 360, I'd expect heavy motion blur. But subtle movement can already introduce a long blur because the motion vector, based on a single frame reads as quick movement. That's indeed hard on the eyes. A good solution would probably be to scale the amount of blur based on distance and time.
@@florianschmoldt8659 yeah I can agree with that, at speeds where the eye isn't going to be able to track an object you probably want some blur to ease the rush of information. But typically if I'm moving the camera, first person or not, I want to be able to clearly focus on an object and follow it. Like I see an enemy, I move the camera to focus on them, my eyes continually stay on that point throughout the movement but during this the enemy becomes blurred. What's the point in that? It's unnatural (to how eyes work) and artificially reduces clarity. The difference is that in cinema/TV the blur of the camera movement is used intentionally or at least considered aesthetically. But in a game the movement of the camera is almost always functional. This is exactly why documentaries are filmed most often with static-ish shots at a higher frame rate or even slow motion giving it essentially 0 motion blur. The camera movement is functional and intends to keep the subject on screen, clear and crisp.
Great effect! There's just one thing that looks off with the final result: If something moves in front of a stationary background the background is also blurred. I think this is also a problem in the paper you mentioned and, for me, it kind of ruins the depth of the image. In real life this obviously doesn't happen, the background shouldn't get blurred. I thought about a solution to this problem using some kind of ID stored with the velocity data, but it's probably nearly impossible to resolve. Because if you were to not blur the background, the bluring of the foreground object would kind of create a transparency 'hole' in the image, where we wouldn't have any background info to fill it in with.
I actually fixed it in the latest implementation. It was all down to my blending heuristics rather then the velocity dilation method. Its looking much better in terms of quality and cleanliness, and I recommend you download the latest version of the demo and check for yourself. As for the blurring of the object itself, I have to "fake" its transparency by sampling ahead of it still, technically "smearing the background", but the trailing edge blurring correctly for change gets you most of the way there.
These are all very good points you are making, I don't have clear answers yet but here's what I have to say: 1. My focus was on getting a high quality result with this method, so chances are that in its current state it is less performant than other methods at similar dilation radius on HD screens. What CAN be said in the favor of the current method, is the fact that the increase in dilation radius only asks for a logarithmic increase in processing power, without sacrifice of any details or fidelity, which is unheard of with the other methods I have showcased in the video which require a linear increase. 2. I have showcased a full screen view of the blur in action in a previous video. if that does not suffice, you are welcome to try the demo for yourself and see it at full resolution! 3. The limitation with this current method, and every other method as far as I'm aware, is that it captures the movement as it is at the instant the frame is taken. In order to show the wings of that vehicle's motion range at a consistent blur, which I believe move rapidly like a hummingbird, I would have to capture the game at a higher framerate than the rate of wing flap. At that point yeah, no problem.
@@sphynx_owner8224 I've never touched Godot but I'll try your demo on my 3060 machine. Thanks for the response. I'll be following your work on UA-cam. It seems high frequency per object motion blur is still a white whale. I wonder how the wings would look beating below 60hz. I assume the same limitation applies to rotational motion for the spokes on a car wheel. Also wondering how much work it would be to convincingly fake it in your method. Thinking about motion blur in games is a bit mind-bending as filmmakers think about motion blur in terms of shutter angle or shutter speed/exposure time with a constant frame rate. In films 90° at 30fps is already considered an "action" shutter speed with minimal blur so basically equivalent to 360° at 120fps with each frame fully smearing into each other, only without the stuttery feeling. So I wonder at what point is it more realistic to just omit the motion blur and have the extra performance? In a game, it ideally would also be static at a fixed frame rate but in reality, it is constantly in flux, and gamers (including me) don't like being locked to a certain FPS. I can forgive being capped during cinematics where such artistic control is most important. Games shouldn't have a constant motion blur setting like they do now. It should be dynamic based on the gameplay situation. Low to none during fast-paced combat and liberal amounts during the lulls between based on art direction, where twitch reaction isn't necessary.
@@shApYT I think the connection between game motion blur and camera one is only analogous, with the camera shutter being the reference frame for motion blur effects, but is not the limit, nor should it serve as some sort of standard. While motion blur can simulate the shutter of a camera, it can also just be treated as a way to smooth your experience with the same refresh rates, and each of those approaches can be satisfied by my implementation in multitude of ways. For gamers, I think its up to you to decide what you can afford and what you want your experience to look like. What I think is up to me and developers adding the motion blur to their game is to make sure it would not be in the way of your experience to the point that you have to turn it off. As for the wings and wheels, yeah it would need to be specially handled and has to be done separately.
What nobody talks about is that motion blur in games negatively interferes with the fact that monitors don't strobe, but instead display the image for a certain period of time, further creating a blur on objects that move across the screen. That's the reason I disable motion blur, because both of those effects together are just simply to much for me. On the other hand, if your screen would be strobing, it would be possible to follow a moving object with perfect clarity with your eyes. There's is no reason to reduce clarity with an artificial motion blur. Reality does not have motion blur. If you follow a moving object with your eyes, it appears completely clear.
4:40 : I hate motion blur because:
1) I play fast paced games where it's crucial to know the exact silhouette.
2) Looking around ingime is more like turning your entire head than head + eyes. You cant account for my eye wandering around and tracking things not just in front of me. Similarly why depth of field is annoying because you cant know what at any given moment im focusing on rather than just assuming that the stuff straight ahead is what im looking at.
3) I get more than enough blur from my monitor when looking around ingame.
4) Given the annoyances above it's not worth spending more GPU resources for me. It would have to give me FPS in order fo me to be worth it.
EDIT: For racing games its crucial tho. And for that it seems like a very good one.
This is a very insightful laydown of issues, here's my answer to each one (take it with handfuls of salt):
1. you are right, turn it off at that point.
2. for that I plan to implement motion separation for camera movement and objects, and it should help with that, so only object's movement would get blurry, but not camera movement.
3. that is true, but at lower refresh rates, even at 60 hz, it really elevates the smoothness. If you have 144 hz screens, it can still help somewhat with smoothing very rapid movement, but if you care for performance, the change would be negligible.
4. yep, do your own considering and see what you prefer. I just aim to produce a better effect by default so you are not "forced" to turn it off hopefully.
racing games and games that want to appear more cinematic. I think that at subtle levels it can also be in high fidelity shooter games like battlefield and COD. Up to developers at this point. Its really all about immersion an personal preferences.
Yeah
I was playing rust, before disabling it, trying to jump to see over a fence
I didn't enjoy my vision being covered in Vaseline when I'd have been able to see fine, jumping irl
@@runforitman You wouldn't see motion blur irl because our eyes do not have motion blur when moving. It only happens when objects move fast not the eyes. It is a thing that happens with *cameras* not eyes and the author did mention that. Google saccadic masking if you want this is how our brain cancels out motion blur.
i love motion blur because it's fun
I feel that _camera_ motion blur in first person games detracts from the experience, yes. However, I do enjoy _per-object_ motion blur in first person games.
When a minigun is spinning in a characters hands, it's more visually appealing to have the barrels spin with some blur, and (especially when spinning up and not yet firing) a spinning minigun barrel is more obviously in motion with a bit of blur (granted, usually the character's stance&silhouette changes to indicate they are primed to fire, which is more visually obvious).
Maybe the approach in the video could somehow use a velocity buffer that is not influenced by camera motion, or applies an inverse of the camera motion to eliminate its effect. After that, (if necessary) maybe a shader using this technique could only apply to objects with a "motion blurrable" tag enabled, as applied where deemed necessary between tech art and art teams. That said, I'm beyond my technical depth here, I might be missing a lot.
1. interesting topic
2. presented clearly
3. straight to the point
yea this is a sub for me. good work!
Thank you!
Me too
I think it’s even more impressive that you managed to do this on your own, many people who are in school don’t want to go anywhere this kind of work
Thank you for the kind words!
The issue with all artificial motion blur is that you can follow a fast moving object in real life with your eyes and then what is blurred in your field of vision inverts. Like if you’re looking at a car, the background should be blurred, but if you look at the background, the car should then blur. So artificial motion blur has to assume what you are in fact trying to focus on. I think this is what would contribute to motion sickness more than anything
That is a very good point and I think it is more significant to the problem than my argument about centered blur. Thank you for pointing it out!
@@sphynx_owner8224 thanks for the reply! I’m sure VR people have headaches about this when you start thinking about eye tracking vs head tracking (you can follow an object without moving your head), the fovea, etc etc…
This is why I always disable motion blur and depth of field in video games. I don't get motion sickness but nothing is worse than having stuff I'm trying to look at become a blurry mess.
@@sphynx_owner8224 It's a tricky problem to amplify motion without actually washing out the high frequency details that define an object in focus, quickly.
As that is what's actually important to achieve with motion blur - bringing out the direction of an object through time, because you're stuck looking at a 2D projection of 3D space.
I expect it's more than a couple years away at the consumer level, but it would be really cool to see eye tracking used to shift the focus of motion blur.
Perhaps the best motion blur algorithms will be the ones that are useful now, but also prepared to utilize such technology when it becomes available.
bro dropped out of high school and still wrote a better paper than me or any of my peers. damn.
Goes to show that formal education needs an update. It needs to be more about promoting the joy of learning and teaching methods for sorting through information, and less about feeding kids data and testing how well they've memorized it. One teacher is all it takes to completely kill someone's potential interest in a given subject, and that's what school does a lot of the time by turning learning into a chore.
This is typical with tech professionals. There was a guy during crowdstrike who made a video saying he didn't know how to troubleshoot safe mode and read crash logs, not in that exact word, but basically argued those lines. I can easily run safe mode and pull up the program who crashed, which will tell me what the EXACT problem is. He's an idiot. I met a tech support at work who replaced some dead hard drives who said they used RAID 0. I seriously doubt that, and if true someone needs to be fired. This is most tech professionals in general today. This phenomenon is known, and I have heard that if the trend continues, we will reach a catastrophic event of failures because the people won't know how to fix anything. People are getting hired that don't deserve jobs, there's a system in place that rewards bad actors and keeps out talent, having ridiculous requirements of certification, experience, and personal connections, and it's not sustainable without causing a global crash. We maybe have 20 years without a correction. All the old talent is retiring, and we're left with idiots.
@@JohnDoe-ip3oq Not gonna lie, I'm a natural optimist, and my default position is it can't be all that bad, or correct thinking will prevail when its all said and done, but, based on recent events and personal experience, people be getting more and more idiotic as time goes by. Maybe we're just at that age when we start seeing it? On the other hand, my doctor's office just set up an automated online appointment system which doesn't let you send an appointment request outside office hours. IT'S AUTOMATED AND I ASSUME ASYNCHONOUS, WHY WOULD OPENING HOURS MATTER!?
The actual tech on display here is impressive, but your demonstration of it is even more remarkable. Well done!
Appreciate it!
When you add something that isn't contradictory to a thought, use the conjunction "and," not "but".
Really nice work, this looks great. You know motion blur is good when the final image doesn't look like it's "motion blurred" (in the traditional video game sense), and it just looks a bit closer to photorealism
Thank you! this is awesome to hear. You should try the demo and see it in full resolution if you haven't already.
Very impressive. It doesn't matter that you don't have an academic background, you clearly have a natural talent for tech art. Talent like yours is scouted for all the time... In fact if I ever need a shader god one day, I'll know who to hire. Great job
This looks really fantastic, great work! I wonder if you'd be interested in giving a talk about this at GDC next March - talk submissions are opening shortly, and I think it'd be a great fit!
I would be honored, and the possibility sounds amazing! I would look into it at some point and see if its even possible, thank you for suggesting it.
I played around with your demo (in godot 4.3, should've specified that. effect breaks in current release 4.2.2) and it looks really good. The centering did always bother me, so seeing someone create a version of the effect without that without compromising on performance is really nice. Good stuff.
Super impressive man, and it’s comforting to know you don’t have an academic background, I don’t have one myself but have been a programmer for 16 years. I have a number of projects that I have started upon, and then realised the amount of work rivals any degree course. Sometimes my projects lead me into areas I struggle to comprehend. I have also attempted to make motion blurring systems for Godot but could never quite produce something as realistic as this. Bravo!
This would not have been possible without the new compositor effect feature that was added to the beta, which exposes the render thread for you in engine and gives you access to velocity textures.
Best motion blur I've seen in a game was Quake 2 remaster. I don't know exactly what they did but it seemed like the blur amount was tied to an exposure duration of 1/350s instead of the framerate, so as the framerate fluctuates, the amount of blur stays constant. I have a suspicion that the reason why motion blur looks so wrong in a lot of games is because frame duration is not a constant in games which makes the length of the blur fluctuate from one frame to the next, in addition to being far too long. Interesting video!
frame independent blur is a feature that I have added recently, it may require a bit more attention though, and in my opinion goes against the whole "intuitiveness" thing. What I do agree is not letting the blur get smeared below a certain framerate, as to not be jarring.
I may be mistaken but I believe for Quake's case, because the basic game rendering is so cheap on modern hardware, they tell the engine to render at like 500fps internally and then composite all of those frames into a color accumulation buffer which gets presented at 60fps, which is the brute-force method of simulating how light from moving objects would actually collect on a camera or our retinas.
@@sphynx_owner8224 in cinema the exposure times generally never exceed 1/48th of a second (180° shutter angle), and many types of scenes call for much less yet.
Just want to congratulate on your effort regardless if its a new approach or not, it looks great! feels and plays great as well! The video is excellently executed as well. Congrats!
Thank you!
awesome work, I always wondered why game motion blur looked so different from cameras and raytraced 3D renders, its cool to see it visualized here. nice job on the paper and thanks for publishing it on github.
One of the problems with motion blur is that in real life if you track an object with your eyes, there is no motion blur, but a game assumes your eyes are locked at the center of your monitor and are never tracking objects.
True but camera based motion blur; which is how we capture the world, does look straight ahead. Therefore this method is the best you can hope for. Until all devices for gaming have eye tracking embedded in them and software authored to use it, this is gonna be as good as it gets.
Or instead of one camera we have two cameras one for each eyeball for stereoscopic vision, and write optional software for eye tracking hardware, when enabled you can independently track objects in the world with your eyes. DOF also needs this.
That's impressive. Motion blur done right shouldn't be obvious at all until it's paused and that's exactly what I experienced. When I first saw the final output my brain was like "what motion blur"? Well done, that looks perfect.
I'll never forget seeing the game Lost Planet, which was the first game I really remember noticing the motion blur in. I thought it looked so cinematic when the main character ran around. In my mind, it was the future of graphics right there. For the record, I'm sure it wasn't the first game to have it, but it was the first time I really noticed it.
This video brings back some of that old excitement I had seeing motion blurring in a game. This is fantastic work, and I really appreciate that you shared so much information on how you came up with the solution. Super cool! Instant sub.
Amazing work, especially for a sphynx cat. Bravo
Trying my best :)
The big problem I see in game motion blur are the lack of arcs. Most of the time it looks like vector blur where stuff just blurs linearly, but when you're swinging a mouse around, the motion blur on a bright light or something should be curved like it would be in real life/a path traced engine like Cycles.
Looks incredible mate! Love that this was a self-driven pursuit.
Would not have done it if it wasn't interesting at least. Thank you!
@@sphynx_owner8224 I've been into 3D, VFX and games forever, and I've never come across such a strong solution. Spent plenty of time thinking about it too! Short only of managing to include curve information for rendering wheels and such, this is the best realtime solution I've ever seen.
I'll be dropping a personal invention in a similar spirit fairly soon, though it relates to colour, not motion blur. Keep showing them what's possible without a bloated budget!
@@sentinelav Its awesome to hear you have your own invention you can share with the world as well. As for the wheels, its an inherit limitation of having an instantaneous linear velocity buffer and not being able to sample it in infinitely small intervals, thus it is handled separately in any industry standard implementation. I am working on that as well with the focus of just getting it working well.
@@sphynx_owner8224 Yes, the instantaneous velocity aspect is definitely at the core of the problem.
My thinking was that if you sample the current velocity and that of the previous frame, you could determine a curve to average across, instead of a linear path.
The idea would be to project the vectors from the current frame to points on the previous frame. From these points, the *change in vector direction* would be determined. You'd be leveraging the fact that with two vectors, you'd essentially have enough information to draw a bezier curve.
This is the concept, but in practice, I have no idea how to go about the implementation as I'm not *really* a shader programmer. I'd love to know your thoughts on the practicality of something like this!
I have given thought into that, and was able to extract things like curl coefficients into a texture, the problem is that my experience is rather limited with this, and it seems unrealistic to pursue currently. It WOULD be cool if I was able to take care of curves and wheels in the same blur, but it seems like radial blur for wheels is a safer approach.
This is a very cool break down! Each of the freeze frames in your demo look really great. It could be a cool experiment to make it respond to an area of focus (like gaze, but there probably isn't fast enough gaze tracking yet). Maybe if gaze tracking ever gets to that point in VR or something, the motion blur skeptics will be willing to keep it on.
This so so fascinating and well made, i started working on godot at the end of last year, but you are running laps around my head with the technical terms, great stuff, subbed maybe you will share more stuff to learn
Saw the screen at 6:02 and immediately thought "Yeah, you're going the JFA way!". Awesome work!
I deeply appreciate your work. Motion blur that matches real life is my dream. BECAUSE, to me any frame rate above 30fps looks fake. There is a reason why 24fps is used for movies and that is because when they shifted to 60fps for TV, everyone thought it looked fake. Why? Motion blur. 24fps films are the most natural looking motion blurs and for this reason, we desperately need to emulate the motion blur that occurs in 24fps film. The end goal is reality and the pathway there is realistic motion blur.
There's no such thing as the perfect frame rate
The same way there's no such thing as the perfect resolution
Frame rate is just temporal resolution
In general, the higher the better
The only reason why 24 FPS is the standard
Is because back in the day of film we needed a way to record as much temporal resolution while still using the least amount of film per second
24 was just the sweet spot of extracting as many minutes out of a roll of film while still having relatively smooth motion
This is a really interesting approach with a pretty exceptionally looking result. Awesome work!
Thank you!
This is so cool. Especially that you documented your work in a paper. Thank you very much!
I, for one, love motion blur. I feel it makes the games I play look much more smooth and realistic. But I accept I'm not in the majority here.
Even though I know almost nothing of computer rendering, I really liked your clear, concise and easy to grasp presentation here!
To me it really depends on the implementation.
I like per object motion blue that emphasise fast movement of objects. It looks good.
I hate motion blur that blurs the screen as I am looking around. I want clarity while looking around, not vaseline lens.
If you guys want to help with playtesting and giving feedback, feel free do go to the Godot Effects and Shaders discord at: discord.gg/MhfCkhV42T
youre showing it in such a fun way! and youre a sphynx cat so extra points for that
Hey, thanks for this! I haven't seen any games approach motion blur like you have, and to be frank I think you have the nicest looking motion blur to date. It manages to communicate fast motion without obscuring the image like most current motion blur does. I could definitely see myself using this in games if the option was available!
Thank you so much!
Aw man, you actually gave me hope that you solved the general case for curved motion blur. In all seriousness, great job!
That was absolutely smooth mate! Great video!
Nice work mate, don't know how this ended up in my feed but I'm glad it did. Subbed for more.
Nicely done. I would ask for a full screen result video clip though. It’s a bit hard to tell if there are artifacts on the 1/4 screen.
thank you. There is a full screen demo video I uploaded on my channel just before this one, but if you want you can do one better and try out the demo I have linked for yourself!
Beautiful presentation. I hope you do make it to GDC and do a talk!
I love it, that end result it's just amazing
beautiful work, hope this will be adopted in the industry
Hah this is a great solve for realtime motion blur! Back at uni I did my final year thesis on general motion blur (both in generating it algorithmically and performing velocity estimation from observed motion blur), and I would have been stoked if I'd come up with+refined anything as clever as this. Congrats
you would be a great teacher.
Great work! Looking forwards to seeing it in games real soon!
Really great video - and a really great and performant motion blur technique!
honestly, this is impressive, great job!!
This video will help a lot of game developers out there , from solo indie beginners to big commercials 👍
I was coincidentally reading the thread yesterday. Slick stuff indeed 👍🏽
Thank you! Care to elaborate which thread you saw this on?
@@sphynx_owner8224 It could have been reddit and/or github. Not sure, but I definitely saw some of your other videos and posts there.
Got yourself a sub 👍🏽
amazing work. great video. this channel will take off i can feel it
I'm just happy people enjoy this video, it means a lot to me.
Super impressive. Excellent work.
great explanation, amazing work!!!
keep it up
awesome presentation and visuals!
Thank you!
looks awesome, most high school graduates couldn't put this shit together, well done friend
Great job! I was really impressed by your tenacity with this project and to bring it to completion must feel great. I’d love to talk to you about a project idea I’ve been thinking about for some time, but unable to find someone with the programming skills and interest to help me realise it.
Its not completed but getting it to a presentable state and showing it to the world had me shaking and crying in excitement. I would love to hear about that project idea of yours, but I cannot guarantee anything regarding being capable enough to pursue.
"How does this have so few views?" I thought and realized that the video is only a few days old. Well, I hope you get some recognition for this!
This is by far my best performing video, and I am very satisfied. Thank you!
Easily subbed. Very concise. Keep up the good work, you are going places if you want to.
I could totally see this effect when combined with other camera artifacts like lenses distortion, grain, and light bokeh could lead to a very believable in-universe camera.
Thanks for sharing your work! It's very inspiring. I wonder if this technique could be extended for radial motion blur. That's probably much more complicated. For racing games, linear motion blur makes wheels look very strange, and I think it's important to make it look good for that genre.
Radial motion blur needs separate treatment all around (no pun intended), but I do have it on my sights regardless because its has to be added to the implementation that makes it to Godot. its is a rather confined effect that has a very specific use case, so ill just aim to getting it working well.
@@sphynx_owner8224 I look forward to seeing what you develop!
I think it's important to make a distinction between "camera motion blur" which applies to the velocity vectors of the environment when the camera is turned, versus "per-object motion blur" which applies instead to an object's animation. As others have pointed out, it's the disconnect between the parts of the environment that the player's eyes are tracking and the motion blur applied to those elements that causes this kind of motion sickness. The solution to this is to disable motion blur applied to the environment by changes to the camera or the velocity of the player character. But per-object motion blur applied to animations is hugely important for selling a naturalistic look and keeps things from looking like a hyperreal arcade game. Most games sadly offer only a single toggle to disable motion blur altogether for both the camera and object animations. I wish more developers understood this critical difference.
It is understood in this case, and in the future if i follow through, you would be able to select coefficients for each component of a velocity separately, that is the camera part of the velocity for the object and the object's world velocity. If that does not work worst case you would be able to turn them on and off separately.
This is some really impressive work!
This is really nice! You should clean the paper up a bit and put it on the arxiv! The approach is very interesting, you might get some traction there :)
Thank you! I wish I knew how 😅
@@sphynx_owner8224 The first part is to register! Sadly, you might need endorsement if you don't have an institutional affiliation (just write "independent researcher"), but it's worth trying :)
Excellent video!
Also really glad to see the JFA algorithm getting some more love.
underutilized I say
Definitely. Probably because it's so counter intuitive. But that's what makes it a great insight.
The recent Radiance Cascades idea has a similar feel to me.
Keep going, love your stuff!
it's good that you took your time to do proper research.
Great video with great attention to detail. Well done.
In unreal engine, it's obvious that thin foreground objects are not blurred outside their boundaries during camera rotation. This new method sounds promising.
I'm not a fan of 'filmic' motion blur, but I like to use motion blur during fast camera rotation and disabling it with slower or no rotation, based on a curve. It's easy to implement and it could bridge polarized opinions. It's close to eye movement compensated motion blur, which is the perfect implementation because it blurs things that move in your eyes, rather than on screen only.
I use backlight strobing with a high vertical total as well, together with perfect frame synchronization (v-sync & fps=hz=fps limit), so it looks even more like 1000 hz. I hope there will be sample and hold correction based on eye movement in the future. It uses an eye tracking device to update the position of each frame on screen as fast as the monitor is capable of. This minimizes sample and hold blur, more specifically the shifting of lower fps frames in your eyes when looking at moving objects (because your eyes don't stop moving 100 times per second to capture each frame sharply).
If all of this sounds complicated and confusing, it is. Motion clarity is not simple to achieve, but it pays off in the end. The blurbusters website and the r/motionclarity subreddit are great recources on the topic.
This is also an idea i had. And one that is unintentionally present in my implementation, as the larger step size multiplier dictates the size of velocity in pixels that is required to be picked up by the dilation. I need to fix that, but i would still implement it as its own feature. A screen enthusiast like what i assume you are would probably not need this in all fairness, as 1000 hz is basically real life 🤣. Other techniques that were suggested and are on the agenda are center fade of the blur, to keep the center of the screen generally sharp, and all these solutions can coexist.
@@sphynx_owner8224 I just use a blueprint to calculate the camera rotation speed, make a threshold curve out of it and set the motion blur intensity with that. Another solution could be to do this per pixel on the GPU, to better discriminate still pixels from moving ones.
Also, I do need the best motion blur that is available. I'm not rendering 1000 fps, just 100. Motion blur is one of the things that make it look like 1000 fps, but glitches are well visible at 100 fps and break the illusion.
Good work! Thank you for sharing this.
Looks really nice, but I wish you had spent a bit of time comparing it to fast existing techniques in terms of performance. At least in the paper version. Brilliant work never the less, and thank you for releasing it under such a permissive license.
Awesome stuff bro!!
looks awesome and natural.
Great video! Really impressive stuff, even more so considering your background (or lack thereof?)
Also, call me old, but I always turn motion blur off, because video games just look sharper and nicer without it, like they used to lmao
Nice. I'm not aware either of using JFA for motion blur, but it's been a while since I've looked. Jimenez motion blur for Call of Duty should still be among the state of the art. I'm not persuaded about the idea of "non-centered" motionblur and its effects on sickness, fwiw we've found that a good way to control motion sickness is to allow separate controls for camera motion blur versus object motion blur. Motionblur if you think about it physically, you should generate all intermediate images from the beginning to the end of the frame shutter time, and average them (in fact you can do exactly that, with brute-force sampling, to get a ground truth image easily) and so if an object is moving at a constant velocity during the exposure time, it will have a motion blur streak that starts from its position at the beginning and extends to its position at the end. The object appears "centered" in the image because at the center you have the most overlaps, while at the begin/end you didn't capture the object before that and after that, so there is no "trail" there. This is true only when you are simulating something that exposes into frames, e.g. film and so on, you can reason that eyes probably don't have a global shutter and so they work differently - maybe there is something there, perceptually might be better to motion blur in different ways, not sure. Lastly. I've skimmed your paper and watched the video, it's hard to tell whether or not this method ends up having more or less artefacts than the current state of the art - because in the end we always rely on heuristics of one kind or another, and the "devil" is exactly in these. You have to guess what direction is important, as most MB methods store only one (and there is room there for improvement!), and you have to hallucinate what is behind a moving object (disocclusions), as you have only one color buffer, and it's not easy to tell how your technique fares with these inherent problems of using one velocity and one color. The paper could use a few passes to make it more clear and readable in general, but if (IF!) you want to improve it, I'd suggest to focus a bit more on the heuristics. Good job!
There's a distinction that needs to be made between a symmetrical motion blur and Centered motion blur. A good motion blur would appear symmetrical around the core of a blurred object, but that center of the blurred object would be between where it is in the current frame and the past one. Centered motion blur does not average values in the past of an image, to heuristically get close to the average of all intermediate stages between the current frame and the last, but it does it half in the past, and half in the future, sort of extrapolating it beyond any potential path it may take. I think I do a pretty good job of laying it down in the video, but the final point is that it's center is around the object position in the current frame, where in reality it would be between the position in the current and the last frame, thus to my knowledge less accurate, and why I said what I said about it. I also laid out the reasons to have it from a technical motivation standpoint, which is not negligible.
I hope to get close to any state of the art when it comes to robustness of the technique and quality of the final result, and while I'm presenting it here, I am still going to work on it a lot more as its very new still. The reason I even released all that I did about it is because I have to if I want it play-tested and eventually added to Godot, meaning it has to be public and under MIT. And since the video uploaded I have added to it quite a bit with the help of testers in the community.
I appreciate the feedback regarding the video and paper. I at least suggest you watch the video in its fullest to get my point about centered blur, but I understand the lack of clarity, as I did not expect this to be on the same level as a proper academic video, and just do the job of communicating my very new discovery.
You are correct to say that my motion blur is far from a perfect simulation of a real one, but compared to the state of the art, I believe I have found something special, which is why I even went to this length presenting it to the world. You are correct to assume that there are artifacts, but the fact of the matter is that for the artifacts you need to handle and tune out (and fix), you get an effect with an unmatched fidelity and resolution compared to the previous techniques that I have showcased, and with a complexity curve that is unheard of with those techniques either.
As for the paper, I know its not perfect, but I'm also unsure where to improve it and solidify it, so I would accept any criticism/corrections and would change it accordingly. Especially since I come up with improvements to the technique very often.
@@sphynx_owner8224 So I agree that in practice MB does this slightly wrong thing of using a motion vector that is from this to last frame (backwards finite difference), and then interpreting that velocity as "half in the past half in the future". And that for the pragmatic reason that you know the motion blur should be "symmetrical" as you say, so it makes sense to "expand" the object color half/half, whilst it's impractical to determine the direction of that expansion using velocity that matching - half in the past, half in the future, as you'd need to compute and store an extra set of transforms (two to compute the velocity half/half and one to compute and render the "center" object position).
Thinking of it - one could actually compute only two transforms - this frame and previous - and then render object color by averaging them, thus creating a color image that is "correctly" in-between. This would actually be very easy to do, conceptually, but a bit of a pain to patch everywhere transforms are passed in an engine I suspect, and most importantly, I doubt this is an important source of error. I might be wrong though! Might be fun to experiment, maybe making a quick prototype.
I did watch the video, and I think I get (hopefully) the centered argument, it is very interesting indeed for a lot of other reasons too.
Re: the paper - there are improvements that can be made simply to its wording used (eg I don't know what a "sharp" input buffer is - full resolution maybe?) and style (the code for example is quite ugly in its formatting and also relatively not optimal both in terms of performance and in terms of style), but these matter less... The thing that would imho matter the most is to explain clearly all the heuristics used with the motion vector JFA logic. E.g. "I use complex sets of conditiions that take depth and velocity directionality into account, some are non-continuous" - these would be nice to know more about (e.g. sample_fitness...).
You talk of things like "perpendicular offset" and "parallel threshold" and then "perpendicular threshold" - none of these things are clear to me. Perhaps they would if I spent more time with the code - but those kinds of things are where I'd spend more time, maybe some illustrations etc.
Good luck!
Nice video! I really wish it showed the performance impact compared to other motion blur techniques.
I solved the issue you mention at 4:00 in my reshade implementation (vort_Shaders) of the Guertin/McGuire/Jimenez motion blur by using prev frame color and depth.
Thank you for bringing my attention to the issue. As far as I know, no other implementation of motion blur based on those papers has solved the issue, so maybe I'm first?
Amazing! Thanks keep on good work
Thank you for this! Really awesome!
Amazing video, glad it appears on my feeds !
But now I want to test it on my end and see what's going on. I've seen the demo is under CC4 but I've also seen it was for proprietary use for Godot Engine in the paper. So I'm a bit confused about what I should do if I want to implement it in a personal project of mine (let's say a Game Engine for example)
Aside from this, again, incredible work and research. Really mind opening
I misused the word proprietary. its under MIT license
@@sphynx_owner8224 Very good to know, thanks a lot !
I do suggest that you wait a bit I'll be releasing a much better version very soon which would include a more robust and performant set of implementations for you to choose from
A zoomed in slow motion side by side with like 30, 60, 90 and 120fps would be great to judge of the quality of the effect with the same settings as well as the optimized number of passes for each.
An other thing to look at is how it handles inconsistent framerate and frametime spikes, does it feel jarring then ?
Does it play well with animation that are at a much lower frequency as the framerate, maybe the added smoothness of the frames with movement makes the frame in between.
How does it handle jittery objects (like Bethesda physics) ?
Having some control over the strength and distribution blur could be very interesting. Instead of only being a blur it could be used to create more of a smear effect, dilating the object more than distributing its light.
If it looks good it could add a lot of artistic potential to Godot games that can't compete in the photorealism with other game engines.
Didn't watch the full video but Impressive
Yay! Good real-time motion blur to go with! I personally don't understand people who turn off MB always. in all games. I can only relate if the implementation is awful.
UE's implementation of MB is also somewhat interesting point of discussion, because i think in the majority of projects that utilise it, it instantly gives itself away that it's UE game with it's "UE look". It is somehow flawed i guess. Because if it would've been done right it wouldn't be obvious immediately and always.
Thanks for sharing the method that you've researched and developed! I personally have been "researching"(impostor syndrome isn't taking it easy on me lol) emulation of halation effect that is present on photographic film, when a bright area is contrasted against a dark area, there's some subtle reddish-orange light that is spilling over to dark area from bright spot(it's very different to bloom). Imo it's quite PBR, it takes in Linear Rec709 framebuffer, so it has a realistic representation of what's bright and what's not. There's basically no info on how to emulate it, aside from tutorials for davinci-premiere-photoshop which are 1.for 8bit sRGB videos or images 2.completely non energy conserved 3.Most of them are just thriving for the "similar look" with no physical ground beneath it. Or there's also some proprietary solutions like davinci built-in halation, or dehancer plugin, they still work afaik only with sRGB. And also paid.
Grasping inspiration from movies and images shot on film took this project far.
I was really hooked when you mentioned about center or end motion blur, because 2 years ago i was playing around with blender cycles motion blur and was wondering, what would be the most accurate in respect to real cameras motion blur. I felt like default "center on frame" option might be not it, and default shutter curve might also be a bit inaccurate to what's happening in real camera. I stayed at default center on frame option(which after watching that vid seems to be incorrect), with shutter curve changed to triangle, with no actual testing being done, just "what felt right". What are your opinion on what would be the right settings? Thanks!
That comment almost became a standalone book lol
That's awesome to see you have your own research you engage in. I have not worked in blender and video editing softwares enough to tell you.
One of my problems with current motion blur implementations is that the vectors can only represent straight trajectories, causing incorrect blur on rotating objects or anything not moving in a straight line. Sometimes I try to think of a way to store "curved" motion vectors and solve this issue, but I can never come up with anything performant.
I recommend you take a look at Unreal Engine's solution docs.unrealengine.com/4.27/en-US/RenderingAndGraphics/Materials/HowTo/RadialMotionBlur/
@@sphynx_owner8224 Yeah, a blurred texture definitely works in most cases. I still find the idea of curved motion vectors pretty interesting though.
@@Frickolas I have just finished making what you are describing, and I may make a video about it so stay tuned :)
Aww, I was happy for a moment when I thought "solving" motion blur meant getting rid of it.
You dropped out of HS and wrote a paper? Damn that's really surprising and impressive!
Despite being about to finish college I cant stand academia and writing paper and research. It's boring, I'm too hands on, too practical and impatient. Kudos!
very interesting, very compelling, instant sub
Lovely work.
If there is need for ground truth implementation for comparisons, I would suggest old good accumulation buffer.
Render n images during the time shutter is open and average result.
Can be used for AA and DoF as well. (As seen in Gran Turismo camera mode.)
Cool research. In case you were having issues with access, many papers are accessible via (cough) sci-hub.
looks good, research in this direction is a good idea as most sota approaches are still very unappealing
I understand the distain that people have from motion blur effects, and its why I took such a stand on common practices in state of the art motion blur effects and avoided them such as centered blur. I hope and aim for my method and final product to stand out in its tolerability.
If its possible it would be nice if motion blur can be detached from the scene.
As in, motion blur applies to everything except: enemies if there are enemies, anything beyond ~5 or 10 meters away from the camera, see through patterns/transparent materials like dirty windows and chain fences and camera movement that isn't forward (whip pans don't have motion blur but moving forward does)
Project CARS 3 applies motion blur to everything close to the camera except the car body. Interestingly enough, doing a whip pan in third person and going into photo mode mid pan lets you explore the world with motion blur which is really cool and you can adjust the "shutter speed" motion blur amount while viewing the 3D motion blur.
This is so incredible. /applaud.
Hallellujah! Motion blur that doesn't look ugly! You've done it!
Great work! People only notice motion blur when it's crappy and deduce 'all motion blur bad'. When it's good the they just deduce that the game looks good
Plenty of comments here make it clear to me that what people hate is camera motion blur, but they don't necessarily know what that it is or how it differs from object motion blur.
It would be awesome if this was polished and optimized, then integrated into mainline. Very cool!
Agreed. I've been working hard on making this a reality and I hope it would be.
Seeing the greattl things you have achieved has renewed my inspiration. I too was a hughschool dropout, now trying my hardest to use godot ro the best of my abilities.
I have visited your channel now, and I'm very impressed, subscribed!
Fascinating stuff, excellent work!
Thank you very much!
Hey S_O, great video--I loved the work that you demoed and your technique is super cool. The velocity channels were interesting but very had to watch for most of the video; it's data meant for a buffer not for viewing. That, and showing the 4 channels for most of the video meant that we couldn't really see the effect that you worked so hard on--even on my big monitor a quarter of the screen was just too small to see, let alone appreciate, the details.
The clearest and cleanest example in your video was when you were pausing so we could actually inspect the motion blur effect you achieved. A side by side comparison of the action wih and without the effect would have gone a long way as well.
I think what you made was really cool and I can't wait to learn more about it.
Thank you!! this video was not a showcase of the actual effect at its fullest, you are right. For that I have already released a video just before this one, and better yet, you can get the demo and experience it at full resolution!
Amazing work!
here before viral
ps: You should be proud of yourself, outstanding video, I understood most of it and im kinda slow 💀 so big ups to you and your channel 😁
Thank you! I'm glad you enjoyed it.
Cool but I’m still instantly turing that off in every game
I don't give a shit if you dropped out elementary school. DUDE YOU ARE TALENTED !!
I've heard so many weird arguments of gamers why they hate motion blur. My favorite "That's not how eyes work". Ignoring that motion blur doesn't try to simulate eyes but a moving object on a static screen between two frames. And that movement is happening, no matter if it's toonish, abstract or realism. I wonder how those people explain motion blur in videos and why objects are still blurry, no matter how hard they "track it with their eyes".
The only real reasons to turn a quality motion blur off, are competitive fast shooter or games trying to fake a stop motion look.
I think motion blur has gathered a bad reputation from PS2, up until a couple of years ago with low quality implementations, smearing it over multiple frames. Todays motion blurs are near perfect and your version looks great. I wouldn't even offer the option to turn it off :D
Because that's not how eyes work.
If you're running 24fps - the frame rate of cinema, then yes, you need motion blur to not make it look rough, in cinema this is naturally achieved by the 1/48 shutter.
60fps content - i.e documentaries typically have a 1/125 shutter speed and thus far less blur, if any.
Videogames ought to be run at 60fps + and don't simulate either documentary content or Cinema.
They simulate live movement, which has no motion blur. Now a touch to smooth out the in-betweens at 60fps is down to taste, but it's absolutely not necessary and at higher frame rates is completely pointless.
I you watch "live movement" live on a screen, you'll get motion blur. As I said, "Everything that is happening between two frames. So of course, with higher fps, you'll get less drastic movement which needs less blur.
And I won't disagree, that a couple of games overdid the effect. Looks especially bad if it stretches over multiple frames, resulting in a long blurry streak, even if the motion indicates that the blur should be curved.
That wouldn't be the quality I'd advocate for.
But motion blur itself is still important.
I've seen streamers disabling motion blur. Just because chat said so. But they enable sharpening, play in 4K and then complain that their eyes hurt. Probably because of all the fast paced, crisp detail the game throws at them.
@@florianschmoldt8659 The blur isn't introduced between frames though, it's on the frame. My point is that on 60+ FPS blurring isn't necessary because the frame transitions are for most people nearly imperceptible or very easy to get used to.
In regards to it not being how eyes work - blur on objects is one thing and fine, particularly when used for stylistic effect (e.g cars going fast). But blur on camera movement is where people have issues, when you pan your eyes across a scene in reality you don't do it smoothly, you skip between clear, static points. Motion blur on camera movement makes this impossible and itself causes eyestrain and motion sickness for some.
@@nebky What I was trying to say is that motion blur fakes the movement happening between frames.
I'm mixed on camera motion blur. On one side, I don't see why I would have any other expectation how cameras work in games than real cameras.
If I want my UE5 character to see, I give him a camera object and not "eyes" for a reason.
The problem I see with camera motion blur is a technical one. If I spin my character 360, I'd expect heavy motion blur. But subtle movement can already introduce a long blur because the motion vector, based on a single frame reads as quick movement. That's indeed hard on the eyes. A good solution would probably be to scale the amount of blur based on distance and time.
@@florianschmoldt8659 yeah I can agree with that, at speeds where the eye isn't going to be able to track an object you probably want some blur to ease the rush of information. But typically if I'm moving the camera, first person or not, I want to be able to clearly focus on an object and follow it. Like I see an enemy, I move the camera to focus on them, my eyes continually stay on that point throughout the movement but during this the enemy becomes blurred. What's the point in that? It's unnatural (to how eyes work) and artificially reduces clarity.
The difference is that in cinema/TV the blur of the camera movement is used intentionally or at least considered aesthetically. But in a game the movement of the camera is almost always functional. This is exactly why documentaries are filmed most often with static-ish shots at a higher frame rate or even slow motion giving it essentially 0 motion blur. The camera movement is functional and intends to keep the subject on screen, clear and crisp.
Great effect! There's just one thing that looks off with the final result: If something moves in front of a stationary background the background is also blurred. I think this is also a problem in the paper you mentioned and, for me, it kind of ruins the depth of the image. In real life this obviously doesn't happen, the background shouldn't get blurred. I thought about a solution to this problem using some kind of ID stored with the velocity data, but it's probably nearly impossible to resolve. Because if you were to not blur the background, the bluring of the foreground object would kind of create a transparency 'hole' in the image, where we wouldn't have any background info to fill it in with.
I actually fixed it in the latest implementation. It was all down to my blending heuristics rather then the velocity dilation method. Its looking much better in terms of quality and cleanliness, and I recommend you download the latest version of the demo and check for yourself. As for the blurring of the object itself, I have to "fake" its transparency by sampling ahead of it still, technically "smearing the background", but the trailing edge blurring correctly for change gets you most of the way there.
How performant is your method compared to other contemporary solutions? Would love to see a follow up with statistics.
Also please upload in 4k even if your capture is 1080p for higher bitrate.
This might be a stretch but could you see how faithfully your method can replicate the wing blur of the ornithopters from dune?
These are all very good points you are making, I don't have clear answers yet but here's what I have to say:
1. My focus was on getting a high quality result with this method, so chances are that in its current state it is less performant than other methods at similar dilation radius on HD screens. What CAN be said in the favor of the current method, is the fact that the increase in dilation radius only asks for a logarithmic increase in processing power, without sacrifice of any details or fidelity, which is unheard of with the other methods I have showcased in the video which require a linear increase.
2. I have showcased a full screen view of the blur in action in a previous video. if that does not suffice, you are welcome to try the demo for yourself and see it at full resolution!
3. The limitation with this current method, and every other method as far as I'm aware, is that it captures the movement as it is at the instant the frame is taken. In order to show the wings of that vehicle's motion range at a consistent blur, which I believe move rapidly like a hummingbird, I would have to capture the game at a higher framerate than the rate of wing flap. At that point yeah, no problem.
@@sphynx_owner8224 I've never touched Godot but I'll try your demo on my 3060 machine. Thanks for the response. I'll be following your work on UA-cam.
It seems high frequency per object motion blur is still a white whale. I wonder how the wings would look beating below 60hz. I assume the same limitation applies to rotational motion for the spokes on a car wheel. Also wondering how much work it would be to convincingly fake it in your method.
Thinking about motion blur in games is a bit mind-bending as filmmakers think about motion blur in terms of shutter angle or shutter speed/exposure time with a constant frame rate. In films 90° at 30fps is already considered an "action" shutter speed with minimal blur so basically equivalent to 360° at 120fps with each frame fully smearing into each other, only without the stuttery feeling. So I wonder at what point is it more realistic to just omit the motion blur and have the extra performance?
In a game, it ideally would also be static at a fixed frame rate but in reality, it is constantly in flux, and gamers (including me) don't like being locked to a certain FPS. I can forgive being capped during cinematics where such artistic control is most important.
Games shouldn't have a constant motion blur setting like they do now. It should be dynamic based on the gameplay situation. Low to none during fast-paced combat and liberal amounts during the lulls between based on art direction, where twitch reaction isn't necessary.
@@shApYT I think the connection between game motion blur and camera one is only analogous, with the camera shutter being the reference frame for motion blur effects, but is not the limit, nor should it serve as some sort of standard. While motion blur can simulate the shutter of a camera, it can also just be treated as a way to smooth your experience with the same refresh rates, and each of those approaches can be satisfied by my implementation in multitude of ways. For gamers, I think its up to you to decide what you can afford and what you want your experience to look like. What I think is up to me and developers adding the motion blur to their game is to make sure it would not be in the way of your experience to the point that you have to turn it off.
As for the wings and wheels, yeah it would need to be specially handled and has to be done separately.
What nobody talks about is that motion blur in games negatively interferes with the fact that monitors don't strobe, but instead display the image for a certain period of time, further creating a blur on objects that move across the screen. That's the reason I disable motion blur, because both of those effects together are just simply to much for me.
On the other hand, if your screen would be strobing, it would be possible to follow a moving object with perfect clarity with your eyes. There's is no reason to reduce clarity with an artificial motion blur. Reality does not have motion blur. If you follow a moving object with your eyes, it appears completely clear.