Point rays, promote parameters

 


Là encore, des exemples de point sop et de point vop sont fournis.


D’une manière générale, les langages compilés sont plus rapides que les langages interprétés. C++ et vex sont compilés, python et mel sont interprétés. La pénalité pour la vitesse du code compilé est le temps qu’il faut pour compiler ; si vous avez déjà souffert en regardant UE4 compiler à partir de la source ou d’autres outils, vous saurez combien de temps cela peut prendre.


Vops est une interface de nœud sur vex comme mentionné précédemment. Chaque fois que vous modifiez un nœud vop, vous modifiez le code, par conséquent, le code doit être recompilé. Houdini le fait automatiquement à la demande, et est en fait assez rapide en ce qui concerne les compilateurs; modifier un seul nœud, vous voyez généralement la mise à jour du résultat en une fraction de seconde.


Cela dit, cela peut s’additionner. Et si vous utilisez des nœuds complexes, le temps de compliation peut passer à 0,5 à 1 seconde. Cela ne semble pas beaucoup, mais si tout ce que vous faites est de déplacer un curseur, cela peut rapidement devenir ennuyeux.


Mais pensez-y; la plupart des programmes que vous utilisez quotidiennement sont compilés, mais peuvent gérer les entrées changeantes sans avoir besoin d’être recompilés. Un programme comme photoshop aura des entrées dans le code prédéfinies pour des choses comme la taille d’un pinceau plus mince, le programme est compilé, maintenant vous pouvez changer la taille du pinceau en temps réel via ledit curseur.


Vous pouvez faire une chose similaire avec vops. Vous pouvez définir certains paramètres comme entrées dans votre code « compilé ». En houdini, ce processus est appelé paramètres de promotion. Une fois cela fait, ce curseur ou cette valeur ne vit pas « à l’intérieur » du code vop, mais à l’extérieur sur le dessus des paramètres vop. Maintenant, lorsque vous modifiez cette valeur, le code ne se recompile pas, vous obtenez des performances beaucoup plus rapides.


Dans le gif animé ci-dessus, vous pouvez voir le décalage lorsque je modifie la constante. Voici une ventilation de ce qui se passe dans ce gif:


  1. Faire glisser la valeur constante est un peu laggy. boiteux.
  2. Déconnecter la constante
  3. Cliquez sur l’entrée de l’attribut, choisissez « promouvoir le paramètre ». Crée un petit nœud de stub.
  4. Faites un clic droit sur le nœud stub (il faut généralement zoomer un peu, petite zone de frappe!), choisissez « exposer l’entrée » pour voir le nœud
  5. Donnez-lui un joli nom, par exemple 'Num rays'.
  6. 'u' pour monter et quitter le réseau vop
  7. Le vopsop a maintenant un nouveau paramètre, 'Num rays'. Faites-le glisser, les performances sont bien meilleures.


Que s'est-il passé? Le réseau vop a été recompilé, mais cette fois, il prend maintenant un argument, 'num rays'. L’argument est externe au vopsop, par conséquent, il n’a pas besoin d’être recompilé lorsque l’argument change. Cela équivaut à de bien meilleures performances. Vous pouvez (et devriez!) exposer autant d’arguments que vous le souhaitez, et vous n’êtes pas limité aux valeurs float ; il y a des interfaces utilisateur de rampe pratiques, des listes déroulantes, des bascules, tout ce dont vous avez besoin.



0 Commentaires