5.590 - History-Based Parametric Modeling is here

To reflect your answer, I would like to take away your iPad and replace it with a Samsung Galaxy Tab. What is what you can’t do or need to do differently compared to the iPad?

I understand that for you and your team, parametric modeling is a huge milestone. And maybe people around you like working that way, but please understand that there are people like Jirka or me, that work differently, because their minds work a certain way. So as he said, we did not participate in the beta, if its about features, we dont use?

Previously, sketches where detached from 3d objects, so deleting them was safe. Deletion is a way for us non-parametrics, to keep the project clean but also organize them a certain way in our minds. Also back then sketches in the same plane would be combined rather than having them in different sketches in the same plane. This now makes it impossible to connect dots of an existing sketch and the new one.

Also modifications are “remembered”. Back then, when an object was modified, in my mind, that is the state of the object. If I come back the next day, seeing the object as it is, this is the state of that object. Now when I move the object or apply modifications, older modifications show up, because of the parametric history. This is not what I would expect. Because these old modifications are OLD. But now I have to deal with them in my mind even tho I dont need them anymore.

I could go on and on. Allow people to choose whether they wanna use parametric history or not.

ApplicationFrameHost_NSmxyo8Pzc-ezgif.com-optimize

ApplicationFrameHost_ryubnt2wDb-ezgif.com-optimize

This well illustrates the disconnect a lot of us are experiencing. The sketches are tied to the bodies… but only to an extent. When they’re physically separated it’s almost impossible to remember every sketch associated to every part. Especially as assemblies get more complex. We’re being asked to have it half way and make do while it’s developed further.

Personally, if this is the route this programming is heading and judging by the responses from shapr staff it is and there’s no going back, either the sketches should be completely tied and organized to the original body in a way that’s easy to navigate (it’s own folder perhaps), or not at all.

This would absolutely be a complicated development procedure but one I believe makes sense.

I understand why shapr is going to add a collapse history function (entirely) to appease the old way crowd, but that’s an all or nothing response to the half in half out functionality of the current version.

Do you think a relationship icon in the Items panel of some sort would help?

I was thinking something along these lines would help visually identify the relationship at a glance. With a button next to the eye button on each body allowing you to expand or collapse the relationship tree. And when the relationship tree is expanded the sketches show up in the design workspace and when collapsed the sketches hide.

For example:

Body 01        (Relationship tree button) (hide/unhide button)
        |---------> Sketch 01
Body 02        (Relationship tree button) (hide/unhide button)
        |---------> Sketch 02
        |---------> Sketch 03

2 Likes

That would be slightly helpful. But as we’ve been told to just hide sketches, the main consensus has more or less been to have them in a single folder. Having to scroll through potentially hundreds of sketches to find a particular one is also the disconnect.

I believe it would be easier that when you create a body from a particular sketch(es) it creates a folder titled Body XX (until it’s renamed just like now) that contains the body and it’s associated sketches that contain the dependencies. This would help to quickly identify the sketches associated with a particular body and keep it organized and aid navigation when referencing through the history menu.

Edit: Also this would allow you to select the folder itself and move the body and sketches as one. Assuming that is also fixed as currently you cannot.

So now we wouldn’t have a list of bodies and sketches individually in the items menu but folders containing both. These can in turn be used as sub folders for assemblies, etc maximizing the workflow with the new system.

2 Likes

I agree, that’s essential what my example is.

I was thinking more along the lines of a psuedo folder instead of an explicit folder, though.

In my mind as soon as you created an object from a sketch Shapr would automatically nest the sketch into the pseudo folder of that body with the body being the top level and clicking or unclicking the relational tree button expanding the psuedo folder where the related sketches would be nested.

I’d be happy with either way!

haha guess it’s a difference in terminology. I was just trying to figure out how to incorporate it into the current UI that is intuitive for a lot of longtime users that have only ever had the Items menu.

Either way having the dependencies “grouped” so that they’re consistently held together is essential to making this work and have the shapr intuitive feel too it. How that’s accomplished i’ll leave to the people better at coding than me.

Do you know you can filter the history by the object? And doing so you can easily find the sketch associated with it? And even open the sketch for editing there.

1 Like

Yes, although admittedly since my main project i’ve been working on has had so many issues (which you know) and is also an older file I haven’t fully been able to delve into HBPM fully.

However the way it’s been explained is to just have a folder for all the sketches which is messy. Also the video that @mwetzko posted demonstrates that the associated sketches don’t “follow” the body creating a disconnect in the thought process of where things might be.

Just offering a suggestion/alternative that could help the old version crowd adapt easier to the HBPM since it’s not going anywhere.

I agree this kind of visual disconnection is irritate but I think they working on it. I see in new gamma version they made connection which move sketch with object if you change history in the past. So maybe next step will be moving it in a future :slight_smile:

Awesome to hear. I think the release was a bit rushed to the market with some of the errors and feature updates that are coming to address the issues. Would have preferred a single streamlined update but that’s how the process goes.

I don’t think so. Beta versions was tested for months among beta testers and all new users of Shapr3D. For example I never saw non-parametric version in my life :slight_smile:

Just before release to old users no new bug reports were coming so only way was to release it to the old users and collect new info from them too.

Ahhhh… I wonder how many of the beta testers were previous users for the past few years? And on varying devices? I’d assume there’d be a large cross section to gain the most feedback, but if that was the case would think a lot of this would have been mentioned already.

Either way I’m sure the team is working hard to solve some of these issues. I hope updates are staggered via priority vs trying to bundle it into one fix.

I think quite lot of them. Because new users don’t need to join to beta program to get parametric version by default.

Having a separate relationship tree would be redundant IMO. I do as @Xdrakosha described and use the automatic filtering in history to find all the sketches and operations pertinent to a selected body.

1 Like

Perhaps, I was just trying to think of a way to have things organized using the tools and UI that were available before that so many of us got used to. The reasoning is many creative types that use these programs are highly visual people, not data and list driven. Having as much line up in a highly visible fashion would be more intuitive in my opinion.

Half the complaints on HBPM is that it’s too damn different compared to the direct modeling for older users. Whether it will be redundant can be debated, it does not mean it won’t be useful.

2 Likes

100% I’m one of those visual creatives.

This doesn’t address the cleanliness that automatic relationship nesting would provide in the Items panel itself. In my opinion, it’s not redundant to have sketches automatically nested with the bodies they’re relationally tied to. It makes for a cleaner Items panel and easier association at a glance.

Honestly, I don’t open the History panel a lot. It’s too visually overwhelming to me with hundreds of items just listed one after the other and associating what those items mean to the model is difficult for me to visualize. As far as I can tell you can’t create folders in the History panel to group steps by bodies, which would help people like me form a better mental picture of what everything is doing and associated with in the panel.

I don’t know: pressing a three-key combo may interrupt the workflow too much.

To add to the redundancy, multiple bodies can be extruded from the same sketch, so you’d end up with multiple references to the same sketch in the relationship tree.

Wouldn’t you have to have that same reference to begin with if it’s related to multiple bodies as the system is currently set up?

We’re just trying to find a way to bridge the divide between the people that prefer the old direct modeling and the new HBPM so that these boards don’t continue to just be people upset and frustrated. We’re offering ideas, not just shitting on them.