2010年03月31日

Vectexビルド更新 r27840

Graphicall.orgのBlender2.5 Vectexビルドを更新しました。

Linux 64bit

Linux 32bit


Windows 32bit


ソースファイルのパッチ(Blender2.5_Vectex_patch.zip)

今回の更新内容は、

   1. トランクの変更(27332 : 27840)を取り込みました。
   3. SVGファイルを連番ファイルのアニメーションとして使用した場合の不具合の修正。

となっています。

注)3月25日にr27736のビルドをアップロードしましたが、そちらにバグを混入していたことに気付いて、バグフィックス版としてr27840のビルドをアップロードし直しました。前回の更新でも同様のことをしてしまったばかりなのに、同じような失敗を繰り替えしてしまってすみません。


○SVG 連番ファイルについて

SVGフォーマットはアニメーションを表現するための仕様も含んでいて、本来ならばAVI、MPEGなどの動画ファイルのように一つのファイルに複数フレーム分のデータを保持することができます。
そのためSVGファイルを連番ファイルとして使用することは通常はほとんどないと思います。
ほとんどないとは思いますが、Blenderのイメージテクスチャの仕様上このような形でのSVGファイルの使い方もできてしまうので、実際に使ってみるとどうなるのか試してみました。
pic100330_01.jpg pic100330_02.jpg

連番のSVGファイルを出力するようなソフトウェアは恐らく存在しないのではないかと思いますが、Freestyleとsvgwriterモジュールを使うことでBlenderで作成可能です。

BlenderのFreestyleブランチについては、こちらの開発ブログかBlenderartist.orgのフォーラムのスレッドに詳しい情報があります。
Freestyleの機能を試すにはGraphicall.orgにアップロードされるカスタムビルドを使うのが簡単です。

svgwriteモジュールはFreestyleブランチ開発チームのT.K.さんが作成したものです。こちらのT.K.さんのサイトから入手可能です。

もともとのアニメーション用svgwriterはXMLファイルとして各フレームのデータを一時的に保存して、それを一つのファイルにまとめるような仕組みになっています。
このXMLへの書き出し部分のpythonコードを静止画のSVGファイルのヘッダ作成を行う部分と置き換えると、SVGファイルを連番ファイルとして出力できます。

こちらにSVG連番ファイル出力用に改造したsvgwriterモジュールを置いておきます。

本来なら一つのファイルにまとめられたSVGアニメーションをVectexで使用できるようにしたいところですが、現在のところQtSVGでフレーム位置をコントロールする機能が見当たらないため、当面の間はアニメーションに対応するのは難しいと思います。


Blender2.49をベースとしていたときのVectexでも、一応SVG連番ファイルを使用することができました。
しかし、SVGファイルを連番のアニメーションとして使用すると各フレーム毎に大量のタイルキャッシュ画像が作成されるため、簡単に数ギガバイト単位のメモリを消費してしまいます。
前回の更新で、Blender2.5の現在のバージョンのVectexでは、連番のアニメーションとしてタイルキャッシュを使用した場合は、各フレームのレンダリング終了後に作成されたタイルキャッシュを削除してメモリを開放するようにしています。
これにより比較的メモリ搭載量の少ないコンピュータ上でも、Vectexでタイルキャッシュを使ったSVGの連番アニメーションが可能になっています。

SVGファイルを連番ファイルとしてBlenderに読み込んでいる場合、UI操作でタイムライン上のフレーム位置を変更するのに合わせてプレビューの更新が行われます。
通常のビットマップ画像ではフレーム位置に対応した画像をディスクから読み込む処理が行われるだけですが、VectexではSVGドキュメントの読み込みとそのレンダリングという通常より面倒な処理が行われます。
前回の更新の時点ではSVGファイルを連番アニメーションとして読み込んでいる状態でVectexパネルの設定(Base Colorなど)を変更すると、マテリアルのプレビューが表示されている場合などにBlenderがクラッシュする可能性がありました。
今回の更新でこのようなクラッシュが起こりにくくなっていると思います。


○SVG 連番ファイルの使い方
念のためVectexでSVGファイルを連番アニメーションとして使用する手順を書いておきます。

SVG連番ファイルの作成はFreestyle BranchのBlenderで行います。
あらかじめ上記の改造版svgwiterモジュールを適当な名前でハードディスク上に保存しておきます。
適当にアニメーションが設定された状態であると想定して、SVGファイルの出力に必要な手順だけを説明します。
プロパティエディタの「Render」コンテキストで「Post Processing」パネルを開き、「Freestyle」チェックボックスをオンにします。
pic100330_03.jpg

