SavMartin
Refactor Randomize
This PR should be taken after 'Refactor Unwrap' as the scaling function has changed slightly.
- Add steps
- Add scale random
- Add true seed transform (now when changing properties, the random will be predictable)
- SpeedUp x1.4 in island mode
-
SpeedDown x1.25 in face mode
- Add clamp method for BBox
- Removed multi_obj_loop
- Removed numpy methods
- Using functions from utilities_uv (scale, rotate, translate)
The code has been greatly simplified by: f = (f,) if self.bool_face else f, this avoids a lot of conditional expressions.
Only now I found out that the default parameters of update_edit_mesh cause unnecessary calculations in our case, it will be necessary to apply the following arguments for this function wherever possible.
bmesh.update_edit_mesh(me, loop_triangles=False, destructive=False)
The Rotation and Scale Strengths are now breaking the "Withing Image Bounds" and "Pre Center" modes. As far as I can tell right now, the transformation pivots for these two options should be revised.
Only now I found out that the default parameters of update_edit_mesh cause unnecessary calculations in our case, it will be necessary to apply the following arguments for this function wherever possible.
bmesh.update_edit_mesh(me, loop_triangles=False, destructive=False)
Indeed
@franMarz Didn't it go outside the border before that, too? I think this algorithm was a little buggy to begin with. But I know the best way to fix it so the islands don't go out of bounds.
@franMarz Didn't it go outside the border before that, too? I think this algorithm was a little buggy to begin with. But I know the best way to fix it so the islands don't go out of bounds.
I use it a lot and it was performing better with rotation. And yes, it's a bit buggy, but not that much, especially for islands/faces whose bbox were close to (1,1) in any axis. I can look into it anyway, but probably not soon.
@franMarz Fixed this bug, but I added the steps parameter, and it doesn't work correctly for it, but I think it's acceptable for now. It seems that the logic during rounding needs some thought
Fixed. But now I don't like the Steps addition. I prefer the Int Mode, it was only a property (better than two IMO), was not clamped to 1 UV displacement and using two float properties doesn't make sense to me here. I added it for randomizing mapping outside the 1-1 UV Space for images scaled below 1 in their mapping controls within the shader. Obviously is not gonna work with Within Image Bounds, we can place the Int Mode below it in the interface panel and make that clear in the description. It just worked with the U and V Strengths to control the maximum Int steps that could be reached for each island/face in each direction.
It's great. Just a few things:
- There is a problem with "Pre Center" scaling down the selected UVs with Strength values close to 0.
- I don't fancy the fact that Rotation is being performed always counter-clockwise with positive values, and Scale is making the islands always larger for values higher than 1 and smaller for values lower than 1. I'd rather make both random with their values just controlling the strength of the transformations, not the signs. So maybe Scale should start from 0, too.
- I don't quite get what Steps do, a description would be very welcome. It's the Steps behaviour the expected for values greater than 1?
To understand what STEPS is for:
- Create a 10x10 Grid
- In the material add procedural Checker texture with scale of 10, (don't forget to connect UV).
- In randomize, select Per Face and enable STEPS.
- Change X&Y Steps to 0.1
We get randomly but evenly distributed uv on cells.
The problem with "Pre Center" can't be called a bug, since the scale of the islands is adjusted to it, so I decided to just notify the zero Strength
I don't know why the islands rotated (more often) counter-clockwise. They rotated clockwise too, but I agree, much less often. I changed the random to random.uniform and it seemed to rotate evenly.
With the scale now turned out to be better, it suits your requirement, and with additional parameters it is possible to imitate the past version
Due to your last 2 commits I'm now getting this error in the console when trying to enable the add-on. I'm using Blender 4.0.2 on Windows:
from . import utilities_uv
File "C:\Users\a\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\TexTools\utilities_uv.py", line 343, in <module>
def get_selected_uv_faces(bm, uv_layers, rtype: list | set | iter = list):
TypeError: unsupported operand type(s) for |: 'types.UnionType' and 'builtin_function_or_method' "
I messed up the branch for these latest commits, but fortunately there's nothing radical about it, except that annotations aren't supported by the old python
Yeah, we better keep TexTools compatible with Blender versions using Python older than 3.10.
I'm willing to merge this, because the improvements are good enough and the patch has been open for a long time already, but I don't get something still.
When I added this tool to master, the Pre-Center option just made the islands align to the UV Space center like when you use our Align operator with Center as Direction while in Faces or Island UV Selection Mode. It was a long time ago and as a user of Blender I hardly ever have used this option, though, so I don't remember why I added it in the first place. Anyway, I find it even less useful if the UVs tend to go to the center, downscaling the islands, for low randomization strength values. Maybe I'm just missing a good point here. And maybe we should remove it altogether and make the code easier to maintain.
About the operator itself, we should change its name from "Randomize Position" to just "Randomize" in my opinion. You can randomize any transform after all.
Precenter combined with strength play the role of a dynamic bbox, though I don't know if that was intended as the original purpose. Yeah, the randomize is cool, I didn't think it could be controlled to such a degree.
But that's nothing, I'm thinking of changing the bake system, add a lot of stuff, adding a ui list with multiple modes (to bake like in Substance Painter multiple modes at once), adjusting skew by bevel mask, add cancel bake. Also iterative bake system has one strong disadvantage associated with high padding, when padding of one island overlaps the other, it can be solved by making padding yourself, through gpu shader (references are available). But first we need to simplify the existing code, which has echoes of version 2.79 and below.