Hey all!

I'd like to share a journey of filmmaking history! Yes, not al history is worth noting, but I think this one might just be the next, uhm, medium to big thing, hehe.

NPR has always been very popular, especially with children, but there are people, like myself and many others, who think of NPR as more of a medium than a genre. In a lot of western thinking, anime is classified as "cartoons" which also says "for children" and let me just say, if you think all anime is for children, perhaps it's time to do a little research yourself, lol.

Speaking of research, this next level thing, didn't say how high, is motion smear for Blender using the vector blur. Think of it as the easy and the quick way to handle motion blur in an anime/NPR style.

I have done a few of these kinds of nodes and effects before, that's no secret, BUT, this one has really taken the cake as being the most ambitious attempt at delivering a tool that is aimed at being plug-n-play. Of course, everything will need adjusting, but I want it to be so simple and so ready for the workflow, that it just kinda slides into it's place, like ta-da! hahaha.

So the question is, how do we build this kind of thing? I'm not new to building stuff in Blender and I love doing it and people love what I build, apparently, so this is kinda like an extension of that. HOWEVER, I'm not the only one with ideas, so I wanted other people to also learn what goes into building something like this; we've been taking a journey from day one in the BNPR group and I'd like to share what has been going on there so far.

Pierre Schiller had asked me to share something about the speed mesh tutorial that's more updated for the newer members of the group. No problem. I started thinking in the comments and did the video experiment above.

NOT happy with the initial result and also NOT from a practical stand-point, I tried animation nodes and it gave a MUCH better vibe, BUT again, not happy. Really felt like a post processing method would be better and would work in more shots and quicker. I remembered that the devs promised that eevee would support all the passes with it's rewrite and that means it would get the vector pass as well, so a post method should be pursued now, while they are still developing or re-writing eevee.

A quote:

"Thought it would be a fun thing to show people what the thought process looks like around this kind of thing, so I'm trying to post as I go, hehe. Actually have one this morning, gonna post now!"

Deciding to go the post-processing route, I wanted to share WHAT and WHY, before and then the theories around HOW. GGXrd is of course one of the most famous examples of smearing you can find, but all of their stuff is modeled - which if you have a set of actions, is fine, but not if you're making a tool for other people to use in their stuff.

My theoretical method was:

- Create something that moves quickly (rig style) or use something existing.

- Use the previously built nodegroups that have motion masking:

- Try to get the vector blur to "blur over alpha". Make it nice and clean - say 64samples or a smidge more with a good falloff in the spot mask.

- Harden the alpha + anti-alias

- Generate outlines for the blur from the constant alpha.

- Cut the excess lines with the original object mask.

In theory, this could give a spiked appearance that looks modeled for the most part and would have outlines. It would be subject to limitations from the vector blur node (your action/motion will always be centered on the current frame, until new features come in).

Onto the drawing board!!

I was babysitting and only had my laptop to work on, which is very slow and can only handle up to 2.79a, so I had to work in 50%HD and Cycles (which is a given anyway, LOL). GOT SO MUCH DONE - got a functional result, but lacked masking to a T, gooodnessss!!!!

The list of stuff I shared:

- The masking from the older nodes fell pray to internal changes between 2.77 and 2.79a...

(FOUND OUT LATER IT DID NOT, lol)

- No anti-aliasing here, and 50% HD, because laptop slow and no 2.9, lol.

- This means I need to adjust the masking before taking it further - to clean it up when there is no motion or spikes going on.

- Vector blur blurs over objects too - did not think of that, LOL. This means that you CANNOT get away from the smeariness. At those speeds, I do not consider this the biggest issue, tbh.

- I still have to take this to 2.9+ before adjusting further.

- Still need to rig test it (just to separate specific motion from background)

- Thankfully, I've already created a vector pass mask, so that is still relevant.

I invited other people in the group to also participate, but I doubt they did, LOL. Nothing personal, but this is technical and if you shy away from the compositor, it's not gonna happen...

That last point though, helped sooooooo much! As I shared on Post 2, I have built some previous tools that came in handy with this one; primarily masking based on motion, which is totally available for download within some of the other motion blur type nodes - so you can check out how it works - it's fascinating! Unfortunately, at this stage,...yeah, see the next post.

Not a lot happened this day, because drama we do not speak of, LOL, but, the biggest deal was being able to take it from 2.79a to 2.93+. This also meant that it was very much a day of polishing what was already there with the minor addition of depth based scaling:

- Anti-aliasing is now used, rendering at very low samples, with denoising.

