Pipet (EX9.Texture) bug on floating-point-textures

vvvv beta bug
1

I came across a bug in Pipet node, it doesnt work on floating point textures (A16B16G16R16F, R32F etc), which are the most interesting - this would allow to move some calculations to gpu, and read back precise data

proof in file:

pipet_bug.v4p (15.3 kB)

2

I was under the impression pipet was slow because it worked in float…
Can i ask again for a super speedy 8bit per channel version (threaded would be nice ;) ), a luminance only(or per channel) version and a float version.
I’ve been told that jitter and ofx can do pipet much faster than vvvv and it would be a really useful node if it wasn’t so resource hungry!

3

havent tested it specifically, but i thought pipet is slow when it is massively spreaded… I need it mostly to read just few numbers, maybe a spread (100 values or smth), from a small texture (1x1 or 100x1). Never noticed any serious slowdown on that… The only problem is these
floats

4

Massively spreaded is where it gets useful for lighting :)

5

i use pipet loads and not overly large spreads. recent project that required spread of 500 and I couldn’t get 60fps even i7 at 4GHz!!! There was a tonne of other stuff going on but without pipet 60fps with it 45fps. I soooooooooooooooooooooooooooo wish for a faster pipet.

6

Any chance for this bug to be fixed soon?

7

@ft: it is. pls join us on irc for a test.

8

@catweasel : maybe you might be remembering it being slow because the values are converted from 8-bit colour values into 64-bit doubles (conversion itself is generally slow)

@unc : yep, long standing issue.
one temp workaround is make a shader that decomposes 32bit / 16bit floats into 4 8bit colour values and then pipet that / convert it back. It’s obviously a little messy / slow for multi-values, that’s what it’s a ‘workaround’ :).
if you want to do multiple values, you can use multiple render targets for the decompose values