Harayoki's

  

poser links


poserの調子がかなり悪いものの、
SL含め、他アプリを全部落としていると
安定して動きがちなようです。
リソースを食いまくって遅くなってるだけなのかな。
そういえばDAZ{StudioもSLと同時立ち上げしてるとかなり重かったし。
やっぱりよくフリーズしてしまいますが、がんばれば使える、という感じです。


さて、poser7にてctrl+Dの地面に下ろすというショートカットを使い
完全に地面と同じ高さでアニメするようにしたbvhをSLにアップしてみました。


四つんばいポーズです。
poser上でいじくって遊んでたらこんな変な色になりました。アバタの色はbvhファイルに書き出されないので平気なはず…


平気でした。この後、優先度最大の4でアップロードしなおしました

今度は空中に浮かなくなるでしょうか？  続きを読む

poser links




デフォルトキャラのサイモンさんを消すと反応なくなります。
すでにSL用に作ったファイルを編集して何かしようとしても固まります。
VISTAだからかなあ。

#2で書いたように設定ファイル消してもダメです。
また再インストールか…。

困っちゃうなあ、もう。  

animationControl links


例によってlslWikiからですが
座っているときにカスタムアニメ(優先度が高くないもの)を再生するときには、
デフォルトで再生されるアニメをとめてからにしたほうがいいよ！、と書いてあります。
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llStartAnimation

To animate someone sitting on an object, it's a good idea to stop the generic sit animation first (llStopAnimation("sit")) unless the new animation has a higher priority than the default sit.

いっぽうセカンドライフ覚書さん - 1L$で入手できる、アニメーション自動販売機
で紹介されている自動機を購入して、

これです

中のscriptを見てみると(ソースが見えるってすばらしいですね)
llStopAnimation("sit")だけでなく
llStopAnimation("sit_generic")とも書いてあります。
sit_genericとは一般的な座りポーズといった意味でしょうか。

これは、座ったときにsitだけでなく、場合によってはsit_genericも再生される事があるよ、
そのアニメの再生も止めておかないとね、という事だと思うのですが…


sit


sit_generic

動作含めて全く同じに見えます…？


調べてみると、他にも座り系のポーズは色々あるようですね。  続きを読む

animationControl links


見た目が面白くないエントリー投稿期間チュウのharayokiです。

前のエントリーなどに書いたとおり、
現在、１つのオブジェクトに座った数名のアバタを同時に
アニメさせたりコントロールする事に取り組んでいます。
これがなかなか敷居が高い…。
lslって不便だなあ、と思いつつも
がんばればできそうなのでがんばっています。:-)

今回はllStartAnimationについてです。

llStartAnimationはアバタにアニメーション再生をさせる命令ですが、
不思議なことに引数がアニメデータの名前しか取らず、
対象となるアバタのキー値などを指定しません。
これは、scriptでのアニメ再生には事前にアバタにアニメ再生許可を取る必要があり、
その命令(llRequestPermissions)では
アバタをキー値で指定するため、scriptはそのアバタを記憶しており
lLStartAnimationおよびllStopAnimationでは引数にアバタの指定がいらない、
…とこういう事のようです。

変な説明ですが、llRequestPermissionsで指定したアバタをアニメさせたりアニメをとめたりすることができる、という事です。


それは結構なのですが、これってつまり…
同時には1人のアバタしかアニメ制御できないという事になりますね。
その都度llRequestPermissionsを別のアバタ
に対してやり直せばいいのでしょうが…。
やってやれなくなさそうなものの、なんだか処理がアバタ管理で大変な事になりそうです。

ここで考えました。
アニメ再生許可を得たアバタのキー値のメモリ上の記憶はプリムごとにされるのでしょうか？
それともscriptごとなのでしょうか？
もしscriptごとに記憶されるのであれば、プログラムをうまく分散させることで
複数アバタのアニメコントロールが見通しよくできそうです。
(パーティクル放射などはscriptごとではなく
プリムに対してひとつですが、これはなんとなく大丈夫な気がします。)

ということで実験です。


この適当なプリムには、
タッチするとアニメを3秒ごとに計5つ切り替えて再生するscript１つと
座るとアニメを同様に5つ再生するscript１つがくっつけられています。
(ソースはエントリーの最後にあります)

この状態で2人のアバタをアニメ制御させることができるでしょうか？

結果は動画で確認どうぞ。  続きを読む

イスに座った複数人をまとめてアニメさせる。。。と言うことをやってみたく。
そこを目標としていろいろ挑戦してるのですが、
Poserを使った固定ポーズ作りもちょろちょろっと、がんばってみることにしました。

