Dynamic Component Instances and File Size?
-
Hi all,
So... I've got this custom plugin (kind of a suite of tools, I guess) that I've written at work. Basically, I'm using SketchUp as a combination estimating/layout tool for Engineered Wood Products (EWP).
I have to say, this tool is pretty amazing, thanks only to extensive tutorials and shared information on sites like Sketchucation... the countless things I've learned from this community in helping me learn Ruby and the SketchUp API are invaluable.
That being said, their are a couple things that I'm wondering if there is any at all to do about. The biggest one is file size.
Now, I know there's probably nothing to be done, but just the same, I have to ask. In my layouts, I'm working on buildings which can be tens of thousands of square feet per floor. On one floor, by the time I'm done laying out the floor system, I will likely have thousands of components in the file. I have a base set of only 6 dynamic components which are placed, rotated, scaled, etc to create the layout components and thus the material list.
I can totally understand that the more components there are, the bigger the file, the more RAM required, etc. However, it seems that with SketchUp, the file size seems to increase exponentially... so for a while everything is fine, but at a certain point the file grows more for adding, say, 100 components than it did for the previous 100, and the 100 previous, etc (as does the slow-down and hour-glassing waiting for SketchUp to catch up). Most projects I work on end up being around 200 MB files, which doesn't seem right to me... I thought that part of the reason to use dynamic components was to reduce needed data/file size, but the inverse seems to become true at some point.
I even toyed around with making a '2D-only' version of my components - thus flattening the layout and reducing the geometry vastly - but this seemed to have little effect on the file size, leading me to believe that most of the file size was coming from the overhead of the simple fact that they are dynamic components... am I wrong on this? Something about this doesn't seem to jive in my gut.
From my understanding, even though I'm using the same base component, since each one is positioned and scaled and such, SU makes each one unique... which I think is the problem. But, I have no way to stop that from happening, so... I think I'm out of luck? -
I'd post examples, but the SKP files are gigantic, and my plugin code is just shy of 200,000 characters altogether.
-
using Ruby on a selection you could collect or group a number of components, read, count the data, then explode the inner components to form a new group component, purging as you continue
-
@pcmoor said:
using Ruby on a selection you could collect or group a number of components, read, count the data, then explode the inner components to form a new group component, purging as you continue
I'm not sure I fully understand what you're saying there... though, along those lines, I've noticed this: I'll have one building level complete, might have say 2000 components. I have a tool created to copy and move selected objects - it groups everything selected, translates the location, then explodes the group. At least as far as the file size is concerned, these new copies are effectively the same as the originals (very little file size change). BUT, when I change even one property on these copied components - even something simple and not referenced by other properties, like a changing an object's floor name from '2nd Floor' to '3rd Floor' - then the copied component upon redraw is broken out by SU into it's own unique component... so if I do this on all those objects from one floor, suddenly the number of unique components in the model doubles. It's just frustrating. So much more could be done with SU if there was a way around this.
-
my suggestion is to destroy the collection of components after collecting the data and creating a new one containing raw geometry (the exploded DCs) then purging the drawing of these 100 or so DCs, Perhaps before such an event the group of DCs could be saved to a separate file so the newly formed group component can be swapped for editing if required
-
@pcmoor said:
my suggestion is to destroy the collection of components after collecting the data and creating a new one containing raw geometry (the exploded DCs) then purging the drawing of these 100 or so DCs, Perhaps before such an event the group of DCs could be saved to a separate file so the newly formed group component can be swapped for editing if required
Unfortunately, that won't work - I have to be able to go back into the file later and edit the floor layout and products for structural plan revisions and the like, so it can be quoted 1-3 times, then submitted to building departments 1-3 times, etc, and revised over and over, and the data retrieved over and over likewise. If I explode the components, I lose most of the data and capabilities I need to retain. I could like you say put them in another file, but then I have two files instead of one, and the 2nd file is still huge, so no space is saved (actually losing space since I have two files).
-
could you post the skp of one component so people could test with the actual thing?
I just tested copying a 100kb component 1000 times -> file size went up from 100kb to 242kb.
Copied those 1000 components again 30 times so in total 30.000 components -> file size was 4Mb.
Applied a random rotation and scale to every component -> file size was the same as before.Maybe it's some attributes or dynamic component behavior that's causing this? Posting a sample component file would help determining the problem.
-
@kaas said:
could you post the skp of one component so people could test with the actual thing?
I just tested copying a 100kb component 1000 times -> file size went up from 100kb to 242kb.
Copied those 1000 components again 30 times so in total 30.000 components -> file size was 4Mb.
Applied a random rotation and scale to every component -> file size was the same as before.Maybe it's some attributes or dynamic component behavior that's causing this? Posting a sample component file would help determining the problem.
It has to be something related to the dynamic components, yes, I just don't know what.
I have attached an example - this skp has 240 instances of one of the components, which is the maximum I could fit into the file before it exceeded the 4 MB file size restriction on attachments here.
The component that's been inserted by Ruby is only 37 KB as it's own file.
Each time, the code is figuring out the position, length, and rotation needed, adding an instance of the component, setting some various dynamic properties, and then redrawing the component.
-
Ok, in this file there are 243 component definitions and they all contain the same 4 sub-components. Is it possible for your workflow to use a group as a top-container instead of a component? If I do that, the file is only 106kb.
-
@kaas said:
Ok, in this file there are 243 component definitions and they all contain the same 4 sub-components. Is it possible for your workflow to use a group as a top-container instead of a component? If I do that, the file is only 106kb.
Well... I'm not sure how that would work, for a couple reasons... 1) I have to do reporting on the components, which in the case of the component in the example file can be anywhere from 1" to 66' long, and the geometry of the sub-components needs to be correct... and that one example component can be up to 20 different products each with different geometry so the component needs to be flexible. 2) I need to be able to easily edit, audit, and track them later, repeatedly.
So, my real question I guess is this: if the geometry is not the problem, then what about the dynamic component is making the file so huge? Is there some way to do them to avoid the bloat, certain functions on properties that cause the problem, or what? I don't understand how/why a few properties placed on an object can make it grow in data size so drastically.
-
Hi
to illustrate the group, explode, outershell and purge concept I added a similar DC (metric Australia) for an I beam. The component is the larger one on the right side.
The process is to explode, outershell, explode the selected inner group geometry. A process made easier with a script. Whilst still retaining the outer component (wrapper). Then finally purging the model.
I find groups of 10-20 more manageable, once done they can be copied with minimum file size changes, further more the fixed lengths can be still changed using the user form.
At any time they can be reinstated by swapping the exploded group with the original component.Components built with an outer wrapper, with common custom attributes will update. so a common alenY that references LenY will update, thus a steel channel can inherit the common attributes of a timber beam. In other words the lengths of the beams will match on swapping. I am current building some examples on my warehouse page (same user name pcmoor).
philip
-
The exploding/shell/replacement thing is interesting, but not what I have in mind - also, not really dealing with the question, which is why is the file so large to begin with. I've done far more complex drawings in AutoCAD and other apps, and the file size is nothing close to this. Just doesn't make a whole lot of sense.
I guess the answer is "it is what it is"... -
Its all got to do with DCs, as observed moving them individually after a copy make SU update everyone to an unique instance. This issue has been raised with the powers that be, however it remains to see if any resolution in the next release
An alternative which seems to work is to group the copies. Quarantine. The group can be moved and another group of same components if altered inside does not effect similar groups.
-
@pcmoor said:
Its all got to do with DCs, as observed moving them individually after a copy make SU update everyone to an unique instance. This issue has been raised with the powers that be, however it remains to see if any resolution in the next release
An alternative which seems to work is to group the copies. Quarantine. The group can be moved and another group of same components if altered inside does not effect similar groups.
Yeah... also not incredibly feasible, given the flexibility I need. I guess I'm just kind of stuck with how things work right now. When I have layouts with as much variance in them as the example I attached, it becomes very difficult to group any items together.
-
this maybe solved by a simple trick via Dave
Components with attributes creates unique copy when attributes changed
Hi, I have set up a set of components to add in electric sockets and lights. They have a simple set of attributes to set height above floor level, as well as number of switches/ sockets which resizes the plate and numb…
SketchUp Community (forums.sketchup.com)
Advertisement