mieki256's diary



2017/03/18() [n年前の日記]

#1 [dxruby] DXRubyのCustomRenderTargetを勉強中その2

_DXRuby開発版 を使ったスクリプト中で、 _tinywavefrontobj を用いて Wavefront形式(.obj + .mtl)の3Dモデルデータを直接読み込んで描画してみたり。

_crt_test05_readobj.rb

こんな感じの結果に。



一応、.obj を直接読んで使えることが確認できた。

ついでに、3D描画部分の背景として、2D画像をフツーに描画できるかどうかもテスト。DXRuby ならこういう描画も可能であることを確認できた。コレ、Ruby + gosu + opengl では、OpenGL描画部分の背景に2D画像を描画できなかったわけで…。いや、もしかすると gosu も書き方次第でできるのかもしれないけど、ググってもヒントが見つからなくて。

さらに、頂点配列、法線配列、uv配列、頂点カラー配列を、別々の頂点バッファにして描画できるか試してみたり。一応描画できてるように見えるけど、これで合ってるのかどうか…。昔は、1つの頂点毎に、頂点座標、法線ベクトル、uv等をまとめてしまったほうが速かったらしいけど、最近のGPUは分かれてるほうが速い事例もあるそうで。まとめたほうがいいのが、分けてあるほうがいいのか、どっちを使ったほうがいいのかちょっと分からんけど。

_GPU本来の性能を引き出すWebGL頂点データ作成法 - Qiita
_wgld.org | WebGL: インターリーブ配列 VBO |

何はともあれ、こんな感じの描画ができるのであれば、例えば 2DのSTGやアクションゲームでも、背景をそれっぽく見せられそうな予感。

jsonと.objのどちらがいいのやら。 :

jsonファイルを解析して頂点配列等を取得するのと、.obj + .mtlファイルを解析して頂点配列等を取得するのでは、どちらがいいのだろう…。

例えば、RubyのjsonライブラリがCで書かれてたりするなら、一旦jsonにしておいて、jsonを読み込んだほうが処理時間も速いのだろうけど。

もっとも、パース(=解析)にかかる処理時間を気にするなら…。jsonになった時点で、もはや中身を眺めて修正したり等はほとんど不可能な状態になるのだから、いっそのことバイナリで保存したり読み込んだりするほうがいいのかな、とも思えてきたり。でも、エディタで開いて一応は内容が見れるテキストファイルと、何が何だか分からない謎バイナリでは、前者のほうが気分的に楽かな…。

頂点カラーを記録できる3Dモデルフォーマットを探していたり。 :

テキストで記述されていて、かつ、頂点カラーを記録できる3Dモデルフォーマットは無いのかなとググってるところ。

ここ数日使っている Wavefront形式は、テキストで記述されてるので解析しやすいものの、頂点カラーについては記録できないみたいで。いや、アプリによっては頂点情報に頂点カラーまで付加してしまうものもあるらしいのだけど…。

そもそも blender上で頂点カラーを指定するのって、どんな操作をすればいいんだろう。ソレ以前に、blenderは、頂点カラーを使える機能があるのだろうか。

仮に blender がそういう機能を持ってないとしても、Wings3Dあたりではどうだろう。Wings3Dは、ゲーム向けのローポリモデルを作成しやすい、という話を見かけたから、頂点カラーも指定できそうな。

課題。 :

今のところテクスチャを使ってるモデルしか描画できないので、テクスチャを使ってないモデル、及び、複数のマテリアル(材質設定)も描画できるようにしたいのだけど、さて、どうすればいいのやら。シェーダを数種類用意して対応するのが妥当なのだろうか。それとも違う方法があるのだろうか…。

ピクセルシェーダ内の計算も、これで合ってるのかどうか…。意味も分からずコピペしただけなので…。 _グーローシェーディング(Gouraud shading) とか _フォンシェーディング(Phong shading) とか勉強しないと、なのかな…。

#2 [nitijyou] ファンヒーターが壊れた

自室で使っていたダイニチ製のファンヒーターが壊れてしまった。運転開始ボタンを押してしばらくすると、液晶画面に「F06」のエラー表示が。

_エラーへの対処方法一覧 - 石油暖房機器 - DAINICHI によると、「F06」のエラー表示は、気化器サーミスタオープンなる症状らしい。修理が必要ですよ、と書いてある。

