background

スポンサーサイト

--年--月--日(--)

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


上書きについての走り書き

2007年02月26日(Mon)

バンプの不具合の件。
前回アップロードしたファイルを数人の方にテスト頂いて、いくつかの事が明らかになった。
テストして頂いた有志の方に感謝しつつ、簡単にまとめてみると。

とりあえず不具合内容は、

「Poser 7日本語版でルートノードのバンプにイメージマップノードが直接接続されているフィギュアや小道具をロードすると、イメージマップノードのファイルが正常に読み込まれておらず、そのためレンダリングすると他のイメージが適用されてしまう」

である。これはマテリアルルームでイメージマップノードのファイル指定をイチからやり直すことで対処できる(回避じゃないぞ、遭遇してしまってるんだから)。複数のイメージマップノードで同じファイルが指定されている場合、Poserは1つのファイルを使い回すので、一回だけ指定してやれば全てのイメージマップノードが正常に戻る。

これを、もうちょっとなんとかならんか、ということでウダウダ考えている。

  • どうやらライブラリからの追加やシーンファイルのオープンでフィギュアやプロップがロードされる時、同時に読み込まれるはずのバンプマップがまずいことになってしまうらしい。
  • ロード時に読み込まれるのはマテリアルにP4書式で記述されているイメージファイルである。
  • なので、このP4書式をサクってロード時のイメージファイル読み込みを行わなければ、シェーダツリーが適用された時にファイルは正常に読み込まれるので、問題を回避できる。
  • これはマテリアルルームで手動対応するよりは、多少は楽かもしれない。

これを主軸にして、さらにウダウダと外堀を埋めていく。

  • マテリアルファイル、マテリアルコレクションファイル、MATポーズファイルを適用した場合にも同様の現象が起こるらしい。これが同じプロセスで発生しているのかどうかは不明。
  • Poser 7Jでしか発生しないが、シーンファイル自体は英語のファイルでも発生する。
  • 間違って適用されてしまうイメージファイルは、2度目のレンダリングからは先頭のマテリアルグループに存在するファイルだが、テスト結果を頂いた限り、1度目のファイルにも実は法則性があるっぽい。

てな感じだ。以下本題。

casiopeaさんのブログで、P7Jのファイルの記述が怪しいという記事を拝見した。シェーダツリーによるP4書式の上書きの法則性も知りたかったので、作成したファイルをP6JとP7Eで読み込んで動作を確認してみる。

使用したファイルはテストデータのNoP4、P4書式はNO_MAP指定で、シェーダツリーは ":runtime:textures:test:test1.jpg"という指定になっている。

まずはシーンファイルを開いた状態のP6J。

  070226-1

P4書式はサクられたまま、シェーダツリーではファイル名しか保存されていない。また、ロード時にテクスチャを読み込んでいないので、テクスチャシェーディングにしていてもテクスチャは表示されない。これがP7Eの場合はと言うと、

070226-2

Mac版ではアプリケーションフォルダからの絶対パス(しかもスラッシュ区切り)に変わっている。次に、このシーンをそのまま一度だけレンダリングし、ファイルを別名保存したところ(もちろんレンダ結果は正常である)。P6J。

070226-3

ボカシで大変失礼だが、この部分はボリューム名:ユーザID:~と続いている。基本的にMac版P6Jはファイル記述は全てボリュームからの絶対パスである。レンダリング時にシェーダツリーの記述によってファイルは読み込まれているはずだが、まだP4書式への上書きは行われていない。また、テクスチャシェーディングにもテクスチャは反映されていない。

P7E。

070226-4

ここでシェーダツリーのファイルパスが何故か元のpz3の記述に戻っている。あとはP6Jと同様。

ここで、一度シーンファイルを閉じ、「Poserを終了せずに」同じファイルを開き直してみた。Poserは一度ロードしたファイルは、Poserを終了するまでその所在地を記憶している。この場合、P4書式をカットしていることがどう影響するか。というわけでP6J。

070226-5

ファイルを開いた直後に、そのまま別名保存したものである。P4書式の部分にも絶対パスでファイル指定が入り、テクスチャシェーディングも始めから適用されている。

次にP7E。

070226-6

こちらはRuntimeからの指定で、やはりP4書式が上書きされている。つまり、Poserはロードの時点で、ファイルの読み込みは行わないもののシェーダツリーを読み出していて、メモリ上に同名のファイルがあればさっさと適用してしまうようである。

さて、では最初のファイルを開いて、そのままマテリアルルームでマテリアルグループを一つだけ表示させ、その状態でファイルを別名保存してみよう。マテリアルルームの操作は、ファイルにどのように反映されているか。

