Anyone Know Why DC's are so Buggy?

SketchUp Dynamic Components
, ,
1

Hi All,

Does everyone have issues with DC’s? Is it the UI that makes them so difficult? For example. Per my Dynamic Logo - the Code is ignoring values in one of the objects and not the other… And today I’m building a different logo and when I add a LenZ value to one of the Sub components, or even affect the value, the Logo jumps to a distorted view and will stay that way if I don’t hit ctrl+z…

Does anyone else have these issues? I always run as admin and I can only install Sketchup so many times lol

T.

2

Here’s what I’m talking about… I’ve built this logo exactly the same as the other logos I’ve built over the last few days and for whatever reason this one is not working right at all. I restarted my computer and it’s still not working.

3

Can you post the model? What comes to mind is location and orientation of the group/component axis

4

I’m not sure whether they are buggy exactly but they can be very difficult to get right. A large part of the problem is the clunky interface.

DCs were introduced to great fanfare quite a few years ago but no development work has been done on them since. Some people persevere and get them to work but a lot of us find that it is easier to start from scratch (which defeats the whole point of them!). You have to have a very good reason to want to bother.

1 Like
5

Here’s the model. The problem is that this model was built using the exact same workflow as the other two that work normally. Things like this happen all the time for me and sometimes closing SketchUp fixes it or restarting my computer but for some reason this particular model refuses to work correctly.

I’ve built Dynamic Models a bunch - Doors, windows, lights, etc. - for the other designers at my workplace and have just tolerated the bugs. But now I’m trying to build some client facing assets for the team and it’s really starting to bug me lol The idea is to build a Dynamic Logo set so as to avoid building them over and over again. Creating a standardized logo set for each of our clients would help speed up the Designer’s workflows. At least in theory… if the UI would work.

Here’s the model. Take a look and if it’s just a cursed object we’ll have to figure something else out.

FROG_DYN_LOGO.skp (7.1 MB)

I’m also attaching the logo slick just to show you what the goal is

TCU_Dynamic_LogoSlick.skp (5.9 MB)

6

Not Entirely sure what I did differently other than the order of operations but now the Component is working correctly in terms of the sizing issue. So… Idk lol

7

If your geometry is not too complicated then creating a parametric extension is a better route than a DC in my opinion.

8

I suspect the problems with DCs boils them to them being created by enthusiastic enthusiasts, not trained software engineers at the time [my speculation]. That and probably management rushing in a new feature rather than properly build something to last [also my speculation].

DC is a great proof of concept and would be lovely if it worked properly, but there are just too many quirks for me to stand it. Like, why is it hardcoded to two units rather than supporting the full SketchUp unit catalog? Or why does it break when unit display is suppressed? Or why does it use a graphical style in the uncanny valley next to native OS style? Why does it stretch materials? Why does it alter SketchUp API classes? Why does it lack a proper separation between back end and front end (for instance, the methods it adds to Transformation to extract angles return rounded angles in degrees, not precise numbers in radians)?

And DC itself is just the start. Then there are the third party extensions abusing DC functionality, despite DC not having a public API. This is essentially hacking DC and works by accident, not by an agreement of how DCs are intended to work. This has also been quoted by SketchUp developers as a reason why DCs can’t be updated and fixed; it would break the workflow for countless of people relying on these third party extensions that inevitably would break.

3 Likes
9

Eneroth I agree. It’s a great function for the customer - in theory - but it definitely opened new doors to problems they didn’t really expect. I’m not a trained software engineer and only have a tiny bit of coding experience so my issues are mostly just from inexperience and lack of understanding some of the syntax and functions capable of creating what I need.

It would be really cool to get into creating extensions for my workplace but I feel that’s a ways off yet.

P.S. Camera Memory completely changed the Design workflow here at Advent lol Probably top 3 of my most used plugins.

10

Hope S.L. will not read this :astonished:

Now… "hacking into"DC’s even got promoted for a short amount of time: Redirecting to Google Groups

1 Like
11

It looks to me that post is about 10 years old. Also the code it shows is not Extension Warehouse compliant as the attribute writing and Dynamic Component redrawing will be added separately to the undo stack.

12

See Scott Lininger - Bitsbox | LinkedIn his resume (with education) is at the bottom of the page.

Scott L. (and the other Scott) perhaps did their best at the time (2007) with what they knew of Ruby (whose popularity in the U.S. had recently surged in the prior few years, along with Rails for web development.)

There are things I wouldn’t have done myself, but that comes with many years now of experience. I cannot say I’d have not have implemented all the DC code as classes if I’d have had to do it when I was “green” at Ruby. Also the way they are implemented version wise makes it difficult to officially add new features, as this would require versioned dynamic component models in the 3D Warehouse.

Some of the “work properly” kind of stuff has a lot to do with how the SketchUp core is (or was at the time) working. Again keep in mind this was likely Scott’s initial project with SketchUp. I suspect the answer to many of the “whys” is that he had to get a bare bones implementation working before adding in the extras.

But as anyone who has worked out in the world in an engineering department knows, other priorities intrude, marketing always wants to release early to enhance sales, etc.

It was a simple example … which also predated the implementation of the Extension Warehouse. How could it comply with something (EW) that would not exist for another say 4 years ?

Secondly, … Scott shows the call to #redraw_with_undo which itself has an operation inside it. Undo operations cannot be nested which is what would happen if this call was put inside another model#start_operation block.
The additional arguments that allow stitching operations together came out at about the same time that DCs were released, but I cannot remember if Scott leveraged these new arguments as DC development likely predated then (or probably at least began) before these arguments were implemented.

But, in hindsight, we can see that Scott was too open with the implementation details of this closed source extension.

3 Likes
13

I have searched for _attributes to display or popup in the Attributes panel, but only _name works

14

@DanRathbun @eneroth3 This is probably a topic fo another thread, but would you be more interested in working with DCs if they were open sourced? That way if you wanted to build your own bespoke version of them you could (and preserve any custom functionality you built for a client lets say) and the main DC branch could benefit potentially from improvements that people like you have created in your forks?

15

it is and always has been an open licence…

theoretically, anyone can modify it or host it on Github etc…

# Copyright 2019, Trimble Inc

# This software is provided as an example of using the Ruby interface
# to SketchUp.

# Permission to use, copy, modify, and distribute this software for
# any purpose and without fee is hereby granted, provided that the above
# copyright notice appear in all copies.

# THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
# IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

#-----------------------------------------------------------------------------
# Name        :   Dynamic Components Extension
# Description :   A script that loads the Dynamic Components as an
#                 extension to SketchUp
# Menu Item   :   N/A
# Context Menu:   N/A
# Usage       :   N/A
# Date        :   10/16/2008
# Type        :   N/A
#-----------------------------------------------------------------------------

john

2 Likes
16

For extension development, it would be better with libraries for common functionality, like handling object parameters and UI etc, and then implement it in extension individually, than having extensions depends on another extension.

1 Like
17

I disagree. I personally believe that this blurb was mistakenly pasted into this extension registrar script (or a registrar file from another open source extension or example was used as a template.)

Then why is the actually extension code rbs scrambled (in older versions) and rbe encrypted (now in current versions) ?

Theoretically, the description (in the registrar file) only describes the script that loads the Dynamic Components extension, not the whole extension code. So the license you speak of may only extend to that 1 file.

UPDATE: I looked at an older version running in my SU2016 install, and the ".../ruby/dcloader" file is an unscrambled .rb file, that states clearly at the top:
“# License:: All Rights Reserved.”
I will admit I’ve seen the code for the remainder of the files, and they all echo that all rights are reserved, as well as a copyright set to 2012 for Trimble, Inc. Again, the actual running code file do not give permission to copy, change or distribute the DC code.

