電子工作

冬休みの自由研究:基板の自作(2) DesignSpark PCBの準備

基板を自作するにあたって、プリント基板設計ツールを使用する必要があります。今回は、 RS Components が公開している回路図面や基板パターンのアートワーク設計できる無料のCADツール、DesignSpark PCB(以下 DSPCB)を使用します。回路設計ツールとしては Autodesk EAGLEも無料版があり、「【アイロン不要】プリント基板を自作してみよう【生基板】」でもEAGLEが使用されているようですが、基板サイズや層数、非商用限定などの制限が多いようなので、今後使用することを考えるとちょっと躊躇してしまいます。(→と思ったら、EAGLE って Fusion360 との抱き合わせなんですね。Fusion360に課金すればEAGLEまで使えて機能無制限と考えると、かなり悩ましい。。。)

ただ、現時点ではDSPCBを使用して基板エッチング用のパターンをどのように出力するのかわかっていないので、ここで困りそうならその時点で方針を考えることとします。

DSPCBのインストール

DSPCBのサイトからインストーラを落とし、インストールします。また、DSPCBを使用するためには DesignSparkのアカウントが必要なようなので、アカウントも作成しておきます。このあたりは特にハマることも無く、サクサクッと進んで無事に DSPCB の起動までできました。

電子工作

冬休みの自由研究:基板の自作(1) 材料の用意

電子工作は小学生の頃からやっていて、なんやかんやで電子回路の設計とか実装とかの勉強もやってきていたものの、そういえば今まで自分で電子工作用の基板を作ったことなかったなぁということに気づいたので、人生で一度くらいは自作してみることにしました。最近はネットを探すとこういう情報も豊富にあるので、とても助かります。今回は

を参考にさせていただきました。

材料の用意

無水エタノール・塩・クエン酸は自宅にあるものを拝借します。それ以外は

  • 生基板
  • フラックス
  • オキシドール
  • アセトン
  • スチールウール
  • 油性ペン
  • エッチング用紙皿
  • スポンジ

を用意しました。アセトンは薬局でも在庫が無かったのですが、マニキュアなどを除去するための強力除光液としてアセトン100%のものがあったので、それを購入しました。普通の除光液を使うとどう影響するのかはわからないです。その他ちょっとしたものは100均で購入し、全部で大体3000円くらいで揃います。

明日以降、用意した材料を使って基板の自作をしていきます。

コンピュータ

bind を Docker で動かす

bind を Docker で動かすようにしたので作業メモ。

Dockerfile と初期イメージの作成

$ mkdir docker_bind
$ mkdir docker_bind/conf

$ cat docker_bind/Dockerfile
FROM centos:centos7
RUN yum install -y bind bind-utils && yum clean all
EXPOSE 53/udp
CMD [“/usr/sbin/named”, “-c”, “/etc/named/named.conf”, “-u”, “named”, “-g”]

$ docker build -t bind ./docker_bind/

$ sudo docker run -it bind /bin/bash
[root@148a28083361 /]#

named.conf を取得

$ sudo docker cp 148a28083361:/etc/named.conf docker_bind/conf/named.conf

リポジトリ作成

$ cd docker_bind
docker_bind$ git init
docker_bind$ git add Dockerfile
docker_bind$ git add conf/named.conf
docker_bind$ git commit -m ‘docker_bind initial import’
[master (root-commit) be44df1] docker_bind initial import
2 files changed, 66 insertions(+)
create mode 100644 Dockerfile
create mode 100644 conf/named.conf
docker_bind$

named.conf 編集

docker_bind$ git diff conf/named.conf
diff –git a/conf/named.conf b/conf/named.conf
index 89338bd..3027c20 100644
— a/conf/named.conf
+++ b/conf/named.conf
@@ -10,15 +10,18 @@
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html

