[Question] DC Size and New Definitions

danielbowring

When making a Dynamic component, you'll often want to adjust the position (X, Y, Z) and size (LenX, LenY, LenZ). I'd always assumed this happened (at least for the value) at the instancelevel, but it appears for size this happens as the definition level for both formula and value.

This means if you change the size of an instance, you can end up with an identical definition with one instance that just has a different transformation.

To clarify, I can set the value and formula for any instances position to any value and it will effect only that instance. If I do the same for size, it copies to all instances, even though this should also only be a change in transformation. This means if I need to do a transformation that can involves size, I need to make a new definition for that instance.

However, if I perform the same action using COPIES, I can get the desired result without any new definitions.

So my question is: Why does positioning work the way I would expect it to, but sizing has a set of (seemingly arbitrary) special rules? Or am I misunderstanding something along the way?

Attached is a sample file - try to get sample!small_a to be sample!small_size in all directions, and sample!big_a to be sample!small_size * sample!small_factor in all direction without making a new component definition. sample!implement_b shows an expected output (using COPIES, so there is only 1 definition required for it)

dc_trans_sample.skp

danielbowring

I thought this might have something to do with situations that would require a new definition for varying size (LenX, LenY, LenZ) - but it seems that the COPIES method still deals with the situation (mostly) correctly. See the attached file for the example.

