So I am trying to download 3.2.0 so that I can say with certainty I hate the tab UI, but I run into this in chrome:
And then if I ignore it, this in Windows:
I think that at this point UVPM makes at least some basic amount of money that should cover you getting a digital signature. Average user should not be expected to disregard 2-3 unique security warnings to use regular software they purchased
EDIT:
Ok I tried it and I hate it even more than on the screenshots. If I have reasonable sidebar with that is wide enough to display most button titles but not too wide to take away too much of a viewport space, with UVPM I need to extend the sidebar to that it takes too much of the UV viewport just to read most of the button titles. Then when I switch to literally any other tab, the sidebar is frustratingly wide and everything is unnecessarily stretched so I have to resize the sidebar back to not waste viewport space. So now, with 3.2.0 I have new frustrating duty of constantly wrangling the sidebar size because of one special snowflake addon tab:
Itâs so embarrassing that at the default width, your (unnecessary) set buttons donât even have readable title:
If sidebar width is sufficient to not clip any labels/icons in UVPackmaster tab, then all the other tabs are way too wide and fat. If all the other tabs are that their optimal readable width, then UVPackmaster tab is way too narrow and clips lots of stuff.
On top of that, since you used some unique wonky stuff to re-implement existing functionality, I can no longer just display all panels and Ctrl-Click their headers to isolate one since your panels arenât really panels, just boxes. So now I have to keep unique muscle memory for unique UI interaction again just for one very special addon tab.
Lastly, links to previous versions are removed, so now I canât go back to the 3.1.5
Ok, the UI mockup is going to take me a while since the UI is quite complex. Doesnât mean itâs hard, just lengthy. But I got a big chunk done already. And it brings all the benefits of using the native blender UI functionality, such as Ctrl+Click to isolate panels, click-dragging over the panel headers to open/close many panels at once, etcâŚ
For example since the main panel with the Pack button is now tiny, it can be easily pinned using Shift+LMB and it then shows in all other tabs. So that way user can have pack button easily at their disposal regardless of the active tab, but the pinned panel is very compact so it leaves space for the contents of the panels in other tabs. Thereâs some slight renaming for better consistency, and also reorder of advanced options vertically based on usage priority.
I will do Aligning and Grouping panels next, then Options/Preferences. Main point is for it to feel like a part of Blender, not something wonky thatâs been hammered into existing UI with blunt force.
Also if I am a new user, and I am confronted with something like this:
Itâs much less scary. I simply see just a duo of pack buttons and few very basic self explanatory knobs. Then I see collapsed panel saying âAdvanced Packing Optionsâ. If I am a new user that doesnât need to do anything advanced yet, I can be like âCool, I can ignore it for now and look at it when I need toâ
Once the mockup is finished, the only difference will be that between Advanced Packing Options and Utilities panels will be 3 more: Aligning, Grouping and Preferences. But they all will be collapsed as well so it wonât be much more overwhelming to new users.
Yes, I am aware that usually one doesnât work with the entire map duplicated, thatâs why the user has a possibility to use many different tack groups in order to configure the functionality (by simply assigning different islands to different groups and also keeping some islands not assigned to any group). This way you should not be forced to disable the Require match for all option. Did you try it that way?
Also note that for the functionality to work stable sometimes it is required to remove UV vertex duplicates (as the tip says). In order to do that run âMerge UV By Distanceâ with a very small offset.
If you still are not able to make the feature work as desired, could you please some simple blend file with the problematic UV map? It would significantly simplify the debugging process.
I work in mobile gaming. We have to save texture space, so we use various tricks like mirroring, polygonal tiling, incuts⌠UV layouts, where some of them are used, now conflict with the Track Groups feature.
Mirrored and dublicated. The UV01 square contains only half of the mirrored cylinder. The one next to it has a duplicated cylinder, but its halves were stitched together by automerge.
Partial overlap. A very common technique for walls, beams, ropes. The texture is baked with a reserve, and parts of the model use parts of the baked texture.
Mirrored text cut. If one of the sides of the model with text is mirrored, sometimes the text has to be cut out and mirrored.
In all these cases, ** Track Groups** does not work. Or I didnât understand something.
Hi @glukoz
Not sure if this is best way to solve this, but having two island grouping with same label is a bit confusing.
Perhaps the one generated by Panel should be named something different ? like grouping editor
O and I think it would be nice to just move the Remove UVP data join with Utilitis Panel .
Finding Utilitis with an Extra Orient UV Panel is a bit cumbersome I think.
I took a look at the blend file you attached. It turns out that the functionality doesnât work in the scenarios you provided because the islands from the blend file are only similar by their border shapes whereas the tracking functionality is currently based on vertex layout similarity between islands.
In a future release I will implement an option for the tracking to also analyse islands based on border shape similarity and that should solve the problem.
I have messaged @glukoz some time back with working mockup of the better UVPackmaster UI, but so far nothing has changed. Hereâs the video showing the mockup:
If anyone else here thinks current UVP 3.2.0 UI is inappropriate and agrees that it should be improved, or at least reverted, then please let glukoz know!
Let me paste my original response to your mockup I sent you in PM as it is the most relevant to the discussion:
First of all thank you for the entire work you put into this, I really appreciate it.
Unfortunately it turned out exactly as I predicted: your approach is 100% better than mine when dealing with basic packing scenarios while it becomes inconvenient when switching to more complex use cases.
Let me name two examples such cases:
using a grouping scheme in a group-based packing mode while using another grouping scheme to define lock, stack or track groups.
working with packing functionalities in a group-based packing mode, then switching to grouping islands by similarity, then switching back to packing again.
In both above cases your approach turns out to be inconvenient.
Please understand that while Blenderâs default panel system is the best way to go when all panels are based on independent logic, it becomes unhandy as soon as panels are dependent on each other and logic between them is more complex.
That being said, your proposal provides many ideas which are worth implementing for sure. Most notable being the split into basic and advanced packing options panels.
In fact, Iâve already implemented such an advanced options panel in the addon version 3.2.0-u2. In that version I also introduced changes which minimize the problem of the left margin being too wide. In such a form I donât think it is much of a problem on resolutions supported by modern-day displays.
And few words more:
Can you now admit that the new UVPM UI system is equivalent to the approach Blender uses natively in the Properties view? If not then please provide a single difference as you didnât do it so far.
Now your main argument is that the multi-panel buttons take too much space on the left side of the tab, right? So that labels are not readable? So my best advice is this: a side effect of you sharing the mockup is it is visible how wide you keep the Properties panel in the Blender UI. Set the UVPM tab width to 2/3 of your Properties width - everything will be perfectly readable.
Not even mention the obvious fact that if a user is familiar with the tool, it is not required for every single label to be fully visible for convenient usage.
In Properties Editor, you can only see one tab at a time. The whole point of your button UI is ability to show contents of multiple tabs at once by Shift-clicking them. This completely changes the purpose of the button bar. Tabs in the Properties editor are never meant to show contents of multiple tabs at once. Properties editor is a tool to switch between displaying a single type of scene/object/tool data. Your buttons are additional UI to manage the UI. Properties Editor is a single place designed to switch between multiple systems and aspects of scene. Your addon panel is a single place where you somehow managed to break display of single addon/system into multiple pieces user has to wrangle.
Tabs in Properties Editor do not completely break the functionality of Blender UI panels, such as ability to Ctrl+Click to isolate single panel, Click-Drag over panel headers to batch open/close them, Click-Drag them to rearrange their order and Shift+Click them to pin them.
Properties Editor is an Editor, not overlay panel. Itâs not drawn on top of another viewport so you are not fighting for a space.
Native Blender tools do not use vertical button bar in any sidebar panel anywhere in the entire Blender.
Regarding to your original response. Again, thereâs absolutely nothing related to group based packing modes that necessitates the existence of UI to manage the UI. A simple example: If I shift-clicked every single button on your button bar to make every single panel active, and then the button bar would magically disappear, every feature of UVPackmaster including group based modes would still be usable, there would not be anything missing from the UI.
No, it is totally not true. Iâve already explained this.
Itâs sad that you put so many energy into this conversation but apparently after such a long time you still have no idea what the main rationale behind the new UI system is.
âYou choose which multi panels to show by using toggles on the left in the UVPackmaster3 tab. Every toggle drives a single multi panel. You can press a toggle with Shift in order to enable more than one multi panel at a given moment. Contents of currently selected multi panels are displayed in the main column of the UVPackmaster3 tab.â
Literally the only difference between the âmulti-panelâ UI and regular Blender UI is that this UI can allow you to completely hide panels, instead of just collapsing them into a header. At the expense of:
Horizontal space
Most of the mechanical panel functionality (as described above)
Consistency with rest of the blender and other addons.
Before you again say âBut the properties panelâŚâ let me try to explain it in a different way. The properties panel tabs are essentially a radio button, only one tab can be active at a time. Thatâs no true for your button bar. If it was true, youâd never implement it because you would find it limiting that user canât have for example âPacking Optionsâ and âOther Toolsâ activated and visible at the same time, and would have to constantly jump in between the tabs.
Once you realize that without ability to show multiple tabs at once the panel would not make any sense, the claim that:
âThe whole point of your button UI is ability to show contents of multiple tabs at once by Shift-clicking them.â
âŚmakes more sense. If you think it does not, then only other two intentions I can think of to have this button bar is:
Trade off horizontal space for vertical one (no collapsed panels but button bar vs no button bar but collapsed panels).
I donât deny it. The fact that it can be achieved doesnât mean that it is the whole point.
Do you even read what I am writing? Iâve already told you this: this feature is optional - it is not required to use at any time for convenient addon usage. Not using this feature doesnât limit the user in any way.
Let me explain it in a different way: there is literally nothing what prevents you from treating UVPM multi panels like radio buttons. Nothing.
Unfortunately what you cannot understand is that the native way of handling panels in Blender stops being convenient when the number of panels in a tab becomes large.
Blender devs are very aware of it, thatâs why they introduced buttons which filter panels by property type in the Properties Editor. Now the only difference is that UVPM multi-panels filter panels not by property type but by functionality type.
But you know what? In fact, Blender also natively provides buttons which filter panels by functionality type (once again: Blender devs understand that showing too many panels at once is a UI disaster). So here are the aforementioned buttons:
Yes - exactly UVPM multi-panels are simply tabs from the logical point of view. The concept is identical to such an extent, that in fact I initially planned to do the UI rework by simply splitting panels into a few native Blender tabs (here is a proof).
I resigned from this plan simply because Iâve got feedback from some users saying that they have many tabs present in the N panel already so adding 4 new native tabs there is not very desirable.
But the fact is UVPM multi-panels are simply tabs. As well as buttons in the Properties Editor - they are also tabs. As well as tabs in the N panel⌠well they are also tabs
Sorry but no amount of mental gymnastics you do will solve the fact that the current solution doesnât look good, doesnât work well and is just not appropriate for commercial addon of this price. Commercial addons should be held to a higher standards than the free ones. They should not feel like some random wonky kitchen sink of buttons. There are so many different ways to solve it.
Like neither of these two issues requires adding a vertical button bar to solve. Do you really think you, in particular would not be able to create a grouping scheme editor panel class that can be instanced into lock, stack and track groups panels individually when you already did that when you literally built entire UI sub-framework on top of Blenderâs native one in your addon? (Your packer addon seems to be overwhelmingly just custom UI code).
It feels like you very well know that already, but itâs too hard to track back now that you invested so much time into doing complete UI overhaul, just to scrap all the work.
Of course your addon would be worse if one single addon just for UV packing had multiple sidebar tabs. That would be very bad, because single UV packing addon has no business being that complicated UI-wise. So what you did is instead create another duplicate tab bar where you did exactly the same thing, with the exception that yours uses non standard visual style, non standard layout rules and breaks the UI management functionalities of the sidebar panels. Exactly those functionalities designed to make management of larger amount of panels easier.
Itâs only a bunch of your personal options - nothing more.
This only proves you know very little about the addon code. And generally about how the packer works as you only use a small subset of its all capabilities. The multi-panel code is about 1% of the entire addon code (if not less).
I just implemented a logic which is already used by Blender natively in many places. And itâs really funny you cannot admit it when being confronted with simple facts.
But itâs your problem - not mine. For me this conversation is over.
Starting from this version the engine installer on Windows is signed. Accept the certificate if Windows asks you for it during installation.
Significant boost when packing a huge number of islands into many tiles thanks to the new option Tile Filling Method. The option can be set to one of two values: Simultaneously and One By One. The Simultaneously method is much faster, when packing a huge number of islands (thousands of islands) into many tiles. When packing a moderate number of islands, performance of both methods is similar. The new option is available in the Tile Setup subpanel:
Improvements for the Normalize Scale functionality. The user now has a possibility to specify scale multiplier to be applied after normalization is done on a per-island basis. The multiplier is specified in percentages. The idea is the user may assign a scale multipliers larger than 100% for islands having higher priority and/or multipliers less than 100% for islands with lower priority:
WARNING: this new functionality is going to replace the older feature Island Scale Limit (which was less convenient to use). The Island Scale Limit feature is now obsolete and will be removed in a future release of UVPM.
New option for the Border Shape similarity mode: Check Holes. When enabled, the Border Shape mode will also take into account shapes of inner holes when determining if two islands are similar (not only outer shapes).
Ability to move the active target box in the box edit mode directly in the UV editor when pressing and holding LMB inside it.
Speed up the Select Similar operation using multithreading.
New general UI option Short Island Operator Names: make island parameter operator names in the UI shorter. For example: change the name Set Rotation Step to Set, the name Reset Rotation Step to Reset etc
Increase the maximum group number from 100 to 1000.
Is the advantage that scaling can now no longer accidentally scale each time you pack? I forget the specific situation in which this happened (normalisation turned off?), but it happened a few times. If not that, whatâs the advantage to this, it seems the same at least superficially?
edit: as far as overlapping similarity goes, I often mirror only parts of an island onto itself, and as their border is now different (even though every vertex falls exactly onto another!) they donât stay together with the âExact matchâ.
Hereâs a sloppy example where I drew on where the selected faces originated, where theyâre now overlapping their mirrored equivalent.
Are you now comparing the old Island Scale Limit feature with new Normalize Island Multiplier?
The new feature is much more convenient because the old Island Scale Limit only defines the upper scale limit to be used during packing with no guarantee that the limit will be actually reached. So the user had little control over the resulting proportions between after packing when using that feature.
Now Normalize Multiplier is more convenient because it allows one to set the proportions in the precise way: when set, the resulting proportions between islands will be exactly as specified by multipliers.
This release didnât introduce any changes to the overlap detection logic. The islands you showed do not satisfy requirements for the Exact overlap mode in general. You should use the Any Part mode in this situation.
If you believe you found a bug, please consider sharing a minimal bled file allowing to reproduce it
UVPM multi-panels are simply tabs from the logical point of view. The concept is identical to such an extent, that in fact I initially planned to do the UI rework by simply splitting panels into a few native Blender tabs (