親父さんの運転する車で、近所にあるホームセンター、ホーマックまでファンヒーターを運んで修理をお願いしてきた。とりあえず見積もりを出してもらえるらしいけど、下手すると二週間ぐらいかかるかも、との話。

件の店では、既にファンヒーターをほとんど売ってないそうで。店頭にはコロナ製の製品しかなかった。値段は税抜き14,800円。

ついでに、ホーマックで犬の餌も購入。柴犬用と謳ってるドッグフードだけど、食べてくれるかどうか…。

何時頃買った製品だったか。 :

検索してみたら、 _2007/11/05 に買った製品だったらしい。ダイニチ FW-322S とメモしてあった。

当時の店頭では9,980円で売られてたのか…。すると、今は製品価格が1.5倍に値上がりしてるんだな…。と思ったが、ググってみたら、9,980円前後で売ってるお店もあるな…。今回店頭で見かけた製品は、何かしらランクの高い製品だったのだろうか。

階下のファンヒーターを貸してもらえた。 :

親父さん曰く、「1階の奥の部屋に置いてある古いファンヒーターはほとんど使ってないので、ひとまずソレを使え」とのことで。助かった。

自室まで運んで動作確認。フツーに動いてくれた。

CORONA GT-3240、と書いてあるな…。 _道燃整組 コロナ年度表一覧 によると、1991年の製品らしい。…えっ? 1991年? 大丈夫かコレ。

コロナ製品は、一部にリコール対象製品があるようで。「手を汚さずに開け閉めできますぜ」てのが売りだったタンクの蓋部分に問題があるらしい。

_コロナ石油ストーブ 油タンク確認不足で火災の恐れ - リコール情報のお知らせ - ヤフオク!
_CORONA Information web
_recallpapaer.pdf
_株式会社コロナが製造した石油ストーブのリコールが行われます(無料点検・部品交換)(METI/経済産業省)

幸い、型番リストの中に GT-3240 は入ってなかった。古過ぎて、タンクの蓋が昔ながらの金属製なので、リコールにはならなかった模様。

2017/03/17(金) [n年前の日記]

#1 [dxruby] DXRuby開発版のCustomRenderTarget関係を勉強中

_DXRuby開発版 1.5.21 以降は CustomRenderTarget というクラスが追加されて、ソレを使うとDXRubyでも3D描画その他ができるようになる、ということで書き方を勉強中。と言っても、開発版のzipに同梱されてるサンプルの、3Dtest.rb、spheretest.rb をコピペして弄ってる段階だけど。

ひとまず、こんな感じに。

_crt_test03.rb



しかしコレ、テクスチャの描画はどうやるんだろう。…もしかして 2Dtest.rb を参考にすればいいのだろうか。

意味も分からずにあちこちコピペしてみたら、なんだかソレっぽくなってきた。

_crt_test04.rb



最終的に各ドットの色を決めてくれる、ピクセルシェーダのソースをどう書けばいいのかチンプンカンプンなので、なんだか色がおかしいような気もするのだけど…。とりあえずテクスチャも描画できるのだなと。

OpenGL上では、u,v の v を上下反転しないと正常な描画にならなかったけど。DirectX ではテクスチャ座標の上下の向きが違うから、u,v の v を反転しないまま使えば正常に、と思ったけれど実際試してみたら OpenGL と同様に v を上下反転すると正常描画されるようで。…ホントにそうかな。自分の書いた変換スクリプトがバグってないか。怪しいな。

tinywavefrontobj.rbを更新。 :

先日作成した tinywavefrontobj.rb を使って、Wavefront形式(.obj)の3Dモデルデータファイルを、実験用モデルデータへと変換出力しようとしたのだけど。

調べてみたら OpenGL と DirectX は座標系からして違うようで。OpenGLは +z が手前だけど、DirectX は +z が奥らしい。なので、OpenGL用に書いた件のスクリプトは、そのままでは使えなくて。

_OpenGLの座標系

また、現状の CustomRenderTarget、というか VertexBuffer は、頂点インデックス配列を使わないらしい。DXRuby開発版の readme.txt にはそのように書いてある、ように見えた。
■4-7. VertexBufferクラス

