- Montreal, Canada
- Personal website
- Work website
- Vimeo profile
- SoundCloud profile
- Facebook profile
- 8 months 2 weeks ago
- Last seen
- 9 hours 40 sec ago
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.
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?