It will provide you with a base-line to measure variations of different approaches and their suitability for your needs as well as provide insight to the problem beyond your initial assumptions. I always recommend prototyping the simplest and most straight-ahead solution first - even if you know it will not meet the requirements. You may be building it just for yourself, but if you are going to be using a setup a lot and/or it is critical to a project, it’s worth taking the time to define your performance requirements and create your test data.įirst Pass - Putting the “Pro” in Prototype But the better and more varied your test data, the more reliable your picture of the performance of your algorithm and the subsequent decisions based on it will be. At worst, you can create your own test data and swap it out with the real stuff when it’s available. Ideally this test data will span the simplest to the most complex scenario and cover a wide set of variations. Then I gather test data and inputs representative of what it will have to operate on. The machine resources it’s expected to work within.
SIDEFX HOUDINI 16 SOFTWARE
Although written from the perspective of an artist/TD working in Houdini within the Sop context, most principles should apply to Houdin’s other contexts, and broadly it should be useful in creating algorithms in other software or programming languages.ĭefine Required Performance and Gather Test Dataīefore I start to develop any algorithm, I define what the appropriate levels it needs including:
In this article I outline my process of how I prepare and optimise my algorithms in Houdini to hit performance requirements. If your algorithm cannot stay within a machine's resources whilst evaluating, it will frequently overwhelm the machine causing work to come to a halt.
For example, if an artist needs fast feedback in order to interact fluently with it, an Artist will not be able to use it effectively if it takes too long to reevaluate or cook.ĭo it within the available machine resources. For example, if your algorithm makes procedural rocs, it needs to be able to create geometry of a certain density to hold up.Įvaluate fast enough. However, it may not always do it at the appropriate scale, within an acceptable time, or within the available machine resources. Sometimes we create an algorithm that has the desired output when given a valid input. This reality can feel distant as we work in Houdini’s environment concentrating on aesthetics and solving our problems, but to think of our graph of nodes and lines of VEX as algorithms can help us improve our workflow, setups and productivity. An algorithm is an umbrella term used to describe any process or set of rules that can be followed - usually a computer. These sets of rules and processes are algorithms. I think the true power of Houdini is that it allows an artist to solve technical problems and leverage technical processes to make beautiful things and solve complex problems from a high level.Īs we connect nodes, write VEX in wrangles or wire Vops together, we are creating a set of instructions or rules, that given a set of inputs - for example geometry data or user input - output a result.
0 kommentar(er)
