[RELEASED] uTire Dynamic Tire Deformation V2

A last minute issue popped up(in HDRP triangles randomly disappeared, it was fun), but it's finally fixed, I just submitted 1.3, should be available soon.
For the next few weeks I'll have to put it aside, but I have ideas about how to make the setup process a lot simpler - I'll have to experiment with it first so no promises yet, but what I'm saying is I know the setup process isn't ideal yet, but it'll be better.
The gif is from the new example scene(Examples\3D Collisions Example), it's using the built in wheel collider and a really S***ty car controller.

@khos thank you for your kind words, I really appreciate it! It's crazy how big the difference is compared to the old videos.

@m0nsky I didn't forget about your request about the second texture set, it won't be available in the update(I want to come up with a general solution, most people won't need a second texture set, I don't want to use up two samplers for no reason), but I'll come up with something soon. If you need the feature ASAP let me know, and I'll prepare a special package for you right away.

 

I can't wait to try out this sample (new example scene(Examples\3D Collisions Example)) to get the really soft wheels!

 

Looking really good!

I've been very busy with some other work but next week I hope to get started. One question though: When I work with medical scans and perform measurments etc on the bones, I make the meshes isotropic with edge length ~0.75. This is of course too dense for tyres, but what edge length do you recommend for big wheel loader tires? (900m radius and ~700mm wide). I'm currently drawing the tires (using Rhino) so it would be nice to know a suitable mesh density when I export it out of Rhino.
https://st.mascus.com/imagetilewm/product/a33777de/volvo-l180h,3062a2ac.jpg

// Rolf

 

@khos Unity worked crazy fast this time, the update went live just a few hours after my last post.

@LAROM depends on your mesh and the environment, you don't necessarily need a lot of rays to get convincing results, in these demos I always use 3x32(two rings on the sides, one in the center, each with 32 rays), but honestly it would work just fine with just 16(and this could be even less as it's possible to only cast rays between certain angles(so if you know for a fact that your wheel will only hit the environment on the bottom(and this is the case for like 90+% of the games) you don't need to waste the raycasts. Just to make sure we are on the same page, you don't need a ray for each vertex. If you have trouble setting it up I would be happy to help.

 

Edit
Everything now works as expected on HDRP 5.13

 

@m0nsky Crap, sorry, thanks for letting me know - it's nothing life threatening, I just accidentally included the old(HDRP 4.x) shader instead. I'll update the package right away(and send you the correct shader in a few minutes)

 

Coo

Awesome! Already trying the samples
So how can I ask Unity to give you an award for this?

 

Just to give everyone using HDRP a heads up, turns out the issue was a bit deeper than I initially thought. I included the old shaders(not the super old 4.x, but an older version made for 5.13 - the resulting image would be really similar to the one posted above), however even with the updated shaders the issue was still present. Turns out HDRP 5x doesn't play well with arrays and instancing, at least not yet, when instancing was turned off on the material it worked as expected.

So for the time being, under HDRP, turn instancing off. If this issue won't be solved by Unity in the near future I'll make sure instancing can't be turned on on the materials.

@khos hehe, thank you, I'm glad you like it! Yes, when Unity finally announces the long awaited Wheel Deformation Competition, I'll be ready!

 

5.x changed how arrays work under hood, they need to be treated bit differently. I haven't checked how this asset uses them but it could something wrong on the original template already, it's easy to miss.

 

I'm loving your (new example scene(Examples\3D Collisions Example) , trying to get that added to my scene it not that easy, my wheels don't have that same awesome bounce yet (they work nice but not as nice yours!). I wish there was a way to almost automate the wheel setup so mine can behave exactly like in your sample.
I'm going to try move my car mesh / controller over to your test scene and adjust your sample to use my stuff, see how that goes.

 

Hi! "Scene view controls" not always save changes. Need to use serializedObject.ApplyModifiedProperties(); to save variables always and under any circumstances.
Please read this - https://forum.unity.com/threads/custom-editor-variables-not-saving.513406/#post-3361120
I recently encountered the same problem and this link helped me. Simple need to use serializedObject and Property methods.

 

@Fortunato1 Maybe I'm missing something here, can you please provide an example when it's not working as intended? I'm not using serialized properties on the scene view controls at all, I'm modifying the properties directly - I do use them on uTireWorldSpaceSynchronizerEditor, however I also call serializedObject.ApplyModifiedProperties() at the end of its OnInspectorGUI() function.

@khos I'm crazy busy with my projects at the moment, but maybe next month I can spend some time on uTire again - the setup process will be heavily simplified. No promises on the timeline yet though, but it'll be done. [to give you a rough idea, by the looks of things I can finish my tiny project by the end of the month, after that I can spend a few days on uTire, if that'll be enough(I doubt it, but we'll see) it'll be ready by then, if not then I can only work on it again when I'm done with my main project - which needs at least another 3 weeks full time. So best case early June, worst case early July]

 

