This seems like a good idea, but I think it is starting to get too complicated for a typical user to be able to even understand. For starters, people are already complaining about too many sketches (granted, automatically organizing them in folders helps, but still …) and remembering which generation of a sketch is the correct one to use at any given time could be a nightmare.
Suppose you move one of the copied bodies, then later still need to move one of its copies (which creates yet another new sketch), and so on. I realize that everything is supposed to be moved and saved together, but trying to figure which sketch is the correct one to propagate changes to the correct set of derived bodies seems like more trouble than benefit. Plus, if this is now automatic behavior, every time you move a copied body, a new sketch will be created – many of which would never be used, creating even more “sketch bloat”.
And that is not even considering how to program this correctly. Seems like a huge added potential for both errors and performance issues.
Yep, but as you said, most users don’t want to know the why and how. That’s for the people behind the scenes. I’ll disagree though, the reason people are complaining about the sketches is precisely because they are only partially connected and don’t visually follow the body. Thus making them just as useless as they were in direct modeling.
This was addressed and not as described, the particular quote was in reference to multiple bodies created from one sketch. Copies of a body would just be copies as they currently are, they don’t generate new sketches. Same as the current method, so no “sketch bloat”.
The only sketches that would be created would be ones where multiple bodies are derived from the same sketch and only if one of those particular bodies is moved. This is no different than currently copying the sketch and using it’s unique signature to create that secondary body. It’s just asking the program to do it automatically and organize the unique signatures together.
True, I have no idea how this would be programmed. I’m also pretty sure that these conversations around programming features are already quite complex. But the changes don’t seem much different than what’s currently occurring… Sketches can be selected as a whole and moved/rotated with no change to the spatial relationship with each other, this translates to the body itself with ZERO effect on history order or function or visual 3d representation of the body. Copies of bodies are still just copies of bodies. Adjustments can still be made via sketches after the fact. All of this is based upon the original spatial coordinates of the sketch plane(s). This is the current system AS IS.
It’s not changing the full system, it’s allowing the functions that are currently available to be tied together and to be organized in a specific more navigable manner. This would lead to less user errors especially for visually minded people and as for performance issues, I doubt it would be a huge burden since it’s only altering spatial coordinates at the beginning of the history tree, not adding to history and subsequent calculations as you described in your other post. The current performance issues are more related to the rollout of the update than the programming itself, or so I’ve been told and to quote “this is not true”
For all the talk of how HBPM is the new way of doing things and better and how people will come around to it if only they could see the benefits, I’d assume that making changes to make it EASIER for more people to come around to it would be more beneficial than “deal with it”.
Okay, all fair points. I should have more carefully read the other discussions. As you have described things, I can see how it fits the new paradigm where everything, all the time is now direct modeled.
Even so, as a former programmer, it makes me nervous, even though I have no idea what their source code looks like. End-users always think things are a lot easier to implement than they really are. Worse, what users think they want is often not the same thing as what they really want
Shapr3D has garnered praise for its transformative user experience. When I say experience, I’m referring to its intuitive operation across all functionalities, efficiency and performance, among other factors.
I believe the primary focus lies in ensuring user experience quality. However, I personally feel that the decision to release this significant update may have been premature, as it doesn’t seem fully prepared to cater to the diverse needs of all users.
Probably, but then again it’s our duty to inform the program how to improve, if not we wouldn’t have HBPM to begin with if other users didn’t speak up. And I dunno, I think i’ve been pretty clear in explaining not only what i want, but also why i think it’s a good idea as well as how it could be implemented in the easiest way possible given the current paradigm
As has been pointed out, this approach has been in beta for over a year and has been mentioned on the website and in the forum and on social media, but apparently not many folks paid attention. Even if it was in beta for another year or two before release, I fear the response would have been the same.
Sure, but how would people know if they didn’t actively seek out the information? You’re assuming users follow programs in their spare time. They don’t, they expect improvements to what they’re using, not a fundamental change to how things work. I utilize it for what I need when I need it. I only became active on here to get answers about the release. I first tried on Instagram after searching it out, that didn’t get me anywhere.
Pop ups in apps for news and updates are common. I never once got one saying “hey this is where the program is headed, give it a shot and give us feedback before we release it and you have no choice but to use it.”
The people that were in the beta, had a year to already get used to it, and/or have only used this version of shapr have one frame of reference. The rest of us who had no damn clue and used shapr in one form for years prior got blindsided. To tell us it’s not different, there’s no performance issues, suck it up, blame it on users not understanding it, is just a cop out. The proof is in the turnaround to change multiple things back and collapse history after the beta went live.
Yeah, programming is hard, and I’ve been programming since forever, but so many programmers are so myopic about it.
The main problem is that programmers know exactly what they coded, so obviously they will do it the right way. But that way will rarely be intuitive to a new user.
For instance, a few updates ago, something happened with the “Rename” algorithm. For decades, every piece of software has brought focus to the input box when you initiate a sequence. But now, when I rename a project after creating one, the input box comes up but there is no cursor. It didn’t used to be that way, but then I figured out that you have to tab to it for some reason. If something like this gets by the development, then who knows what else is happening.
