• マインクラフト リソース等の構造について解説 (途中その①

    2019-10-12 22:25
    (この記事はまだ作成途中です。予告なしに追加、一部変更がされる可能性があります。)

    初めに 

     このブロマガ、シリーズでは末っ子的な解釈でのマインクラフトJEのリソース又はリソースパックの構造などについて解説していきます。

     マインクラフトでブロックを設置すると一口にいっても、何個かのプロセスを経て、その結果として目に見える形でブロック設置は行われます。
    自分でリソースパックを作成・開発を行う際、この何個かあるプロセスのうち、一つでも正しい記述・構成に整えられていないものが含まれていると、想定していた結果が得られません。

     各プロセスについて正しい知識・見解を持ち、上手くいかなかった場合の傾向と対策を知ることは、リソースパック開発の効率化においてとても重要であると僕は認識しています。

     内容はかなり多岐にわたりますし、僕自身なにか覚書に残してきたわけではないので、結構な範囲での情報の漏れがあると思います。
    さらに専門的な部分で、本来の用途、事実と異なる表現をしている可能性があります。

     このブロマガはあくまで末っ子的な解釈での解説する記事です。上記のことを了承した上で、あくまで参考程度にご自身のリソースパック開発にお役立ていただければ幸いです。




    ブロック設置等を構成する各プロセス解説

     この記事では、マインクラフトでワールドデータの特定の座標のブロックIDを何かしらの手段でもって別のブロックIDに変更することをブロック設置であると仮に定義しています。
    これには、特定の座標のブロックの ●ダメージ(メタ)値変更 ●エンティティの変更 ●NBTの変更 ●バイオームの変更 ●光源レベルの変更 などは含まれません。

     マインクラフトでは、1.リソースデータの読み込み、2.ブロック設置に際して下記のプロセスを経た上で、クラフターの目に見えるようになります。


    1.リソースデータ読み込み


    1-a.リソースデータの配置。
    1-b.圧縮したブロックデータをRAMに保存、すぐに使えるようにする。


    1-a.リソースデータの配置について

     リソースパックによる変更等なければ基本的には省略されますが、あった場合読み込んだリソースパックの優先順位などを基に、バニラであるリソースデータを含めテクスチャのデータ、モデルのデータ、ブロック設置の規則のデータ、音や言語等に関するデータ等を機械的に読み込むために都合のいいように再配置、圧縮を行います。


    1-b.圧縮したブロックデータをRAMに保存

     使用しているマインクラフトのバージョンのjarファイル内のcomフォルダーの内容に従い、
    ・ブロック設置の規則
    ・モデルデータ
    ・テクスチャデータ
    をRAM 所謂メモリーに一時的に保持します。


    2.ブロック設置


    ⓪ブロックデータをRAMに保持
    ①ブロック設置に関するイベント
    ②ブロック設置の規則の指定
    ③ブロックモデルを設置
    ④ブロックの設置状況に応じて周囲を含むブロックのテクスチャを変更する。


    ⓪ブロックデータをRAMに保存

     基本的に上記1-bと同じ。ただリソースデータとは別枠で、ブロック本体のイベントのデータ、ブロック設置に関するイベントのデータ等もブロック設置には関わることになるので、これらも同様にRAMに保持されます。


    ①ブロック設置に関するイベント
     マインクラフトのブロックは(1)条件や(2)クラフター等のとる行動などにより(3)多様な種類、異なる状態のがそれぞれ指定されます。
     (1)条件
    ・クラフターのゲームモード
    ・クラフターの位置座標
    ・クラフターの目線の角度
    ・クラフターの目線の先にあるブロックの種類や状態
    ・選択しているアイテムの種類
    等です。
     (2)クラフター等のとる行動
    ・上記(1)の条件を踏まえた上でブロック設置のボタン(デフォルトであればマウス右クリック)を押す。
    ・コマンドの入力によりブロックの設置をする。
    ・クラフタ―以外のmobAIの活動。
    ・時間経過・天候によるランダム要素を含む変化活動。
    ・人工的なものを含むマインクラフト特有のギミックによる変化活動。
    等です。
     (3)ブロックの種類・状態
    上記(1)の条件を踏まえた上で
    ・設置するブロックのID
    ・同じIDでの異なる状態
     (・ブロックの向き
     (・周囲のブロックの向き、状態に合わせた種類や複数適用されるモデル
    ・自然な落下

     マインクラフトで内部的に行われるイベントは、僕の認知している現状リソースパックによってユーザーサイドから介入、変更をすることは一部を除きできません。
     ブロック設置に関するイベントに変更、追加を行うには、新規・既存のMODの開発・導入、などを行う必要があります。

    イベントに関してリソースパックでできないこと

    ・ブロックのあたり判定の変更
    ・ブロックIDの追加
    ・ブロック設置の条件の追加・変更

    イベントに関してリソースパックでできること

    ・再生する音源ファイルの追加・変更


    ②ブロック設置の規則の指定

     上記ブロック設置に関するイベントを通して、適用するブロック設置の規則【blockstates】を指定します。
    blockstatesはリソース内のassets/minecraft/blockstates内に各ブロックごとに配置されています。
    blockstatesのファイル名は基本的にデフォルトのもの以外に変更することはできません。

     バニラではない、forge MODによりブロックが追加されている場合、assets/minecraft以外の別のフォルダーに配置されます。

    例①ConquestReforged-3.0.2-mc1.12.2の場合
    assets/conquest/blockstates内

    例②cocricotMOD for 1.12.2の場合
    assets/cocricotmod/blockstates内


    ブロック設置の規則には、2019/10 packformat:4の現在、variantsmultipartの二つの形式があります。

    variantsは一つの座標につき、設置条件などによって異なる単一のモデルを適用するもの。
    multipartは一つの座標につき、設置条件などによって異なる複数のモデルを適用するもの。

     例えばアカシアの木材のフェンスの場合、フェンスの設置されている場所から北と東にブロックが接続されているモデルがあるとします。



     これをvariantsで分解して考えると、北と東にブロックを接続された状態のモデル(acacia_fence_ne)単一を適用しているとなります。



     また、multipartで分解して考えると、
    ①中央に柱のモデル(acacia_fence_post)
    ②北に向けてフェンスの側面接続時のモデル(acacia_fence_side)
    ③東に向けてフェンスの側面接続時のモデルをY軸を基準に90度回転させたもの

    の以上三つのモデルを1つの座標に同時に複数適用している ということになります。



    アカシアのフェンスでの、それぞれの形式の特徴ですが、

     variantsでは一つのブロックの変異体を全て表現するにあたり、最低で6種類(無接続、N接続、NE接続、NS接続、NES接続、NEWS接続)のモデルが必要になります。
     multipartでは1つのブロックの変異体を全て表現にするにあたり、最低で2種類(柱、側面接続)のモデルが必要になります。

     リソースパックを作成しているバージョンで、デフォルトでmultipartが適用されているblockstatesをリソースパックでvariantsのblockstatesに変更することはできます。(逆はできるか忘れた。

    また、multipartの記述ができるのはpackformat:2以降のリソースパックがつかえるバージョンでだけで、packformat:1以前のバージョン JEでいう1.9よりも前の1.8.xのバージョンではvariantsでの記述しか行えません。











  • 広告
  • 【CIT】MODの力で3Dテクスチャを増やそう!STEP2-A 自作リソースパック導入編【Optifine】

    2018-06-04 20:58
    少し時間が空いてしまいましたが、前回(【CIT】MODの力で3Dテクスチャを増やそう!STEP1 CITとは?【Optifine】/ar1552048)からの続編でござる。

     今回は実際に自作のリソースパックへ、CITを導入しようというお話です。
    この記事ではモデル自体の作成などに関する解説は行ってません。作成に関するブロマガなどに関してはこちらでURLなどまとめてるので、よかったらそちらご参照くださいな。

     また、このブロマガではA『citフォルダー内にmodelデータを置いて、そこから適用させる』、B『models/blockフォルダー内からmodelデータを読み込んで適用させる』の、2パターンで解説させていただこうと思います。

    前者、A『citフォルダー内にmodelデータを置いて、そこから適用させる』パターンであれば、
    単純にフォルダーごとに管理できるのでリソースパック作成がスムーズになりますし、


    後者、B『models/blockフォルダー内からmodelデータを読み込んで適用させる』パターンでは、他の既存のリソースパック内のモデルを、別の自作パックで読み込んで使うみたいな場合に便利です。
    使い方は人それぞれですね。

    どちらをやるにしても、たいして大きく手順が増えるわけでもなく、すこしファイルの数が多くなったり、引用元の記述をかえるとかそんなもので済みます。どういう意味をもった作業手順であるのか、理解して身に着けることが重要です。

    手順0 用意するもの

    ・自作のリソースパック ・・・上手くいくか不安な方は、コピーしてバックアップなど撮っておくといいかもしれません。

    ・zipファイル解凍or閲覧ソフト ・・・7zip等がおすすめ。解凍せず、zipのまま中身が見れるので、少し手間が省けます。

    ・文章ファイル等のeditソフト ・・・Notepad++がおススメ。なくてもwindows付属のメモ帳などでも編集できますが、あったほうが確実に効率的です。

    この記事では上記2つのソフト、7zip,Notepad++が入っている体で解説をしています。別のソフト入れてるよーという方でも、実際やっていることが同じであれば問題ありませんので、悪しからず。

    手順1 citフォルダーをリソースパックに作成しよう。

     早速、リソースパックの中身をいじっていきます。

    今回ブロマガでの解説するにあたっての末っ子のリソースパック構成はこんな感じ。
    右画面が選択されているリソースパック、下から順番に、

    1 【32x】Halcyon Days“3D”Resource Pack for 1.8 1/01

    制作者いけぞう様

    2 Tachibana TEX 3D【ver 3.1】【Java Edition】
    制作者Tachibana様

    3 自作リソースパック

    の順で構成しています。数字が大きくなるにつれて、リソースパックの読み込み優先度が上がっていく感じですね。
    実際に弄ることになるのは、主に3 自作リソースパックです。他のリソースパックは特にいじる必要はありませんが、そこは臨機応変に。別のリソースパックでも大して手順はかわりません。



     自作リソースパック(今回はパック名1.12.2for_buromaga)のフォルダーを開いた画面です。内容物はassetsフォルダー pack.mcmeta pack.png と一般的。

    このブロマガの記事を読んでる方はある程度の経験を積んだうえでたどり着いた方だと思うので、どこまで説明していいものかわかりませんが、⓪assetsのフォルダーの中に
    ①minecraft
    ②mcpatcher
    ③cit
    の順番でフォルダーを構成していきます。 1.11以降で作成する場合は、フォルダー名に、大文字のアルファベット等は使わないようにしましょう。1.10以前であれば大文字も使えないことはないですが、小文字で統一しておいたほうが無難です。
    ①minecraft ②mcpatcher等のフォルダーがすでにリソースパック内に存在していれば、新たに作成する必要はありません。

    cit適用のための.propertieファイルや.jsonファイルは③citのフォルダーの中に入れておけば動きますが、今回この記事ではこの中にさらに、
    ④items
    ⑤ halcyon_dayz_3d
    ⑤ original
    ⑤ tachibana_tex_3d

    と細分化してフォルダーを作成します。


    手順 A『citフォルダー内にmodelデータを置いて、そこから適用させる』


    ↑これは、木のボタンに適用させたモデルで、①wooden_button.json

    ↑こちらは、作動させた木のボタンに適用させたモデルで、②wooden_button_pressed.json

    これら2つのモデルでやってみましょう。名前をクリックすると、DLできるページに飛ぶようにリンク張っときます。(テクスチャuv適当なのはご愛敬)

    ご自身で作成されたモデル、または準備が面倒であれば上記二つのモデルファイルを用意し、
    手順1で作成した、citフォルダー内のoriginalフォルダーを開き、その中に設置します。

    本来ブロックとして設置する際、blockstatesをいじらないのであれば、上記のままのファイル名が望ましいですが、citでは特に必要ないのと、名前も長ったらしいのでそれぞれgear_0,gear_1と名前を変更します。オリジナルのモデルであればお好きなものをどうぞ。


    変更後がこちら。
    次に、citにこれらのファイルを読み込ませるための、".properties"ファイルを作成します。


    新規でテキストドキュメント”.txt”ファイルを2つ作成。




    ファイル名を ”好きな名前.properties”に変更。
    propertiesファイルが用意できましたら、さっそく中身の編集をします。


    Notepad++など新しく導入した直後であれば、右クリックなどでプログラムを選択して起動します。


    編集画面がこんな。当然出来立てほやほやのファイルですから、中身はからっぽです。
    ここに各命令文?パラメーターなどを入力していくわけです。

    citのpropertiesファイルで記述するものとしてはこちらの公式サイトで軽く紹介されていますが、これがそのまま読み解けるのであれば、こんなブロマガ必要ないですよね?それだと少し寂しいので改めて解説させていただきますが、

    ==========================================

    matchItems=
     ・・・citを適用させるアイテムのIDを指定します。これは複数種類のアイテムに対して同時に指定することができます。アイテムIDに関してはこちらのIDリストから参照するか、
    ゲーム画面、オプションやインベントリ、チャット画面など開いていない状態で、
    F3+Hを入力していただけると、Advanced tooltips(選択しているアイテムのIDやnbtタグなどを確認できるモード)を使用できるようになります。

    nbt.display.Name=
    ・・・citが適用されるアイテムのdisplay nameを指定します(金床などを使用して設定できる名前のこと)。
    の先の書き方としては ipattern:*[ここに好きな名前]*
    [ ] は別にいれないです。 display nameに使用できる文字としては、基本的にアルファベット。リソースパックに使用するファイル名と違い、ここでは大文字、小文字両方ともに使用することができます。ここで大文字でdisplay nameを指定したとして、ゲームで名前を変更するときは、大文字小文字関わらず、同じファイルを参照するようです。
    (ここでGEARと名前を指定しても、ゲームではgear Gear GEARどれでも同じモデルがでるということ。)又、上記アルファベットのほかに簡単な記号なども使用することができるようです。


    tile=
     ・・・モデルに張り付けるテクスチャーファイルを指定します。
    モデルjsonファイルですでにテクスチャが指定されている場合は省略することができます。
    ①.propertiesファイルがおかれているフォルダーと、同じ場所にテクスチャファイルがおかれている場合はそのままテクスチャのファイル名を。
    ②別のフォルダーにテクスチャがおかれている場合はそのフォルダの場所を指定した上で、テクスチャを指定します。

    例① .propertiesフォルダ内にある、"gear.png"というテクスチャファイルを読み込む場合。
    tile=gear

    例② texturesフォルダ内、blocksフォルダ内などにテクスチャファイルがある場合
    tile=assets/minecraft/textures/blocks/gear


    model=

     ・・・citで使用するモデルファイルを指定します。
    今回の記事ではモデルファイルはすべて.propertiesファイルが置かれているフォルダーとおなじ場所に.jsonファイルも置くことにしますが、これも上記tileと同じように読み込むフォルダーを指定することができます。

    ==========================================
    と、凡その概要がこんなですね。

    これを、今回作成するgear_0,gear_1の.propertiesで実際に記入すると↓こんな感じになります。


    gear_0.properties


    gear_1.properties

    matchItemsでは、木の剣(268)、石の剣(272)、鉄の剣(267)を指定し、
    nbt.display.Nameではそれぞれの名称
    modelでは先に用意したモデルファイルを指定してます。
    今回モデルファイルですでにテクスチャが指定されているため、tileは指定していません。

    ⓪プロパティが記入できましたら、
    ①そのまま上書き保存、
    ②ゲームでリソースパックが適用されているのを確認したうえで、
    ③読み込み。
    ③´読み込みがすでにできているのであれば、ゲーム画面でF3+Tでリソースパックをリロードします。

    さて、無事導入できているか確認してみましょう。

    鉄の剣を取得し


    金床で名前を変更


    名前を”gear_0”に・・・


    おや・・・?




    どうやら無事に適用できたようですね。


    ”gear_1”でも導入成功を確認。 でかいでかすぎる。


    額縁に貼ってみてもひとまず問題はないようですが・・・?


    実際にブロックに適用されているモデルと比べてみると案外大きさに差があるのがわかりますね。


    それに手に持っていたり、インベントリ枠でも、大きさのギャップというか、少し主張が激しすぎて邪魔くさく感じますね。

    これらの解消をする手順、またB『models/blockフォルダー内からmodelデータを読み込んで適用させる』パターンの手順の解説はまた次回のブロマガで。

    それでは。

  • 【CIT】MODの力で3Dテクスチャを増やそう!STEP1 CITとは?【Optifine】

    2018-05-31 23:13
    どうも末っ子です。

     今回のブロマガは、クラフターの間で今地味にじわじわブームが起きつつある、自作3Dテクスチャー・・・に便乗してお送りする、Optifineに同梱されている機能の一つ、
    Custom Item Textures 略して CIT を
    みんないじってみようぜ!っていう布教する目的の記事になります。

     一から全部丁寧に解説~という感じの記事が書けたらいいんですが、生憎僕もまだCITに関しては触り触りやっている段階なので、あまり自信はありません。まだ触り始めて3日程度ですので。
     なので、あれこれ説明、解説するにあたって言葉足らずになることも多々あるかと思いますが、そこはこの記事を読んでるあなたもきっと立派なクラフターだろう、ということで、実際に触ってみながら、この記事を読んでいただけたらと思います。


    STEP1  CITってなんなの? CITを知ろう!

    各種リンク類

    ↑何となく勢いで作った動画。別にこれを見なくてもさほど支障はないです。興味があったら見てね。

    https://bitbucket.org/prupe/mcpatcher/wiki/Custom_Item_Textures
    ↑本家?CIT解説というかCITが出てきたところの説明ページ


    CITとは?

     さて、そもそもCITとは何なのか という話。ある程度前提となる知識が必要になるかもしれません。わからない単語があれば、Twitterで質問するか、ぐぐるかしてください。

     まず、古くからクラフターに親しまれてきたMODで、”Optifine”または”mcpatcher”というものがありました。
    Optifineは主にMinecraftの描画関係、各種映像系の設定を細分化し、映像をより綺麗にまたは動作を軽くさせることを目的としたもの。
    mcpatcherは、Minecraftでつかわれているテクスチャーに、特定の規則性を持たせて上書きする形で、追加のテクスチャーを張り付けることを目的としたMODです。
     今日ではmcpatcherは一部?Optifineに吸収され、最新のOptifineを導入すれば、mcpatcherは同梱されていますので、別で導入する必要はありません。

     今回紹介するCITは、そのmcpatcherにある機能の一つです。
    他にmcpatcherの代表的な機能の一つとして、みなさんにも親しみがあるだろう”CTM”というものがあります。

    【minecraft】縁の下の力持ち?CTM解説講座!【再編集版】http://ch.nicovideo.jp/ebibagamon72/blomaga/ar294668

    ↑エビバーガモンさんのCTM解説ブロマガ

    ”CTM”はMinecraftにおいて、Tile・ブロックに張り付けるテクスチャデータ、terrainに規則性を持たせてテクスチャを追加するための機能。これのおかげで、本来テクスチャが変わらないはずのメタ数値を持ったブロックに新たにテクスチャを追加したり、設置条件によってテクスチャを変更して張り付けたりといったことができます。

    ”CIT”は、上記CTMでテクスチャの変更をすることができないアイテムや、プレイヤーが身に着けた防具に、特定の”データ値”を指定し、モデル、テクスチャを指定する機能。

    ”データ値”とは 又はNBTフォーマット マインクラフトの各種データを保存するために使われる特殊な形式。 今回の記事ではその中で主に、アイテム類の損耗具合であったり、どんな名称をつけられているか、みたいな趣旨で表記しています。


     あれこれごちゃごちゃ書いてきましたが、早い話がブロックじゃないアイテム類のテクスチャを、金床で特定の名前を付けた時や、特定の消耗度になった時だけテクスチャやら見た目を変えるのがCITの機能です。

    さぁなにはともあれ実際に触ってみないことには始まりません。やってみようそうしよう。


    CITを触ってみよう!

     お手軽?にCITで遊んでみるため、一般的に配布されているリソースパックで、CITの機能を使用しているものをつかって、実際にCITを体験してみましょう。

    1.まずは環境の準備だ。

     今回このブロマガでは、

    [1.12.2] compatible Conquest_ 32x32 を使用します。
    ↑をクリックすると、DLページに飛びます。まだ持ってない人はDLして適用できるようにしましょう!


     また、CITやCTMの機能を使用するにあたって、Optifineが導入されているMinecraftが必要です。https://optifine.net/downloads ←こちらからOptifineの元ファイルをDL、導入しましょう。リソースパックに併せてver1.12.2の物を使いましょう。末っ子はOptiFine 1.12.2 HD U D1を使用しています。

     次に、Optifineの導入されたMinecraftで、CITの機能が使えるか確認してみましょう。


    ゲーム画面でOptions(設定)をクリック


    Video Settings(ビデオ設定)をクリック


    Quality(品質の設定)をクリック  この時点でこのボタンが表示されていなければ、Optifineが導入されていないMinecraftでやっているってことになります。ランチャーをもう一度確認してみてね。


    Custom Items(カスタムアイテム) この項目がONになっていればCITが使える設定になっているということですね。

    上記環境準備、確認が終わったら、さっそくconquestを読み込んでいきます。

    2.ConquestのCITをいじる!


    Conquest クリエイティブ ゲーム画面です。 地面が砂岩になってますが、これは生成するときに設定をいじっただけなので特に気にしないように。




    手持ちインベントリに、鉄の剣を幾つか、それと金床を用意し、設置します。


    そのまま金床を右クリックして編集GUIへ 鉄の剣をセットして、
    名前が"Iron Sword"となっているのを"Angelic fork"に書き換えます すると・・・?


    鉄の剣の見た目が変わり、どっかのアニメでみたことあるような槍になります。


    この通り、実際手に持つこともできますし。

    アーマースタンドや、額縁に飾ることもできます。

     他にも同じ鉄の剣でも
    • assegai
    • ballheaded warclub
    • bardiche
    • bastardsword
    • bronzeaxe
    • Large axe
    • Bearded battleaxe
    • Billhook
    • boneclub
    • broadaxe
    •  
    •  
    •  

    などなどなど  たくさんの武器のテクスチャがConquestでは用意されているようです。(90種類近く?)
     武器のほかにも、防具、盾、エリトラにも同様の機能が使用されています。専用のwikiページにも、それらの一覧や動画などが挙げられているので、そちらをみてみるのもいいかもしれません。

     といった感じで、これがCITの機能です。
    実際の所バニラ、MODなしのリソースパックでも、UDVMと呼ばれる微妙に似たような機能、技術もあるのですが、
    ・UDVMだとアイテムを変更させるのに実質的にコマンドが必要。
    ・一方こちらCITでは、MODの導入が前提となりますが、金床を使うだけで変更させることができます。
    なので、CITのほうが、リソースパックを実際に使用する人にとっては親しみやすい&サバイバルモードでも使用しやすい機能となっているので、よろしいのではないかと個人的に思っています。


     次回の記事↓

    【CIT】MODの力で3Dテクスチャを増やそう!STEP2-A 自作リソースパック導入編【Optifine】