Anyone Know Why DC's are so Buggy?

SketchUp Dynamic Components
, ,
21

Forking does not work for a shared object space like embedded Ruby. It’s fine for system Ruby where only one copy of the code would be loaded.

Again, it is not set up to be shared code library … and so it would basically need a complete reorganization, which means …

(1) … will not work the way the code is organized.

This means they will not open source it as doing so would increase the damage that some of the DC “hack” extensions already do.

(2) Ruby itself is a dynamic programming language. This allows code objects (modules, classes, methods and other objects,) to be modified and expanded at run time. So forking isn’t actually needed.
Some extensions just change the DC classes for their own needs.

This situation was much worse before Ruby 2 came out with SU2014. These 2.x version of Ruby now have refinements that only apply within code files that “use” them.

However, the DC code is an engine, that does automated things, such as attaching observes, etc. You cannot refine the DC observer classes and then expect the other DC code files to use the refinements because they don’t make any using calls. (The code predated refinements and anyway the code couldn’t know ahead of time that later loaded extensions need to refine them.) It’s a “catch-22” scenario.

But, (3) … I myself reorganized, properly coded and fixed a nifty idea (scene aware DCs,) posted in a public blog by one of the SketchUp team members, (but was not coded correctly with best practices or written to be included within the actual DC extension,) and actually GAVE it privately to the team.

The response was a terse policy statement … “we do not accept code donations”.

So unless “The SketchUp Team” publicly changes this (privately expressed) “policy”, there is not any point in pursuing this as a collaborative effort.

How the Dynamic Components extension works is not hard for a good extension developer to figure out. Already some developers have created alternative parametric components extensions.

But doing a good job on something this complex is a very time consuming endeavor, and so these extensions become commercial extensions, as they have great value.

1 Like
22

I get that there are some technical problems with running essentially two versions of DCs at the same time… I was thinking of some kind of versioning system… SketchUp could come with DCs 1.0 let’s say, and any fork a developer does is 1.x.

This way a dev could add functionality, but require an additional, or upgraded DC extension…

Perhaps another scenario would be that DC’s are open sourced, and any fork disables the built in DC extension automatically on start…

Point being is that DCs haven’t been touched in any meaningful way in so many years. Because of this developers that would have used them haven’t, or in some other cases that I’ve seen developers are doing ugly hacks to them, or just going off and building their own versions of them from scratch. There’s a lot of fragmentation out there that nobody can really quantify.

If they were open sourced it won’t be perfect, but at least thee’d be some clarity around what people are doing with them and what they want. That might be the only way we could get the SketchUp team to see what developers want to do, and what they’re doing with them in a way that they could potentially integrate into the main DC code.

23

If people are encouraged to fork DCs we’d risk having multiple “1.1” by different people, with slightly different features. Forking isn’t a good idea here. If open sourced, it’s better to have one official version and let people contribute to it. In any case I don’t think there is anything to salvage in the DC code base. It’s better to build anew properly on a stable base than trying to resurrect this code base. It can be seen as a proof of concept though.

24

Having multiple “1.1s” would certainly cause some issues…

Here’s how I’m seeing it:

I’ve seen several developers create custom component libraries for commercial customers. These customers typically want special functionality beyond what a typical DC can do. In many cases developers are forced to hack on top of DCs. Aside from the issues we know about, what these developers are worried about is that someday SketchUp could kill DCs, rendering their plugin/components useless in a newer version.