(中略) このバージョンではIndexBufferは用意されていません。

ということで、tinywavefrontobj.rb に、いくつかオプションを追加して、DXRubyから使えるデータにも変換できるように修正。

_mieki256/tinywavefrontobj

とりあえずだけど、DXRuby で使えるデータを出力したいなら、--no-index --zflip --color --hexcolor オプションをつければなんとかなる、かなと…。
ruby tinywavefrontobj.rb sample.obj --no-index --zflip --color --hexcolor --json > sample.json
オプションの効果は以下。
  • --no-index : 頂点インデックス配列をつけない。
  • --zflip : z値を反転。OpenGLとDirectXはz軸の向きが逆、らしいので。
  • --color : 頂点カラー配列も出力する。とりあえず、Wavefront形式(.obj)ファイル内の、マテリアル(材質設定)のdiffuse色を、頂点カラーとして代用。
  • --hexcolor : 色を 0xAARRGGBB の形で出力。

jsonファイルにしておけば、Rubyスクリプト側では以下のように書いて読み込める。
require 'json'

...

vertex_array = nil
normal_array = nil
uv_array     = nil
color_array  = nil

File.open("sample.json") { |file|
  hash = JSON.load(file)
  vertex_array = hash["vertex"]  # 頂点配列
  normal_array = hash["normal"]  # 法線配列
  uv_array     = hash["uv"]      # uv配列
  color_array  = hash["color"]   # 頂点カラー配列
}

ところで、色の並びは 0xAARRGGBB でいいのかしらん。DirectX はそのへんどうなってるのかググってもよく分からなかったのだけど、0xRRGGBBAA とか 0xAABBGGRR もあるのだろうか…。

Matrixクラスで少し悩んだり。 :

_RubyのMatrixクラス の中に look_at() なんてメソッドは見当たらないのに、サンプルは動いているぞ、どういうことだ? などと悩んでしまったりして。

コレ、DXRuby開発版自体に、Matrix という名前のクラスが含まれていたのですな…。考えてみたら、DXRubyのサンプル側では require 'matrix' が書かれていないから、Ruby標準添付ライブラリの Matrix じゃなくて DXRuby が持ってる Matrix が使われるのだな…。

_3度目のVectorとMatrix - mirichiの日記
_[Ruby][DXRuby] DXRuby ユーザのための 標準添付ライブラリの紹介(前編) - あおたくノート

DXRuby側の Matrix はゲーム用に特化したものらしい、とメモ。更に、Ruby標準添付ライブラリには、 _Vectorクラス もあるのですな。これも DXRuby側で独自のクラスを持っている、と…。

しかし、たしかにコレ、ちとハマりそうな気がする…。クラス名をビミョーに変える等は難しいのだろうか…。いや、難しいからこうなってるのだろうけど。

参考ページ。 :


2017/03/16(木) [n年前の日記]

#1 [ruby] 3Dモデルデータファイルを読み込んでRubyから使いやすい形に整形するRubyスクリプトを書いた

Ruby + gosu + opengl で実験する際、一々モデルデータを紙に描いて座標を決めて配列にしていくのが面倒臭かったので、Wavefront形式(.obj)の3Dモデルデータファイルを読み込んで、Rubyから使いやすい形に整形して標準出力に出力する Rubyスクリプトを書いてみたり。

_mieki256/tinywavefrontobj

tinywavefrontobj.rb というファイルをダウンロードして実行すれば使える、はず。

Wavefront形式の全ての属性に対応してるわけではないけれど、実験用の頂点配列、法線配列、uv配列、面配列(頂点インデックス配列)をちょこっと作りたい時にはひとまず使える、のではないかなと。

使用例その1。 :

例えば、blender でこういうモデルデータを作成して、Wavefront(.obj)形式でエクスポート。

tinywavefrontobj_ss01.png

ちなみに、Wavefront形式は、三角形ポリゴンと四角形ポリゴンを混在できるのだけど…。後になってからRubyスクリプト側で、面配列(頂点インデックス配列)のみを眺めてそれぞれ三角ポリゴンか四角ポリゴンかを判別するのはおそらく不可能。故に、エクスポート時に「三角面化」にチェックを入れて、全てのポリゴンを三角ポリゴンにしちゃったほうがいいと思う。

