MikeJ, that is what I supposed someone could be doing.
A smart guy would just Store the current selection (there is an option for that), merge the file and preserve or not the new selection. The previous selection would be easily recalled (also, there is an option for that).
What I want avoid is in the future someone asking: "why that feature was removed? I loved it, I would like get it back" - we already have examples about this kind of situation.
MikeJ,
The way that Merge worked was kind of messy, which is why I am so glad that Micheus is fixing it...
I don't think it got used much because of how messy it was.
Micheus,
I played with "Replace current" a bit more and it looks like any current selections are dropped and the merged in object keeps the selections it had when last saved. Do I understand it correctly now?
Thanks,
oort
(03-17-2014, 09:41 PM)micheus Wrote: [ -> ]MikeJ, that is what I supposed someone could be doing.
A smart guy would just Store the current selection (there is an option for that), merge the file and preserve or not the new selection. The previous selection would be easily recalled (also, there is an option for that).
But how does that affect the selections in the file to be merged in? When you say 'store the current selection' which file are you referring to? I still don't understand the 'traditional' workflow, so I'm a bit lost.
(03-17-2014, 09:41 PM)micheus Wrote: [ -> ]What I want avoid is in the future someone asking: "why that feature was removed? I loved it, I would like get it back" - we already have examples about this kind of situation.
I completely understand your reasons. But a 'smart guy' (who I am assuming Wings3D users to be) would recognize that an old, inefficient workflow should be given up in favor of a better one.
MikeJ,
Old habits die hard. Here is an example of something that changed because it was considered to be a better way but upset quite a few people...
Gripes
oort
As I said before, I do understand your argument. People hate change of almost any variety – even when it's in their best interests. I know that all developers struggle with this, including our own most excellent Micheus who works hard to make these improvements for us.
However, by your own admission, the old merge functionality was quite messy and, as such, a lot of people avoided using it. I know I don't want to use it – even with the current plug-in that Micheus is creating for it. It is both inefficient and nonintuitive. And by his own admission the plug-in isn't going to change much of anything because he doesn't want to upset people who are already used to the old, messy workflow.
Nonetheless, I can take a hint (after a fashion) and realized that I am swimming upstream with this argument. Changes will not be made to make the merge functionality work efficiently and intuitively, so I will just leave it and this discussion alone.
What Micheus has done so far has already made Merge 100% better and I think he is going to add the "new selection" option, which should make it work the way that you and I would like it to work...
oort
I am trying to think of what would be the best method to add the option to have the merged in object auto-selected...
Should another group of choices be added to "Elements to Merge" and "Selection option"? Maybe something like "Merge Mode" or "Merge Type"??? In that group have "Selection" and "All" as choices. Merge Mode or Type may be misleading. Not sure what would be best.
Otherwise under "Selection option" you would have to have something like all of the following...
"Preserve Current"
"Add to Current"
"Replace Current"
"Preserve Current add All"
"Add to Current add All"
"Replace Current add All"
Maybe there is a better way... Maybe Micheus already has a better way???
Edit: Or maybe all you need is the ability to enable/disable "auto-select mode"???
Thanks,
oort
(03-17-2014, 11:24 PM)MikeJ Wrote: [ -> ]even with the current plug-in (...)
It's not a plugin. Just correcting the terms.
A plugin is something that I can make available for anyone that wants install it or not. This is an addition to a resource already in the Wings3d core - it will be available only if the main devs decide that. In this case, I just learned a little bit more about wings3d codes. (but, I don't care)
Quote:so I will just leave it and this discussion alone.
No problem. It's a brain-storm.
Just for use a simple (stupid) example about why to take care about the selection in a scene/object being merged, try to suppose that someone has a object library. In this case, a tree which the its base has one face selected for use when it is merged. So, we are creating a new scene whose we want put a lot of trees - we use the command .Put On. for that and it requires one face selected in the source object (in our case the base of the tree):
I used the traditional
Merge for that.
oort, I think it'll become [more] confused.
Micheus,
I was having a hard time thinking of a way to do it that wouldn't cause confusion. We can just select the merged in object/objects in the Geometry Graph. I hope dgud will approve this update to the Merge command.
Thanks again,
oort
I really dont know if the selection options in Merge window are so useful (there are many limitations to deal with multiple selections in Wings, for example, user has to select/deselect one by one, an entire folder cant be hidden with a single click, etc).
The fact is: Wings accepts two objects (or more) with the same name! I ever understand this, and i dont know if this can be useful some way.
So, thinking in Merge command, the ideal imo would be:
(a) an option to Replace the object with same name by the one is being merged (delete homonimous in scene)
(b) another option to Rename the object is being merged, if there is another one with identical name in scene (keep both ones)
Just to explain, this is how the stuff works in commercial packages.