zip and unzip

August 7, 2012 posted by: Elias

the beta28 release will contain two new spread operations available for all major data types: zip and unzip. their operation is best explained by two screenshots of their help patches: Unzip

for performance reasons each zip and unzip comes with a normal and a bin sized version. for example if the task at hand is to zip two spreads slice by slice the normal version will be much faster than using the bin sized version and setting the bin size to one. so if possible use the normal version.

together with their bin sized versions and the ability to control the number of input (in case of zip) and output pins (in case of unzip) via a config pin they form a very versatile pack of nodes able to replace the functionality of various nodes from a simple vector join/split to the very famous (and probably hardest to find for beginners) Stallone node.

by making use of the newly introduced streams they are able to outshine their “competitors” by up to a factor of ten in terms of performance. the higher the slice count the faster they are compared to the rest. only at very low slice counts (< 25) their performance is not as good as for example a native vector join as with all plugins the transition from the unmanaged world of vvvv to the managed world of a plugin comes with a small overhead.


Comments:

Comments are no longer accepted for this post.

readme
07.08.2012 - 22:26
Elias is on fire. This is neat, thanks!
robe
08.08.2012 - 09:59

@Elias

So this would be better than a vector 3d join/split to manage for example a huge vertex buffer and apply some calculation in-between?

Tnx

Elias
08.08.2012 - 11:44
@robe yes. just did a quick test with the v.x file changing the x-coordinate by a random amount and framerate increased from ~170 to ~220 when replacing the 3d join/splits with zip/unzips.
alg
08.08.2012 - 18:07
Can’t understand, why this nodes not called like Vector (Join Fast) and Vector (Split Fast) for example.
Elias
08.08.2012 - 20:48
the names are borrowed from the functional world of programming languages…they have been there for ages and describe the operation very well. better than join/split in my opinion.
hrovac
08.08.2012 - 20:54
+1 for Join fast & split fast as well i am not living in the world of functional programming ;) i prefer the chaotic world of nodes and noodles
bjoern
08.08.2012 - 22:21
The Bin versions concatenate, right? So in their case zip doesn’t fit quite right… Btw. none of them beats the mighty stallone, having control over input / output count and the joining logic at the same time. Stallone (Spreads Fast), unreal.
joreg
08.08.2012 - 22:42

nono bois, this is not a jukebox. the name is the right one. we don’t want to have fast and slow versions of nodes that do exactly the same.

it is important that when you need a vector (join/split) you use a vector (join/split) and not any other node that you heard is faster. because maybe in an upcoming version we have an optimization for vector (join/split) that is just as fast or even faster than zip/unzip and then you have to change all those nodes back.

so use zip/unzip when you need general un/zipping functionality else use vector (join/split) and bug us to improve their speed. one step at a time…

bjoern
08.08.2012 - 23:08
I’m fine with zip anyway, just smart-assing. But will Unzip replace Decons, like woeiuser stated here?
gregsn
09.08.2012 - 00:26
yes. in the current alpha it is like that.

Contact


Imprint

vvvv - Dießl & Gregor GbR
Oranienstrasse 10
10997 Berlin/Germany
VAT: DE275566955

groupӘvvvv.org

Follow us

Mastodon.social
Pixelfed.social
Github
Vimeo
Youtube

Sign up for our Newsletter

Your subscription could not be saved. Please try again.
Your subscription has been successful.