tinywavefrontobj_ss02.png

tinywavefrontobj.rb を使って整形出力。
ruby tinywavefrontobj.rb sample.obj

こういう結果が得られる。
@vertexes = [
  1.0, -1.0, 0.0,  # 0
  -1.0, 1.0, 0.0,  # 1
  -1.0, -1.0, 0.0,  # 2
  1.0, 1.0, 0.0,  # 3
]

@normals = [
  0.0, 0.0, 1.0,  # 0
  0.0, 0.0, 1.0,  # 1
  0.0, 0.0, 1.0,  # 2
  0.0, 0.0, 1.0,  # 3
]

@faces = [
  0, 1, 2,  # 0
  0, 3, 1,  # 1
]
これをRubyソースに貼り付ければ実験に使えるだろうと。

jsonやyamlで出力。 :

json や yaml でも出力できる。

ruby tinywavefrontobj.rb sample.obj --json > sample.json
{"vertex":[1.0,-1.0,0.0,-1.0,1.0,0.0,-1.0,-1.0,0.0,1.0,1.0,0.0],"normal":[0.0,0.0,1.0,0.0,0.0,1.0,0.0,0.0,1.0,0.0,0.0,1.0],"face":[0,1,2,0,3,1]}

ruby tinywavefrontobj.rb sample.obj --yaml > sample.yml
---
vertex:
- 1.0
- -1.0
- 0.0
- -1.0
- 1.0
- 0.0
- -1.0
- -1.0
- 0.0
- 1.0
- 1.0
- 0.0
normal:
- 0.0
- 0.0
- 1.0
- 0.0
- 0.0
- 1.0
- 0.0
- 0.0
- 1.0
- 0.0
- 0.0
- 1.0
face:
- 0
- 1
- 2
- 0
- 3
- 1

Rubyスクリプト側で、例えば以下のような感じで書けば、jsonファイルを読み込んで、頂点配列、法線配列、uv配列、面配列(頂点インデックス配列)を得られる。
    require 'json'
    ...
    vertex_array = nil
    normal_array = nil
    uv_array     = nil
    face_array   = nil
    File.open("sample.json") { |file|
      hash = JSON.load(file)
      vertex_array = hash["vertex"]
      normal_array = hash["normal"] if hash.key?("normal")
      uv_array     = hash["uv"] if hash.key?("uv")
      face_array   = hash["face"]
    }
    ...
    if uv_array
      puts "use texture"
    end
    if normal_array
      puts "use normal"
    end

RUbyソース内から呼び出して使う。 :

以下のように書けば、Rubyソース内から呼び出して使うこともできる。
    require_relative 'tinywavefrontobj'
    ...
    o = TinyWaveFrontObj.new("sample.obj", true, true)
    vertex_array = o.get_vertex_array
    normal_array = o.get_normal_array
    uv_array     = o.get_uv_array
    face_array   = o.get_face_array
    ...
    if o.use_uv
      puts "use texture"
    end
    
    if o.use_normal
      puts "use normal"
    end

#2 [ruby] Ruby + gosu + opengl でプログラマブルシェーダを利用してみる

_算譜記録帳: OpenGLでの頂点データの扱いの変化 を参考にして、OpenGL 2.0風の書き方を ―― プログラマブルシェーダ(頂点シェーダ、フラグメントシェーダ)を用意して3D描画するRubyスクリプトを書いてみたり。

正直、自分の書いたソースはグチャグチャでアレなのだけど…。Web上で紹介されてるOpenGL関係のソースは、そのほとんどがおそらくC++で書かれてるっぽいので、「Rubyで書くとこうなるよ」てな例としてアップロードしておくだけでも多少は意味があるのかなと。

まずは三角形を描画。 :

まずは、三角形のみを描画してみる。

_gosu_opengl_20a.rb

こんな感じの結果画面に。
gosu_opengl20_ss01.png


ポイントになる部分だけをメモ。
  # プログラマブルシェーダの初期化
  def init_shader
    # 頂点シェーダ(Vertex Shader)のソース
    # gl_position に (x, y, 0.0, 1.0) を渡してる
    vert_shader_src_a =<<EOS