アニメーション作成はまだまだつらいです。専門スキルですし。
しかし固定ポーズならけっこういけそうなので、そちらを繰り返しやってみる事で
まずは操作方法やアップロードまでの流れなどになれて、
技術的なスキルを磨いておこうと思います。
それだけじゃアニメーションのセンスはつきませんけどね。
まあ、とりあえず。

まず、ポーズを作ってみました。


いじけ座りのポーズです。

DAZ|Studioをいじった時にいろいろ基礎知識がついたのか
Poserが使いやすいからなのか、
サクっと作れてしまいました。

これをbvhファイル(アニメーションデータファイル)で書き出します。
まちがって総フレーム３０のまま書き出したので
ファイルサイズが大きくなってしまいました。


そのbvhファイルをSLのアップロード画面でプレビューします。
うまくいきそうです。
プライオリティは普通最高にするのでしょうけど、最低の4にしておきました。
(それとも最高が４でしたっけ？→追記：４が最高の優先度でした)
とにかく他のアニメと重ねた時の挙動をつかみやすいように偏った値にします。
また、最後のフレームでループする設定にします。
手は握った状態、顔は退屈な表情に設定します。  続きを読む

しました(笑)

ゴミエントリーですいません；

※ソラマメさんおめでとうございます  

sit2avator links

#2の下の方で述べた変な挙動の説明です。

リンクされたプリムそれぞれでCHANGED_LINKを扱っている時の
動作ログ(llSayさせた情報)をもう一度みてみると…

◆Harayoki Kuhnが青いプリムに座る
ObjectBlue: ObjectBlue sit Harayoki Kuhn
ObjectRed: unsit
ParentObjectWhite: unsit

◆nanasi gonbe(仮名)が白いプリムに座る
ObjectBlue: ObjectBlue sit Harayoki Kuhn
ObjectRed: unsit
ParentObjectWhite: ParentObjectWhite sit nanasi gonbe

◆nanasi gonbe(仮名)が立ち上げる
ObjectBlue: ObjectBlue sit Harayoki Kuhn
ObjectRed: unsit
ParentObjectWhite: unsit

◆nanasi gonbe(仮名)が赤いプリムに座る
ObjectBlue: ObjectBlue sit Harayoki Kuhn
ObjectRed: ObjectRed sit nanasi gonbe
ParentObjectWhite: unsit

このように、アバタが座った(立ち上がった)対象以外のプリムでも
CHANGED_LINKイベントが発動しているのが分かります。
そこではllAvatarOnSitTargetの値は前のままです。

なんだこれは？なんだか、余計なイベントが起こってるなあ、と思ってしまうのですが
よく考えればCHANGED_LINKは"リンクがチェンジした"というイベントなので、
意味合い的にはコレであってる事がわかります。

しかしながら

changed(integer che){

    if(che & CHANGED_LINK){

        key av = llAvatarOnSitTarget();

        if(av!=NULL_KEY){

        	//アバタが座った

        }else{

        	//アバタが立った

        }

    }

}

という感じのscriptはアバタが座った/立ったの判別によく使われているので
"誰も座ってなかったのに、アバタが立ち上がったイベントが取れた"
とか
"アバタがすわったままなのに、再度座ったイベントが取れた"
という風に感じてしまうわけです。

リンクされたプリムそれぞれでsit系のイベントを扱う場合、
llAvatarOnSitTargetの値がNULL_KEYか否かだけでなく、
前と状態が変化しているかどうかまでみてやらないといけないようです。
さもないと予期せぬ動作をするscriptを書いてしまうかもしれません…注意ですね。

ちなみに、自分が先ほど作ったSitAvManagerModule
(子プリムたくさんにイスプリムがある時などに威力を発揮するマネージャ…説明しづらい)は
その辺りの事もケアしてscriptが書かれています。

次のエントリーあたりでは、このモジュールを使ってイスに座ったアバタ全員を
アニメさせるような事をやってみます。  

sitModule links


先のsitマネージャモジュール(いい名前思いつかず…)のサンプルを作りました。
2つの子プリムに座ったアバタ2名を親プリムから操作します。

まず、前準備です。


3つのプリムはリンクされていて、左右の白いのがイスとなる子プリム、
真ん中の薄くて丸いのが親プリムです。
３つともにllSitTraget指定をしているだけのsitPosスクリプト(共通)が張り付いています。
サンプルのSitAvManager_sample(ソースはエントリーの最後)はここに記述してあります。


このように、

左右の子プリムには、先ほどのSitAvManagerModuleが貼り付けてあります。


では映像で確認どうぞ。  続きを読む