The Spin Wheel Effect (S.W.E.) is a C# plugin for Unity3D thought to help developers to avoid the ugly Stroboscopic Effect (a.k.a. Wagon Wheel Effect), which occurs when a wheel rotates faster than the frame rate of the game.
S.W.E. has no FPS impact on your game, since it automatically generates blurred textures just one time and swaps them accordingly to the wheels’ speed. It requires a little time every time you load a wheel configuration (less than 1s in most cases) and some amount of memory (20-100 MB) depending on the size and number of generated textures. A memory counter is shown in the inspector and a texture compression option (very slow) help users to choose between size and quality.
FEATURES
GPU generated textures Diffuse and Bump maps supported Mobile compatible (tested on Android) Standard and Legacy shaders supported Outer Rim, Tyre, Tread, Spokes and Brake Disk supported Textures compression (slow) Versatile (not only for car wheels) Different input handlers Unity 5.0+ compatible UnityCar ready Save/Load config system Example of runtime wheels swap
NOTES
Some modeling and texturing work may be required in order to correctly set up the system. All the wheels must respect a given hierarchy.
I suggest to use the support if you need help to learn to use this system.
If you already purchased the package on the Asset Store, but also to ask something about the product you can contact me for support in the following ways:
Email:fra3point@gmail.com
Please, add this string in the message title: [SWE Support]
Skype:fra3point
Please, add this string in the contact request: [SWE Support]
-Added Shading Mode: Legacy or Standard
-Bug fixes
-Added a new wheel model
-Older version compatibility (Unity 5.0+)
-Added a new scene with input handler to simulate a tourbillon mechanism
As now, I’m working on a new version that will include:
-New ready-to-use wheels
-Save/Load config (different wheels may have different settings)
-Swap system example for runtime wheel change (see the video!)
Check it out with this example!!
And here are two of the wheels included in the upcoming version:
-Added a simple Save/Load configuration system -Added a dynamic Spawn/Swap wheel system -The main example scene has been updated with the new features -10 ready-to-use wheel models included -Minor bugfixes
Included wheels:
For a complete list of the included wheels, please check this Sketchfab collection.
- Removed editor references in runtime code - No more resources folders needed - Shader model 4.0+ is required on Direct3D platforms
As @600 kindly reported to me, there was a bug in the 1.2 version that occurred during the Build of the project. I have fixed it and it works now (tested on on Windows). I haven’t tested it on Mac, but it should work without problems by modifying the shaders (remove the #pragma target 4.0 line in the blur shaders).
Next release spoiler:
1) First, I’m planning to generate the normal maps by the GPU via shader/blit. This will improve a lot the generation performances. As now only the diffuse textures come from the GPU, while the normal encoding (which takes the most part of the computation time) is made by the CPU.
2) A new ready-to-use wheel model for trucks or buses
The blurred normal maps comes now from the GPU (100x faster!) - Added a new truck wheel - Improved dynamic wheel swap system - No more need to include shaders in Graphics settings - Bug fixes - Improved custom inspectors
Known issues:
Some materials are useless, and the hierarchy of the models can be simpler. - Some example models are not well uv mapped and they seem unbalanced. - There’s a leak of render textures and materials, only visible with Profiler. - The blur of the tread bump map isn’t perfect until it reaches the maximum value. - Shaders MUST be set in Edit->Grpahics->Always included shaders, in opposition of what I wrote in the Asset Store release notes.
Next release spoiler:
Some of the v1.4 known issues will be fixed - The properties maxBackground and shadowStrength will be deleted because they can cause confusion. They will be replaced by an automatic and adaptive method which adds extra alpha to the spinning mesh accordingly to the angle between the wheel and the camera’s view. This adds some realism to the effect, since it simulates the occlusion the side faces of the spokes create on the inner parts of the wheel when you see the wheel from the side - The example wheels will be re-textured to be better looking and balanced. - Mobile and PC shaders will be merged - The minimum Unity Editor version required will be 5.3.5
Hi! Can blur images be generated in an editor or elsewhere, but not on runtime? This will increase build size, but probably might eliminate hiccup. If there are any oO
Hi! This will be possibile after a little script modification but the hiccup is really small on high end platforms. If you saw the demo of course you noticed the hiccup because
that is the old demo, and it is slower
for demo purpose the generation of the textures is made every time you change the wheel, but it’s better to first change the wheel and then, when you load the driving scene, call the geberation process. The loading time will be a little longer (in high end platforms less than 0.5s) but the user won’t even notice it during the scene change. I’d prefer this solution in your case.
Anyway, If you’ve already purchased S.W.E. and you need that script feature I’ll make it for you. I don’t know how much time would it take because the 1.6 release was planned to be the last one and this feature world require some days.
Just bought it!) I think premade textures are way much better then those, generating at runtime. We have a case, where cars are instantiated at runtime. We would like to lessen every other impact on ms. Not sure if it’s okay to ask for such a modification, but since you are asking…
I appreciate these suggestions and I’ll do my best to implement them. It will be quite hard because the code is long and complex, so, as I previously said I don’t know how long this update can take.
In the meanwhile, I still want all you to focus on the possibility to call the GenerateTextures() method only during the scene load, making the computation time (0.5s in old machines) absorbed by the scene loading time.
Hey, thanks for being responsive. Actually, I just tried your package, and it seems like no spikes or whatsoever changing the wheels. No idea how well it will behave within our project, but so far optimization is a beast!
Haven’t dig into the code yet, but I think it won’t be a problem for us to modify this stuff for our needs. Thanks again for a great asset, keep up the good work and don’t mind me! 15 bucks spent well
Cheers!
upd: and since we all sharing awesome ideas, would be totally cool if wheels could react to timescale. you know, like slo-mo stuff and all that. hope won’t be a problem for us to do that)
@crudeMe Thanks for your recent purchase and for the kind words! I did a huge work in order to optimize the generation process. Almost all the work is done by the GPU, which is incredibly fast for stuff like that!
But… I don’t understand what you mean when you say: “it seems like no spikes or whatsoever changing the wheels”.
meaning no hiccups or freezes, lags or whatever impacts on performance. Great job on optimization! As to my last upd in the comment about time scale, seems like speed=s*Time.timeScale works in SpinWheel.cs, but it won’t freeze totally if time scale is zero. Going to look at it tomorrow)
I’ve never thought to the slowmo effect, but I don’t think it’s hard to do. Just keep in mind that even if you slow your game your wheel will have a blurred texture on it, and simply scaling down the game speed won’t alter that texture. Try pausing the game while the wheel is spinning: you will see the wheel with no rotation (because of the pause) and the blurred texture on it, like if the time scale would be 0.
So I don’t think you’ll need to set different parameters or alter the code to get a good slow motion effect.
Anyway, if want to control the speed of the textures swap just check the minSpeed and maxSpeed variables (a brief description of them is in the user manual).
Edit: in the example scene you didn’t find any freeze because all the generation work is made only when you click “save”, simulating a generic moment in your game when you can call the GenerateTextures() method, i.e. a scene change/load (as I said in a previous post).
I don’t have Unity 5.5 yet, so I can’t test the package with that version. But I think it should work fine.
You were interested in plane propellers, right?
I’ve just checked the plane example scene and I found a little error. The system just works fine but there’s a null variable that I didn’t check before Debug.Logging it, so there will be a null reference exception but there won’t be any crash or freeze! I’ve already fixed this little bug happening every time a wheel doesn’t use all the texture maps (like the example’s propeller).
Hi, what about changing the rims colors at run time after the wheel is set up… is this still going to work or once is set up, no more modifications should be made - thanks ?
Hi! You can change the rim color at runtime but after that you must “update” the system by calling the GenerateTextures() function. There’s an example scene in the package in which you can change the rims’ color.
Please think about a common game situation:
You are in a beautiful garage, you choose the wheel you want on your car, then you paint it with some colors, you save your settings with a function and, at last, you change scene (or not) before running in some tracks.
Simply calling GenerateTextures() in that saving function you’ll make it absorbe the generation overhead (<0.5 seconds in most cases).
If you are a good programmer, then in the package you will find all the necessary to code your own paint&save system, but if you’ll need help for this, please contact me for support at fra3point@gmail.com.
