It looks a bit too smeary. I wonder if that’s just the low framerate or if you have used shutter longer than 0.5 frames (which you never should) 
Despite that, it still looks better than one without motion blur. I would not bother about re-encoding and just upload them all to YouTube, their compression isn’t bad. Also, h264 movs over mkv 
1 Like
It’s 25fps. I first used 0.5 and had the impression the stuttering is still there. But I guess it’s also due to bad V-Sync in the player. Thanks for the tip What is bad with mkv? I’ll try 60fps with low motion blur to see if it’s better.
It will always stutter at 25FPS, because it doesn’t very well align with 60Hz monitors. To get really smooth picture you’d have to render at 30FPS. 25 or 24FPS will only look good on 120Hz TVs
But going over 0.5 (180°) shutter is called shutter crime. It makes everything look uncanny and fake. You never see it in movies because faster than 180° shutter isn’t physically possible with rolling shutter cameras. It is possible with never cameras, but should not be used anyway or you’ll get that mexican ugly soap opera look
So as a rule of thumb, every time you do motion blur, simply keep the length at 0.5 frames, and you are certain you are getting correct motion blur.
As for MKV, it’s the format that’s way less supported out of the box, and also youtube may have hard or slow time transcoding it. Where as if you upload h264 mov, it will be really easy for youtube to crunch, and for anyone you send it to to play. It has also great quality/size ratio. For some reason, I always think of mkv as that wonky codec pirated movies are distributed in 
2 Likes
It seems 60Hz is still the most widely used indeed. It’s a mess with old 50Hz here (PAL), new 144Hz (who had the idea? It’s a round multiple of 36 and 72, so not a single video on earth) .
I thought new cameras can read the full sensor at once, but I know what you mean with the look
Note that mkv is just the container, I used H264, but at very low compression level. Which was useless with the heavy motion blur
Nearly 1 min per frame, awesome, can’t wait to see it with intel denoiser, will be even faster than Eevee I guess
In the mean time, you can convert to pfm and indeed get impressive results at 16spp already.
1 Like
@bliblubli That sounds pretty awesome, the results are impressive!!! I was wondering, the full course version will head to something similar in terms of performance? As a dev myself i like to mess with C++ but actually never opened Blender source. Is worth more investing in the course or the build itself? I’m asking because i can’t afford both, the coin conversion in my country are huge.
Hi,
yes, the course gives all the recipes to get a build even faster than E-Cycles, as you can make it a perfect fit for your CUDA GPU(s). If you already know how to code, some part may sound very simple, but you can then get a very good kick start, which can help a lot in such a huge code base.
And as a bonus compared to the builds, you get some cool new modifiers and links to cool patches People taking part to the course can also get 50% on E-Cycles (so 5€/month) if you want both the knowledge and the convenient updates, support and bug fixing. If you want 12% off, use this link for the course
1 Like
By the way, for those interested by the course, I’ll do some final polishing this week so you have some days left to get it at the reduced price.
The bug with the lower noise algorithm (dithered sobol) is fixed. I’ll upload a new build soon
1 Like
Very impressive updates bliblubli! I’m curious if these accelerations also apply to viewport previews as it’s where it could make the biggest difference for a someone working with asset creation. I’m also curious if there are any patches that can accelerate the pre-render preparation (e.g BHV building) so data could be thrown on gpu faster for viewport preview. Several big textures and heavy model kills interactivity. Lastly I suppose there is nothing on Denoising viewport render? After all this is what all other render engines do (vray, mantra, arnold etc) - denoise initial steps so artist has clear image what one is working on. Tnx
Some of the improvements make viewport faster, but viewport is using progressive rendering, which is very slow and nearly abandoned. The overhead of updates, etc. make the optimizations invisible, but a way to remove this overhead is on my todo-list. I have very alpha code that make viewport 4x faster with 100% same output as master, about 8x faster with some tricks. When it’s ready, it will go in a feature update.
For big textures, you can already use the persistent image option in master iirc.
I’m working on making the BVH build time and CPU rendering faster, I think it could be released soon.
10 Likes
Is that still using progressive rendering? Or is it somehow tiled rendering under the hood? If not, do you think it would be possible to achieve?
This sounds very interesting, is it possible to try this on 2.79 for a monthly price ?
1 Like
The monthly offer is only for 2.8. You can try on 2.8 one month, if it works as you expect, take 2.79.
1 Like
the maximal 8x boost is with tiled rendering indeed.
Hey Mathieu,
first of all: your results are very impressive! Great Work!!
I would love to see more of those specific fundings. Eg: Just making blenders raw viewport faster i would spend a lot for, but also making cycles progressive viewport faster would be nice…
I am interessted in buying e-cycles perpetual lic for b28.
Mostly working with simple studio scenes doing packshots, i ask myself how your e-cycles will perform here?
Is 95$ the normal price or the reduced one? For how long will it bereduced?
Cheers, dave
1 Like
Hi Dave,
E-Cycles works well on all scenes that use regular path tracing and are rendered using CUDA. The reduced price was until this WE. You can try 2.8 for a month to see it it works well for your workflow. If you then want all 2019 features updates, tell me and I’ll send you a coupon with 1 month deducted.
Cheers, Mat
ok, cool:)
I will try it.
thx
Have been following with interest this thread and looking at these very impressive results.
I might have missed some posts though and I know that there are supposed to be some more OpenCL improvements coming as well. Could OpenCL in threory become as efficient as well or are these big optimizations CUDA only?