@jbacus is there any truth to this statement?
I am sure the community would welcome an overhaul on DCs, and its about time something was done, sure can improve?, build into the main code,whatever…but do something!
@eneroth3 “It is much because people insist on building,” there is no “native” or endorsed alternative!
Given a two year period they would adopt any new technology, we all have to do it all the time. Look at the uptake time in using the new report writer… there are still those who prefer to use some “cutlist” but with continuing improvements, the native way will win.
Well there is. If you want your extension to draw things you can code that yourself instead of building around DCs. In case it wasn’t clear I’d like to clarify that I am referring to building around DCs with your own code, not using the plugin from the UI as it was intended to be used.
So what you are saying is build you own DC builder with the extra bells and whistles, This is like building the wheel again. How then will others add to it if where isn’t a common ground that DCs provide?
Well hopefully the Sketch developers will do just that , until then I need DCs and the report writer to do my job, if it means an extra script then so be it, But I have not got the time or money to rebuild Sketchup to make the square parts round,I believe that is their job not mine
Again, there is nothing wrong with using DCs in a modeling workflow. The problem is when a plugin developer uses DCs as an integral part of their own software. The latter is like using your neighbor’s house as a structural element for your own house, and prevents your neighbor from replacing their house as it would lead to your house collapsing.
Look I totally agree, its a risk they take, all it means is that they are trapped and have to use a previous version of Sketchup, then give them a few years, they will update or slowly dissolve. This is true of all software. But if Sketchup keeps on (as you suggest) looking after this minority, then they will be the one who will be dissolved.
Stated like this, you could also say it is wrong if your plugin depends on Faces, Edges, ComponentInstances and so on…
DC is part of the default SketchUp distribution and fairly saying I have built multiple plugins that depend on them.
If the SU team will kick the current DC out of a new release of SketchUp, I’m totally fine with that. Things deprecate all the time. But, until that day, I will continue using them and depend on them when a client of mine is willing to automate them.
The difference is that Faces, Edges etc are all part of the documented public API, and intended to be used in third party extensions.
DCs is shipped with SketchUp but not a part of SketchUp’s core, and it is perfectly valid to disable it if you don’t use it (as with any other plugin). Just because something is available to use doesn’t mean it’s good practice to do so.
Under the hood DC is just attributes. The only thing “not good” about it, is that it registers itself as a global variable,which is more a cosmetic issue, and the fact it is an extension.
It currently is the only “native” way for users to create “intelligent” objects in SketchUp. You cannot just expect everyone to start scripting in Ruby.
I think Julia’s point is that building on something else’s internal methods is risky, because
they can be changed at any time and break your plugin and
they are not documented and you can only be confident to some degree that you have a correct understanding of what they do. Worst is the plugin working with dynamic components stops working, but in other domains like automotive every line of code must be proven to be correct.
It is a very specialized target to write “plugins” for a “plugin” (although it’s true, dynamic components are in every SketchUp installation). I remember when Google shut down their user-contributed 3D buildings layer, some people had to search a new business. It was just a too specialized target to make your business dependend on.
It all comes down to 1 thing: cost
If I’d have to mimic functionality provided by DC, I’d have to charge more + I have to explain why something a client believes is part of SketchUp isn’t .
But, maybe we, the developer community, should just come ourselves with a good solution. Why don’t we collaborate on a DC replacement that we can include in our own extension?
To get started, I created a github repo, still empty, but I’m willing to put some effort in it:
What a DC replacement would be totally depends on what you used DCs for in the first place. I’ve made several extension that draws stuff to groups, and have observers to react to the user scaling it and redraw according to the newly defined size. That is quite simple. The difficult (and time consuming) part would be to make an interface where the user can create their own objects however they like. This has never been needed in my extensions.
If I find the time I can make some code example for the former use case.
I think a replacement for developers to use should mimic all the functions DC has and react to the same set of attributes. It should make it possible to work with already created DCs, without the need for DC to be installed or activated.
When version 2018 was released, we saw the ‘advanced attributes’ being introduced for Components in the entity info. These 4 Xtra attributes can’t compete with the dynamic and versatile nature of the DC.
If you want some information attached to your component, add an attribute, fill in the info and it is there, available in the Report Generator, LayOut etc… No xtra plugin, no need to ruby around.
The fact that the clasification (IFC) makes use of the Component Option Dialog tells me that DC won’t be decapicated, for the importance of IFC/BIM/information in the AEC-industry is key for the survival of many (small) companies that need to collaborate with large firms and don’t have the budget for BIM-applications from AD (or Tekla!)
Yes, you can open a door with DC, but the full integration of IFC and BIM opens many more doors! @nnijmeijer
… but then again… if a custom one reacts to the same set of attributes and a future version of DC changes the formatting of the attributes… we are doomed. But, maybe it is fair to say that at least the formatting and naming conventions of the attributes are static. Otherwise, all those millions of DCs will become deprecated.
We shouldn’t confuse SketchUp entity attributes with dynamic components. Entity attributes are the “base” technology where users can store information with a model. Component Options and Attribute Inspector are user interfaces for that. Classifications use attributes for storage and add the IFC export capability. Dynamic Components add dynamic capabilities.
So, yes, I think attributes definitely won’t go away, because a lot of technology are based on them.
I don’t know of any project that tried to rebuild an existing project up to 100% compatibility and succeeded. They all reach a level almost as good as the original, but never reach relevant market share. This binds resources that the community could use to develop something simple, but with innovative ideas.
What is needed is a stable API for Dynamic Components.
The SketchUp developers shouldn’t confuse this, either!
By showing the ifc-attributes in the DC’s component options dialog and giving the user the possibility to alter (ifc)attributes, but not exporting them in the IFC-export, an enduser might be confused by it, too.
We need a roadmap!
The actual implementation of Dynamic features like
Changing Material
Rezing of doors and windows etc. in the right proportion
Animations like opening doors/rotation etc.
is subservent to the information of that feature.
‘Ah , well it is nice to see I can change the color in the model, but It is better to have it on black and white’