The best way is to use a C# or a VB component to transpose these
lists. I think in C# you can use transpose directly. You can ask this
on the VB/C# forum on our new website, www.grasshopper3d.com
- Scott
On May 27, 3:56 am, Tonsgaard wrote:
> Being a long time user of Generative Components trying to use
> grasshopper i miss the "transpose" command.
> I have a point list like this:
>
> 0, 1, 2, 3, 4, 5
> 0, 1, 2, 3, 4, 5
> 0, 1, 2, 3, 4, 5
> 0, 1, 2, 3, 4, 5
> 0, 1, 2, 3, 4, 5
>
> and a want to transpose dimensions to:
>
> 1, 1, 1, 1, 1
> 2, 2, 2, 2, 2
> 3, 3, 3, 3, 3
> 4, 4, 4, 4, 4
> 5, 5, 5, 5, 5
>
> Surely I am not the first in need of this...
> how would i go about and do this...? I suppose its quite easy in VB
> script, but being used to GC's C# like language, I kinda dont know how
> to do this...
>
> thanks...
>
> Tonsgaard…
ches it with the first branch in Tree B (and then the first branch in Tree C if more than two trees are involved).
I'm planning to add better branch matching logic, but I'm not going to touch it until I have a good idea about what's needed and how it can be accomplished without breaking existing files.
So, the branch "address" is only used to sort the branches in a single tree. Thus, a tree with the following branches is always sorted in the exact same way:
{0;0}
{0;1}
{0;2}
{0;3;0}
{0;3;1}
{1;6}
If you have another tree with different branches:
{0}
{1}
{2}
{3}
{4}
{5}
Then the matching will be:
{0;0} -> {0}
{0;1} -> {1}
{0;2} -> {2}
{0;3;0} -> {3}
{0;3;1} -> {4}
{1;6} -> {5}
As long as people adhere to your advice: "it is best for the addresses of each tree branch to be in the same format", there will be no problem. But it is at the moment extremely difficult to perform complex matchings.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 9:25am on August 11, 2010
byte-accuracy red, green, blue channels) = 27 bytes. More likely 28 bytes as colours are probably stored as 32-bit integers, allowing for an unused alpha channel.
28 * 800,000 equals roughly 22 megabytes, which is way down from 9 gigabytes. That's a 400 fold memory overhead, which is pretty hefty.
Grasshopper stores points as instances of classes, so on 64-bit systems it actually takes 64+64+3*8 = 152 bytes per point*, which adds up to 122MB, still way less than 9GB. It would be interesting to know where all the memory goes...
* Grasshopper points also store reference data, in case they come from the Rhino document. This data will not exist, but even so it will require 64-bits of storage.…
Added by David Rutten at 4:13pm on December 11, 2014