That’s what this addon does.
I meant that it can be done as a native implementation since its already done for shadows .
Yeah, I guess that the devs, being the realtime nature of the engine were hoping to implement a more efficient and sophisticated approach, like vector blurring or something like that, and then left it for later so to focus on the more vital features. The old school subframe sampling motion blur es really easy to implement. Let’s hope to see it in 2.81 at least 
Done!
Now It takes the setting from the output settings (Images only, video formats default to PNG).
Tell me if it works ok for you. Had an issue with the gamma, I hope I solved it.
Hi Pablo,
great that you made the changes so fast.
The PNG-Export works, but I think you have the compression set to 100.
The Normal F12 Render has around 700kb.
The exported Motion Blur Image has 200kb.
This extends the render time tremendously.
Blender is extremly slow in PNG compressing.
The gamma (washed out) problem still exists.
Hi Pablo! I’m super excited for your addon. I’m having a similar issue like @NewVisitor and I’m not sure how he got it fixed. I have tons of addons at startup and it won’t work with any scene. A viewer node is created but without motion blur. I’m on the 5/07 build.
Now I tried a factory start with the test blend file. It won’t produce any motion blur, and the viewer node won’t be connected automatically. If I connect the viewer to the comp I get a crash. And lastly, If I delete the viewer node and render I get this output.
Hope this is useful, Thank you!
> Traceback (most recent call last):
> File "C:\Users\*\AppData\Roaming\Blender Foundation\Blender\2.80\scripts\addons\eevee_motion_blur.py", line 456, in execute
> renderMBx1fr(frame, shutter_mult, samples, context)
> File "C:\Users\*\AppData\Roaming\Blender Foundation\Blender\2.80\scripts\addons\eevee_motion_blur.py", line 111, in renderMBx1fr
> mbCompositorSetup()
> File "C:\Users\*\AppData\Roaming\Blender Foundation\Blender\2.80\scripts\addons\eevee_motion_blur.py", line 48, in mbCompositorSetup
> v.location[0] = tree.nodes["Composite"].viewLocation[0]
> AttributeError: 'CompositorNodeComposite' object has no attribute 'viewLocation'
>
> location: <unknown location>:-1
Hi felipetorrents,
I can’t give you a hundred percent solution either.
I have also tried umpteen variations, deaktivate Plugins, Factory Reset etc., nothing changed, all my old Scenes crashes.
Then I threw everything out of my default scene that didn’t fit in there. and now it’s working.
Please don’t ask me why I don’t know.
In this Blank-Scene I append the objects from my old files, working flawlessly.
I hope it works for you, too.
Eevee-Motion-Blur-Template.blend (1.1 MB)
The error message you posted only states that there is no viewer node available and one is being created.
1 Like
mmm that’s not okay… should be a bug at Blender level… I’m using a method called save_render() that supposedly takes all the image setting from the sets in the panel. I’ll see how to solve it and maybe report the bug.
Thanks again!
I’m trying to solve the compression defaults issue. We may be hitting a bug, i’m finding an erratic behaviour, sometimes it uses the declared compression an sometimes it doesn’t.
What’s the issue with gamma you mention? You had it before this update?
With these settings in my machine it saves the same gamma output as the F12, but mabe it depends on the machine or some color setup. And it’s inconsistent with the method I used before( .save() ).
Maybe I will open the field to be editable. If you tell what’s your issue with the gamma it will be helpful.
Thank you!
Well, it look like we’ve hit a bug.
There’s a new version of the addon online, that makes it respond a bit more to the settings.
But:
The compression % of png behaves completely different when handled by the save dialog in the Render View window, and when saved in python via the .save_render() method.
I saved the same PNG via UI and via python at different compression settings, here are the different sizes i got:
The highlighted files (blue) are python output, and the files beginning with F12 are saved in the “F12” window, the number before the p is the compression %.
So, in python you have to go to 11% or below to get an uncompressed image, above that is almost fully compressed.
The F12 behaves differently, but both are heavily quantized. I haven’t tried all 100 percentages, this is enough to get that something is not right at the API level (or worse). I’ll gather more data and file a bug report. By now we can have uncompressed PNGs by selecting in the output panel 10% or less and it apparently works.
I have yet to check what happens with the other file formats.
[edit: typos]
Hi Pablo,
works great.
I make a quick test.
Blender Output Panel = 15%
F12 Render = 1.278 MB
MB Render = 385 KB
Blender Output Panel = 5%
F12 Render = 6.232 MB
MB Render = 6.232 MB
The Gamma-Shift is generated by the Blender Image Editor.
I don’t know if this is a bug or if it’s supposed to be.
Edit:
Typo
Yes, I don’t completely understand the gamma issue, and I couldn’t find specific documentation about it. This workaround is a bit weird because it’s doing image math using float operations on the raw pixel values, and couldn’t find good docs on how this work with the different gamma encodings or color spaces out there.
For my setup the default gamma of 2.2 that I’ve set works ok, but common sense tells that these can’t be simply hardcoded or chosen eyeballing result, I’ll research on that.
When you take the images outside blender, do they look the same as the F12 ones? (that was my goal) at what gamma setting?
Thank you!
No, there is one small difference.
With my test picture I could not see any difference with the naked eye, I first had to use the pipette tool for help.
Red:
F12 = 198 45 35
MB = 197 49 40
Green:
F12 = 19 202 19
MB = 25 202 25
Blue:
F12 = 20 20 177
MB = 26 26 176
Color Settings:
1 Like
this may be an issue with the nodes naming, I’m addressing the nodes by it’s default name, that’s error prone I know –but as I stated earlier, my prime focus was making this work– Now I can focus on making everything better. Try naming the Composite output “Composite” in the compositor, if it was renamed or if it’s missing, connected to the render output, and with no Viewer node.
I’ll try to find a more robust way of finding the Composite node, maybe try the default name first –for speed– and if that fails, traverse the node tree searching for any Composite node.
If you can, confirm that the node name is the issue.
Thanks for your feedback!
1 Like
I checked the EXR files and they all blurred according to the settings I was playing with. They were not being displayed on the viewer node but it works! I’m going to try with a few scenes if there is a naming problem. Thank you!
Thank you! I have a hint on what may be going on, i have to run some tests, this is very useful
1 Like
I analyzed the images with identify (imagemagick) and found out there (and nowhere else) that the images are saved with a built in gamma of 0.454545
That’s –almost– the inverse gamma that I’m applying, except for some rounding error:
1/2.2 = .45454545454545454545
I’ve modified the script to use direct gamma instead of inverse, and set the default to 0.454545.
Do you mind redownloading the addon and run that test again?
Remember to change gamma to 0.454545 if not a new file.
If it’s not that we may be hitting Color management issue…
Thanks again!
Hi Pablo,
I make a Test with Version 0.31.3.
If I leave Gamma at 0.45 I get the same values as in the image above, so no change.
My Test-File:
RGB.blend (2.2 MB)
1 Like
Then we found another reportable issue I guess. The save_render() method is very opaque, it doesn’t expose any tweakable parameter, and is supposed to take them from the UI, but uses another pipeline, probably pre OCIO. I’ve run a few tests with Standard Color Management and end up even worse.