A small update is waiting for approval(NWH Vehicle Physics integration)
---
I spent quite some time on simplifying the setup process for 3D collisions, but I hit brick walls every time, automatic solutions worked for this model but not for that, in the end it was extremely convoluted code-wise and it could really save a minute or two, for the time being I put it on hold indefinitely - maybe later on I'll have a moment of clarity and make something that will work for every mesh, but for now it seems like a dead end.:\

 

I hope you can get this brainwave and finish your plan, what part are you not 100% sure of, is it some code?

 

@khos the issue is for an automatic solution to work with every mesh the wheels have to be made in a specific way, but since day one my goal was to make it a totally generic solution which can work with any mesh(the only requirement now is the mesh have to face in the correct direction). Ideally you would only have to set the inner radius(the outer radius is easy to calculate from mesh bounds) by hand and the rest would be calculated automatically, but this falls apart as soon as the scale is changing or even if you just change the number of rays(one would think a simple multiplier would solve this completely - hence my original confidence -, but it gets more complicated, the number of rays, the direction of rays, the scale of the model, the shader settings and the world itself all have to be set up in relation to each other and I just could figure a formula that would work well enough to even call it a beta feature).
I'm sure it can be done, and I absolutely intend to make it happen but for now I feel totally burned out on the subject, hopefully later on with a fresh mind I can come up with a proper solution.

But to give some better news about the roadmap, since the job system was introduced a really long time ago(is anyone still on Unity 2018<? The only reason I have 2017.1 still installed is because uTire was released with it), I'm thinking about rewriting runtime code to use it, especially for the 3D collisions this should be a major performance uplift with lots of vehicles(or rays).

 

I am making a 2.5D game. The meshes are 3D, but the physics are 2D. Are you planning do make a 2D-version that works with wheeljoint2D?

 

RedHotFlasman Sure, I'm not familiar with the 2D physics tools but if it's possible to extract the min max and current joint position then it should be straight-forward. I'll try to dig into it today and let you know.

 

When I saw it I was thinking the same!
Here is my first implementation.

Thx @Pecek for this wonderful asset. I understand how much work and time there was involved!
Some feedback. The deformation as shown in the video moves faster than the collision surface. I play a lot with all the parameters following the latest video tutorial, but I was unable to much it perfectly. I was wondering if it was my particular round mesh shape. Still, it works very well!

 

@AlanMattano Thank you, I'm glad you found it useful! Maybe it's the angle, but your wheel looks pretty good to me(in fact I thought this is what you try to replicate lol), I'm working on a 2D physics update now(along with some heavy refactoring, this update should be live sometime next week), but if you want I can take a look at your mesh and see if I can help you with setting it up.
Just send me a PM or email with your wheel\prefab as a .unitypackage(so I can make sure we have the same transform setup and whatnot). One thing though, this is just an approximation, not proper soft-body physics, so sadly inaccuracy is just inevitable with this approach. The upside is even on low-end mobile you should get away with 60+ wheels with world collisions, and at that point the vehicles themselves would be the bottleneck anyway.
Btw thank you so much for mentioning me in the description, it was heartwarming!

 

This UTire is beautiful

Ok, I was trying to isolate all the code for making a prefab for testing (and PM). I wish to have the minimum code as possible in my simulator because it takes time to compile. I wish to make a prefab containing all the uTire code.
I try to clean examples, documentation, etc but I get this:

Assets\2SD\uTire\Scripts\uTireManager.cs(434,4): error CS0246: The type or namespace name 'WheelBase' could not be found (are you missing a using directive or an assembly reference?)

and I do not know where to find it.
So here is the question before making the prefab:
What folder inside uTire I can be safely deleted?

PS: Now I was wondering if after all is it possible to have only the shader in my project? (and take out uTireWorldSpaceBehaviour)

 

