Kewl's picture

@Kewl

Kewl's picture
@Kewl commented on @Kewl's Discussion, “CPU efficiency in Calculate node

Ah, OK. I've seen in other dataflow programming software (like SonicBirth) that divisions are really not ideal and turning divisions into multiplications (1/180 becoming a constant by being calculated only once) is a better approach. If Vuo is not sensitive to this, so much the better.

Kewl's picture
@Kewl commented on @Kewl's Discussion, “Cylindrical projection to fisheye

Thanks! As for the dome, I have to use my imagination at the moment...

Kewl's picture
@Kewl commented on @Kewl's Discussion, “Make Noise Image node: half-tile option?

Or, what percentage of the image, on each side, is used to render the tiling?

Kewl's picture
@Kewl commented on @Kewl's Discussion, “Cylindrical projection to fisheye

This is what it looks like with actual music, in Ambisonics B-Format.

Kewl's picture

Yes, you're right. But... For me it changes the strategy for the image rendering from layers.

Let's say I want a 1x3x1 tube scaling. A good image for that would be 3140x3000 pixels. But if the image is applied to the tube before the tube scaling, the image will be squeezed to 3140x1000 pixels (loss of data) and than re-stretched to 3140x3000 (extrapolation of data). I have waisted CPU cycles to render an image bigger than necessary and to squeeze that image.

If I know that the image is applied before the tube scaling, I can distort the layers (taking into account the tube scaling) before render to image and render the image at 3140x1000. Once applied and scaled on the tube, the image will have the good proportions, but I will have potentially saved a few CPU cycles by avoiding the generation of "useless" pixels that get lost on the image squeezing.

Or maybe not... Is Vuo vectorizing matrix data for processing?

Pages