「Layers」パネルを開き、一番下の「Add Style Modue」ボタンを押します。
pic100330_04.jpg

「Add Style Module」ボタンのすぐ下にデフォルトのスタイルモジュールが追加されるので、ファイル名の横のフォルダボタンを押して他のスタイルモジュールを選択するためのファイルブラウザを開きます。
ファイルブラウザが開いたら、上記の改造版svgwriterモジュールを選択します。
pic100330_05.jpg pic100330_06.jpg

「Output」パネルで出力先を指定します。
pic100330_07.jpg

「Render」パネルで「Animation」ボタンを押して、アニメーションのレンダリングを実行します。
pic100330_08.jpg

これで、JpegやPNGなどのビットマップ画像のレンダリングイメージの他に、SVGファイルが出力先のディレクトリに作成されます。
pic100330_09.jpg


VectexでSVG連番ファイルを使う手順です。
プロパティエディタのTextureコンテキストでテクスチャのタイプを「Image or Movie」にします。
pic100330_10.jpg

表示されるImageパネルで「Open」ボタンを押し、ファイルブラウザでSVG連番ファイルの一番最初の番号のファイルを開きます。
pic100330_11.jpg pic100330_12.jpg

上記のFreestyle + svgwriterモジュールを使ってSVGファイルを作成すると透明な背景に黒の線で描画されることになるので、テクスチャプレビューは真っ黒のままでわかりにくいかもしれません。
その場合、Vector ImageパネルのBase Colorを適当に変更します。
pic100330_13.jpg

Imageパネルの上から2段目に「File」「Sequence」「Movie」「Generated」という4つのトグルボタンがあり、SVGファイルを開いた時点では「File」が選択されています。(r27757以降は、トグルボタンからプルダウンメニューに変更されているようです。)
この中の「Sequence」を選択します。
pic100330_14.jpg

するとテクスチャプレビューが真っ黒になるかもしれません。
これは、トグルボタンのすぐ下を見ると理由が分かります。
連番ファイルの最初のファイルとしてframe0000.svgという名前が設定されていますが、実際に保存されている連番ファイルはframe0001.svgが最初のファイルになっているため、存在しないファイルを開こうとして失敗しているという状態です。
連番ファイルを使用する場合、全体でいくつのファイルを使用するのかを指定する必要があります。
「(0)Frames:0」となっている数値ボタンに連番アニメーションの最終番号を入力します。
pic100330_15.jpg

「Start:1」の値を変更すると、使用される連番ファイルの最初の番号を変更できます。
「Offset:0」の値を変更すると、Blenderのタイムラインと連番ファイルの対応の仕方をずらすことができます。
「Auto Refresh」をオンにすると、Timelineエディタなどでカレントフレームを移動するのに合わせて、対応する位置の連番ファイルが自動で読み込まれテクスチャプレビューが更新されます。
pic100330_16.jpg

「Cycric」をオンにすると、連番ファイルのアニメーションの長さを超えるフレーム数に対して、連番アニメーションを繰り返すように対応させることができます。

この他、コンポジットノードのイメージインプット(ヘッダメニューのAdd->Input->Image)でもほぼ同じような操作でSVG連番ファイルを使用できます。
pic100330_17.jpg

上記の手順を手っ取り早く試せるようにテストデータを用意しました。(改造版のsvgwriterも一緒に入れてあります)
test_data100330.zip

Freestyle用の.blendファイルでは、改造版のsvgwriterのファイルパスを指定しなおす必要があります。
posted by mato at 00:27| Comment(22) | Blender Vectex | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
お久し振りです。
Vectexについてですが、Win64版にてタイル キャッシュ オプションを使用した場合に
不具合がある様です。
Blender起動時に表示される立方体に
http://croczilla.com/bits_and_pieces/svg/samples/tiger
のtiger.svgをテクスチャとして適用してレンダリングした場合、
タイル キャッシュ オプションoffでは
Mem:4.76M (22.69M, peak 40.58M) Time:00:01:00
、タイル キャッシュ オプションon(Mem Max: 0)では
Mem:518.72M (49.25M, peak 579.35M) Time:00:16.28
となります。
亦この現象は、Win32版でソリューションBlender内の
プロジェクトblender_renderに対して/fp:Fastオプションを付けた場合にも発生致します。
x64アーキテクチャではFPUが使われない為、亦Win32版での不具合の出方も考慮致しますと
恐らく浮動小数の演算精度絡みなのではないかと思います。

