Hi, everyone! I'm working on an advanced Spinning Wheel Effect for both 2D and 3D development, and I want to show it to this community! THE STORY Some time ago I started to work on a car game but after about a year of development I've suspended the project because it became too big for me. During that period I created a lot of useful stuff for car games, in particular for tuning car games. At the end of 2015 I decided to extract those (sub)systems from my game, improve them, and create asset packages for each of them. And this is the first! THE SYSTEM This package will help devs to avoid the ugly wagon effect that occurs when a wheel is rotating faster than the frame rate of the game. Given a well structured wheel model and some parameters, the script automatically generates some blocks of progressively blurred textures, and mutually swaps them basing on the wheel speed. I know words are always the worst way to explain things, so here's a short video showing the effect in action: [I'm sorry for the bad UV Map of the BMW logo, which doesn't seem to be well centered] As you can see, the rim model fades out while another "plate-shaped" model (I'll call it SpinRim) fades in with a proper blurred texture. Also, you can see the same effect on the brake disk, on the frontal part of the tyre and on the tread. In particular, the system can generate these blurred maps: SpinRim diffuse Brake disk diffuse Brake disk bump Tyre diffuse Tyre bump Tread diffuse Tread bump Of course, I could add all the Standard Shader's texture maps, but I don't think it would be a good idea. WHY STATICLY GENERATED TEXTURES Initially all was done at runtime and the framerate was quite good. Here's what I did at the beginning: But after that I added the support for the tyre and the bump maps... And I faced a dramatic FPS drop. I use some custom blur shaders using multisampling (up to 360 samples!), to generate a different texture for each map, each frame! For example, using a 360° spin blur was like sampling 7 maps * 360 samples = 2520 samples each frame. So, I decided to use the old but good static way: the system generates all the needed textures and it stores them in an array. Depending on the size and quality of the reference images, all these textures will use some memory, but the FPS are always the same!!! I let the user choose how many textures have to be generated for each map. A good value for me is 10 (for a total of 70 textures). The best effect is of course obtained using 360 textures for each map, one for each degree of rotation, but it is a useless waste of memory. "DON'T DO THIS AT HOME!" WORKFLOW There's an only step to follow in order to work with this system: create a good wheel model. Unfortunately, not all wheels can be used here. Since this isn't a motion blur effect (which works as post processing effect) there are some simple rules to follow while modeling the wheel. Here's a preliminar candidate for the wheel's structure: OPTIONS And, finally, a list of the currently available options: SpinRim resolution: the resolution of the generated textures to be applied to the SpinRim model Tyre resolution: the resolution of the generated textures to be applied to the Tyre (front) model Tread resolution: the resolution of the generated textures to be applied to the Tyre (tread) model BrakeDisk resolution: the resolution of the generated textures to be applied to the BrakeDisk model MaxBlur: the maximum angle of the spin blur effect. Generally, the maximum blur should be 360, but I found that something like 90-100 is good, too. AlphaMultiplier: multiplies the alpha channel of the transoarent maps (for me 2 is good) Samples: how many textures the system have to generate for each map? 10-20 is a good value. SamplesDistibution: the distribution of the calculated blur's angle. It uses different mathematic formulas. Useful for a better low speed blur spreading when using a small amount of textures. FadeTreshold: in this variable isn't 0 the rim model won't be completely faded and its alpha will be FadeTreshold Texture arrays: these arrays are shown in the inspector in play mode as read only. This is intentional, because these arrays are automaticly allocated, filled and assigned to the game elements. CONCLUSIONS And this is all! I hope you will find this interesting, and please tell me if you think that there are things to add or modify. I want to thank a couple of members of this community, which helped me to write some shaders: bgolus mgear Thanks for reading this long post!!!