I'VE ALMOST HAD IT WITH TRYING TO UNDERSTAND DC's!!!!
-
Glad to hear I'm not the only one loosing my mind, Trevor! I'm sure for some DC guru its childs play but it seems that the deeper you dig, the more time is spent on trying to troubleshoot formulas....
-
like object programming - encapsulate the objects. if the picket is simple, then create as a group and use the master to host the parameters and things like "count" etc, then in the group (picket) simply use the Copies and simple space rules to lay them out. if the pickets need to align end to end and the space can vary slightly, then compute that in the master and create an adjusted space after computing the number of pickets you can fit in a given length. or if spacing is important, compute the final size picket (in the master) and IF(Copy=Copies, last_size, normal_size). on align, IF(Copy=Copies,Master!LenX-normal_size,Copy * (normal_size+spacing)) etc.
if the object is complex, then make it a component with everything it needs to function but remember to pass parameters to it from the master otherwise using the component options UI will not work as sub-components do not surface their parameters to the UI. likewise you cannot reference the parents parent so you need to pass parameters on the components.
it can be frustrating. i've spent a few days making dynamic stud wall framing which has a feature to prevent end studs from overlapping because i wanted them to be usable for 2D drafts. yikes! and even after you test and test, there's always a glitch which needs adjusting... i'll get it eventually... it would be great if there was a native API which could be used with Ruby scripts to i could use/replace some of my scripts as plugged into a DC as the math in a DC will not properly support some of the math needed...
-
I realized very early that DC's and me would never be friends, after I spent a day trying to figure out a DC way of saving me ten minutes if it actually worked I came to the conclusion that ten minutes more modeling isn't such a bad thing.
-
Many,many, many of the plug-ins make modeling so much easier and I am thankfull to all the Ruby experts that have created them.
Then there is DC.
I felt somehow I was at fault because DC would never work right for me. Like Solo, I found it easier to spend a few more minutes working on the model "conventionally" than spending hours trying to make the thing work. The concept is GREAT however and I hope it eventually gets tweaked into someting workable.
By the way, had a thought... did AutoDesk have anything to do with developing it? Just asking.
-
Even of the pre-made DC's by those who understand them... who uses DC's? I haven't seen an example yet of a DC that I thought would really do exactly what I wanted, or which I would use repeatedly for different permutations.
I think a poll might be interesting (as far as these limited-participation polls go). I've wondered how widespread the use is. It's an ingenious concept, but has it caught on?
-
i've been struggling because the intricate 3D models then need to be translated into 2D plans or exported as DWG in 2D to interact with other people in the process of getting things built... so having the ability to use parameters, scale, and switch between 3D and 2D views easily is important to my work flow. scripts only take it so far, so the DC components (like framed walls, doors, windows, etc) all help with the modeling, drafting and material lists more than the scripting or individual modeling does (at least for me). so i try to invest at least 5 hours per project creating re-usable DC components so the next project is somewhat reduced in time and the quality is the same or better even.
i think the biggest win for pre-built is the kitchen components - there seems to be quite a few nice ones out there plus Pella and Marvin both have some nice windows and doors.
-
Those are good examples, gullfo. Cabinets especially. I have had some reservations about Manufacturer models (some are heavy while not looking very good--and lacking the options).
-
@solo said:
I realized very early that DC's and me would never be friends, after I spent a day trying to figure out a DC way of saving me ten minutes if it actually worked I came to the conclusion that ten minutes more modeling isn't such a bad thing.
At First I thought you guys were talking aboutWASHINGTON D.C. which we will never understand either
. . .but going to Pete's point. . . if it takes 14 hours to figure how to make a DC to save 10 minutes what's the gain? Short of some animation things (doors opening or something) I don't see what all the fuss is about. Stairs and fences can be re-modeled ususally a lot faster than it takes to input in all the data to make it DYNAMIC. SO i don't use them either.Just my 2c
-
@unknownuser said:
@solo said:
. .but going to Pete's point. . . if it takes 14 hours to figure how to make a DC to save 10 minutes what's the gain? Short of some animation things (doors opening or something) I don't see what all the fuss is about. Stairs and fences can be re-modeled ususally a lot faster than it takes to input in all the data to make it DYNAMIC. SO i don't use them either.
Just my 2c
all minutes aren't created equally.
Ive made 4 DCs that I use occasionally. . one of them took me two days to build and it saves around 20 minutes of drawing time. (the others took less time to make but they still knock off minutes when the minute$ count)
the thing is, those 20 minutes are much more valuable to me because they occur on site where as the 2 days making the DC was done in leisure time.
..if any of that makes sense
-
That's the thing Jeff, if I had a product that I used often and it made sense for it to be a DC then I'd probably have tried harder, longer or asked for help. Now my wife on the other hand is a CKD kitchen designer and she uses 20/20 daily, she is talking of using Sketchup in the future and this may be when DC's will come in very handy or even necessary.
I guess it comes down to when or how you will use them or even need them.
-
Ditto.
-
@unknownuser said:
Ditto.
oh. I totally understand what you guys are saying and for the most part, I'm the same way.
it's just that I happened to find a use for them in which it made sense for me to spend the time creating the DC.. so I was just adding my own experience.
I do wish the sketchup team developed them much further beyond the initial release.
a DC GUI of sorts would probably do wonders as far as getting more people to use them.the current implementation is far too codey(?) for most people. we generally want to SHOW the computer what to do instead of TELL it what to do.
(the show vs tell is probably the wrong choice of words here.. replace them with whatever works better
) -
I agree, it should be easier, It feels like I need to learn a new program almost. I'd like presets with configurable options, drop windows maybe with options, easy building UI, etc.
or even as you suggest something like a macro, where I can record the action. -
@solo said:
or even as you suggest something like a macro, where I can record the action.
I was actually thinking something along the lines of grasshopper (maybe not as intense though
)maybe:
[in DC design mode or whatever]select a face
assign a push/pull modifier to the face.
the modifier could then be controlled via a slider or numerical input etcor select a component
assign a move modifier to it
show the direction you like
check yes/no for copymove
etcitd be a lot more user friendly like that
-
-
DC's are half the reason I bought Pro 7 and gave up very soon after the purchase. I figured I was just too dense to get it.
-
phew... now I feel much better that you guys are of the same opinion....
I like that idea about selection a face and applying a group of settings to come up with what's require: Goh's 1001bit tools does a similar thing and it works well for me.
Maybe I just drop the DC thing all together.
-
I concur with ArCAD's experience - the way DC's are deployed completely hampers their usefulness.
I have plenty of programming experience, so found the maths side not too bad and managed to create several DC's that I thought would be useful....
....until I looked in my Components toolbox - "Part#1", "Part#2", "Part#3",..etc...
...which I then rename as "Part Small", "Part Big", "Part Huge" etc. and then try to remember to drag the right one into the model so that I don't then end up with another new series of #1,#2,#3... (except that I will anyway if I alter any parameters "on site").
I think, at best, they can be used as a kind of templates for quick construction of regular "non-DC" components. But as has been pointed out already, SU is so fast to model with, that I may as well have just built "Part Small", "Part Big"... as separate components in the first place.
To be more useful, I would like to see something like...- Only ever one definition (visible?) in the component toolbox.
- A new native component attribute "Suffix", visible in the Outliner - e.g. for a component called "Nut", we could add "M3","M4" etc. according to parameter values - purely as "aliases" to help us see what is what and for use in reports, but not changing the DC definition in any way.
- "Variants" itemised according to their parent definition and sorted by parameter values in reports. So I can quickly see that I have used 25 M3 Nuts, rather than having to check each "Nut#x" component individually to see see what parameters it has.
In principle, DC's have a lot of potential - but I doubt it can ever be realised unless the implementation is thoroughly overhauled.
-
Well this turned into a surprising thread. I hadn't expected so many experienced users to be having issues with DCs. I guess someone needs to grab hold of this aspect of SU and give it a real good shake to give us a more useable format.
I did have another play yesterday to create an inclined beam and realised that DCs are really lacking some basic shape modelling commands such as add and subtract, but with SU's solid modelling this must now be a realistic prospect?
-
yeah, naming your parts and using materials (i use colors named as needed "lumber_stud", "machine_bolt" etc then replace if used for rendering later) is key to making the reporting work well. then i import to excel and run some macros to remove extraneous values and summarize (DSUM DCOUNT etc) to create the materials list. it would be nice to have the reporting take families of groups and report directly though...
it would be cool if DC had a "record macro" function. but some more functions (like % (mod)) would be nice plus parent's parent referencing (as well as inserting of Ruby code
)
Advertisement