- Upped the samples on the actual smearing, just to clean it up. Instead of 64, I use 256. Will probably reduce this and also reduce the relative span of the blur (instead of double the mask, just 1.5, for example), so I can bring the samples back down, to something like 125 or so, to still get a clean look. I want this to look great as a still thing too, you know.

- Cycles used here, cause vector pass (coming to an eevee near you, lol.)

- Spikes scaled according to distance from camera. I did limit the distance from camera at which it scales, so it 1) Only scales up from what it was and 2) Only starts scaling up about 95% of the way to the camera. This just helps keep things more consistent - sounds odd, but considering the values it works with, that 95% might be less - it's all about map ranging that camera span, hehehe.

- Fix the masking (find out what broke between 2.77 and 2.79)

- Apply masking

- Clean up the noodles (already started with frames)

- Create NodeGroup

- Test it on existing setup - possibly that backflip Mordercai thing from the speed mesh tutorial! That would be fun!

Oh, also, just to recap, the devs re-itterated that Eevee wil support all the passes and that vectors are possible now in the viewport, so the vector pass is on the horizon! :D

Normally, I'd advise against this sort of thing - building something with the promise of something in the future, but that's kinda how business works in general and it's already functional in Cycles, so you can theoretically render out the vector and take it to eevee too. Somehow it will be VERY useful! Like I said, next level - how next, we have no idea! haha.

The day's biggest update: MASKING

Masking was a huge deal for this to work and that has been sorted! Whoohoo!!! :D

   It did not break in the update to 2.79 - YAY! So glad to be wrong on this one! The values in the masking were off, because this requires a much higher speed to respond, so I simply had to up the minimum and maximum values and clamp the final mix.

   I was concerned that the masking might be broken, because the vector pass is quite the one to figure out:

RGBA all contain vector info - R+G Previous frame & B+A the Next.

Now, if you break these up, you can make them black and white in a sensible way to create a mask that becomes whiter with motion and darker with no motion, despite direction. So cool! The vector pass never changed, BUT, for the masking, the values were set to a max of 40 and minimum of 0, so it was kinda lit all the time, LOL - thus, appeared to be broken.

For a bit more info, check the quote at the top of the page here!

Why would masking be such a big deal? Well, there's a lot that goes into creating the spikes and a lot of it still sits there, waiting for the spikes to grow, unless you tell it to go away when there is no motion for the spikes to grow; that's why, hehe. It is a VERY invisible, but VERY important part of the feature that it WILL NOT function without - unless you wanna try to keyframe everything yourself? I prefer the computer do it for me and do it right, LOL.

Other updates for the day!

1) I did some refinement of what is where with frames, but a lot is still noodle soup, so this is also needs to be sorted out properly so that everything is clearly defined and understandable.

2) Some extra masking of the vector pass itself also needs to happen.

3) This is the harder part of any research and development task - BREAK IT! Every project has a part where the basic thing works, but it works in isolation with a very limited demand placed on it. For example, there are no other objects, there is no other masking, there are no other effects applied and the background doesn't budge, nor tries to interfere with the vector pass or final result.

What needs to happen now is it needs to be thrown into various situations and be "tried by fire" as it were:

- Occlusion by other objects (might need animated masking for this)