The Google folks and now the Trimble folks have not entirely treated the DC extension as open source. Yes, from time to time, they’ve posted informal and formal (blog) posts showing little hacks that change or add to DC behavior. They really should have instead “baked” this extra behavior into the extension.

18

At first the license only applying to the registrar made little sense to me, as the registrar is an integral part of a software, not a separate software, but then I noticed the description “A script that loads the Dynamic Components as an extension to SketchUp”. This might very well be the case, as absurd as it is.

19

Just open sourcing the code the way it is now, will not facilitate customization. The DC code objects were not written for this in mind. (As Julia says they are not a library.)

Part of the issue is that the 2 dialogs are hard-coded to use the current code objects (classes.)

What’s more, the add functionality mechanism, is a weird implementation where new DC subclass needs to be implemented and any dynamic component that wishes to use it, needs to have it’s hidden version attribute changed to the version of the subclass (which is part of the class name identifier.) Ie , now: DynamicComponentsV1 … follow on editions with more functionality would use a subclass that is named like: DynamicComponentsV2, DynamicComponentsV3, etc.

This really means that the SketchUp Core team (who is responsible for the DC code,) needs to be the party that adds new DC component subclasses. Otherwise, there would be a bunch of competing 3rd party version 2s, and 3s, and 4s, etc. (I suppose there could be a community extension hosted on GitHub that extends the DC extension, to prevent clashing code.)

But even weirder, is that this scenario sets up a situation where “out in the wild” there could be a mixture of DC component files of varying versions. The 3D Warehouse (I don’t believe) is setup to handle filtering and download by DC version (although this appears to be what Scott planned back in 2007.)

I think he intended for the versioning to be transparent to DC users, but something known by DC authors. Perhaps also if the modeler of DC chose to implement a V2 feature then the code would just transparently set the DC definition’s "_formatversion" to "2.0" in the background. (But the author has to be themselves running a DC extension that supports newer DC versions.)

But this sets up a challenge. What if an older SketchUp version inserts a V2 DC into the model, and only an old V1 compatible extension is installed. Does a message box warn the user to update the DC extension? Answer: Yes, (manually changing a DC version and attempting to apply a DC option change, even one that is still V1 compatible, results in a messagebox.) ie:

image

But once the messagebox is dismissed the dynamic option change is actually applied. But the DC Options dialog will not recognize the selection of the DC instance until this dialog is closed and reopened again.
The V1 authoring dialog will flat out refuse to display any authoring controls for a higher version DC component. (It displays a message that the user needs to select a component even though one is selected.)

What if it’s a pre-2017 SketchUp and cannot update because all V2 compatible DC extension versions are rbe encrypted (ie, post v2017. If y’all did not notice, the DC extension for SU2018 and higher is distributed only as rbe encrypted code. This likely means users still on versions earlier than SUv2016 would be “out of luck”.)

1 Like
20

I totally get what you’re saying Dan, I was thinking a scenario like this:

DC’s are open sourced but still included in SketchUp. So every DC maker can make a DC that works theoretically with every version of SketchUp.

Now let’s say someone contacts you and wants a special DC library built, one that’s not possible with DCs in their current form. You go grab the DC code, fork it and build your custom library for a client. For the client to have working DCs they’d need to have your extension.

So the client is happy, they have their custom DC library up and running. You can maintain, fix, and extend it however you want and you don’t have to wait for SketchUp to fix something.

Now, let’s say you did something so super cool in your fork now SketchUp could pull that functionality into the main DC branch, thus benefitting the rest of us.

So in the worst outcome you as the dev get the control you need, and in the best outcome that customer actually ends up not needing your extension anymore and you (and others) can build better DCs.

SketchUp would ultimately maintain the canonical DC code so they could make sure it works with every SketchUp release, 3D warehouse, etc. Devs could branch, but it would be “at their own risk” so to speak.