Followup
| Message |
 |
- Date: 2011-04-10 20:49
- Sender: Ton Roosendaal
- For new users it might be diffucult to find out when things fail because you expect different behaviour, or when things fail because there's a bug.
But it would be very helpful to not report your expectations or remarks on conventions. Making Blender (better) is not what we have this bug tracker for. If you like to help, you can find a "get involved" linked on frontpage blender.org.
The "interface screwup" I can't see even, where is this property window that shows the UV coordinate values? It really helps best to just attach a .blend file as example.
| - Date: 2011-04-10 20:55
- Sender: Burt Reynolds
- Disclaimer: I'm not a developer, but a user
First of all, there are no accepted interface conventions among 3d apps.
Second of all, common sense does not dictate that vertices be merged automatically by default. While this may be desired in some cases, it cannot be desirable in the general case, because meshvert to uvvert is a 1:N mapping where N is the number of faces that a uvvert is connected to. The fact that they appear merged in the UV editor is merely a UI feature. In general it is advisable to not start with the UV mapping until the mesh topology has been settled. Yet for the most part, Blender will update the UVs where it makes sense (ie. when subdividing faces). There could be a "merge UV verts" feature" in the merge tool, but it should not be the default, and I doubt any other package collapses UV vertices by default either.
The script you quote is not part of Blender 2.56, I would assume it collapses the vertices of the existing UVs through some heuristic, but this isn't really related to the problem you describe.
Thirdly, I do not know what property window you are talking about. In 2.49 you could edit UVs numerically through the "N" panel. In 2.5 I don't see such a feature. It might be you are misidentifying the "select" operator popup. Its numbers refer to the mouse coordinates.
Lastly, there is "B" for box select in the UV editor as well as the 3d view.
| - Date: 2011-04-10 22:49
- Sender: Ian B
- It's the inconsistency in the UV updating that's the issue here. If I subdivide a mesh edge to create a new vertex, the UV map is updated correctly to add the new vertex/faces and the UV vertex is created in a suitable location. Great. Now I merge the mesh vertex I've just created with a surrounding one to remove it again. The UV map is left with the faces removed, but the vertex unconnected where it was previously created, and doesn't update to reflect the mesh merge just done, leaving a hole in the map which needs manual attention. That update might be a "convenience", but it's a consistent convenience, and after many such mesh edits on a complex mesh this becomes a significant problem. There ought at least to be a preference setting to control this behaviour.
In UV edit mode there's a property window named "Select" at the left-hand side. In there is an XY coordinate box titled "Location". Click on a vertex and this updates, but not consistently. It's editable, so the logical assumption is that this is a tool to update directly the UV vertex you've just selected, since it tracks that. If it's not, then it's not performing a terribly useful function.
It would, however, be a very useful function indeed to be able to manually input the XY UV coordinates for a UV vertex on a texture, since that would allow highly accurate joins of submeshes using a single texture without seams. Since you can only UV-edit one mesh at a time, an easier way to set the edge joins exactly on the UV texture rather than visual trial and error would be highly preferable.
Standard interface conventions are something that have been developed fo 40 years since Xerox Parc. Unselectable menu options should be greyed or removed rather than being clickable and doing nothing. Objects shouldn't move unless you have them selected and you drag them holding a button down. Interface elements (like coordinate boxes) that don't produce changes when you edit them should not be editable... It's not about standards within the small subset of applications that are 3-D apps. it's about consistency with 40 years of standardisation on how users interact with graphical software. Interface standardisation and consistency, rather than arbitrarily reinventing a perfectly good wheel, decreases the learning curve for users and improves productivity. And as pointed out, it makes the difference between bugs and designed behaviour more obvious for users...
| - Date: 2011-04-11 00:11
- Sender: Burt Reynolds
- Please understand that there is no general solution to your problem, that makes sense in the general case. Blender cannot read your mind to figure out your intent (yet). If you can come up with an algorithm that does what you want, you can propose a patch for an option.
"Select" is the OP for selection in the UV editor, its inputs are coordinates which are derived from the relative UV coordinates of your mouse at the time you press the button. If you change them manually it would have the same effect as clicking onto that area (ie it will select the closest vertex from these coordinates). In 2.49 there was a numeric editor in the UV editor, that does what you want, it's seems to be missing in 2.5 though, as of yet.
If you want to edit UVs of different meshes, consider assigning each a vertex group for the whole mesh and then temporarily join them for UV editing.
>"Unselectable menu options should be greyed or removed rather than being clickable and doing nothing."
Blender follows this for the most part (This can be a non-trivial problem). Please don't mix up "This doesn't do anything!" with "I don't understand what this does, so it doesn't do what I expect!".
>"Objects shouldn't move unless you have them selected and you drag them holding a button down."
This is phrased a bit weird (Obviously Objects will have to move in other ways in an animation package...) but I see where you are getting with this: You want blender to make all these operations click-drag because that matches your expectation. You want Action->MouseButton->Drag instead of Action->Drag, which would have the drawback of occupying one mousebutton, as opposed to the LMB confirm/ RMB reset transform there is now. I personally prefer the blender way as I feel it is faster.
>"Interface elements (like coordinate boxes) that don't produce changes when you edit them should not be editable"
They do produce changes, you just did not understand them in this case.
If you just took the time to learn the package and accept the way it does things (which may have a reasoning that you do not understand yet) you would find that things make a lot more sense and you think they do now.
| - Date: 2011-04-11 02:56
- Sender: Campbell Barton
- I can only assume you were mistaking the buttons under "2D Cursor Location" as the selected vertex location?
Added back uv selected vertex location r36094.
@Ian B, you mention many things that `should be` different, while I agree decimate should support UV's, vertex-colors, this is not the purpose of the tracker.
Since I cant see any other bugs in your report aside from the one mentioned above. - closing.
| - Date: 2011-04-11 04:14
- Sender: Ian B
- Thanks for agreeing that there is a deficiency, even if it's not considered a bug. Hopefully I can look forward to progress in future versions. ;)
| |
|