- What happens in a busy scene with multiple objects (ALREADY solved - everything that needs the spikes has to be done in one, or it won't look right - think of a foot behind and a fist in front - occlusion won't happen right if it's not calculated together and blurred - some shortcomings to exist, such as coupled smearing - say a fist connects with a ball, the ball and the fist would have their spikes mixed - would look better than trying to figure them out individually and trying to mask the spikes appropriately...).

- Test what speeds make the most sense and make those the defaults - needs to be simply animatable for comedic effect, for example. So far not a problem, but defaults are important.

And finally, I had to figure out what needed to be exposed for ease of use (such as masking, min and max speed, depth, etc.)

I have to add though, in hindsight, there is no special mask needed for occlusion, lol, but we'll get to that later.

Let's kick this one off with the updates from the day:

- Things got really organized in the node group

- What still needed anti-aliasing got AA'ed

- Masking was organized - there were two situations that required masking, so little surprised by that, but not rattled - everything cool.

- Speed related node(group)s have been marked with blue, but I want to avoid using this "go inside" method, because that defeats the purpose of being user-friendly. I want to, instead, use drivers from the outside to control all the nodes at the same time.

So, what was the excitement all about then? It was about this - using two instances of this nodegroup in the same frame!

Of course, nothing is generally straight forward, so, it obviously takes some thought and a lot of prayer, hehe. So, I was pondering the technical issues that might arise for this (haven't gotten to testing them yet), and a few things hit like a ton of bricks:

- The vector blur node uses the Z pass not just for the vector aspects of the blur, but also to tell the node what to mask out. SO, no need to worry about object occlusions, since the effect's alpha is derived from the node's own resulting alpha - occlusions come prepackaged. Whether the alpha may need some extension or not, remains to be tested, so let's add that to the list (below).

- This also means that you can apply the effect separately to different objects, because Z pass. In theory, you'd simply mix these, because of the vector pass and it's blurring, into one another. For example, let's take the ball hit again. You'd put this effect on the hand first and the result goes into the image of the ball's turn to get the spikes added. This'll blur the ball separately and give it it's own spikes - Z masked to some extent. How this looks remains to be tested, BUT I'm VERY VERY excited that it might be doable separately!!! :D

EEEEECK! Thought it completely impractical until today!

My only concern is that this might require adjustment to how the alpha is calculated and require the whole Vector pass and not just the object we want masked (to prevent overspikes, under-occlusion and such)

Still haven't tested this yet, because there are more important things, but for this day, these were the things I felt important to test - to make sure every situation you might encounter is covered:

- Alpha length when node occludes blurring - may require whole vector pass

- Effect when combining objects

- Effect when doing objects separately (order may matter significantly, but we'll see)

- Drivers for the nodegroup (was impossible because dependency graph pre-2.8); VERY important for slow motion as well as being able to mute the effect

- Motion in a real-world situation to determine defaults (OLD PROJECTS HERE I COME!)

- Effect of texture offset when handling objects separately (considering inclusion of such a feature - already animated along Z, so this will also be Z - Math - add probably)

- Test HDR scenarios - bright sun, bright reflections, etc. Clamping vs no clamping - HSV's V maybe mixed in at the end for non-object stuff? Will see...

One to-do came to mind!

   When I built the setup, I did not include outlines, because they blur with the vector blur and it is ugly as mess! So the node group does generate base outlines based on the normal pass (my usual approach, because freestyle and lineart are just too slow on my system - both fail). This definitely needs some kind of revision, because some use LineArt, for example. I'll have to add some kind of cleanup method for the blurring and I have a theory:

- Remove outlines from the inside of the node (excluding spikes) - use LineArt just 'cuz possible real world scenario.

- Add color option for the spike outlines

- Put outlines in at the start

- Add a keying node with good defaults and a color access to the outside. Give it a very sharp ramp and maybe dilation to remove the outlines with inpainting (driver control for width on the outside (?) - line thickness can vary between projects and resolutions...).

- Do this only for the blur that fills the spikes (only area where it matters) use the default image with lines for the rest.

I did get to the above, but found it excessive in use, since most people would use black outlines, but this covers the bases should something else be needed.

The biggest mistake, I would say, was to hope that the grease pencil would show up in the compositor, but no, it does not. Did I know that when I added this in the comments?

"For the outlines - if the grease pencil does get seen by the cryptomatte or object index (depending on EEVEE), then that should be used instead. Using keying can also remove the black of the eyes, for example, or other color information not related. It's better if lines themselves are masked and not color.

Line mask it is!"

NO, of course not, hahaha. Dumped LineArt almost as quick as I added it, because of frustration, but the next day's post's comment on it was priceless!! To be fair, lineart does give a great result - just can't use it in post...

I also did implement the line mask and created new nodes to support the masking features:

"Maybe an additional little nodegroup so that the masked outline color can be used for the spike outlines as well. When you have line art using the lights, the whole gets darker or brighter as you go and that will clash with the spikes, so I'm thinking just adding that extra little control via an additional group might be helpful. Will also require the line mask, but should be interesting for sure."

 - New defaults:

* Speed min is still 60

* Speed Max is now 1000 (seems to be the same as when set to 0 in the vector blur node)

* Scale is 1.5, because spikes are too rare at 1

And the surprises:

 - Drivers now run the min and max speed, but they have trouble appending and functioning, so I need to find the problem there... When they work, they work amazingly well, but they break with a new appending.

 - Outline Mask and Outline removal nodegroups are awesome and functional, and also not really needed unless you use colored outlines...

 - I dumped lineart's use for this, because it's too slow for my PC, and they are invisible to the compositor. I COULD NOT get them working no matter what, LOL. The funniest thing is that it tells me to use the Color Index Pass. Oh yeah, I totally found that in the list of passes, right before the Big Ben pass and after the Painterly Background Filter pass, LOL. Maybe it's just me, but I could not get a working result with that. So, instead of opting for something like that, I went for a color keying node and that works when greasepencil doesn't use lights (to keep the color stable).

- New controls added; offset, mask erosion, scale, spike outline color, colorswitch and so on.

- Normal Dot was also not correctly aligned; saw a weird directionality on the ball in one frame and YIKES was it off! hahaha.

- Discovered lots of masking discrepancies with the other objects now in the shot. Not surprising, which is why you have to do tests... Stuff happens.

- Progressive speed masking rocks! I love that it fades the spikes in the faster it gets!

- VERY happy with today's work. Continuing with the tests now!

- DOES NOT work with reflections... Kinda saw it coming, but oh did it hit home when it did, LOL. Not touching that math with a 10ft pole to try and make it fit reflective shapes. NO, haha.

- Cycles was horribly slow and I needed to denoise as well. Will try a new Blender 3 build tomorrow, maybe. Those claimed 2x-5x speed-ups are VERY welcome, hahaha. Last test was last week and it gave me an error for a missing dll and wouldn't start. Not the first time a program did that, haha. I do think I know the cause, so I'll try to address it asap!

And finally, I could give a great shout out to Kristof Dedene for his incredible cloud method. It's best on a dome of some kind, because the response from the world is just too static... It's like it literally copies the position of the camera and yeah, I hate that in situations like this! haha.

Kristof Dedene's method: 

ONTO THE NEXT ONE! hehe.

The axe used in this test, comes from a very recent cartoon I made for another product on my CGTrader store - the axe itself. I LOVE that cartoon, as much as I slaved to get it done as quickly as I did, lol.

It is super short, but what a fun project!!

I have done all the development I could do with Suzanne in isolation, which is why I'm tackling some real world situations by going for old projects, adapting them to cycles (cause no vector pass in eevee just yet) and giving those a go. LOTs of changes happened since then, but here are some from this test:

- Texture scale had to be increased to double the default, because of the thin nature of the axe handle. I'm considering that this will be used for characters a lot and they have skinny limbs in relation to the screen, so yeah... considering 3 to be the new default.

- Blur strength is now also a control, because for slow motion, you need to be able to really ramp it up, without actually having the physical speed in the viewport.

- Some minor adjustments within the node as it relates to masking and mixing.

- Alpha mask added for mixing (consists of the spikes and the original object mask at input - just added and clamped)

- Thought that MAYBE the driver appending earth shattering problem was solved, but no, no it was not. It's still broken on entry into the atmosphere, so I need to find some way of making the data path relative so it doesn't break every time...

- Clamping still needs to be examined for HDR situations

- Slow-mo part added to clarify, hehe.

- Running dude from my nodegroups video

- Mr Lumberjack from the cartoon

- Mordecai's backflip from the speed mesh tutorial

Then, occlusions and other tests! 

...Later that day...

I was wondering if Cycles was gonna finish today or not, lol. Thankfully it did!

New defaults are good!

 - Texture scale will be 3

 - Blur 2

Looks fantastic on a character - added frames in the comments on Linked in and on Facebook. The character is mine from a project that is still in production - exodus first, hehe.

Not much development today, tbh, just rendering and gotta say, I was nervous putting the blur on 2, but I love it! I will make it the default though.

When it comes to adding the group to a new project, Linking doesn't work either. My guess is, Append to default, fix and save - that should work - still have to try that...

In the meantime! He is running like mad, hehe.

And that is where I am at right now. I know this has been a lot to digest and if you're still listening or reading, WOW, you're good! I hope this has inspired you to dig into the dream features that you want and that you can finally start to build them!!

I honestly cannot wait to get this done, because it looks incredible and I want to get it out there! I thought about it a lot and I think I'm gonna release it before Eevee gets the vector pass, because it is functional and can be used with Cycles (clearly), so with all the speedups and stuff, this works! Can't wait to try Blender 3 though! EECK! Love it!

As an aside, I know some of you guys are expecting me to release this for free. I simply cannot do that, as much as I'd love to... It took me a week+ of full time development - including render time - to make this and trouble shoot it and and and. I don't ask a lot for my tools, because I know many need it that can't pay much. It will go on my CGTrader as soon as possible so you guys can add it to your own projects asap! :D

Doesn't keep you from building your own version though - which is the ultimate intention of the many many posts detailing the development - couldn't put it all here - just too much. Again, I added the links to the original posts so you guys can check out the examples, comments, questions, answers, images, etc.

GOD bless you! (^^,)