もう一つ、パッチによるimagetexture.c内
void ibuf_sample(ImBuf *ibuf, float fx, float fy, float dx, float dy, float *result)
から
void ibuf_sample(Image *ima, ImBuf *ibuf, float fx, float fy, float dx, float dy, float *result)
への変更についてですが、
ibuf_sampleはノード方面のCMP_displace.c内do_displaceとCMP_mapUV.c内do_mapuvからも呼び出されており、
こちらの引数の数は変更されていない為変数の値が不正になっていると思われます。
RE_render_ext.hのibuf_sample宣言部も変更されていない為、
今迄コンパイルが通ってしまっていて顕在化しなかった様です。
CMP_displace.cとCMP_mapUV.c側にImage *imaを追加して解決しようとしたのですが、
呼び出し元を追いかけてみたところ変更すべき関数が芋蔓式に増えていって
私では把握しきれなくなってしまいました為
とりあえずsvg画像使用時以外に障害が出ない様ibuf_sampleの引数を変更するのを止め、
ewa_eval(rev.27840時点ではboxsample)呼び出し時の第1引数をNULLにして、
値が不正になる事の抑止を試みました。
幸いibuf_sampleはdo_displaceとdo_mapuv以外からは呼び出されていない様ですので、
一時凌ぎではありますがこれでsvg画像使用時以外は問題無い様に思われます。

亦、rev.28651にてrender25ブランチよりタイル キャッシュが導入され
コードが大きく変更されました為、
現在新しい構造のコードに古い構造のパッチ コードを強引に押し込んで
とりあえず機能させているという状態です。
他にもコンフリクトを含む更新が何度かあり、亦上記の不具合の件もあり
Vectexが現在正常に機能しているのか私では分からなくなりつつあります。
お暇な時にでも一度見て頂けますと有難く思います。
rev.29178時点で私が使用しているパッチはこちらになります。
http://booster.x0.to/Blender/etc/Vectex.patch
Posted by at 2010年06月04日 19:45
お久しぶりです。
このところソースコード、ブログ、両方ともまったく更新をしていなくて、いろいろとご面倒をおかけしてすみません。

win64でのVectexの不具合について、少し状況が分からない点があります。
この不具合はBlender2.49、Blender2.5のどちらでも起こるのでしょうか?
また、Blender起動時の立方体にtiger.svgをテクスチャとして使用する以外は、カメラの設定やレンダリング画像のサイズ、テクスチャ座標の種類(Generated,Object,UV,その他)などは一切変更しない状態で再現されるのでしょうか?
不具合の内容というのは、メモリの使用量が増大する、レンダリング時間が増えるということであって、レンダリング結果自体は通常と変わらない形で得られるのでしょうか?
私自身はWin64版のBlenderをコンパイルする環境がないため、Win32でblender_renderに/fp:Fastオプションを指定するという方法で再現を試みましたが、どのようにすると再現できるのかわかりませんでした。


もう一つのパッチの不具合についてです。
本来、私の方でトランクの変更に合うようにパッチを修正しなければならないのに、大変なお手数をお掛けしてしまって、ほんとうにすみませんでした。
imagetexture.cのファイル中でVectexに関連する関数の引数にImage *imaを追加しているのは、レンダリング実行中に何らかの理由で使用中のImBufが解放されるような事態が起こった場合、Vectexのバックエンドデータが不正に破壊されるのを防ぐための処理にImage *imaを渡しているためです。
そのような処理はBlender2.49では必要なかったのですが、Blender2.5ではレンダリング実行中でもGUI操作が可能になったため、いろいろと試行錯誤を繰り替えした結果現在のような形にしています。
ただ、Blenderのソースコード中に参考にできるような他のコードが見つからなかったため、自己流のあまり良くないコードになっていて、可能であればもっと違った形に書き換えたいと思っていました。
imagetexture.cの関数の引数からImage *imaを外せるようにできるか、もう一度ソースコードを見直してみたいと思います。

よろしくお願いします。
Posted by mato at 2010年06月05日 01:06
申し訳ございません、検証が雑で発生条件を勘違いしておりました。
本日検証し直しました。