#version 120
attribute vec2 coord2d;
void main(void) {
  gl_Position = vec4(coord2d, 0.0, 1.0);
}
EOS

    # フラグメントシェーダ(Fragment Shader)のソース
    # gl_FragColor に (r,g,b,a)=(0, 0, 1, 1) を渡してるので、青一色になる
    frag_shader_src =<<EOS
# #version 120
void main(void) {
  gl_FragColor = vec4(0.0, 0.0, 1.0, 1.0);
}
EOS

    # (r,g,b,a) の r,g をx,y座標で変化させるのでグラデーションになる
#     frag_shader_src =<<EOS
# #version 120
# void main(void) {
#   gl_FragColor[0] = gl_FragCoord.x / 640.0;
#   gl_FragColor[1] = gl_FragCoord.y / 480.0;
#   gl_FragColor[2] = 0.5;
#   gl_FragColor[3] = 1.0;
# }
# EOS

    # 頂点シェーダを設定
    # ----------------------------------------

    # 1. シェーダオブジェクトを作成
    vert_shader = glCreateShader(GL_VERTEX_SHADER)

    # 2. シェーダのソースを渡す
    glShaderSource(vert_shader, vert_shader_src_a)

    # 3. シェーダをコンパイル
    glCompileShader(vert_shader)

    # 4. 正しくコンパイルできたか確認
    compiled = glGetShaderiv(vert_shader, GL_COMPILE_STATUS)
    abort "Error : Compile error in vertex shader" if compiled == GL_FALSE

    # フラグメントシェーダを設定
    # ----------------------------------------

    # 1. シェーダオブジェクトを作成
    frag_shader = glCreateShader(GL_FRAGMENT_SHADER)

    # 2. シェーダのソースを渡す
    glShaderSource(frag_shader, frag_shader_src)

    # 3. シェーダをコンパイル
    glCompileShader(frag_shader)

    # 4. 正しくコンパイルできたか確認
    compiled = glGetShaderiv(frag_shader, GL_COMPILE_STATUS)
    abort "Error : Compile error in fragment shader" if compiled == GL_FALSE

    # 5. プログラムオブジェクトを作成
    @shader = glCreateProgram

    # 6. プログラムオブジェクトに対してシェーダオブジェクトを登録
    glAttachShader(@shader, vert_shader)
    glAttachShader(@shader, frag_shader)

    # 7. シェーダプログラムをリンク
    glLinkProgram(@shader)

    # 8. 正しくリンクできたか確認
    linked = glGetProgramiv(@shader, GL_LINK_STATUS)
    abort "Error : Linke error" if linked == GL_FALSE

    # 9. シェーダプログラムを適用
    glUseProgram(@shader)

    # 設定が終わったので後始末
    glDeleteShader(vert_shader)
    glDeleteShader(frag_shader)

    # シェーダに渡す属性のインデックス値(0,1,2,3等)を得る
    attr_name = "coord2d"
    @coord2d = glGetAttribLocation(@shader, attr_name)
    abort "Error : Could not bind attribute #{attr_name}" if @coord2d == -1
  end
OpenGL 2.0 でシェーダを用意する手順としては…。
  1. シェーダオブジェクトを作成
  2. シェーダのソースを渡す
  3. シェーダをコンパイル
  4. 正しくコンパイルできたか確認
  5. プログラムオブジェクトを作成
  6. プログラムオブジェクトに対してシェーダオブジェクトを登録
  7. シェーダプログラムをリンク
  8. 正しくリンクできたか確認
  9. シェーダプログラムを適用
更に、1から4までは、頂点シェーダとフラグメントシェーダの2回分、処理を行うようで。

_DXRubyのShader と同様なのだけど、Ruby + OpenGL を使って実験する際、Rubyスクリプトのソース内に、シェーダプログラム(GLSL)のソースを直接ずらずらと書けるあたりはありがたいなと。気軽に実験できるというか。

もう少し複雑な描画をしてみる。 :

正直なところ、シェーダをどんな風に書けばいいのかまだ全然分かってない状態なのだけど。以下の記事で参考として紹介されてるシェーダを使わせてもらって、もう少し複雑な描画を試してみたり。

_床井研究室 - 第1回 シェーダプログラムの読み込み
_床井研究室 - 第2回 Gouraud シェーディングと Phong シェーディング
_床井研究室 - 第3回 テクスチャの参照

