Dynamic Component Instances and File Size?
-
@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
Advertisement