Houdini

今回の話は、Linuxユーザのためだけですので、あしからず。 なにか間違った値を入れてしまったりして、メモリが右肩上がりに上昇し、メモリをフルに使いきり、パソコンが動かなくなるということは、時々あるでしょう。会社のマシンは128GBですが、まれになります。 そんなときは、 CUIモードで対処したり、同僚のマシンから操作してもらったり、泣く泣く電源を落としたりと、みなさんもこんな経験はたくさんあるでしょう。 残念ながら、いろいろセーブしてなくて、「ごめんなさい」を連呼しながらEscを連打しても、ダメなときはダメです。 そうなる前に、問題のプロセスを強制的に終了させましょう。 というわけで、今回はBashを調べてみました。基本Linuxで仕事してますが、Bashやコマンドは避けてきたので、何か間違ってる点や、もっといい方法がありましたら教えてください。 プロセス一覧から探しだして、kill まずは、ベーシック。 プロセスを表示するコマンドはps。 みなさんは、どういうオプション使っているかはわかりませんが、自分はいつもこれ ps aux 端末内外のプロセスを表示して、CPUとメモリの使用量も表示させる。 さらに、Houdiniのプロセスだけを表示させる ps aux | grep houdini-bin 表示された結果から、見つけた対象のプロセスIDを殺す。 kill -SEGV 123456 このSEGVは、ホント助かりますよね。Windowsにはないらしいですが、可哀想に。 これで、プロセスが死に、$houdini_tmpのなかに、シーンファイルが、保存される。まっ、たまに保存が失敗することがありますが。 さて、ここまでは普通の手順。もう少し、賢くやってみましょう。 すべてのHoudiniプロセスを、kill まずは、今あるHoudiniのプロセスすべてをKillします。 kill -SEGV `ps aux | grep [h]oudini-bin | tr -s ' ' | cut -d ' ' -f 2` houdini-binは、houdiniの立ち上げ方によって、名前変わるので、各自変えてください。ちなみにhoudini-bin はターミナルで、houdini_sourceをセットし、houdiniとタイプし起動したら、そうなります。 なので、それらを考慮するなら、複数指定しときましょう grep -e [h]oudini-bin -e [h]indie-bin []を使う理由は、プロセスにgrep自身が表示されないようにするためです。 ps aux | grep [h]oudini-bin 実行すると、こんな感じのものが返ってくると思います。 shohei 9042 4.7 1.5 5985364 2067844 ? Ssl 10:54 11:17 /opt/hfs16....

New Network Editor さて、賛否両論ありそうなこれ。見た目は可愛くなりましたね。 そして描画速度も速くなりました。Pythonでノードを何千と作ったり、AlembicのHierarchyを保持して展開するときなど、大きな差が出そうです。 あのノードの形、可愛くないから使いたくないとか、デフォルトを変えたいって人はいるでしょう。僕はノードを組む上での自分なりのルールがあるためノードの色が最初から付いているのは非常に不便でデフォルトを変更してます。 そこで、どうやってカスタマイズするかを紹介します。 書き方は、インストール先の$HFS/houdini/OPcustomizeに記述されてるので覗いてみてください。 Sample 文頭がopdefaultcolorで始まるのが色の設定。 文頭がopdefaultshapeで始まるのが形の設定。 では、$HOME/houdini16.0/OPcustomizeというテキストを作って編集してみましょう。 まず形から変更してみましょう。 SopのMergeを丸にするには opdefaultshape Sop merge circle 形の種類ってヘルプのどこかに書いてあるんですかね？5分位探してなかったのであきらめました。 そこでPythonで選択したのノードの形を取得してみます。 import hou n = hou.selectedNodes()[0] ns = n.userData('nodeshape') ds = n.type().defaultShape() print(ns, ds) userDataに入ってるのは、NetworkViewで変えた形で、defaultShapeは名の通りです。 続いて色です。個人的に勝手にノードに色がつくのはうっとおしかったため、すべての色の設定をクリアしました。 opdefaultcolor -c これで、Houdini Pathの順番で、このファイルより前で設定されたopdefaultcolorはClearされます。 形の設定をクリアするには、同じく-cです opdefaultshape -c 色をつけるには opdefaultcolor Sop rop_geometry 'RGB 0.451 0.369 0.796' ノードの名称、色とか形を調べるのはメンドイんで、ノードを選択して実行すれば分かるようにして、作業しました。 import hou ns = hou.selectedNodes() for n in ns: nn = n.type().nameWithCategory() cd = n.color() ds = n.type().defaultShape() us = n....