Rubyスクリプトは、こんな感じに。

_gosu_opengl_20g_read_json.rb

  • jsonファイルになってるモデルデータは、tinywavefrontobj.rb を使って用意した。
  • 頂点シェーダのソースファイル(.vert)と、フラグメントシェーダのソースファイル(.frag)は、前述の参考記事内で紹介されてるものを利用させてもらって実験。

結果画面は、こんな感じに。



ということで、Ruby + gosu + opengl を使っても、OpenGL 2.0風の書き方はできるみたいだなと。

課題。 :

今回、マテリアル(材質設定)を一種類に決め打ちして描画したけれど。複数のマテリアルを使ったモデルデータを描画したい場合は、どういう書き方をすればいいのかなと…。

_glBegin と glEnd を使って描画した場合 は、処理が遅い代わりに、ポリゴン一枚ごとに材質設定をし直すこともできたので、複数のマテリアルを使っていても描画ができたけど。頂点インデックス配列を渡して一気に描画する場合は…。

もしかしてそのあたり、マテリアル毎に分割した頂点インデックス配列を用意して対応することになるのだろうか。それとも、「この面にはこのマテリアルを使う」てな指定も可能になる書き方があったりするのだろうか。マテリアル情報をVRAMに転送しておいて、マテリアルインデックス配列を渡して、みたいな。…そんなことできるのかな。

テクスチャを使ってる時と使ってない時で、違うシェーダを使って処理してるあたりも気になる。1つのシェーダでどちらにも対応できないものか…。

参考ページ。 :

#3 [prog] オンボードビデオ上でのVBOって意味あるのかな

ここ数日、OpenGL関係の勉強をしてるのだけど、なんとなく疑問が。

メインメモリ上に頂点配列その他を置いておくとアクセスが遅くなるから、GPUが管理してるメモリにその手のデータをあらかじめ転送しといてそっち使うと速くなるよ、ソレをVBOって呼ぶよ、みたいな話があるわけだけど。

今時のPCってオンボードビデオが多かったりするし、そのオンボードビデオはVRAMとしてメインメモリを使ってるわけで。そんな状況下で、GPUが管理するメモリ上にデータを転送してみても、速度の違いが出るのかなと。結局どっちもメインメモリを使ってるやん、と。VBOが有効だったのは、高速なメモリを入手するのがコスト的にちと厳しくてビデオカード上にしか載せられなかった時代、3D描画したかったらGPUが載ったビデオカードを増設するのが当たり前だった時代、そんな時代の話だったりしないのだろうかと。

もちろん今でもゴイスなビデオカードはフツーに売られてるし、複雑な3D描画をしてるゲームを遊びたいなんて時はデスクトップPCを買ってビデオカード増設して、てのが当たり前だったりするから、VBO的なソレがは有効な場面がほとんどやで、とも言えそうだけど。

でも、CPUの中にGPUまで入っていて、ソレを使って画面表示してるPC上では、どの程度意味があるんだろうと。意味があるとしたら、それは何故なんだろうと。CPUもGPUも同じ速度のメモリを使ってるはずなのに、どのあたりの仕組みで速度差が出てくるのだろう…。

いやまあ、「それなりのスペックのPCではそれなりの速度で描かれるけど、ゴイスなビデオカードを積んでるPCではゴイスな速度で描かれるのだから、後者を意識してソースを書くべき」という方針もアリなのかな。逆に、「今時皆が持ってるのはえてしてそれなりレベルのPCなんだから、それなりの速度で動いて、その代わりソースが書きやすければそれで十分じゃん」てのもアリかもしれないけど。

まあ、そんな疑問を持ちました。とメモ。

#4 [nitijyou] 親父さんが退院

手術も無事に済んで今日の午後退院。

もう1回手術しないといけないはず、なのだけど。何故か、次回対処すべき患部が、今回の検査中に見つからなかったそうで。造影剤が少なかったのか、それとも前回の手術で状態が変わったのか分からないとのことだけど、映像は撮れているので探してみるとお医者さんは言ってたらしい。どのみちしばらくしたら診察しないといかんので、その時には状況が分かるのだろう…。

以上、3 日分です。

過去ログ表示

Prev - 2017/03 -
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 31

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project