Since the LenX and LenY modifies the definition of the component, you would expect there to be 3 variations of the component (at the three different sizes). In reality it generated 6 (each of the expected 3 has an identical pair, [i.e., each copy/instance has it's own definition]).

dc_different_definition_copies.skp

danielbowring

OK - performing more tests it seems that the reason these create new definitions is because the formula differs. Instances from COPIES appear "immune" because the formula is the same, but the value of COPY is different per-instance. Since the forumula of each instance's attributes are equal, the same definition is used. As soon as you want to vary a formula, you need to create a new definition.

This seems logical enough, but still doesn't answer the overriding question. The Size (LenX, LenY, LenZ) affect (and come from) the instance, but are limited by the definition. Position (X, Y, Z) understands this, and will let you enter different formula for the position on different instances without making a new definition, but Size does not.

IMHO, the formula for size - like position - should be per-instance.

The attached file demonstrates changing size (and keeping the same definition) by altering a "non-size" value and having the size vary based on it. (Use the "interact" tool on the first three, the last is static). This is a workable fix for some situation, but not all (For example, placing a component at the "corners" of a bounding box would still not be possible without using COPIES or different definitions)

Does anyone have any more information on this, or a technical reason why this can't be the case?

animate.skp

danielbowring

Had a really good look at this over the weekend, and produced a "monkey patch" that makes size transformation per-instance

NOTE: THIS IS NOT FOR GENERAL USE! DO NOT INSTALL FOR ANY OTHER REASON THAN INSPECTION, AND REMOVE THE SCRIPT (AND RESTART SKETCHUP) BEFORE CONTINUED USE!

` require 'dynamiccomponents.rb'
Sketchup.require('DynamicComponents/ruby/dcobservers')

path = ['@dc1', '@instance_attributes']
path.inject($dc_observers) {|a, b|
a.instance_variable_get(b)
}.merge!({
"lenx" => true,
"leny" => true,
"lenz" => true
})`

Here's my findings:

*  In *most* cases, components can continue to exist and work as they are (e.g., the first sample file in this thread)
*  In some cases, you need to reapply the formula (if made before this script was loaded, afterwards it will continue to work as expected (e.g., the third file on this thread)
*  In the case where the *definition* depends on the size, everything breaks - but only when at a scale with a factor that is not 1 (i.e., anything except (1.0, 1.0, 1.0))

In the last case, the scale will increase by the given factor (i.e, if it should be twice in the x direction compared to the original definition, it will be at first 2x (correctly), then on the next redraw 4x, then 8x, ...
Aside from this, the functionality is (mostly) correct (There are a few situations where some definitions are duplicates, but it is certainly better than when everything has a new definition).

This is about as far as I'll be able to get without word from the SketchUp team (or the ability to get at the source code).

Once again - does anyone have anymore information, or is able to contact the SketchUp guys and get them to have a look at this thread?

pcmoor

0ne point I have found, the copy function within the DC does not make an instance, but another DC embedded within the group. this uses up memory, compare the file sizes of 100 normal copies compared to a DC copying its self. (note you also need to purge the file after going back from 100 to 1)

This may explain your observations

danielbowring

@pcmoor said:

0ne point I have found, the copy function within the DC does not make an instance, but another DC embedded within the group. this uses up memory, compare the file sizes of 100 normal copies compared to a DC copying its self. (note you also need to purge the file after going back from 100 to 1)

This may explain your observations

Confirm on the file size point;

* 0 definitions, 0 instances - 6.93 KB (7,101 bytes)
* 1 definitions, 0 instances - 12.2 KB (12,521 bytes)
* 1 definitions, 100 "copy+paste" copies, 25 KB (25,620 bytes)
* 1 definitions, 200 "copy+paste" copies, 39.7 KB (40,750 bytes)
* 1 definition, 0 "dc-copies" (copies=0, no instance), 15.9 KB (16,373 bytes)
* 1 definition, 1 "dc-copies" (copies=0), 17.0 KB (17,476 bytes)
* 1 definitions, 100 "dc-copies" (copies=99) copies, 86.9 KB (89,005 bytes)
* 1 definitions, 200 "dc-copies" (copies=199) copies, 160 KB (164,302 bytes)

Those numbers don't seem to add up for your theory though (using a naive approach)


>>> file_overhead = 7101
>>> definition = 12521 - file_overhead
>>> definition # Cost of definition excluding DC attributes
5420
>>> one_clone = 16373 - file_overhead
>>> one_clone # Cost of definition including DC attributes
9272
>>> cp_100_cost = (25620 - (file_overhead + definition)) / 100.0
>>> cp_100_cost
130.99
>>> cp_200_cost = (40750 - (file_overhead + definition)) / 200.0
>>> cp_200_cost
141.145 # Acceptable variance
>>> dc_100_cost = (89005 - (file_overhead + one_clone)) / 100.0
>>> dc_100_cost
726.32
>>> dc_200_cost = (164302 - (file_overhead + one_clone)) / 200.0
>>> dc_200_cost
739.645 # Acceptable variance

If there was a copy of the definition for each of the "dc-copies" instances, you would expect the dc_*00_cost to be closer to the value for one_clone

Also
` # 100 "copy-paste" instances

Sketchup.active_model.selection.length
100
Sketchup.active_model.selection.first.definition.instances.length
100
Sketchup.active_model.selection.map() {|i| i.definition}.uniq.length
1

100 "dc-copies" instances

Sketchup.active_model.selection.length
100
Sketchup.active_model.selection.first.definition.instances.length
100
Sketchup.active_model.selection.map() {|i| i.definition}.uniq.length
1`

I imagine some of the filesize distance would come from storing the attributes on each instance (although we have 63385 bytes to account for)
Sketchup.active_model.selection.first.attribute_dictionary('dynamic_attributes').each() {|k, v| puts " #{k} = #{v.inspect}" } _copies_label = "Copies" _has_movetool_behaviors = 1.0 _hasbehaviors = 1.0 _lengthunits = "CENTIMETERS" _name = "Component#1" _y_error = "<span class=subformula-success>10.0</span>*200" _y_formula = "COPY * 200" _y_label = "Y" copies = "99" copy = 10 leny = 39.3700787401575 y = 787.40157480315
I tested this by adding some position and scale attributes to the component, and the file size jumped up to 168 KB (172,766 bytes) (from 86.9 KB (89,005 bytes)) for 100 and 314 KB (321,979 bytes) (from 160 KB (164,302 bytes))for 200. (or 837.61 bytes/instance for 100 and 788.385 bytes/instance for 200). ~800 bytes for attributes only seems a bit heavy for only attributes but doesn;t come near the size of the definition (which, including attributes is 19.8 KB (20,351 bytes) [including file overhead] or 13250 bytes [exlcuding file overhead]

In these tests, there was no excessive components to purge, but that was by design (single depth component. no per-instance formula).

@pcmoor, This leads me to believe that this isn't the cause, but it still interesting information none-the-less. I do appreciate the input, though - and has given me food for thought on the cost of using copies.

Edit: just as a double confirm, if I take the "dc-copies" component, set it copies to 0 and then "copy-paste" for a total of 100, the file size comes out roughly the same as if I had used "dc-copies" (copies=99), at 165 KB (169,312 bytes) (within 3 KB)

danielbowring

Possibly related: This animation behavior.

Click any except the first to see they animate individually, but when the first is clicked it will animate all copies.

Animation on copies