I have a patch that is very simple and allows me to change the effect applied to a Sphere by changing the value of a single IOBox(Value) node. The Sphere is connected to all the effects and all the effects are grouped and out to a Renderer. I use a spread of 0s and set one of the values to a 1 using a the slice index on a SetSlice (Spreads). This spread is then distributed through a Stallone node to all the Enable Pins on the effects. i.e. Only one effect is ever enabled.
I’ve attached the patch if I haven’t explained this too well.
The whole SetSlice > Stallone combination could also be done with one custom node. It would have a configuration pin to set how output pins would be required, i.e. how many effects I am using. It would have a single input value pin to select which output pin would give out a 1 and all the rest would give out a 0.
Would my custom node give a performance gain?
Would there be a memory gain?
I have a strong programming background and there are a few situations where I think I could make a more simple node for what I’m doing. I appreciate I can create subpatches for the use above, effectively making a new node but does this cause more memory use and performance loss that just having it in the root patch?
All advice is much appreciated.
MAINeffectSelect.v4p (8.2 kB)
you could replace the LinearSpread/SetSlice with a PeakSpread. writing a plugin would not gain you much of performance.
you can really improve the performance if you copy all effects code into one file, so that the different effects are implemented as passes. then simply switch the passes.
thanks tonfilm. I didn’t spot the PeakSpread, that would do the trick.
You say I may gain a little performance writing my own node does this mean:
custom plugins have the same performance as the build in nodes?
if I write a my own linear spread node will it, if I code it correctly, have the same performance as the build in node?
if I write a node to do the job of more than one node will I be saving some system resources and gain performance?
Regarding multiple effects, I’m trying to make a content creation system so a user can select a number of XFiles to have in a scene, then apply an effect to shade them with, and set there rotation and scale. All this would be done from a GUI interface and my system may end up with over 50 different effects to apply. Many may be the same effect but with a different texture or a different color. I imagine this would be very difficult to manage if they were all in one effect file. Has anyone some advice on performance issues with such a system please?
I hope this is not too much at once. Cheers
As tonfilm said (and me before, if i remember well :)) one big effect (or several, but 50 sounds too much) is the way to go…The patch structure will gain in visibility and perfs…Even more if you just need to switch only colors, textures or .xfiles!! Spreads are vvvv powa ; and select many x files and textures (via kinda Directory selecta GUI) shouldn’t be a problem just need a good patch though to handle them individualy ;) but i assume this might sound pretty advanced.
Hi Desaxismundi. Yes you did say before in another thread thanks. I’ve just combined the contant and gouraud effects and it’s worked well thanks. OK I’ll combine more and see if it is more manageable that I’m imagining. I’ve just combined the constant and gouraud effects successfully.
One quick question, what method could I use to swap the technique without clicking on the technique pin on the effect? i.e. I need to be able to select it from my GUI.
Thanks loads for input, much appreciated
Ord2Enum(Enumerations) is your node ;)
Edit : As i finally just understood what you are trying to do you’ll definetly need mutliple .fx. But only one instance of each!! (with well selected .xfiles, textures and colors…).or replicate the big one…
@nitro: c# is in its core still a compiled strongly typed language which can archieve similar performance as delphi (where the native vvvv nodes are written in) or c++ if done right. so the code itself will be executed much faster than typical script languages or languages like ruby or python.
note that the interface between the plugin and the vvvv core is slightly more inefficient as the interface between the native vvvv nodes. so in fact a linear spread written as a plugin will probably be slower as the built in linearspread. this would be especially the case as the linearspread isnt actually doing much cpu-wise; it is just shifting memory around its pins (and doing some multiplications on the fly).
on the other side if you are implementing more cpu intensive algorithms which do not exchange much data over their pins, the performance will be on par. things like parsing xml, calculating fractals, talking to devices etc.
also note that each vvvv node creates a certain fixed overhead, and much of the processor time these days is wasted by waiting for the memory chips delivering their data. so a c# plugin which will replace many links and combine many nodes into a few lines of code probably be much faster than the vvvv patch. i somehow doubt that the break-even will be reached by just combining SetSlice and Stallone into one plugin, but larger node combinations certainly will.
Brilliant thanks oschatz. Just the info I needed.
The custom node addition to vvvv has made me so happy. Flexibility!!! you’ve got to love it.