Just an auto survey :)

Need help? We are here.
41

Oh no, I grasp your analogy, it just still doesn’t make much sense to me personally. Nor address the idea that simply changing coordinates of something negates everything else. If the assistant is out of the room, but still follows ALL the steps, including changing the coordinates/rotation at the same step in the process then all the subsequent steps should still follow. You’re saying that they won’t. To me it sounds more like a calculation issue vs a steps in the process issue. I’ll explain…

For instance. If you model a simple screw. You can take that screw and copy it and use it over and over, move them wherever you need them, change the angle to suit the parts. But changing the first screw won’t change the other screws. ONLY by changing the sketch will change all the screws. If I’ve gotten that right then, again at least to me, it’s an incomplete system since it only goes one way and the only thing that is truly parametric is the sketch. Move the sketch, all the screws move.

So by the current standard you can move and re-position the sketch itself, which will in turn move and position the body. It stands to follow that even with multiple sketches, as long as you keep the same relations between the planes then the entire body will not change. So the sketches can be moved without changing the entire order of the history. But somehow moving both together will?

(Edit, i quickly tested this theory by doing this. Selecting and moving multiple sketches at once does indeed work as described. Only the subsequent copies moved in the same relationship as the first)

If the body is inherently tied to the sketch(es), and the dependencies are still tied to the sketch so by modifying that, it can change the body. However the body can be independently moved, rotated, modified from the sketch, so therefore the entire essence of parametric is only tied to the sketch itself. Not to the bodies themselves.

I’ll go back to your point about coordinates in the digital space. To me, it would seem that if you move the body and the sketch follows, the ONLY thing that’s changed is the coordinates and if you rotate then it’s still just a calculation in space. (Same as modifying the sketch(es) to their coordinates in space) Perhaps these calculations are too much for the system to handle or be implemented at a different point. But it does seem to be more of a calculation/implementation limitation vs history and steps.

I’ve wrapped my head around it, hell used programs way more complex and packed with the same stuff, but i’ll state again, I believe this is only useful in certain situations for certain models and/or iterations. For those, yes i’ll make much more use of it. But in the meantime it’s not a huge benefit, if much of one at all. And the implementation is lacking.

I specifically came to Shapr not only because it was iPad based (before the Mac and PC add on) but because it wasn’t parametric and overly complex and I didn’t need massive computing power to run it like I did Solidworks which killed my past 3 laptops.

THAT version was elegantly simple. THIS is more a move to try and compete with the other, as you point out, numerous CAD programs that offer parametric, only with much less of the features. Shapr was unique in that it didn’t claim to be competing with them, just providing an entry point that was intuitive and easy to understand, judging by the comments the last few weeks it’s now neither without re-education.

42