@AlanMattano which Unity version are you using? If anything above U2017 you can use the built-in assembly definitions to easily put scripts into a custom assembly(and unless you change the files you don't have to recompile them). This doesn't affect build times as far as I know, but you wouldn't have to recompile it during iteration in the editor.

The 2SD/uTire/_examples and _Open Source Assets folder is safe to delete, technically you could leave just the shader alone but setting it up with the material inspector would be a nightmare.
Due to the refactoring I mentioned in my last post I would like to ask you to wait a bit with stripping it down, a lot will change in the following days and pretty much everything I would say now would be obsolete in a few days - but I'll let you know as soon as I submit the update.

 

Interesting asset!

I'm curious to know if the system can be setup at runtime. I use blendshapes and instantiation to create wheels on the fly at run-time, then I combine all the meshes when when the user is done changing the wheels. So the end result is a regular combined mesh without blendshapes and stuff, but it's all done at runtime so I can't set wheels up beforehand.

Have you experimented with doing this?

 

@Freznosis Thank you! Runtime setup is supported, there is a heavily commented example script for it.
Setting the materials up should be done at design time, but if your silhouette doesn't change significantly you can re-use the same material setup for a lot of different meshes.
Alternatively, you could set up multiple materials and switch between them based on the new shape, or just straight up manipulate the material values - it's hard to tell which solution would work best in your case without actually seeing the edge cases. Can you show some screenshots or a video, so I can see what would work best for you?

BTW I stumbled upon your VHS effect on Reddit the other day, it looks absolutely phenomenal!

 

Thx @Pecek

I'm using all Unity LTD and Standard PBR. For your project Unity 2017LTD because it was a closer number to the release. And I'm importing the custom prefab package into 20219.3 and Standard PBR. I wish in the future to switch to HDRP.

Ok, I wait a bit with stripping it down. I will try to be more detailed as feedback. I try to maintain my console completely clean. I have like hundreds of plugins and I'm an indie. So if each one gives me just one or two warning this is like 500 warnings in my console and a lot of menu items and tools on the toolbar. Unity becomes unusable.
So for each plugin, I need to take out: variables not been used, line ending, GUI warning, menubar buttons, documentation, extra examples, etc.

For variables that are not used, I usually add

if (variable == "") { do nothing}

at start, awake or disable.
Can you consider taking out warnings while refactoring?
And just if possible, can you include a baker or a prefab maker that takes out editor code?
And as a reminder, include into the doc: The 2SD/uTire/_examples and _Open Source Assets folder is safe to delete. Or a scripting structure small for production-ready.

 

EDIT: I was not able to delete examples and _Open Source Assets because it gives me 3 errors. There are some editor dependencies. I was not able to use just the shader because it does not deform bu itself.

 

I'm currently uploading 1.3.3, it should be live in a day or two.

• Added 2D physics support for WorldSpaceCollisions. There used to be a uTireWorldSpaceBehaviour, now there is a uTireWorldSpaceBehaviourBase, uTireWorldSpaceBehaviour3D, and uTireWorldSpaceBehaviour2D. The setup process is exactly the same.
• Added a faceted-look toggle(in the material window's Base tab) for low poly\flat style games(as these weren't really possible as uTire needs completely smooth normals to work properly)
• Some general restructuring, functionality didn't change but in general the code is more readable and maintainable
• A S*** ton of small optimizations, way too many(and way too boring tbh) to list here

Moving forward I'd like to refactor pretty much everything, make the package a lot smaller(even though the art assets are compressed, they take up like 170mb of the ~180ish unitypackage, it's a pain in the ass to upload/download), simplify the setup process, remove the original shader variant(it doesn't make much sense to use it today, there is so little overhead with the WorldCollision variant if you set the ray count to just 1, you would need hundreds of vehicles before it would even show up in the profile, let alone be the bottleneck - but it makes maintenance a nightmare).

@AlanMattano Ah right, the OpenSourceAssets\Editor folder is required, it's because of the undo-redo manager. If you keep that it'll compile.

 

Hi,
I don't use physics package at assetstore like EVP, RCC, NWH, WheelController3D. I am using my custom physics based on raycast. So, how i can integrate with my custom physics ? When using uTire, is there any effect for my car physics ? Because i don't want to change physics when using uTire.
Thanks.

 

@CoderPro uTire can change the wheel diameter(out of the box for WheelCollider, and WheelController3D), but this is completely optional. The integration just makes the setup simpler for those specific packages, it doesn't rely them in any way.
For the classic shader(which uses the tire compression(it's just a normalized value based on the target position and the actual position) you would have to implement the IWheel interface(there are multiple examples for this).
For 3D world collisions(or 2D as of the last update) it doesn't matter at all, because then uTire is doing its own raycasting.

 

I do want to point out that the raycasting approach will completely break if your game will use Unity Physics package (or Havok Physics) as the physx raycasts will not hit anything on entity side of things.

Of course everything in DOTS is still super raw so this may not be that big of a deal now but still something to consider

 

@rz_0lento That's fair, however when DOTS will come out of preview uTire will either be compatible with it or based entirely on DOTS as well. I'm keeping my eye on it, but frankly Unity Physics is at like v0.2.5 now, I don't see the point in putting work into preview packages that can significantly change in a short amount of time.

Around HDRP 6x I uploaded a new HDRP package and before it went live a new version came out and since they changed how arrays work uTire was broken - in an ideal world I should support every version in a reasonable time, but realistically I'm just one dude trying my best to keep up with the changes.
I don't want to go down that rabbit hole again with DOTS/Unity Physics/Havok.

 

Agree.
Sometimes I wish to bake it out. For example as a prefab. Just to have one script and the shader.
Here there is a second implementation.

 

@AlanMattano woah dude, this looks really good! Would you mind if I put this video on the store page?
Well, if you already have a setup that works for you, and you only use the WorldCollision variants you can remove everything other than the shader itself and uTireWorldSpaceBehaviour.cs, uTireWorldSpaceBehaviour3D.cs(or uTireWorldSpaceBehaviour2D) and maybe uTireWorldSpaceSynchronizer.cs(but you can also set it up by hand, this is like 4 lines of actual code that's doing something) - from the top of my head, there might be some reference issues first but that definitely could be solved by changing a few lines.

 

Yes, of course!

and If you wish I can give you also a tire. If you need one just tell me the size.
here there are some examples: https://www.artstation.com/mattano

 

That's great to hear. I'll be picking this up soon and integrating it into my game. I think it would be neat to have visual tire pressure to help players realize how their car is reacting to the road.

And thank you! That mean's a lot fro man awesome developer like you

I'll be sure to post a video here when I have it integrated.

 

Hello, in the asset page it says Tesellation is only available with URP. Does it mean it doesn't deform the tire with URP? So no visual effect?

And how would you recommend me to integrate this with UnityCar? If you don't know about it, it uses raycasts for its wheel scripts.

 

@AlanMattano I'm so sorry for the late reply, I completely missed the notification :\ I'll send a PM as soon as I can, currently I'm working on a critical fix for my game(it was released mid-February, it's a multiplayer game and I just got aware of the fact that some people can't connect to each other at all, fun times lol) - your artstation says you are a Ferrari designer.. I'm not a car guy myself, but damn. The models(especially the texture work) looks stunning!

@Meceka deformation is working regardless of SRP - you can't subdivide the mesh dynamically in HDRP, that's what tessellation is. However if you decide to pick it up wait a day or two, it should be 50% off soon(not sure when exactly, I submitted the request yesterday it usually only takes a day - it's not part of the Unity sale, no idea why but I couldn't ever participate in official sales(even though I believe I set the maximum sale percentage)).
3D world collision variant works with every vehicle solution without extra steps(as it calculates everything on its own, as long as you have colliders(either 2d or 3d) it will work), I do recommend using this over the old system as the performance difference is minimal but looks much better - in the future the original version will be deprecated, I'm just waiting for 2017LTS' end of life before making bigger changes.

Edit: the discount is live now.

 

@Pecek Thanks for your response. I just purchased the asset.

I was thinking of using the original one to save performance. But because you say that it will be deprecated, then I will use the 3D version. But I wish to use it also on mobile devices. Are you going to make a further optimized version of the 3D version in future?

UnityCar isn't using any kind of wheel colliders. It just sends a raycast to ground and calculates physics force based on this ray and wheel settings. Does it mean it's incompatible? I don't know if other assets (that you have integration) have a similar workflow.

 

When I was testing it I realized that it only works on some layers. I couldn't find it documented anywhere but there is the Tools/TSD/Utire global settings scriptable asset that has a "Physics Interaction Layer" I tried modifying it but it overrides my setting and reverts back to Default/TransparentFX/IgnoreRaycast in no time.

I couldn't open the "Documentation Doxy" file in the project. (There is just html and latex folders with many files in them) I hoped to find more docs in there. Or does it have the same content as the pdf file?

 

@Meceka 3D world collisions can perform virtually identical if you only use a single ray, there isn't much reason not to use this variant - that's why it's going to be deprecated, it's just redundant at this point.
It is absolutely compatible with any and every vehicle solution as uTire is doing its own thing entirely, compatibility with the listed assets only means it's super simple to set them up.

About the doxy documentation, open the index.html - this is a generated script reference.
I'll look into the layer based problem you mentioned later today and get back to you asap.

Edit: Which Unity version are you on? I used an internal editor function that could do some funky stuff on newer versions(it shouldn't ever default itself to IgnoreRaycasts layer), this might be the issue. Comment out Line8 of uTireGlobalSettingsEditor,

Code (CSharp):

1. [CustomEditor(typeof(uTireGlobalSettings))]

set up your layers in uTireGlobalSettings' default inspector and see if it solves the issue. I'm not quite sure what's going on yet, but until I figure it out you can use it like this, this tiny editor script just makes the settings editor a bit less boring, but nothing important is going on.
Also make sure you only have a single uTireGlobalSettings instance in your project(it'll use the first one without checking if there is multiple scattered around the project - the next version will have a safety check for this as well).

 

@Pecek Sorry I just found that index.html

I have set it up with 3D collisions and with writing my UnityCar integrations. So far it works but I will ask in another post if I made it in the correct way.

Unity 2018.4.20f1. I don't know what caused a conflict with setting that layermask, but definitely it was un-settable. Now it works. Perhaps its related with having a editor window of uTire open aside.

Our game will have quality level settings, and we definitely will have one for the tires. But there are some issues with that right now. We are going to change Ray Count in runtime based on quality settings.

I have set Optimization Angle to 180 so that I would have raycasts only at the bottom side.

Ray Count: 64


Ray Count: 8


Ray Count: 3


Ray Count: 1


1st issue is, distribution of Ray's are wrong. Changing Ray Count shouldn't change where the distributions center is. So when I set Ray Count to 1, the ray should be going down, not to right side as in the last image.

2nd issue is, more raycasts mean more deformation. These screenshots doesn't make it apparent but you can easily see that with the screenshot that has 64 rays. Deformation amount should remain the same but it should just increase the detail and resolution when the ray count is increased.

 

The global settings layermask issue happened again. Instead of modifying the code, I set the inspector to debug before modifying the layermask.

 

Follow the tutorial please, these issues have been addressed both in video and in the manual.

• Side and offset axis is important, at least one of them is off in your setup.
• Mesh rotation is important. I can't see it properly in the image, but this also might be an issue here. Edit: I mean the imported mesh' orientation, not the gameobject's in the scene.
• The scale of the mesh is important

More rays mean more contact points, the script registers these contact points and the shader pushes the vertices away from those points based on how far they are. This is by design, not a bug. To get quality levels create 3(or more) different setups and switch between them at runtime.
Simply changing the ray count wouldn't work because this isn't a simulation by any means, it's basically a glorified blendshape implementation.

I dug into the layermask problem a bit more, something is indeed off with the internal call. I'll figure out a way to display layermasks properly in an editor window, but the latest post I found about it yet is from 2014, so yeah.

 

How on earth do you assume I didn't follow the tutorials? I followed your videos and tutorials many times already. And where exactly are these issues addressed in the video or manual?

Which videos and which part of the docs apply when using 3D world collisions instead of the standard? That's not defined or I can't understand it.

The offset axis was set correctly. It was X, but due to a bug with your asset I just had to set it to Y and revert back to X. That fixed the ray distribution issue.

I already had a really hard time understanding how to set up with our vehicle physics(UnityCar). All you say is that its perfectly compatible but there isn't any info in docs about integrating with an external and unsupported physics. And you absolutely gave no info whatsoever. I had to duplicate an implementation and modify the code to fit UnityCar and hack it into your code. Ideally, I shouldn't need to modify your code as it will break with asset updates.
Then there are many values like these...
springCompression,
targetDistance,
GetWorldPose,
steerAngle
...with no comments and I have no idea if these are normalised, direct value, should be negative or positive or absolute? or if local/global? I had to dig through all your implementations code and when it's unclear, I had to just find what they are with time-consuming trial/error.

 

@Meceka I assumed you didn't follow the tutorial because otherwise the axis wouldn't be off. There is a specific video on setting up 3D world collisions(which is also the currently first tutorial video on the store page), and there is one for the old system. There is a separate page in the manual labeled "3D collisions", where each individual setting is explained, and also a brief summary of how it works. I would start there.

Again, 3D world collisions don't care about your vehicle solution at all. There is no integration to be done here.
It's doing its own raycasts independently of anything else. You only need either 2D or 3D colliders for it to work. The vehicle solution used makes no difference at all, I can't make this any more clear.

I already addressed this when you asked about custom wheel integrations a while back. If I recall correctly I told you you will need to implement the IWheel interface to use the manager(or alternatively handle the updates manually), and I also told you there are two examples of this provided, one for the built-in wheel collider and one for the asset WheelController3D.

These properties are used by the built in wheel collider. For easy integration it's standard to use the same properties so you can just switch the type and your code still works, ss the comment says on uTireWheelIntegrations.cs line23.
But I agree, this is a perfectly valid point, if you've never used the built-in collider these values aren't all that self-explanatory(although Unity did a decent job naming the properties\methods).

However I'm going cut this off right here, I'm happy to help anyone in any way I can, but currently this is a $10 asset - simply put, dealing with your tone is not worth it for me, if you want help be civil, if you are not willing to and you still want help pay me properly, or if you want a refund send me a support email with your invoice number and I will start the process right away. I can understand if anyone has problems understanding how a certain system works, I'm absolutely willing to admit if I made a stupid decision(and I'm also willing to fix it), but any form of hostility is just a straight-up no from me.

 

@Pecek I had no intention to cause hostility here. I just can't take false accusations like what you did. Sorry I got angry.

Sorry, you were wrong with your assumption. I already explained this in my last post. Axis wasn't off, It's a bug with the asset. You can easily recreate it. Otherwise I can give repro steps.

It wasn't me. Post #77 was by CoderPro. I admit that I didn't read all the posts in the forum.


I never used the built-in collider. Therefore I didn't know what they could mean or what values from UnityCar I should use for them. Yes, there is room for improvement there.

I don't need a refund. The asset is very nice, definitely worth 10$. That's not what I'm unhappy with. I just could be happier if I received better support so I could integrate it in less time.

I wish I received a similar response as CoderPro got. At least a sentence like that suggesting me how I could start.

 

@Meceka That's fair, my bad about thinking it was you who asked about it. I'm sorry, should have checked it.
The problem you mention is inspector related, the issue is with the axis button itself, that's why selecting another one and then changing back "solves" it. Your ray distribution was all over the place because of this, not because the position\direction calculation is off.

I'll send a PM, I need to know more about the issues you are having.

 

interesting, never saw this asset before, typically I do this kind of work with softbodies and bake into an animation... I wonder how well this would perform on a racing game. looks pretty neat. 10$ too.....( may need to buy this even though I I don't buy many asset anymore..

Nice work.



Edit : just seen this.

`Standard is extremely lightweight, it almost acts like a blendshape, but it takes into account the base tire pressure, speed, angle and compression as well. It works really well on mostly flat terrain, and can handle hundreds of cars easily, but fails miserably on steep terrain.

3D World Collisions variant is considerably heavier, however, it can conform to almost any collider using raycasts(which are fully customizable to fit your performance budget). Suitable for any situation.`

I also like how detailed you are in how it works.

 

Can I make a suggestion, which is to try simplify the setup even more, or just make the setup totally automatic, or add multiple wheel prefabs (e.g. onroad, offroad etc) that are setup for easy plug and play use. To me that will be very useful to see.

 

@Recon03 thank you, I really appreciate it! If you decide to pick it up(or have any questions regardless) let me know!

@khos uTire V2 is coming, with ease of use in mind. I can't really go into details yet as it's still under constant change(this is an almost complete rewrite, the shader, and the scripts as well), today a late may\early june release seems realistic(this could change if something comes up, but the new concept is working, it's just a matter of legwork). I'll give updates on the way, but if you have any other suggestions let me know(on the forum\PM\email, whatever works for you).
This also goes for everyone else of course, I'm all ears to your suggestions.

 

Yes! thanks for the good news Look forward to it.