I want to suggest that a new detail be introduced into the component attribute: Pervasive? Yes/No ,default = NO, so this attribute could be visible in all subcomponents, without needing to rewrite it in all subcomponents.
1 Like
Please explain in more detail what you mean, perhaps with an example. I don’t understand.
1 Like
The SketchUp attribute details are: “Units”, “Display rule”, “Display label”, and “Display in”. I suggest inserting another detail called “Pervasive” (or another name you find appropriate). The options would be “yes” or “no”. If the user chose the “yes” option, this attribute would be seen in all subcomponents of the parent component. Can you imagine the amount of modeling time such a feature would save?
I still don’t understand exactly what benefit this would have in creating models. How would this save me time?
I’m wondering where these attributes come from? What do these mean? Where do you see these in Sketchup? Can you take a screenshot?
1 Like
Like the others, I remain confused about what these are and where they come from. So I think you still need to explain more fully.
For example, “Units” in SketchUp usually refers to the physical units (meters, feet, etc) and precision used to display values. It isn’t an attribute of a component. I have no idea what “Display Rule”, “Display label”, and “Display in” refer to…
1 Like
Imagine an extra detail below “Display in”: “Pervasive” with options “yes” or “no”.
1 Like
So you are referring to a modification to Dynamic Components. You should have indicated that in your first post.
What exactly does Pervasive mean to you?
Sorry. The pervasive detail makes this attribute visible for all subcomponents so you do not have to redefine it in all subcomponents. Example: folga=Parent!folga. See image that follows.
1 Like
I still don’t see how that makes modeling any faster. All I can see is that you are trying to work harder than you need to.
1 Like
Perhaps the answer is reuse of a primitive.
For example: a particle board, only need one DC, for all plain parts, so the axis is same direction for width, length and thickness (x,y,z), the definition “particle board”, the instance name updates automatically to DC, so named base, top, side, rail, plinth… their position and size in refence to the boundary of parent, with axis facing in.
Then there is no need for so many grain directions (material. as per other post) No need to reference other parts, swap or confuse axis, no need to build each part from start, Just as in the workshop, board or timber is flat down, face up, edge front. you then size, cut, rotate and place.
Now if it requires a groove, or rebate, miter. them you swap the plain board for a machined one. Which is built from the first primitive after copy within same file, then deep made unique, then altered. Once completed, change the greyed size attribute to =current(lenx, y, or z) then saveas, then in swap they will update to the current size.
different veneer, edge banding, use OCL
Look share your work flow and purpose, then can help, if DCs required, But for one off, customization, its not worth it, Dave knows best and I agree
The image above illustrates a possible modeling of part of a casework. The Component “Armario” contains components named “modulo”. Each Component “modulo” may contain components named “PortasArmDuplasSup”. Each Component “PortasArmDuplasSup” contains components named “PortaMD” and “PortaME”.
The user can set the parameters of this casework using component options. The material of the components “PortaMD” and “PortaME” is then defined in the component “Armario” by the attribute “mat_detalhe”.
So “mat_detalhe’ must be redefined in the component, “modulo” (1), “PortasArmDuplasSup” (2), “PortaMD” (3) and “PortaME” (4) by using mat"detalhe” =“Parent!mat_detalhe”
My request eliminates the need of all these re-definitions by declaring “mat_detalhe” as PERVASIVE in the component “Armario”.
Maybe I’m missing something here. If So let me know.
I understood what you meant right away. Ya it would be super convenient, but there has never been an update to the DC extension so I wouldn’t hold my breath.
Thanks for your return. As a retired software engineer, I think the modification is simple, depending on how SW is structured. The visibility of parameters is an exciting subject and I dedicated myself a lot when I worked with it. I imagine that perhaps, as it works the way it is, it may not sensitize developers.