Il y a de nombreuses années, j’ai vu une démonstration d’un déformeur d’onde construit à l’aide de SeExpr. C’était remarquablement bon, mais je ne pouvais pas obtenir un binaire du plugin SeExpr. Cela m’a fait regarder SOuP, qui à son tour m’a fait regarder Houdini. Donc, d’une certaine manière, c’était une chance que je n’ai jamais pu obtenir ce plugin! Vous pouvez trouver un peu de cet historique sur l’entrée de déformeur d’onde de la page Soupe.
La configuration commence par un plan océanique (un générateur de spectre d’ondes conduisant une évaluation océanique). J’ai un sop de contrôle, qui est essentiellement un générateur de poignée, comme un null en maya, que j’utilise pour définir la translation / rotation / échelle de l’effet d’onde.
L’effet d’onde lui-même est finalement une rotation, qui est ici réalisée avec une matrice. Dans vex, vous pouvez définir une opération de transformation avec une matrice, et la multiplication des positions par une matrice déplacera votre géométrie. Pour configurer la matrice pour faire une rotation est assez simple, la fonction rotate() prend une matrice, un axe pour pivoter autour, et une quantité.
Pour la vague, l’astuce consiste à contrôler la quantité de rotation avec un falloff. En mesurant la distance de chaque point par rapport à l’origine, je peux mettre à l’échelle la quantité de rotation de chaque point. De plus, en exécutant cette chute à travers une fonction de puissance, je peux lui faire avoir une rotation très élevée au centre, et se calmer rapidement avec la distance, ce qui rend la rotation ressemble à une torsion nette.
Tout cela se passe autour de l’origine, pas bon si nous voulons une vague en mouvement. L’astuce ici est simple. Lisez la position et la rotation de l’action de commande. Déplacez la grille entière afin que l’endroit où se trouve l’option de contrôle soit glissé vers l’origine. Faites la rotation, puis déplacez toute la grille à son emplacement d’origine, mais maintenant avec la rotation sur le dessus.
That explanation will make sense if you've read the JoyOf Vex pages, but won't if you haven't. Learn Vex, it's good for you. :)
You can tilt the deformer around for more interesting effects:
Or tilt it 90 degrees and make a cool whirlpool (here I also subtracted some height from the points the closer it gets to the center):
Use Houdini for a bit and you'll start to lean on its unix style underpinnings. A common thing is to use $VAR variables to proceduralise workflows. Eg, $OS to refer to the name of the current node, $HIP for the path where the current hip is saved.
Pipelines take advantage of this, so Shotgun or the shell where you launch houdini might set $SHOT or $SEQUENCE, and you can setup render paths to always save to the right location, or an alembic sop to always load the right shot animation.
You can get a list of the variables from Edit -> Aliases and Variables, and go to the variables tab. You can also set variables here too.
BUT BE CAREFUL. If you set variables here, these are saved with the hip, and they can take priority over variables set by the shell/pipeline. How can you protect yourself against this?
If you open a texport pane (click the plus button New pane -> New Pane Type -> Misc -> Texport), you can set variables with setenv and set.
setenv COOLVAR = "woo"
or
set COOLVAR = "yeh"
The difference is setenv is persistent, and will show up in the aliases and variables tab and be saved with the hip, while set is transient, and will disappear when you restart Houdini. Handy to know how to do both.
Note that if you update a variable, Houdini won't automatically cook your network. To force this you run varchange in a texport, which will find all nodes that are using variables, see if they require an update, and cook 'em.
time passes
Well this has proven unreliable in production; sometimes the vars are persistent, other times they're not. Annoying.
0 Commentaires