options {
– listen-on port 53 { 127.0.0.1; };
– listen-on-v6 port 53 { ::1; };
+ listen-on port 53 { localhost; 192.168.0.0/24; };
+
+ // listen-on-v6 port 53 { ::1; };
directory “/var/named”;
dump-file “/var/named/data/cache_dump.db”;
statistics-file “/var/named/data/named_stats.txt”;
memstatistics-file “/var/named/data/named_mem_stats.txt”;
recursing-file “/var/named/data/named.recursing”;
secroots-file “/var/named/data/named.secroots”;
– allow-query { localhost; };
+ allow-query { localhost; 192.168.0.0/24; };
+
+ forwarders { 192.168.0.210; };

/*
– If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
@@ -56,6 +59,15 @@ zone “.” IN {
file “named.ca”;
};

+zone “example.net” {
+ type master;
+ file “/etc/named/example.net.zone”;
+ allow-update {
+ localhost;
+ 192.168.0.0/24;
+ };
+};
+
include “/etc/named.rfc1912.zones”;
include “/etc/named.root.key”;

conf/example.net.zone と conf/example.net.rev には通常おこなうようにホスト情報を記述する。

bind 起動

ネットワークインターフェースが複数ある場合、インターフェースを指定しないと下記のようなエラーになる。

docker: Error response from daemon: Conflict. The container name “/bind” is already in use by container “a75d2e62ccde7a0bc3fb07be84fd393607f1286fdacaafa828b06ed2789a32d7”. You have to remove (or rename) that container to be able to reuse that name.
See ‘docker run –help’.

私の環境では KVM も動かしている関係で複数のインターフェースが認識されるため、必要。

$ sudo docker run -d -e TZ=’Asia/Tokyo’ -p 192.168.0.34:53:53/udp -v /home/neo/Documents/docker_bind/conf:/etc/named –restart always –name bind bind

CG, USD

USD のビルドの進捗を確認する

以前、CGWorld の記事で USD のビルドの進捗がわかり辛いということを書いたのですが、最近のバージョン(?) では ${INSTALLDIR}/build/USD/log.txt にビルド時の stdout(stderrも?) の内容が出力されるようです。

そのため、tail を使ってこんな感じで進捗の確認ができます。

[chiyama@docker USD]$ tail -f log.txt
[ 85%] Building CXX object pxr/usd/lib/usdGeom/CMakeFiles/_usdGeom.dir/wrapBasisCurves.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdSkel/CMakeFiles/usdSkel.dir/cacheImpl.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdLux/CMakeFiles/usdLux.dir/diskLight.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdShade/CMakeFiles/usdShade.dir/debugCodes.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdUtils/CMakeFiles/usdUtils.dir/coalescingDiagnosticDelegate.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdShade/CMakeFiles/usdShade.dir/input.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdUtils/CMakeFiles/usdUtils.dir/debugCodes.cpp.o
[ 85%] Building CXX object pxr/usd/lib/usdUtils/CMakeFiles/usdUtils.dir/dependencies.cpp.o

CG, Maya

Mayaのノードで数学の演算を実現する

Maya Advent Calendar 2018 の記事です。@rt_sporty さんがリグっぽいネタ無いですかね~?とかつぶやいていた気がするので、リグっぽいけど関係ありそうな無さそうなネタを投下します。

リグを組むとき、sin とか cos とか abs とかベクトルの計算とか多用しますよね。

でも、Expression で書くと遅い。そしてダサい。ノードベースなんだし全部ノードで組みたいじゃん!って思うのが人情です。

組みましょう。

足し算, 引き算

まずは手始めにここからいきます。これはそのままノードがあります。数値もベクトルもこれで行けます。

掛け算, 割り算, a の b 乗

四則演算を揃えます。

うむ。チョロいチョロい。

逆数

これは割り算がそのまま使えます。

絶対値

これは Maya 上にはズバリそのもののノードはありません。どうしようか。。。ということですが、0 からの距離と考えれば簡単です。

floor

アニメーションカーブと、 Pre Infinity, Post Infinity を使えば実現できます。
アニメーションカーブは通常は input に時間が入力されますが、このように任意の値を入れることもできます。この辺りは結構使うテクニックですね。

Mod

mod(a, b) = a – b * floor(a / b) なので、既にあるノードを組み合わせることで計算できます。

三角関数

これはちょっと困りものです。そのものズバリなものも無いですし、既存のノードで代替するのも難しそうです。展開して近似とかもめんどくさいし重たそうです。
しかたないのでアニメーションカーブで近似します。Pre Infinite/Post Infinite を使えば一周期だけデータを用意しておくだけで対応できます。厳密な計算をする場合はもうちょっとちゃんとやる必要があるんでしょうが、リグ用とかならこれで十分かなと。sin, cos, asin, acos はこの方法で対応できますね。

tan は sin/cos で計算できます。

Log

これも良い感じに軽く計算できる方法が思いつかないのでアニメーションカーブで逃げます。ある程度の精度とデータの軽さを両立するために、キーフレームの打ち方を工夫したりして悪あがきします。あと、余り使わなさそうな部分は Linear で外挿しています。

これくらいあれば必要な演算は大体できるのではないでしょうか。(ゼロ除算は全く考慮してないですが~;;)

CG, USD

AL_USDMaya

PIXAR 標準の USD Maya プラグインとは別に、AnimalLogic が公開している AL_USDMaya があります。個人的には、Maya を中心に据えて USD ベースのパイプラインを組むのならこちらが本命じゃないかなと思っています。あんまり確たる根拠は無いですが。そこは勘ですよ勘!!セブンセンシズですよっ!

PIXAR 実装は Scene Assembly として USD の情報を扱う実装になっていますが、AL_USDMaya はそのあたりの扱いを自前でゴリゴリと頑張っているようです。.usd ファイルを読み込むと AL_usdmaya_ProxyShape ノードが作成され、単一のノードとして表示されるのですが、ビューポート上でオブジェクトをピックするとそこまでの階層がシーン中に現れて操作できるようになります。

このプラグインを使用している様子は “AL_USDMaya Layout and Animation Workflow” で見ることができるのですが、結構独自のツールを作って実現している機能が多いようなので、オープンソースになっているプラグインをビルドすればこれができると思ってしまうのは甘い感じです。そもそも、Hydra を Maya 上で使ってるっぽいことを言ってるんですがこれは一体。。。?

あと、手元でも環境を作ってみてはいるものの、まだ完全に動くようにはなっておらず試行錯誤しているところです。特に VP2 との相性が悪い様でオブジェクトのピック周りの問題が解決していないです。この辺りは PIXAR 版とは違って自前でゴリゴリ頑張っている弊害ですね。

もしかしたら Luma Pictures の outliner を併用すれば PIXAR 標準 Maya プラグイン(+ゴリゴリ自前開発)でも必要なことはできるのかもしれないですが。。。。このあたりは引き続き要調査です。

CG, KATANA

GroupStack

作業をする際、多くの種類のマテリアルをアサインしたり、ショットシーンで大量のアセットを読み込んでそれぞれに Lookfile をアサインしたくなります。
これまでやっていたように、一つ一つ MaterialAssign ノードなどを作成してそれを繋げてもできるのですが、ノードグラフが無駄に長くなりますし、管理も煩雑になってしまいます。

このような問題に対応するため、GroupStack ノードが用意されています。

たとえば、下図のように複数の MaterialAssign が連なっているケースを例にしてみます。

これでも要求は満たしていますが、見た目も良くありませんし、MaterialAssign ノードを増減するために Node Graph を更新しなければいけないので管理も煩雑です。

そこで GroupStack ノードを作って MaterialAssign ノードを選択し、Shift+中ボタンクリックでドラッグアンドドロップします。


すると、GroupStack ノードに MaterialAssign ノードの情報が登録されました。GroupStack ノードを元々あった場所に繋げると、元と同じ状態になります。

GroupStack ノードは一つのノードに対して同じ種類のノードを複数登録できます。反面、異なる種類のノード(MaterialAssign と LookfileAssign とか)を一つのノード中に含めることはできないです。また、登録できるノードの種類は一入力一出力のものに限られます。このあたりは、ノードの性質を考えれば妥当な仕様ですね。

CG, KATANA, USD

USD for KATANA

USD のリポジトリには KATANA 用プラグインも含まれています。ビルドも難しくなく、KATANA プラグインビルド用のオプションを追加して USD をビルドするだけですんなりいけます。

ビルドができたら、KATANA が USD プラグインを認識できるように起動スクリプトに手を加えます。私はこのようにしました。

#!/bin/sh

export KATANA_ROOT=/opt/Katana3.0v6
export DEFAULT_RENDERER=arnold
export USD_INSTALL_ROOT=/opt/usd

export KTOA_ROOT=/opt/KtoA-2.2.1.0-kat3.0-linux
export "KATANTA_TAGLINE=With KtoA 2.2.1.0"

export KATANA_RESOURCES=$USD_INSTALL_ROOT/third_party/katana/plugin:$KTOA_ROOT
export KATANA_POST_PYTHONPATH=$USD_INSTALL_ROOT/third_party/katana/lib:$KATANA_POST_PYTHONPAT

export PATH=$KATANA_ROOT/bin:$KTOA_ROOT/bin:$PATH
export PYTHONPATH=${KTOA_ROOT}/python:$USD_INSTALL_ROOT/lib/python:$PYTHONPATH

$KATANA_ROOT/bin/katanaBin "$@"

KATANA を起動すると、PxrUsd から始まる名前のノードが選べるようになっています。

PxrUsdIn でサンプルシーンを読んでみました。
※ZUp なようなので、TransformEdit で X 軸に -90° 回転を加えています

これで、KATANA でも USD を使用することができるようになりました。

CG, USD

USD Maya plugin でできること・概要

Maya での USD 対応についてこれまで大きな勘違いをしていたので、改めてまとめます。ここでは USD のアーキテクチャというより、実際の実装として何ができるのかに注目をします。

PIXAR 標準の USD プラグインでは、様々な方法で USD シーンファイルを Maya に読み込むことができます。

・Import(Open)
・Reference
・Scene Assembly

上の二つの方法で読み込んだ場合、結局は Maya のシーンデータとして扱うだけで、幾ら .usd ファイル内でアセットが分割して管理されていても Maya 上では巨大な一つのファイルを扱っているのと変わりがありません。そのため、Maya では .usd ファイルの入出力はできるけれども一番美味しいところは実質的に使えないのかなと思って調査を打ち切ってしまいました。

つまり、シーンファイルとして読めて必要な情報は再現できるけれども、その情報を保持したまま出力することができないという勘違いをしてしまったわけです。

最も重要だったのは Scene Assembly として読み込むことができることでした。Scene Assembly を用いることで、必要のない時はアセットを一つのノードとして扱うことができ、内部を編集したい場合は展開して操作することができます。

これを用いることで複数の .usd ファイルを読み込んで複雑なアセットを構築し、その構造を維持したまま .usd ファイルとして出力することができます。
少なくとも、この点に関しては Maya+USD で実現できるということになります。そのため、Maya で USD の恩恵を受けることができないというのは誤りです。非常に大きな恩恵を受けることが出来そうです。

Maya+USD を使ってトータルでどのようなことができるかは “05 USD at ALA – Pixar USD Maya plugin” を見るのが早そうです。こちらは Animal Logic の AL_USDMaya と luma pictures の Outliner(usd-qt?) を使用したフローの解説になるため今回使用した純正の実装とはまた別ですが、Maya 上でこんなことができるんだという参考になるかとおもいます。

※こちらは PIXAR 純正の USD Maya プラグインを使用した例でした。。。AL_USDMaya と outliner を使用した例は AL_USDMaya Layout and Animation Workflow でした。訂正記事中で訂正をおこなうという失態、、、、もうダメだ。。。(´・ω・`)

CG

“USDって結局何なのよ?”の内容に大きな誤りがあるかもしれません

(追記)訂正記事を書きました。やはり私の勘違いで、Maya でもかなりの恩恵を享受できそうです

先日、”USDって結局何なのよ?” にて USD の概要についてご説明したのですが、ここでとても重大な間違いがあるかもしれないことに気づきました。まだ詳しく内容を確認していないので今後確認をしてまとめていきますが、

USD という基盤技術を使うことでコンカレントパイプラインを構築することができますよということでプレゼンでもかなり力を入れて説明がされるところなのですが、残念なことに

通常、我々はそのまま享受することはできません。

(中略)

PIXAR は自社で Presto を開発して対応していますし、AnimalLogic は AL_USDMaya を開発して Maya 上で対応しています。コンカレントパイプラインという思想を実現するための強力な基盤技術として USD を使用するのです。

この部分、特に Maya 対応に関して私が根本的な勘違いをしていて、全く事実と異なる内容を書いていた可能性が高いです。この部分が間違っていると Maya における USD の実用性に対して全く違う結論が出てしまうので、改めて調査をして記事にまとめていきます。

そのため、この部分の判断については一旦白紙とし、保留していただけるようお願いします。