070226-7

P6Jでは、マテリアルルームに入り、マテリアルグループを選択した瞬間にその部分のテクスチャがテクスチャシェーディングに反映された。シーンファイルも、その時点でP4書式が上書きされていることがわかる。マテリアルルームで表示させていない部分の記述は最初のケースと同様だった。

070226-8

P7Eでも同様である。

この一部だけテクスチャシェーディングが反映された状態で、一度ファイルを閉じて開き直してみよう。P6J。

070226-9

やはり、一部のテクスチャシェーディングだけは反映、そしてP4書式への上書きも行われている。

070226-10

P7Eでも同様。

さて。
と、いうことは、P4書式の上書き(というかP4書式とシェーダツリーの整合性のチェック)は、マテリアルルームで該当のマテリアルグループを操作した時、そしてフィギュアや小道具をロードした時に行われている、ということになりそうだ。ただし、ロード時にはシェーダツリー内のイメージの読み込みは行わない。その為、Poserを起動した直後の状態ではP4書式に上書きするべきファイルパスが見つからないためNO_MAPのままとなっている……という感じだろうか。

Poserは外部ファイルを読み込む時、実はファイル名でしかファイルを区別しない。だから別のディレクトリに同名のファイルが存在する場合、それは「同じもの」として扱われてしまい、さらに、「先にロードしたファイルのファイルパス」を意固地に保持している。

仮に、テクスチャを01.jpgと名付け、texturesフォルダ下に保存したとしよう。次にテクスチャを変えたくなって、別のファイルに同じ01.jpgと名付け、textures:testフォルダ下に保存する。すると、マテリアルルームでいくらtextures:test下の01.jpgを指定しようとも、あるいはtextures:test下の01.jpgを指定したファイルをロードしようとも、最初に読み込んだtexturesフォルダ下の01.jpgを表示してしまうのである。

これはテクスチャだけではなく、ジオメトリファイルでも同様である。大人しくファイル名を変更するか、Poserを終了してエディタでファイルパスを変更するしかない。この辺の仕様はPoser 7になっても変わらない。

とりあえず変更されるタイミングがわかったので……うーん……。
……保存時にサクっちゃうとか……どうだろ。

とりあえず、わふうてんまであとよっか。



Comments

> わふうてんまであとよっか。
が、ビビっと来ました(笑)(^^;)
 
Kyotaro さんの使用されているテキストエディタが、
一番気になっています(笑)
 
絶対表現って、
Runtime を複数持てるようになってから
問題になって来たのでしょうか。
そうでもないのかな?(^^;)
 
Poser 内で解決するしかないのかも知れませんね…
よく分かんないですけれども… ヾ(・・*) ちょっとちょっと

Name
kirakira #E9NqROVM
Site
URL
Post Date
2007-02-26
Post Hour
10:06:51

Edit

便利なはずの機能が却ってややこしくしてるのですね。
サポートの皆さん見てますか~と電波送ってみます。
 
和風展>最近まで日時を間違えて覚えてました。(笑)

Name
Youniss #JalddpaA
Site
URL
Post Date
2007-02-26
Post Hour
12:52:52

Edit

>kirakiraさん
何か電気が走りましたか?(笑)それが恋といふものなのです(!)
使っているエディタは、mi(ミミカキエディット)というカンパウェアです。
作成モードやツールが簡単に作れるので、cr2モードを作成して少しずつカスタマイズしていってます。actorとか見出し語単位でジャンプ移動したり、ERCの定型文挿入したり……MacにCR2Builderみたいなのがないのは悲しいことですが、逆にファイルの中身に詳しくなれるんでこれはこれでアリかなと思います。
 