久しぶりのWrangle回です。 個人的にHoudiniにおいて、よく使う必需ノードは、For LoopとAttribute Promoteです。これらがないと仕事ができません。もちろんWrangleも絶対使います。 特にFor LoopはHoudiniを象徴するようなノードだと勝手に思ってます。ある処理を考え、それを他のものにも同様な処理を施す。まさにProceduralに作業する上で必要不可欠なものです。 しかし！ForLoopは処理に時間がかる時が大半です。なぜなら、 すべてのノードがマルチスレッド処理されるわけではありませんし、１つ１つのピースやグループを同時にではなく、順番に処理するため遅くなってしまいます 。 シンプルな例を元に解説していきます。 Sample File : wrangle_03.hiplc (15.5.607 linux-x86_64-gcc4.8) Voronoiで割った1つ1つのピースのサイズを測ろうと思います。あまりにも小さいピースはSimulationに参加させない様にさせるとか、大きいやつはもう一回砕こうとかで使うことがありますね。 ピースのサイズを求めるために、まずMeasureで個々のPrimitiveの面積か体積を測ります。続いて、For Loopで各ピースごとが持っている各Primitive面積の総和を出します。これが、ピースのサイズとなります。 本題です。Wrangleでやってみます。 nuniqueval() uniqueval() findattribvalcount() findattribval() この関数がミソなんでHelpは読んでください。 string piece_attr = "name"; int num_piece_attr = nuniqueval(@OpInput1, "prim", piece_attr); addattrib(0,"prim","area_sum",0.0); for(int i = 0; i < num_piece_attr; i++){ string uq_val = uniqueval(@OpInput1, "prim", piece_attr,i); int num_prim_piece = findattribvalcount(@OpInput1, "prim", piece_attr,uq_val); int prim_piece,ii =0; float per_area,area_sum =0.0; for(ii=0; ii< num_prim_piece; ii++){ prim_piece = findattribval(@OpInput1,"prim",piece_attr,uq_val,ii); per_area = prim(0,"area",prim_piece); area_sum += per_area; } for(ii=0; ii< num_prim_piece; ii++){ prim_piece = findattribval(@OpInput1,"prim",piece_attr,uq_val,ii); setattrib(0, "prim", "area_sum", prim_piece, 0, area_sum, "set"); } } For Loopでやった処理を分解しながら説明していきます。Run OverはDetailです。...