・条件
trunk rev.29232に
http://booster.x0.to/Blender/fix+%20for%20CMakelists.txt.rar
CMakelists-errorfix+.patchとCMakelists-buildinfo.patch及び
http://booster.x0.to/Blender/etc/Vectex.patchを適用し、
WITH_OPTIMIZATIONをOFFにした状態でCMakeにてVC2008SP1のプロジェクト ファイルを生成し、
ソリューションBlender内のプロジェクトblender_renderのみのビルド オプションを変更しつつビルド。
ビルドされたBlender.exeを起動し
http://croczilla.com/bits_and_pieces/svg/samples/tiger
のtiger.svgをテクスチャとして読み込み、Properties - Texture - Vector Image - Mem Maxを0(無制限)にする。
その後、Properties - Render - Dimensions - Render Presetsを
デフォルト又はHDTV 720p or HDTV1080にしてレンダリング。

・結果
32bit版
最適化無し...800 x 600・720pでは問題無し、1080pでは問題有り
/fp:Fast...800 x 600・720p・1080p全て問題無し
/arch:SSE2...800 x 600・720pでは問題無し、1080pでは問題有り
/fp:Fast + /arch:SSE2...800 x 600では問題無し、720p・1080p共に問題有り

64bit版
最適化無し...800 x 600では問題無し、720p・1080p共に問題有り
/fp:Fast...800 x 600では問題無し、720p・1080p共に問題有り
/fp:Strict...800 x 600では問題無し、720p・1080p共に問題有り

どうもメモリ使用量とレンダリング時間が異常に増加し始める閾値の様なものがあって、
それがビルド オプションやアーキテクチャ毎に異なる様です。
只、Properties - Render - Performance - Acceleration structureを
Auto以外に変更してレンダリングしたりAuto以外でレンダリング後Autoに戻して再レンダリングすると
症状が軽減(解消?)される場合がありますので、Acceleration structureの初期値にも何らかの問題があるのかもしれません。
亦Free Image Texturesを有効にしても症状が軽減されるのですが、
2度目以降のレンダリングでは効果が無くなる様でこちらも挙動が安定しません。

検証に使用したビルドとファイル一式→http://booster.x0.to/Blender/etc/test-rev29232.rar

2.4につきましては明日以降に検証する予定ですが、
とりあえず今ある2.4 rev.29060のwin32とwin64ビルド(/fp:Fast・/arch:SSE2等追加オプション多数)では
上記の2.5と同条件で軽くテストしてみましたところ、
タイル キャッシュ無しでは1秒と掛からない1280 x 720のレンダリングがキャッシュ有りでは11分掛かります。
デフォルトの800 x 600では、trunkと同じく問題有りません。
Posted by at 2010年06月05日 15:56
非常に詳しい検証をしていただいて、ありがとうございます。

ご用意していただいたビルド、.blendファイルを使って不具合の状況を調べてみました。
Vectexではもともとのプラグインのときから、テクスチャ座標にUV以外を使用するとdxt,dyt値からテクスチャの解像度を計算する際に問題が起こる場合がありました。
Blender2.49ベースでVectexビルドを開発していたころから何度か対応を試みていますが、十分にこの問題を修正できていなかったようです。
問題の起こっている部分は、現在のファイル構成では source/blender/render/intern/source/imagetexture.c の中の
int vtex_calc_power(Image *ima, ImBuf *ibuf, float *dxt, float *dyt, int *ideal_resolution)
という関数の中で、テクスチャの解像度を計算している処理です。
この中に、if (dot_product != 0.0 && fabs(signed_area / dot_product) < 0.1)というような条件処理を行っている部分があるので、浮動小数点の値をどのように扱うかで不具合の発生状況が変化するようです。
この部分の処理について、もう少しうまく対応できるかどうか調べてみたいと思います。

よろしくお願いします。
Posted by mato at 2010年06月05日 23:29
とりあえず、メモリ使用量増大、レンダリング時間増加の問題を修正できたように思いますので、r29234へのパッチを作成しました。

http://render360sideb.up.seesaa.net/data/blender2.5_Vectex_patch.zip

もう一つのimagetexture.cの関数の引数から「Image *ima」を外すという変更はもっと時間がかかりそうなので、とりあえずの処置で済ませてあります。

よろしくお願いします。
Posted by mato at 2010年06月06日 03:33
更新有難うございます。
trunk rev.29269を使用し昨日と同条件で試してみましたところ、
レンダリング時間の異常増加につきましてはどのビルドに於いても解消されました(1080pでタイルキャッシュ無しが1~2秒、有りが3~4秒)。
一方、メモリ使用量増大につきましては直っておりません。症状の出方は昨日の結果と全く同一で、
正常時の3~4MBに対して300~500MBと一気に膨れ上がります。
Mem Max横のMem usedの表示は正常時も異常時も1のままなのですが、
タスク マネージャの項目"メモリ (プライベート ワーキング セット)"を確認しますと異常時は確かに起動時+300~500MBのメモリを使用しております。
只、連続で何度もレンダリングしてもメモリ使用量がそれ以上に増える事はありませんし、
GBオーダーでメモリを食い潰すならともかく数百MBで済んでおりますので実用上はさほど支障はないかと思います。
tiger.svgを貼った立方体をコピーして6つ程にしてレンダリングしてみても、メモリ使用量が倍々算になったりはしませんでした。