絶対パスはわかるんですけどね。その方が複数の検索するより早いですから……。
あれからPythonのマニュアルみたりちょっと調べたりで、保存前に走らせるカンジのムチャクチャなスクリプトを思いつきました。
……動作確認ができないのが辛いところで(^^;
 
>Younissさん
このファイル指定のあたりとか、P4書式とシェーダツリーとの互換のあたりとかは本当に「却ってややこしくなってしまった」のの代表格みたいな感じですねぇ。
テクスチャのファイル名とか、マニュアルでわかることでもないし……。私もイーフロに向けて怪電波送ってみることにします(笑)
 
和風展、いよいよですね~。私もそろそろ規約を読んでこようと思います(今頃)

Name
Kyotaro #NWbyPjWY
Site
URL
Post Date
2007-02-27
Post Hour
09:43:42

Edit

なんかふとした違和感から大変な検証行って頂いたみたいですみません…m(__)m
自分もP6J、P7J(ともにWIN)でこちらのエントリと同じ事やってみました。
一つだけ、違いを感じたのはWINのP6Jは何をやろうとも、ひたすらテクスチャのソースは「:Runtime~」を固辞するって事ですかね(こんなこと分かっても意味ないw)
 
和風展はまた皆さんの作品を拝見して楽しむだけになりそうです('~')
ん?Pythonスクリプト?('∇')ワクワク

Name
casiopea #4iHNXosw
Site
URL
Post Date
2007-02-27
Post Hour
09:58:26

Edit

この現象も、P4時代の遺物からのトラブルっすね。
P4時代には":texturefile"の書式でテクスチャフォルダ下を検索してファイルを決定する、すなわちテクスチャファイルはすべてユニークな名前であるという前提が存在したのです(むろん絶対pathも使えましたが)。
それが今でもテクスチャ管理の基本になっているんで、こんな混乱が生じているんですね。
ポーザーのよきにつけ悪しきにつけ後方互換性を維持しようとする姿勢がこーいうトラブルを引き起こすんだから…もーP4の書式は捨ててかまわないと思うんですけどねえ(苦笑)
つっか、P4レンダなんて7では完全に意味ないんだから、もうヤメようよ>イーフロさん(´Д`;)ヾ

Name
ほげほげ #-
Site
URL
Post Date
2007-02-27
Post Hour
15:12:11

Edit

>casiopeaさん
いえいえ、この検証で今までよくわかっていなかった上書きタイミングやら、色々なことがわかりました。なんでもやってみるものですね(^^
Windows版はやっぱりパスはRuntimeからの表記だったんですね。配付物などを作る時はそちらのほうが便利ですから、P7で変更になったのが逆に不思議ですね。
 
えー、スクリプトですが、すみませんお願いメールをこっそり送りました。
お手数ですが拾ってやってくださいませm(_ _)m
 
>ほげほげさん
ウワサには聞いていたんですが、実際に不都合に当たると焦ってしまいますね~(^^;
プレビューウィンドウの描画もシェーダツリーじゃなくてP4書式を使ってるみたいですし……。いい加減そろそろ後方互換はインポータか何かに任せてしまって、今風に仕様変更して頂きたいものです。
P4互換レンダも要らないですねぇ。トゥーン以外にメリットは思い浮かびませんし、それも代替可能でしょう。P4レンダで充分と言われる方は、FireFlyがP4互換レンダを包括していることを習得されていないんでしょう(って、コレ前にも書いたような……(^^;)

Name
Kyotaro #NWbyPjWY
Site
URL
Post Date
2007-02-27
Post Hour
19:53:55

Edit

後方互換はもうやめちまえ、というのは賛成ですが、イーフロは当分はやらないでしょうね。
つい最近、Figure Artistなるプロダクトを出していますが、Poserとの機能比較表を見ると、「JamesやJessiのついた、IBL/AOの使えるP4」みたいなもんです。少なくともシェーダーは装備してないみたいで。
 
P7Eも、トランスペアレントマップとテクスチャマップを同時に使うと、速度が著しく低下するとか何とか…
私はまだ当分P6に留まりそうです。

Name
HONEY #pM6OKWLY
Site
URL
Post Date
2007-02-27
Post Hour
22:29:51

Edit

>HONEYさん
なんと、Figure Artistはそんなモノ(微妙に暴言)なのですか。機能を限定するのは別にいいですが、中身までただ限定を掛けただけだったりしたらイヤですねぇ。
Poserが使い辛かったり習得しにくかったりする原因は、多機能ではなく各機能の根幹になる思想の不整合だということをいい加減悟って欲しいものですね。
 
自分もP7完全移行はSR1待ちになりそうです。マテリアルルームの動作が辛くって……。

Name
Kyotaro #NWbyPjWY
Site
URL
Post Date
2007-02-28
Post Hour
00:06:00

Edit

Post Comment

管理者にだけ表示を許可する


Trackback

※このブログにトラックバックを送信する場合、お手数ですが本文中にブログ該当記事へのリンクを含めてください。

トラックバックURL:http://rutenshikai.blog63.fc2.com/tb.php/205-4970f6e5



Menu

Profile

Kyotaro

確定名:Kyotaro
ネタを探しているらしい。

Categories

Calendar

10 | 2017/11 | 12
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 - -

Comments

Archives

Track back

RSS feed

Links

Search

※2011年4月6日のサーバ障害の為、エントリのアドレスが以前のものからズレています。当Blogのエントリにリンクを張っておられた方は、お手数ですがアドレスのご確認をお願い致します。

※Internet Explorer非推奨。


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。