I know there’d be more DC action of a developer could pull the DC codebase into their extension. They’d have the security of knowing that what they built on couldn’t be taken away at any moment. I realize that this could technically mean that a SketchUP install could have two DC extensions running at once, and for these commercial installs I think this is something that a dev could get around by some education or automation (perhaps a dialog box that says “Hey, please disable the built-in DC extension” or something like that.

As far as what you’re saying @eneroth3 I get it, DCs are due for a new codebase. Personally I don’t think any developer is going to independently write a new one. I mean, why would they do it? If they make it a commercial extension it’s going to be a hard sell because they won’t be able to send models to another SketchUp user unless they to have that extension installed.

So perhaps the way to do it is this: Open source DCs, and let the community make improvements. Even knowing that it’s a code base that needs a re-write, start making some incremental improvements. I don’t think SketchUp will do it themselves, so it’s really up to the rest of us. If some meaningful improvements are made I think that will do well in getting people interested in DCs again, or at least trusting that SOMETHING will be improved. If it builds enough momentum that might motivate SketchUp to re-examine a re-write, or adopting code/hiring someone from the community to do said re-write.

25

To clarify, no one is forced to build on top of DC. People make the bad choice to do so. I think anyone charging money for their work should no the difference between “can do” and “should do”. In e.g. the construction sector you wouldn’t even consider skipping a few supporting walls and instead attach your slabs to the neighboring building. Yet some extension developers insists on doing this with Dynamic Components.

You don’t need a separate extension for this functionality. It could be a library you add to your own extension and wrap in its namespace. There is no reason for any clashes to occur bewteen different extensions here.

I think DC is best replaced by SketchUp, not by any individual developer. I have thought about it and made some sketches but it is a huge undertaking.

With my experience from my own poorly written extensions from when I was just starting to learn, in addition to my experiences cleaning up old extensions for clients, I’d suspect it is much less work to just start from scratch and make the right decisions from the start, than trying to incrementally rebuild the foundations of something existing.

26

Client X has 1000 DC’s in the 3D warehouse.
Client X has the need to create reports, Bill of materials, other great things based on attributes that are controlled by DC.
Client X (and their clients) can save a huge amount of time if a developer would create that for them.

You say: No, bad decision, don’t do that?

27

I am one of those people that made a “bad choice” :slight_smile:

Here’s my logic: I was able to create content that theoretically any SketchUp user could consume (and pay for) because DC’s are something that works out of the box in SketchUp and thus has a huge install base.

Did I do this knowing that DCs might not get updated? Yes. Did I do it knowing that they’re buggy at times? Yes. I also did it early on hoping that SketchUp would see that there’s business potential for plugin developers and continue to develop them. They haven’t done that.

So now me, and many other developers who depend on DCs are afraid that they might go away/get broken. Hopefully that puts some context into what I’m driving at here.

The reality is that while DC’s may not be the best code, they work for most people most of the time. There’s a lot to be said for that.

So if SketchUp doesn’t want to update DCs, I, and others do have a business around it an happy to contribute to keeping them alive. We just can’t do that right now.

2 Likes
28

It’s not ideal to have invested so much time and resources in DC, and I think such company should have an escape plan. Such clients need to know they are essentially digging themselves deeper into the hole. Still I think it is a lot more justifiable to build something next to DC for extracting reports based on it, than building onto DC, abusing its internal functionality e.g. for drawing.

29

I think the most basic issue with DC’s is they are far from user friendly.
The extensions that emulate them are far easier to use.
So many Fredo plugins do things that DC can do natively, but take forever to work out and set up. Fredo Scale Stretch for example will resize a window without changing the sills or stiles. Struggling through how to do that in a DC is tortuous.

If they were simple to create they would be widely used and more people would know how to use them naturally. Every DC question that comes along on the forum I read and think, ok I’ll just go and make one to work out the issue or… wait for @pcmoor to answer the question brilliantly.

Sketchup is about simplicity, the tools work easily, pushpull, scale etc makes it feel like you can make anything, then you try your first DC and get stuck at all the formulas and what is lenz etc should be doing.
If you could make it so you just set it out to do it and it works… then you have Profile builder

I’m sure all the code to make a user friendly version is all written already, problem is it’s in a bunch of different authors extensions.

I know I’m being simplistic but that’s what it needs to be to make everyone start using them.

4 Likes
30

Amen, @Box! DCs present in a “they’re straightforward, just try them and you’ll figure it all out” manner, but between bugs, limitations, and a less-than-obvious user interface they are in fact often subtle, complex and difficult for people to get right. They have long lingered in a present but not really supported state, forcing users to come to the forum for help.

2 Likes
31

Could a new/better version of DC’s be made independent of the current version, (Dynamic Objects perhaps?). That would allow those of us who want to migrate/rebuild our dc’s to this new extension if we wanted, while leaving the old DC extension intact so it could be used by those who do not want to make the switch? Absolutely love DC’s, would love them to be improved/updated even more.

2 Likes
32

Absolutely, YES.

1 Like
33

Yes. The main obstacle would be the considerable development effort required. It would take either a really devoted volunteer (or group) or someone who plans to recoup costs by selling the new version.

2 Likes
34

I vote for @pcmoor to head the project (I am sure he is way too busy though). I think maybe the willingness of current users to spend the time migrating to a new VS may be underestimated. I would happily invest the time moving and rebuilding to a better system.

35

Absolutely, and I would think it is less work than trying to fix everything in the current extension.

1 Like
36

Somewhat disagree… If I have to hire a developer to write a DC alternative from scratch that’s a non starter… As much as I would want to do it I can’t justify the expense. I’m not the only one in this position.

Would I pay a developer to contribute to either improving the current ones or contributing to a community effort to create an alternative? Yes.

I’d do this for two reasons: it’d be cheaper but also in either scenario is be contributing to a project that would benefit not only me but one that would potentially create a new standard for DCs, not just one that would benefit a single developer.

If funds weren’t an issue 100 percent agree on a full rewrite.

1 Like
37

I was referring to actually getting DC to a good state, not doing a little patch here and there.

38

A separate (external to DC) extension that only reads the "dynamic_attributes" dictionary is not what I’d call a “hack”. It’s only reading and not interfering with DC operation. (I’ve done this myself, BTW.)

This kind of gets into the realm of replacing the native Generate Report feature because of it’s limitations.
But is a good point, that a newer edition of a DC replacement should at the least have a public API/DSL for retrieving standard data using nice methods.

For example, now you’d might have to separately call a attribute getter for 3 separate attributes (1st needing to know the exact attribute names,) to get a point. If there was a reporting interface, one DSL method could get the 3 attributes and convert them to Length objects and pass them to the Geom::Point3d constructor and return the point object, saving the coder much work.

But this facet also reinforces why it is not likely that Trimble would open source DC code as it is, because they also have the native Generate Report feature partially dependent upon DC working, and they need to keep it working.
They do not need (nor want) to be inundated with support calls and complaints if the Generate Report feature breaks down.

2 Likes
39

yeah… sometimes you have to force a redraw for attribute values to update etc…
Now… you know that DC is part of the C SDK… for some stuff, like:

This at least indicates that the SU team also struggles to make the distinction between: DC’s are just another extension and DC’s are part of SU.

40

This is one of the major problems with DCs. It is an extension but the SketchUp core also has hidden special features for it, like the dynamic attributes directory having a key that can be used to exclude a component from the component browser. These small hacks that contradicts the overall architecture is yet another reason to purge DC and clean up SketchUp IMO.