検証に使用したビルドとファイル一式→http://booster.x0.to/Blender/etc/test-rev29269.rar
Posted by at 2010年06月06日 21:32
お手数をおかけしてしまって、すみません。
レンダリング時間の方が解決できた時点で、メモリの方も解決したものと思い込んでしまい、きちんと確認していませんでした。
メモリ使用量が増加するのはタイルキャッシュ画像が作成されるためだと思っていましたが、実際には画像データではなく画像データを管理する構造体のサイズが増加しているのが原因だったようです。
メモリ使用量増大の問題を修正したパッチを再作成しました。

http://render360sideb.up.seesaa.net/data/blender2.5_Vectex_patch.zip

よろしくお願いします。
Posted by mato at 2010年06月07日 00:26
更新有難うございます。
時間の都合で全ての異なるビルド オプションでの検証は出来ていませんが、
/fp:fastや/arch:sse2等を追加したtrunk rev.29286 32/64bit両版にて
1080pでもメモリの使用量異常増大が全く無い事を確認致しました。

Posted by at 2010年06月07日 22:07
2.4用と2.5用両方のVectexにつきましてですが、
適用した場合texture paintが不可能になる不具合がありましたのでご報告申し上げます。
2.4ではimagepaint.c、2.5ではpaint_image.cに対するパッチにある

