i am working in a small games company (Egosoft - https://www.egosoft.com) and we are now fully switching our pipeline from 3dsMax to Blender.
As we use our own game engine, all our tools are also custom and have to be recreated.
The end goal for us is to have only an add-on which modders can install, to be able to create content for our game.
We now came to a point, where we need a modifier from 3dsMax in Blender, called “UVW Xform”.
This modifier enables the user to transform the UVs of the object (independendly of the shader editor).
How would the process be expected for us to get this modifier (when its ready to use) in the experimental branches?
How long can we expect this process to take until the modifier makes into the release version of Blender?
yes we are aware of the UVWarp modifier, but it is sadly not the “easy” solution, as it seems to keep track of each individual vertex in the UV layout.
The UVW Xform simply translates the uvs.
Its like comparing moving an object (UVW Xform) to creating a shapekey to move the vertices inside of the mesh (UVWarp).
EDIT: I got confused, i was thinking of the AnimAll addon and not the UVWarp.
UVWarp is sadly not as easy to use as we would like to, as it needs for example two objects to work.
Yes I agree - personally I think it would probably be pretty straight forward to implement something to also offer direct inputs as youre used from 3dsmax. But I dont know if there is any interesst from the bf developers to review such a thing, and if it fits their design philosophy… after all sounds pretty trivial to change.
Maybe its also a better idea to extend the functionality of the UVWarp modifier to include the features we need. Its not far off.
It would entail adding the ability to transform the UVs without needing to have a “control/helper” object, but simply be able to edit the properties in the modifier itself.
I don’t see why the UV Warp modifier wouldn’t work, but I don’t know what the rest of the workflow looks like. You can automate the tedious bits with your add-on, parenting and hiding the empty you’d use with the modifier, and give your users a panel to control the offset through. You might need to do some juggling with a property group or two, but there shouldn’t be any big show-stoppers.
as far as i understand the issue we are facing is, that the modifier requires two objects to work. The information about how the UVs are transformed are located in the empty, and not on the object where the animation takes place.
Being able to modifiy the values directly inside the modifier makes us able to have all the actions inside one single object.
Aside of that, it is really great to be able to simply offset your UVs without having to add a helper object and manage it in the modifier.
Accessibility is improved that way, much easier to understand how this modifier works.
Looking for example at the array modifier, its the same there.
By default, you can simply define the offset in the modifier, but can also add as an additional feature a helper object to control the offset.
I had a chat with Lukas Stockner, who simply wrote a patch (its crazy how quick he is!) expanding the UVWrap modifier to be able to work without a helper object.
I will link the pastebin link as soon as i got the ok from Lukas to do so.
EDIT: here is the link: https://pastebin.com/4RRB3Nam
How the modifier currently looks like:
The new implementation adds a “Source” line with a dropdown to select between “transform” and “fixed”
Source set to “transform”:
This is the same behaviour as currently implemented.
Source set to “fixed”:
Here the UI has changed a bit and shows the inputs for the offset, scale and rotation to transform the UVs.
This now makes it much more usable at first sight, as any transformations can directly be keyed in the modifier and no additional object has to be taken care of.
I can definitely see how having to use a helper object would make animated UV offsets hard to work with, especially arbitrary offsets. I’m glad Lukas was able to help.
Quick UI mockup to show a possible solution to that.
I removed the dropdown at the top and integrated the offsets directly above the “object offset”.
This layout is now very similar to the array modifier, less confusing for a user.
This is really cool! Coming from 3ds max as well, I’d wish several modifiers could get an overhaul like this. For example the SimpleDeform modifiers rely on an external object as well, wheras most 3ds max modifiers have their own gizmos.
I agree.
A custom gizmo per modifier (default setting) would be great for accessibility of the modifiers.
This what we did here is an additional option to have numeric input possible.
In conclusion:
A custom gizmo in a modifier would be great as a default.
This custom gizmo prints its transform into the numeric input.
Additionally an object offset can be defined for all the fancy fun
I think just having a set of coordinate spinners (which basically lets you place a virtual gizmo, without it getting a visual representation) with either absolute world coordinates or coordinates relative to the object’s origin point would already do wonders.
I assume it’s very easy to implement as well, since reading coordinates from an external object is obviously already in there.