Thats not quite right. You probably hadn’t read my most recent comment when you wrote this ( I did two in a row because I think I found a better way to explain things. Disregard the history feature for a moment because the way that sketches work now is completely independent of whether history is used or even available in the program at all.

Think back to the old way of doing things. Everything (except sketches) was direct modeled, and it seemed logical and intuitive and everybody loved it. Whatever you did, any associated objects would adjust as needed right before your eyes — except for sketches.

Well, now sketches are direct modeled also. Which is literally the only real change in the way the program works. Now we work with sketches exactly like we are already used to working with everything else. Disregarding the learning curve issues, this is a phenomenal feature. Need to make a change after you have extruded a body? Before, we had to undo, change the sketch and re-extrude. Now, just drag a sketch line or point and the body changes before your eyes.

Granted, it is a change for current users, but to a new user, it is more consistent and probably easier to learn. You can change anything at any time and get instant visual feedback and everything acts the same way regardless of whether it is a sketch or a body.

Again, all this is completely independent of the history feature. Everything works the same as it always has except now sketches also behave the same way any other bodies do. If you delete a body, then any associated features (holes, fillets, etc.) get deleted too. Delete a sketch, then any extrusions get deleted too. But everything you do happens to the current state of the drawing. If you make a copy of a body and then change one of the copies, only that one gets changed.

But this is where the new history feature is useful. Direct modeling of sketches is necessary to enable the history feature but it is not the same thing. When you open the history panel and select an earlier command to modify, that is where the video recorder analogy comes into play. It is exactly like hitting the undo command a lot of times. If you want to change ALL of the screws to a different size, then “rewind” to just before the original copy command, make your changes and hit done. Then every command is re-executed, screws can get relocated, even individually modified, whatever you have already “done” will be re-done to the screws but each will have the new size exactly as if you had done it originally.

Play around with this in a practice design. Make a simple sketch, extrude a few bodies, make some copies, cut some holes, etc. and then experiment. Without even opening history, you can change the extruded bodies by just modifying sketch elements (which you have already figured out). Open the history and play with the different commands to see what happens. Try changing the order by dragging the steps up or down. You’ll probably encounter some warnings, but you’ll quickly get a much better understanding of why and when they occur. I’ve seen some of your other posts. You’re easily smart enough and experienced enough to learn how to take good advantage of this new power.

43

Haha, I was probably in the process of writing my reply before the other posted. I have a bit of the tism, aspergers, so especially online I tend to think more about what I post vs what i’m thinking and shouting to myself in person so as to not come across as a complete a-hole, so it sometimes takes me an hour or more to re-read, edit, re-read and finally reply haha.

And as I stated I appreciate the effort and time. With both of your responses we actually have a lot of common ground and understanding (yay progress!) on the program and its benefits and functionality. It also re-iterates a bit of what I stated in my last post about sketches taking priority over bodies.

Unfortunately I’m a very visually based person, I imagine most creative types are. (can’t for the life of me remember names or birthdays but I’ll remember what car you drive). If I can’t draw something or struggle with the proportions, I’ll mock it up in CAD before assigning dimensions to get the visualization of it down. Now, I do understand in certain instances that will be helpful because I can go back and change the sketch. BUT… I still think we’re on a different page on the singular matter at hand vs the program as a whole.

I am unfortunately one of those people, it’s a sign not only of my curiosity, but willingness to try and learn and more importantly understand. And that is where we’re having fundamental differences. There’s still no simple explanation of WHY the sketch can’t follow the body, when the body can, and indeed does, follow the sketch, considering the only thing changing is coordinates in space, not necessarily the history. And even if you take into account the history aspect it is still only affecting from then on.

Or even more puzzling to me now that I think about it… WHY can’t that change of coordinates be inserted into the history before the sketch? Since it’s starting with a sketch on a plane, defined by coordinates in space, then in theory those coordinates could be altered in the history to match the newly moved location much like all the history that is created AFTER the initial sketch in order to make the body?

I’ll start with saying your last post you said my description is not quite right, but didn’t explain how haha I am glad you said these 2 things though. I’ll completely disagree with the first. I would just grab and move the face or feature to where I needed, instant visual feedback as well. Rarely, if ever have to start over from the sketch.

But will whole heartedly agree with the second. Even in your description the FUNDAMENTAL change has been from changing and modifying bodies and throwing away the sketches, to changing and modifying the sketches in order to modify the bodies.

This is a profound and abrupt change, hence a lot of the pushback and festivus tradition of the airing of grievances haha. For a lot of users the paradigm has completely changed and it’s not hard to see why. The problem I think a lot are having now is also compounded by the ever present phrase of this isn’t different to how things worked before, just hide the sketches! when that couldn’t be further from the truth and passes blame to the users in a more or less, deal with it or you’re just too dumb to understand why this is good for you, fashion.

It’s also human nature to not interpret 2D drawings vs 3D objects in the same fashion. So by now being told to alter a 2D image to change a 3D object there is a disconnect. It’s easier when the object is in the same place and location and you can see the change applied… but in an entirely different location, rotation, angle… now that’s a complete disconnect to alter one and know the other is doing the right thing, especially on a limited screen viewing area. Hence my pressing the point haha.

Yes, I am haha, that’s why I ask the questions I do. Because, although I’ve worked with other more advanced programs, I chose shapr for the simplicity and some of these changes seem counterintuitive to me. And in order for me to make the most of the program, understanding the WHY is part of that in my brain.

44

I’ve figured out a little trick for this mate that I posted on Facebook.

Instead of copying the screws use a linear pattern and keep the first screw on top of the sketch.

This means that you’ve always got one on the sketch and you can use the history to increase the new of copies of the screw by simply changing the amount in the linear pattern.

If you want to add something to the original screw that isn’t already in the history, you edit the first screw, then drag the pattern in the history down to the bottom.

(You might have to drag the alignments/movements of the other screws down below it to accommodate).

1 Like
45

Gave it a quick shot, neat trick.

Tried it out for mirror as well and works in that scenario as well. Useful to know since normally I’ll modify one body, delete the other, then just mirror it again. Still about the same number of steps though hahaha.

46

I’m the same. I’m forever cutting parts in half to edit one side and then using the mirror again.

This parametric stuff is creeping itself into my workflow though.

I added on the Facebook video that it would be beneficial for us to be able to grab multiple history objects and move them at the same time, not sure how feasible that is for them to implement though.

47

Yep sometimes it’s just easier. I’m sure there will be plenty i’ll use it for and experiment with on future projects. But I’ve got a dozen legacies that need to be finished it’s useless for right now haha

48

It can be. Honestly the whole Shapr doesn’t know if you move a sketch is perplexing to me. Every new action is recorded into history so that move would be as well. Maybe new actions reference a discrete location of the sketch? In that case a reference pointer could be used to redirect to the sketches new location. But then that would add a lot of code if there were a lot of sketch moves potentially slowing the program down.

With that though, I’d assume locations would automatically update as the history steps and objects reference the sketches object in code which would contain the new location after the move.

Basically the history and body wouldn’t care that it’s a new location because it knows the name of the object in code and that object would contain all the parameters for the sketch including it’s location.

49

I’m asking this question from ignorance because I have no idea how this stuff works.

How does your idea work when there’s several sketches acting on the same body and have varying positions in the history tree? Like sketches used to cut out or add parts etc.

50

That’s kinda what I was getting at. Only shapr DOES know if you move a sketch… move the sketch and that part of the body will move as well the same direction and amount. But I keep being told that because it’s at the beginning then moving it later on changes everything else.

Only that doesn’t make sense when considering it had to have been drawn on plane to begin with. That creates a sketch plane and that sketch plane is defined by coordinates. So tying it to the body instead of the other way around, would simply change those coordinates within the space for the sketch plane. It would allow the sketch to follow at the very least the original body, not copies and allow that visual connection throughout the process.

51

The same way that moving sketches and bodies within a folder worked prior. You currently can’t move them at once, only independently. Also I believe it was Justin and I discussing in another thread about modifying the Items tree to have the linked items listed in their own section. So by selecting that you can move and rotate and everything would follow. Same as it did before, just with the history still attached.

Edit: So basically a body and all the sketches used to create the body go into a folder. That folder can be selected and moved. But when you call up the sketches you can see them in direct relationship to the body. Making it easier to visually see any changes as they are applied. No matter where you place it.

2nd Edit: i’ve had a few beverages forgive me, in the other thread we were also discussing how the tree might look, so not necessarily a folder but the ties would all be included for the first body created. So selecting the body would automatically select the sketches associated since they’re linked. The entire idea being, if we’re gonna have links and dependencies, lets have them fully. Not just in certain instances like with parts drawn in place.

1 Like
52

I saw that other thread and liked the mockup. I was just asking from a history standpoint.

Sometimes the sketches are used to create more than one body too. Do you think it would need to duplicate a sketch if we moved it with one of the bodies?

I’m not against this idea by the way, I’m all for sketches moving with the original body. I’m just playing devil’s advocate to figure out how it would work.

53

No offense taken, discussion is how progress is made. So even currently, if you model something in one place with all its associated sketches. You can select all those sketches and move, rotate, and angle them as a whole and it will move the body along with it. As long as they are all selected they maintain their spatial relationship to each other not altering geometry.

This was something we discussed prior.

If it’s for a brand new body then I would say yes. Having sketch copies is not really a huge issue currently so it would stand that it’s just duplicated and applied to the new body in the current position and at the current history then starts to apply it’s own history from there. It is after all now on its own new sketch plane with it’s own spatial coordinates. Move the body and now that sketch follows the new body.

1 Like
54

I’d assume Shapr creates an object in code when anything is made in the program. By object I mean the code block that executes lines of programming.

So when a sketch is drawn by someone i’d assume an object is created like:

drawingSketch01
 location: x,y,z

then when a body is defined in code it’s something like:

newBody01
  drawingSketch01

newBody02
  drawingSketch01

drawingSketch01 is the object that contains all the parameters of Sketch 01 in code and could be referenced by anything that calls on it for variables. This is all an assumption on how it’s programmed though.

1 Like
55

Sorry, I did answer at the bottom of the post but did not make it clear that I was talking about your specific example. You’re right that changing the sketch does change the original screw, but it is not the only way. You can also modify the body directly by using the history panel to either modify the variables in one of the commands before you make copies (e.g. an extrusion), or, if needed you can actually add extra commands. Direct modeling the sketch is usually going to be the easiest and fastest way (for the same reason that people like direct modeling in general) but sometimes the history may be needed for more complicated changes.

I’ve been reading and typing, and I agree that what @Justin074 said (from a programmers perspective) is completely plausible. But he is also correct that it would definitely add extra complexity – probably a lot. I obviously haven’t seen Shapr’s code base, but I suspect it would be extremely tricky to implement without LOTS of potential errors. As you’ve noticed, we can direct model sketches now and changes propagate. When you couple that with HBPM, I think it might quickly get too complicated for either programmers or end-users to understand. Whenever you change the sketch, any associated bodies would also change, but at different point in the history, they would be at different locations.

As I said, I have no idea how Shapr’s code really works – just educated guesses. But it seems pretty obvious that they have to constantly recalculate the spatial positions of everything in the drawing just to be able to display it correctly as you move it around.

Where this gets really complicated is when you are doing something with the history. Don’t know if you noticed this yet, but even when you’re backed up, and doing something like changing the size of an extrusion, unless you have a breakpoint set, future changes (from the perspective of the history step you are modifying) are updated in real time courtesy of direct modeling. What this means is that each step in the history list is constantly being calculated and recalculated many times per second to be able to visually display changes as smoothly as possible.

But, as each step of history is calculated, the “moved” sketch is going to be in different places at different times. Not only will this look confusing, I suspect the visual flicker would be pretty annoying.

56

I’m confused by this, that section you quoted was poorly worded… I know nothing about programing language and coding but this doesn’t seem far fetched.

If the original sketch is defined by it’s sketch plane (the one thing that can’t be modified by itself, it has to be 2d) and that sketch plane is defined by spatial coordinates. It can be moved. It can be rotated. But it is essentially constrained within 2d and the planes spatial coordinates simply change to match. That is a variable, just like the dimensions within the sketch. This is currently very easy to do.

If you build a body from it, you can still move the sketch, and it will move that body. IF we could tie the sketch to the body, the only thing in the history that would change, would be the spatial coordinates of the sketch plane.

It fundamentally wouldn’t be changed as an added step to the history, its now an adjustment, or a one time recalculation for the coordinates themselves from their original location. Pretty much how it is now, it’s still at the beginning of the history chain, but can be adjusted similar to how all the other variables within that sketch can be altered to visually change the body and how the original sketches can all be selected and moved into position.

Now all visualization and the calculations involved are only operating from that position, not any previous position in spatial coordinates.

I will agree that if it’s a super complex body or sub-assembly, then the “original” movement change and/or alignment might take longer to calculate since it now has all that history to move with it. Is that what you mean?

If that’s the case then wouldn’t that also apply to say building a part or sub assembly in one shapr file, and importing it, sketches, history and all, into another? Then trying to position and adjust parts of it to make sure tolerances and fit are right? And if that’s the case wouldn’t that render the program unusable anyways defeating the point haha

Like I said, i’m not a programmer, i’m not a coder, give me something physical to break and i’ll find a way to fix it. How any of this could be implemented is beyond me. I’m just asking IF it can be and IF NOT, why.

57

Sorry, I was specifically thinking about your earlier example where you talked about moving a body to a different location and angle, and were concerned that two objects so spatially disconnected would cause a higher cognitive load. I just assumed that was the type of simultaneous sketch/body movement you were asking for.

In general, I can easily understand how your requests would “nice to have”, but I’m also concerned it would add a fair amount of complexity and possible performance issues. And probably not something that should be the highest priority at this moment, especially considering some of the performance and data corruption issues that a few people have.

But a good idea, and something they may be able to do in the future, especially considering how many are asking for better answers on how to handles sketches.

58

Haha don’t have to tell me, I was the one that badgered to prove that there were those issues. A few other users have seen the file and can confirm.

Appreciated, I’m looking to find an easier way to incorporate this so it won’t be so dissimilar to the previous version and bring more people on board to HBPM. I think by incorporating this, if possible, as well as Justin and my idea for item tree UI it would take a LOT of the sting out of the change.

59

If I understand you correctly the question is why a Move/Rotate operation applied to a body will not change the sketches that defined the body. This is a good question, and every parametric modeler handles it differently. The main reason we decided to implement the Move/Rotate operation the way it works now is that

  1. If there are multiple bodies that depend on the same sketch, this behavior would be extremely confusing. You move “Body A” and some parts of “Body B” would change with that. Not great - as you can see similar issues are already causing a lot of confusion, this would be 10x more confusing.
  2. It would be inconsistent with the other operations, and with some other things that the Move/Rotate tool do. For example the Move/Rotate tool is able to move not just bodies but faces and edges as well. These obviously (almost always) couldn’t be expressed by changing sketches, thus it would need to create a new operation in the history.
  3. Bonus: what happens if in the same Move/Rotate operation you have a few bodies and a few faces or edges from some other bodies, that could even depend on the moved bodies. This would mean that the sketch changes and the face/edge changes would be performed simultaneously, leading to a total mess, or a ton of errors.

That being said the complexity and the potential confusion that this implementation could’ve caused seemed to be not worth the potential benefits.

1 Like
60

Hey Istvan,
Glad to see you chime in on this. There was a lot of discussion over the past few days haha. Some you’ve addressed, but think a lot of it may have been missed.

No, the question is why a Move/Rotate/Align operation applied to a body will not ALSO apply to the sketches that defined the body? It will not change the body, just re-position them WITH the body.

After all currently you can select all the sketches that define the body, and collectively, they maintain their spatial relationships to each other. This means you can Move/Rotate/Align them under the current system and the body follows along with it. This doesn’t change history order or any of the operations that come after. You can even change those sketch(es) independently in this new location to alter the body.

My question is, why CAN’T that also work in the other direction when re-positioning the body so that visually and cognitively connected when you adjust those sketches the moved body and NOT have them separated like the current paradigm? ie. currently you CAN do as I described above with selecting just the sketches but CANNOT select sketches and bodies at the same time and Move/Rotate them. This was never the case before. Why can’t it be done now? Especially now that there are these dependencies in place and the sketches are no longer throw-away, they’re integral to making HBPM work, it makes sense to have them linked and together fully, not just in a partial and potentially very disconnected (visual) manner.

Even if you were to say “we can’t/won’t implement this because you can just do as you described by selecting the sketches anyways”… that would require labeling every sketch and creating folders to organize everything manually, very time consuming and tedious to ask users to do. See below where we discussed potential solutions to this issue…

When a sketch is used for multiple bodies, a copy would be made when that body moves. That new sketch, just like other copies even in the current format, get’s it’s own unique sketch plane and name. That can now move with the body independently of the other sketch. Having all the items within the Items list in a tree would mean that selecting them and moving them would be similar to prior versions. If this is implemented with how @Justin074 and I were discussing here navigating these could be easier as well.

This is not what we’re discussing and is no different to how things are now. If you’re speaking to the history order and adding in steps, I discussed that further up the thread^^^.

This concern is also negated if the unique sketch (as described above) moves with the body. It’s the same as it was before moving it. The only thing that will have changed would be the spatial coordinates of the sketch plane(s) that make up that body at the very beginning of the history. All the other features would still maintain their place in the history order. This won’t add steps. It just applies new values to the basis for the first steps, since after all the original sketch plane needs to be defined. It’s just asking to change the values of that definition.

I believe you missed discussion where the movement of the sketch(es) would only apply to the original body created from them. Copies would just be copies of the body. That’s how the history works now. You can have copies of bodies and moving one doesn’t necessarily change/move the others UNLESS you specifically change the history order. (thanks for the tip @Shaun !!!)

If you’re talking about feature selection order, ie. which edges are selected to make a feature like a filet/chamfer, yes you would have to select only edges associated with that particular body, not multiple bodies. That way the Move/Rotate doesn’t affect other bodies. Doesn’t seem like such a huge ask from users when they’re being told to re-learn how to do things to begin with.

If you’re talking about features like replace face, so that faces from one body to another are now coincident, that never stopped the ability to Move/Rotate a body independently previously. I don’t see why it would now unless HBPM is so dependent on order of operations that it always has the potential to make itself a total mess or a ton of errors with such a basic function like Move/Rotate/Align.

I disagree, I believe that implementing this in tandem with the implementation of adding the feature tree/dependencies/links (whatever you choose to call them) in the items menu would actually streamline the process and make it easier to navigate. Especially for older users currently upset about the changes. The History menu itself, as many others have pointed out, is rarely used unless specifically necessary. But as we’re brainstorming these ideas this also wouldn’t affect the history if the changes can be implemented as described.

It would create less problems, be more visually connected, and act more as a natural extension of what Shapr was and how it functioned. Potentially bringing more people on board with the HBPM way of doing things since that’s now the standard we all must follow.

1 Like