+ else if(ima->vtex_flag & VTEX_USE_TILE_CACHE) {

の条件分岐がsvg画像且つtile cache有効時以外でも真になっており、
svg画像でなくても"Can not paint to vectex tile cache"と表示されます。
2.4の場合はダミー用のsvgをロードしてtile cacheを無効にすれば
svg以外でもtexture paintが正常に使用出来る様になりますが、
2.5の場合は同様の処置を行ってもsvg画像且つtile cache無効時のペイントが可能になるのみで、
svg画像以外のペイントが一切不可能です。
とりあえず当該の条件分岐を

+ else if((ibuf->ftype == SVG) && (ima->vtex_flag & VTEX_USE_TILE_CACHE)) {

としましたところ2.4でも2.5でも本来想定されていたと思われる動作になりましたが、
この修正方法で宜しかったでしょうか。

検証に使用したファイル一式→http://booster.x0.to/Blender/etc/test-29679.zip
Posted by at 2010年06月26日 02:12
たびたび、ご面倒をおかけしてしまってすみません。
texture paintが不可能になる不具合について、こちらでも確認しました。
また、ご提示いただいたソースコードの変更で不具合が修正されることも確認しました。

こちらにアップロードしてあるパッチファイルにもこの修正内容を反映させていただきました。

http://render360sideb.up.seesaa.net/data/blender2.5_Vectex_patch.zip

http://render360sideb.up.seesaa.net/data/blender2.4_Vectex_patch.zip

不具合のご指摘だけでなく、適切な修正方法までご提示いただいて、ありがとうございます。
Posted by mato at 2010年06月26日 17:15
更新有難うございます。
patch_33084.txtにつきまして、数箇所不具合がありましたので報告させて頂きます。


・properties_texture.py
bl_default_closed = True

は、コミット31587により

bl_options = {'DEFAULT_CLOSED'}

に書式変更されました。


・imagetexture.c
Displace及びMap UVノードを使用する場合、cmp_displace.c及びcmp_mapuv.cからimagetexture.c内の関数ibuf_sample経由で
最終的に関数ibuf_get_color(renderブランチの場合のみ)及びibuf_get_color_clip(trunk, renderブランチ双方共)が呼び出される為、
関数内の条件式

if ((ibuf == ima->deleted_ibuf) || (ofs > (ibuf->x * ibuf->y))) {

にてNULLであるimaを参照してクラッシュします。
条件式を

if (((ibuf->ftype == SVG) && (ibuf == ima->deleted_ibuf)) || (ofs > (ibuf->x * ibuf->y))) {

とする事により、とりあえず回避可能です。
亦、関数imagewraposa_aniso内の関数ポインタ宣言

void (*filterfunc)(Image *ima, TexResult*, ImBuf*, float, float, afdata_t*, int power);

ですが、変数名は不要ですので

void (*filterfunc)(Image*, TexResult*, ImBuf*, float, float, afdata_t*, int);

が適当ではないかと思います。


・svg.c
関数imb_loadsvg内にて、代入演算子を使用すべき箇所が比較演算子になっております

ibuf->backend_data == NULL;
ibuf->tile_set == NULL;

が、

ibuf->backend_data = NULL;
ibuf->tile_set = NULL;

適当ではないかと思います。


・dynlibqtsvg_vectex.c
コミット30415にて、関数

BLI_gethome()



BLI_getDefaultDocumentFolder()

に名称変更されました。


以上の修正(及び冗長な部分の整理・削除)を施し現在私が使用しておりますパッチはこちらになります。
http://booster.x0.to/Blender/etc/Vectex.patch (rev.33136用)
Posted by at 2010年11月18日 19:45
問題のあるパッチファイルをアップロードしてしまってすみませんでした。ご指摘いただいた内容を修正させていただきました。

たびたびご面倒をおかけしてしまい、本当に申し訳ございません。
Posted by mato at 2010年11月18日 23:03
お久し振りです。
不具合を見付けましたので報告させて頂きます。
初期設定のスタートアップ画面からCubeにSVGテクスチャを設定し、
Vector Image - Use Tile Cacheをオフ、Use Custom Sizeをオンにし、
XとYのサイズを両方共(片方のみだと全く、若しくは殆ど発生しない様です)変更してレンダリングすると
エラー0x00000005(アクセス違反)でクラッシュします。
デバッガーで追って見みましたところ発生位置はimagetexture.c内ibuf_get_color()の

col[0] = ((float)rect[0])*(1.0f/255.0f);

の部分の場合が殆どで、発生状況は
http://projects.blender.org/tracker/index.php?func=detail&aid=22040&group_id=9&atid=498
http://projects.blender.org/tracker/index.php?func=detail&aid=24189&group_id=9&atid=498
http://projects.blender.org/tracker/index.php?func=detail&aid=24983&group_id=9&atid=498
と酷似しています。
imagewraposa()にて代入されたprevibufの示す領域がどこかの(代入前?)の時点で解放されており、
最終的にibuf_get_color()がそこにアクセスしてクラッシュする様です。
只、発生条件がはっきりせず、Use Custom Sizeを何度かオンオフしたり
サイズを2000 x 2000程度まで拡大したり、
或いはstartp.blendを作成してそこから作業すると発生し易くなる様です。
rev.33664のデバッグ版では発生させ辛いのですが、
リリース版やrev.33665以降のデバッグ版では比較的簡単に発生させられます。
亦、32bit版より64bit版の方が発生しやすい印象がありますがこれは気のせいかもしれません。
クラッシュ時の変数の状態も一定ではないのですが、羅列しますと

・ibuf->rectが無効になっている
・ibuf-x, y等にマイナス5桁の異常な値が入っている
・ibuf内の変数の多くに0xfffefffe(解放済?)が入っている
・ibuf->ftypeに268435456(TGA?)が入っている事が多いが、稀に0の時もある
・ibuf->mipmap[curmap]がNULLであるにも関わらず、条件が真になる(同梱のスクリーンショット)

といったケースが多いです。最後はかなり不可解ですが、スレッド絡みでしょうか?
タイル キャッシュを使用していれば不具合は発生しませんので、実用上はとりあえず問題ありません。
尚、Qtは4.7.1を使用しております。
http://booster.x0.to/Blender/etc/x64-test-33664-and-33716.rar

ところで、rev.33665で上記バグ トラッカーのバグが修正され、
mipmapのテストが一つの関数として独立(imagetexture.c内image_mipmap_test())し、
内部処理も条件分岐が分割されて増やされました。
とりあえずコンフリクトを起こしたimagetexture.c内の二箇所を調整して一部をimage_mipmap_test()内に移して一応動作はしておりますが、
従来は開放していたメモリを開放せずに再設定する様にした、という修正内容ですので
上記不具合の件も含めて他にも修正が必要な箇所があるのかなと考えておりますが如何でしょうか。

追補: こちらに提出するパッチを作成していて気付いたのですが、
rev.33665にてfilter.c内IMB_makemipmap()にimb_freemipmapImBuf()が追加されており、
この辺りが不具合が発生し易くなった原因かもしれません。
Posted by at 2010年12月17日 03:36
お早うございます。
rev.33665でのfilter.c内IMB_makemipmap()の変更につきましてですが、
ふと思いつきまして

imb_freemipmapImBuf()




if (ibuf->ftype != SVG) {
imb_freemipmapImBuf(ibuf);
}

としてみましたところ、
rev.33664と同程度までクラッシュ頻度を減らせた様に見えます。
デバッグ版でざっとテストしただけですが、取急ぎご報告まで。
http://booster.x0.to/Blender/etc/x64-test-33716-rev2.rar
Posted by at 2010年12月17日 07:18
申し訳ございません、肝心のimagetexture.cに対するパッチ部分を書き換えるのを忘れておりましたので、
アップロードしたファイルを2つ共差し替え致しました。
Posted by at 2010年12月17日 07:43
たびたびご面倒をおかけしてすみません。

r33665でのバグフィックスによる変更でのコンフリクトにつきましては、私の方でも12/15に確認しました。
今回はなるべくご面倒をおかけしなくて済むようにと思い、その日のうちに私なりに修正したパッチファイルを作成してこちらにアップロードしていましたが、まったく何の告知もせずにファイルのみ差し替えただけだったのでお気付きになられなかったかもしれません。
もしそうでしたら、本当にすみません。こちらのコメントに一言でも書いておくべきだったかと反省しています。

ご連絡いただいた内容については、私の行った修正ではimagetexture.cのimagewraposa_aniso(),imagewraposa()内の/* mipmap test */のコメントのある部分でvectexの処理部分のIMB_makemipmap()をIMB_remakemipmap()に変更しています。
お手数ですが、この修正内容でご連絡いただいた不具合が直るかどうかご確認いただけますでしょうか?
もし問題があるようでしたら、ご提供いただいたファイルを参考にして再度パッチファイルを修正し直したいと思います。

よろしくお願いします。
Posted by mato at 2010年12月17日 23:24
記事の方ではなく、6月のコメントの方のアドレスで確認しておりました。
申し訳ございません。
seesaaはアドレスの違いが大文字と小文字だけでも別ファイルになるのですね。
テストしてみましたところ、Use Custom Sizeの件につきましてはクラッシュしなくなっております。

ところでもう三点追加させて頂きます。
一点目は分かり易い不具合で、初期設定状態でも何でも構いませんのでとりあえずレンダリングした後、
自動的に表示されるUV/Image EditorのEnable image painting modeをONにして
レンダリング結果をクリックすると必ずクラッシュします。
原因は前回と同じくNULLへのアクセスで、
paint_image.c内imapaint_canvas_set()は関数内のibufがNULLでも処理が続行される仕様になっており、

else if((ibuf->ftype == SVG) && (ima->vtex_flag & VTEX_USE_TILE_CACHE)) {

でNULLを参照してクラッシュします。
4行上のコードを真似して

else if(ibuf && (ibuf->ftype == SVG) && (ima->vtex_flag & VTEX_USE_TILE_CACHE)) {

とする事により解決されます。

二点目につきましては前回の私の修正、
imagetexture.c内ibuf_get_color()及びibuf_get_color_clip()の計2箇所、

if (((ibuf->ftype == SVG) && (ibuf == ima->deleted_ibuf)) || (ofs > (ibuf->x * ibuf->y))) {
if (((ibuf->ftype == SVG) && (ibuf == ima->deleted_ibuf)) || (x > ibuf->x) || (y > ibuf->y)) {

につきましてですが、

if ((ima && (ibuf == ima->deleted_ibuf)) || (ofs > (ibuf->x * ibuf->y))) {
if ((ima && (ibuf == ima->deleted_ibuf)) || (x > ibuf->x) || (y > ibuf->y)) {

の方が、実効的には変化無いかもしれませんが
当初のコードの意図により近いと思いましたので変更してみましたが如何でしょうか。
これにつきましては却下されましても特に構いません。

上記二点の変更をpatch_33679.txtに加えて再テストしてみましたところ、とりあえず気付く範囲ではクラッシュしなくなっております。
Custom Sizeを8000 x 8000オーバーに設定したりAAをx16フルサンプルにしたりと無茶をしても安定しております。
http://booster.x0.to/Blender/etc/x64-test-33738.rar

三点目は私では直し方が分からない症状で、Custom Sizeを変更する際にxとyの両方を変更しないと実際の変更が為されません。
例えばx:1, y:1000に設定しテクスチャを線状にした後xを1000にしても、テクスチャは線状のままです。
追加操作としてyの値を+1又は-1すると変更が反映されますが、
999又は1001になったyを1000に戻して実際の結果に反映させようとすると今度はxを変更しなければなりません。
数値の直接入力で、例えば1000から1000への変更で回避しようとしても同値の場合は再計算が行われず、
結果この場合実際の解像度をきっちりx:1000, y:1000に設定する事は不可能となっております。
Posted by at 2010年12月18日 02:05
お早うございます。
三点目につきましてですが、
image.c内vtex_image_update()及びvtex_image_redraw()の中にに一箇所づつあります

if ((old_x != new_x) && (old_y != new_y)) {



if ((old_x != new_x) || (old_y != new_y)) {

としましたところ解消されました。
亦、今朝方のコミット33754にてfilelist.cがコンフリクトを起こしましたので、パッチ内容を少し弄った上で
file_extension_type()内に放り込んでおきました。
http://booster.x0.to/Blender/etc/x64-test-33759.rar

尚、「きっちりx:1000, y:1000に設定する事は不可能となっております」というのは早とちりでしたので訂正致します。
不具合がある状態でもx->適当な数値, y->適当な数値、x->1000, y->1000と手順を二度踏めば可能でした。
Posted by at 2010年12月18日 09:04
不具合についての詳細な情報をありがとうございます。
私自身の単純なミス、あるいは動作確認不足が原因のものばかりで、本当に情けない限りです。
追加でご報告いただいた3点の修正内容とr33754のコンフリクトについて反映させたものにパッチファイルを差し替えさせていただきました。

よろしくお願いします。
Posted by mato at 2010年12月18日 20:27
更新有難うございます。
矢継ぎ早で申し訳ございませんが、コンポジット ノードに不具合がありましたので報告させて頂きます。
コンポジット ノードにてImageノードにsvgを読み込んでいる場合、
Use Custom Sizeを変更すると画像が平行四辺形状に歪んだり、
当初よりも大きいサイズに変更するとクラッシュします。
恐らくはノード側の保持している画像サイズが初回読込時の数値で固定されており、
Vectex側と齟齬が発生しているのだろうと思います。
image.c内BKE_image_signal()に対するパッチ内容の

vtex_image_update(ima);
vtex_image_redraw(ima, ibuf);



vtex_image_update(ima);
vtex_image_redraw(ima, ibuf);
image_free_buffers(ima);

とすればとりあえず歪みやクラッシュは回避可能です。
http://booster.x0.to/Blender/etc/x64-test-33775.rar

只、Textureノードも含めて、サイズ変更後に
ノード内のプレビューが自動で更新されない問題は残っております。
Use NodesがONの状態では

Imageノード・・・接続を弄る or 再読込 or 画像をレンダリング(F12) or
 Texture Paintで何か描く or Properties - Texture - Imageにてファイルをリロード
Textureノード・・・OffsetやScaleを弄る or 再読込(何故かImageノードの方もつられて更新されます) or
 画像をレンダリング(F12)

でプレビューが更新され、Use NodesがOFFの状態では
Imageノード・Textureノード共に画像をレンダリング以外の方法では更新されません。
Posted by at 2010年12月19日 16:37
不具合をご報告いただきありがとうございます。
Vectexをノードで使用した場合にいくつか問題があることは認識していましたが、現時点では私の能力で解決するのは難しいように感じています。

ご提示いただいた方法での修正を行うとバックエンドでレンダリング実行中にVectexパネルの操作を行うとクラッシュする問題があります。
元々blender2.4xではVectex専用のIMA_SIGNAL_VECTEX_UPDATEというのものは用意せずIMA_SIGNAL_RELOADを流用していましたが、レンダリング実行中にVectexパネルの操作を行った場合に問題があるため現在のように処理を分離しました。
このような理由があるため、とりあえずこの不具合の修正については保留とさせていただきたく思います。

また、前回ご提示いただいた2点目の修正についてですが、この適用を行うとLinux上ではTexture PreviewとMaterial Previewを同時に表示させるとクラッシュするようです。
このあたりのコードは私自身もどれだけ意味があるのかよく分からない状態で苦し紛れに追加しているだけなのですが、とりあえずLinuxでは何かしらの意味があるようですので元に戻させていただきました。

ノード関連の不具合につきましては、後ほど時間ができたら少し調べてみたいと思いますが、完全に不具合を無くすのはなかなか難しいと感じています。

以上、よろしくお願いします。
Posted by mato at 2010年12月20日 22:54
差戻しと保留の件、了解致しました。
Posted by at 2010年12月21日 01:06
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。