Wrong number of splits
LKAMinco opened this issue · 9 comments
Idk if this is and feature, but i think that longer markers should mark size by 5, now there is an offset by 1, what lead to wrong numbering and cunfusion.
I can see how it causes confusion. It's not immediately clear that the both the location of the ticks, and the mirrored loop on the right side is correct.
But is indeed the case. The case in which the mirrored loop doesn't line up with the nearest tick is a consequence of the edge's length not being evenly divisible by the distance between each tick mark.
Here in this example below the edge's length is 2.5m and the distance between tick marks is 0.012m
2.5 is not evenly divisible by 0.012.
Here the edge's length is 2.5m and the distance between tick marks is 0.01m
2.5 is evenly divisible by 0.01, so in this case the loops and the ticks do line up.
Ohh yeah i see, in that case it woul be more intuitive if user use distance snap that longer markers would marks multiplication of 5 or maybe just in case where u have set distance to dividable number.
Ohh yeah i see, in that case it woul be more intuitive if user use distance snap that longer markers would marks multiplication of 5 or maybe just in case where u have set distance to dividable number.
To clarify, you are wanting the major ticks to be every 5 ticks instead of 4?
I have plans to make the major ticks every nth tick, where the user can set the value of n to whatever they wanted,
Yep, in that case your solution is even better.
I have plans to make the major ticks every nth tick, where the user can set the value of n to whatever they wanted,
Pushed an update to add this.
Major tick multiplier reset each call of operator. Would be nice if it can be set once and saved. All the settings could be shared among files or at least in current blendfile.
Major tick multiplier reset each call of operator. Would be nice if it can be set once and saved. All the settings could be shared among files or at least in current blendfile.
Sorry, I forgot to add it as an exception when resetting the operator's properties.
Unfortunately, I don't have a way of saving the state of the operator's props to the blendfile or the addon's settings.
Anyways, I pushed a change that should address the reset.
I know that properties can be registered in the scene, which can save then states along blendfile
I know that properties can be registered in the scene, which can save then states along blendfile
This is true.
I just pushed a change to save the property group stored in the scene.
It should now allow most of the snap options to be saved with the blendfile.