お久しぶりです。そこそこ忙しくて、ブログを書くのを怠ってました。 今回の内容はビギナー向けですが、非常に重要な考え方なので紹介しようと思います。Time Dependent Cookについてです。 Time Dependentという言葉は、Houdiniを使ってないと聞き慣れないかもしれませんし、気にしたこともないかもしれません。 サンプルファイル (Fedora21, Houdini15.0.393, linux-x86_64-gcc4.8) What is Time Dependent？ ではTime Dependentとはなんでしょうか？直訳すると「時間に依存」です。 [Time Dependent Cook:Yes]はフレームが変わるとcookする。逆にNoの場合は、 時間に依存してない。つまり、フレームが変わってもcookしません。 1回cookすれば、それを使いまわします。単純な話、レンジが100Fの場合でYesなら100回cookします。Noなら1回のcookですみます。 これを気にせずアセットを作るなんてことは、トーシロー、素人です。一昨日来やがれ。言い過ぎました。 このTime Dependent Cookの情報をどうやって知るかというと、ノードをミドルクリックすれば一番下に出てきます。SOP、DOP、OBJ、COP、CHOP、SHOP、ROP全てのノードで出てきます。（ん？ROPのTime Dependent Cookってなんでしょうね？） また、会社の人に教えてもらいましたが、ノードを光らせてどのノードがそうなのかを識別させることもできます。 どうして重要なのか？ 続いて、活用方法を紹介したいと思います。Houdini始めたら誰しもが使うScatterを使って解説します。 例えば、この歩いている人間にPointを発生させたいとします。普通にScatterすると毎フレーム違う場所に発生してしまいます。これを回避するには、ScatterのパラメータにあるGenerateをIn Texture Spaceにします。一気に処理が重くなりますね パラメータを変えるまでは120fps出ていたのに、 10fpsも出なくなってしまいました。致命的ですね。 速くするにはScatterするのを1回だけにして、後からPositionを動かせばいいのです。TimeShiftでScatterのソースを止めます。そして、ScatterのOutput Attributesから2つを有効にします。これはScatterしたPrim NumberとUVを保存してくれます。 保持したら、最近ついた新しいノードをつかいます。Attribute Interpolateです。1st InputにScatterしたPointをさして、2nd Inputに動いてる人をさすだけPointが動きます。 Attribute Interpolateなかったころ、どうやっていたかというとVopのPrimitive Attributeを使っていました。ちなみにですが、sourceのPrim NumとUVはIntersect Vopでもとれます。 Pointが動いたということで、どれくらい速くなってか試してみましょう。一番最後にTrail Sopをさして、Compute Velocityをvを計算させてみます。毎フレームScatterする場所が違うと、vもおかしな値が入ってしまうので、正確に動作しているかも判断できます。 では、Scatterを毎フレーム計算させた場合です。 続いて、1FだけScatterしたものです。 一目瞭然ですね。処理も速いですし、Velocityもうまく計算されています。 Attribute Interpolateを使うと速くなるよということが言いたかったわけではありません。何が言いたかったかというと、重い処理を極力少なくすれば速くなるよということです。 それを判断する材料の1つがTime Dependent Cookということです。 特になにかしらのエミッターを作るときに、非常にお世話になります。シミュレーションは重いです。エミッターも重いとなるとトライアンドエラーの回数が減ってしまいます。 まとめ 出来る限り重い処理を少なくするためにはどうすればよいか。 今回の例だと 「動いているものにScatterして、Point群を動かす」を「Scatterして動いているものにくっつけ、Point群を動かす」 に変えました。言葉の並び替えみたいなようなものですが、この考え方が重要です。頭の中で、今ある仕組みを文にして、並び替えてみてください。 ただ単純にノードをつなぐ順番を変えるだけでも、速くなるかもしれません。Performance MonitorやTime Dependentを表示させて、どこがネックになっているか見てみましょう。 今作っている仕組みには、これ使えないなと思ってるあなた！本当にそうでしょうか？固定観念を捨てて、違った角度から考えてみてはいかがでしょうか？なぜなら、あなたが使ってるソフトはHoudiniなんです。限界を作ってるのはあなた自身かもしれません。信じるか信じないかはアナタ次第です！笑

レゾをそんなに高くしなくても、手軽にコントロールでき、形を崩しいい感じのShapeを作るを目的にしたRnD Houdini歴5年目にして、やっとSopレベルもそこそこになってきたので、最近Dopに力を入れ始めました。データの流れを考えながら構築していったり、Sopでの知識は必ず役に立ちますし、データを可視化できるので、今までもっていたMicroSolverに対する苦手意識がなくなりました。 FumeやらPhoenix FDにvorticityというのがついてるのに、Pyroにはないのとお思いの方、朗報です。 自分で作れます。 あのプラグイン達はBlackboxになっているので、どのような手法をとっているかは伺えしれませんが、結果的によければOKです。 普通に煙をエミットするとのっぺりとした部分ができてしまいます。 これを崩すにはTubulenceをかけたり、Pyroの場合はDisturbanceを使ったりします。Turbulenceの使い方を間違えると、エミットしてから時間が立っているとこにも強くかかってしまうと、ダサい煙になってしまいます。また、Disturbanceも強くかけ過ぎると、ボロボロになってしまいます。コントロールが難しいです。 Vimeoにあげた動画の、最初の煙はエミットされてからすぐに、モコモコしてるのが分かると思います。これが、求めていたものです。コントロールも結構簡単です。 作り方は、、、いくつかのMicroSolverとSop Solverの組み合わせですｗ Vorticleを作って、渦度が高くないところも高くして影響を与えるみたいなことをしてます。 （Divergenceをいじってもこんな結果ができるはずです。） 手軽に自分で作れるこそが、Houdiniの強み