v2020が国内でもリリースされていますが、モデリング関連の進展が皆無だったのが、個人的には残念でした。。LWは曲がりなりにも統合ソフトなので、モデリングとアニメーションは極力足並み揃えてアップデートして欲しいものです。
今回唯一のモデリング新機能はアクションセンターのローカル（以下AC:Local）ですが、触ってみると、ちょっとマズイ事に気が付きます。
結論を書くと、ローカルの位置はローカル中心になってますけど、方向がローカル軸ではなくて、ビュー座標の奥行軸方向になっていますよね。これではローカルと言えないと思うのですけど。。仮に自分がこの仕様で命名するとすれば、AC:Group　がしっくりきます（笑。
で、こんなローカル仕様だと実機能的にどういうことになってしまうのか。ってことを図で説明しようと思ったのですが、あるユーザーさんが同じ疑問で動画上げてたので、そちらを参照下さい。
https://www.youtube.com/watch?v=xd1EUGwS1uk

それから、見も蓋も無い事を書きますけど、個人的にはローカルはアクションセンターとして実装するよりも、個々のツール側のオプションとして実装した方がしっくり来ると思います。何故かって言うと、ローカルの定義を複数ボタンとして分ける事が出来るからです。例えば、
a.平面メッシュ時の平均法線軸を基準とするローカル軸設定と、
b.立体メッシュ時のビュー座標奥行軸を基準とするローカル軸設定。
又はその他ローカル基準と言った具合に、ツールによって定義を複数持たせる事が可能になります。ちなみにb項は本来オブジェクト座標としてのローカル軸になるはずなのですが、周知の通りLWモデラーにはローカル座標の概念が無い為、b項のような変なローカル基準になります（これが現在のAC:Localです）。それから、現在のTransformツールのようにAC:Localに対応していないツールがありますけど（これも、おかしな事ですけど）、どのツールがローカル対応してて、どのツールが対応していないのか？と言った機能制限？に関しても、ツール側のオプションにすればローカル定義ボタンの有無だけで機能の有無が判断出来るので明確になります。
ま、結局何が言いたいかって言うと、特にモデリング関連の機能やツール開発はｖ9以降からずっーとマズイ感じだなぁ、ってことが言いたいだけで、つまりは単なる愚痴ですね。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

v2020ではMatt Gornerが開発のエンジニア枠から外れ、コントリビューター（貢献者）側に移動しています。この方は元々非プログラマーなので、主にUIデザインの開発に携わり、v10から変更されたダークUIなんかは彼の仕事です。現在、LW3DG側よりNT側の仕事をメインにされているようです。

プログラマー総数に関してはv2019→v2020で変化無しですが、LW3DGの責任者Andrewさんはv2020に於いてもエンジニア枠には居らず、コントリビューター側なので、LW開発への比重は小さい気がします。。Viz傘下になって以降、エンジニア枠は減少しているので、今後、何か明るい情報が欲しいところです。。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

暇つぶしで書いてみました。
何時変更されたのかはわかりませんが、おそらくv2015迄はモデラーのパースビュー上で、Ctrl + ビューの回転アイコンをドラッグすれば、ビューの回転が０°、15°、45°、90°・・と、規定の固定角度でスナップ回転させる事が出来ましたが、v2018辺りから？この仕様が変更されたのかドラッグによるスナップ回転が出来なくなっています。只、v2020でも固定角の機能は残っているので、操作フローだけが変更されている感じです。今回はこのパースビューの固定角の機能に対してストレッチツールが有効なので、その効果を解説してみます。

ストレッチツールは平面ビュー上でマウス操作するのが常套手段ですが、下図のようにパースビュー上で矢印方向に縮小編集する為には・・

まず、左図のように目安でワールド軸を垂直/水平になるようにビューを回転させてから、パースビュー上でストレッチ(Ctrl+ドラッグ）操作します。すると右図のように編集出来ますが・・

結果を平面ビューで確認してみると、当然下図のように微妙に歪んでしまいます。
（数値入力で実行すれば歪みませんが、これ書くと元も子もありません　笑）

1）で、改めてここからが本題です。
では最初と同じように、パースビューのワールド軸を下図のように大体、垂直/水平になるように回転させておきます。（※この時、ワールド軸の中心位置はビュー上のどこでも構いません。重要なのはビューの水平/垂直に対するワールド軸の傾き度合です。下図程度の傾きであれば許容範囲内です。）

2）次にCtrlキーを押しながらビュー回転アイコンを１クリックします（※v2018以降？では絶対ドラッグしてはイケマセン）。すると、下図のようにパースビューのワールド軸がビューの水平/垂直方向に合致（スナップ）します。この状態で・・

3）パースビュー上でストレッチツールを操作すると、下図のようにワールド軸に完全に平行なストレッチが行えます。

このように半ば無理やりパースビュー上でストレッチツールを使うメリットってのは実のところ余り無いです（笑。そもそも平面ビュー上で操作すれば良いことですし、どうしてもパースビュー１画面で編集したいのなら、ストレッチツールよりもトランスフォームツール等の他のインタラクティブツールでストレッチ編集すれば良いことなので、ま、モデラー雑学ですかね（笑。

Shapeの制限？

Shapeはv2018で実装された実体の無いNullをベースとする仮想のプリミティブタイプです。仮想ジオメトリの為、メモリ消費を抑える等のメリットがある反面、幾つかの機能制限を含みます。マニュアルに書かれてる制限事項にはオブジェクトレベルに関わる具体的な制限内容は書かれていない為、オブジェクトレベルの操作ってのがどの範囲を指し示すのかがはっきりしません。よって以下の幾つかの現象がこの制限由来の仕様なのか、或いは単なるバグなのかの判断が難しくなっています。

・Shapeに適用した3D Texture（所謂、3Dプロシージャル）では、カラーマップとアルファ（変位）マップの位置が合致しません（アルファ側のスケールが小さいように見えます）。又、2D、3D Texture共に、陰のエリア（影では無く）にある変位箇所でライトリークのようなシェーディングエラーが発生してます（図の矢印部）。

3D Textureの場合、Shapeではカラーマップに対して変位（アルファ）マップが合致しません（図上）。

一方、2D Textureではカラーと変位（アルファ）は綺麗に合致しますが（図中）、2D、3DTexture共に
陰エリアにある変位箇所（矢印部）に於いてシェーディングエラーが発生してます（図下）。

・ShapeのCube、Cone、Cylinderの透過屈折処理が正しくない。

図左側がShapeプリミティブで右側がPolygonプリミティブ。

ShapeのCubeとCylinderの上下面とConeに於いて透過屈折処理が正しくありません。

・ShapeのSelf ShadowとCast Shadowオプションの効果が正しくない（Receive Shadowだけ正しい）

ShapeではSelf Shadow OFFの効果が無い。

又、ShapeのCast Shadow OFFではSelfの影も無効になります。

・Sphereのように閉じたShapeプリミティブは片面サーフェスで構成されています。よって、Shapeではダブルサイドオプションを有効にしても両面サーフェスのマテリアルにはなりません。

左はシェイプ球、右はポリゴン球。両方共ダブルサイドオプションを有効にしていますが、

Shapeではワンサイドの透過屈折処理です。

・Planeのように開いたShapeプリミティブは両面フェイスの固定ですが、裏面側のサーフェス設定は無効です。

Shape、Polygon共に表面を赤色、裏面を青色にサーフェス（ノード）設定していますが、
裏面から床へ照射された光の色を見ると、Shapeでは赤色のままなので、

裏面の青色設定が無視されている事がわかります。

・ShapeのPlaneに変位（Displacement）を適用した場合は、その裏面側となるフェイスは全く変位しません。

・Unseen By Rayのオプションを有効にすると、Shapeでは何故かラジオシティの影（オクルージョン）が無効になります（ラジオシティ無効オプションのような効果？）。又、Object Dissolveを100%にするとShapeの影だけが残ります。（これらオプションはオブジェクトレベルの操作なので、おそらくShapeの機能制限なのかなと思います。）

・ライトの除外(Exclude)オプション
ライト（直接光）の除外オプションを有効にすると、Shapeを照射した光とShapeの自己の影(SelfShadow)は除外されますが、Shapeが落とす影（CastShadow)は落ちたままになります（上から２番目の図）。又、ラジオシティ除外オプションを有効にすると環境光が無くなり、直接光の陰のみとなる為、冒頭に指摘したライトリークのようなシェーディングエラーが表れます。（これらも上記同様、オブジェクトレベルの操作なので、Shapeの機能制限だと思われますが、ライト除外の制御がままならないってのはオブジェクトとしてどうなの？って気はします。）

上記のようにオブジェクトレベルの制限であっても普通に操作出来る機能もあるので、Shapeは何が制限で何が機能するのかが分かりずらいです。現状ではバグっぽい現象もありますし、同類機能のオプションであっても機能制限で機能しないボタンと機能するボタンが混在しているので、機能性は更に不明瞭です。機能制限が多いツールは使い所に憂慮するので、もうちっと機能精査、拡張してくれればもっと使い所も増え、扱い易くなると思うのですが。。

マルチUVです。

マルチUVとは同一サーフェイスの同一頂点上に複数のUVマップをアサインする事です。

図では板の全上面のUVと、６か所の選択エリアにボルト用のUVマップを設定しています。板のUVに対してボルトのUVは同一頂点上にあるUVなのでマルチUVになります。

Color Layerノードを使って、下層レイヤーに板テクスチャ（板UV）、上層レイヤーにアルファチャンネルを持つボルトテクスチャ（ボルトUV）をアサインすると、図のようにマルチUVとして問題無くレンダリング出来ます（が、以下のような問題が出る場合もあります）。

Imageノードで上層(FG)をボルトUV、下層(BG)を板UVでリンクすると、図のようにボルトUVのアイランド境界に於いてテクスチャが破綻します。

MixerノードでマルチUVしても同じく破綻。

テクスチャの合成では無く、マテリアル合成でも破綻します。

LWはマルチUV対応してるようで、してないそぶりがツンデレっぽくて萎えます。

これらはマルチUVマップを不連続UVに変換する事で回避出来ますが、そのワークフローはお世辞にも適切とは言い難く、むしろ裏技的なアプローチと言っても良いぐらいです。以下にその回避手順（２通りの方法）を載せておきます。LWのUVは昔からこんな仕様なので、例えばMayaのUVセットのようにマルチUVとしての仕様をきちっと確立して欲しいものです。。

●上図全てのノードネットワークで、マルチUVで正しく描画させる為の２通りの方法を以下に示します。

・方法その1

マルチUVをポリゴン選択します（このケースではボルト用のUVマップ）

１項で選択したポリゴンを切り取り（Cut）ます

UVビューに残されたポイント全てを選択します

移動ツールで選択ポイントをUV0.0～1.0範囲外に移動させます

2項で切り取ったポリゴン(UV)を貼り付けます

（補足：ポイント選択を解除していれば、7項に進んで下さい。

この手順通りにポイント選択を解除していなければ、6項で解除して下さい。）

5項のポイント選択を解除します

2、５項でカット＆ペーストしたポリゴンを再結合する為にポイント結合を実行します

UV0,1範囲外にあるUVポイントを選択

8項で選択したUVポイントを消去します。

以上で完了。

冒頭のImageノードで再度レンダリングすると、マルチUVでもテクスチャが破綻しません。

勿論、他のノードネットワークに於いてもこの方法で回避可能です。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
方法その2　（推奨は方法その1）

1）マルチUV（図ではUV_Bolt）を全てポリゴン選択し、Mapタブ ＞ Ajust Poly Mapを実行し、同パネル内のVertex Map欄に当該UVマップを指定（図ではUV_Bolt）し、OKボタンをクリック

2）"Free Move"ボタンを必ず有効にしてから、移動（Move）ツールでUV0.0～1.0の範囲外にUVマップをドラッグ移動します（※この時、移動ツールに"Transform UV"を使ってはイケマセン。このツールは選択UVと同位置にある全てのUVポイントを移動します）。

3）UV0.0～1.0範囲に残されたポイント（図では9ポイント）全てをポイント選択。

４）Mapタブ ＞ Clear Mapを実行し、３項で選択したポイントを消去。

5）移動（Move）ツールでUVを元の位置へ戻します。以上で完了。

（尚、移動ツールの数値入力パネルにあるApplyボタンではUV移動は出来ません）

ノーマルマップ合成です。

ペイントソフトでカラーチャンネルとブレンドモードを使って合成する昔ながらの合成方法をLWのノードに置き換えただけなので何の工夫もしてません（笑。
本来ペイントソフトで行うマップ合成処理をLWでやるのは畑違いと言うか、非効率でやるべきではないのですが、例えば3Dサーフェスにノーマルマップの合成アニメーションを行いたい場合であれば多少の価値はあるかと思います。ノード構成は見ての通りシンプルなので説明は以下に大雑把にしておきます。
R,GチャンネルをOverlayで、Bチャンネルを乗算で合成してます。で、LWのImageノードのブレンドモードにはOverlayがありませんので、見ての通りCompoundノードでOverlay計算をノード構成してます。合成したノーマルマップ画像をダイレクトにマテリアルのNormal入力に接続したい為に（合成アニメーションの為に）、DPさんのObject Tangentノードを使って、ColorベクトルをNormalベクトルへと変換してます。

以下のテスト動画はノーマルマップの合成アニメーションです。
（傷模様の入ったマップとLWロゴマップの合成です。）

以下、LWでの合成処理の理屈を書いておきます。
以前にも少しだけ記事にしてますが、フリーペイントソフトのKritaにはノーマルマップペイント機能があって、且つノーマルマップの合成モードもネイティブで実装しています。Kritaのレイヤーブレンドモードの"その他"の項目に"法線マップ結合"と言う、まんまのブレンドモードがあります。そのモードを合成レイヤーに適用することで、下層レイヤーとのノーマルマップ合成が可能になっています（下図参）。（ちなみにこの"法線マップ結合"のアルゴリズムはPS用スクリプトのCombine Normalと同じものです。）

と言ったように、kritaでは一発合成する為のブレンドモードが存在しますが、当然LWにはこの"法線マップ結合"のような機能は存在しません。そこで先述のカラーチャンネルに対しオーバレイと乗算計算を以って、類似の合成処理を行うことになります。それが下図の理屈になります（下図左側の各パネルUIはKrita）。

https://www.lightwave3d.com/about_lightwave_group/

LightWaveGroupの新たな管理者が決まったようです。
それと同時にLWGroup"専任の役職"は無くなったようです。
・Vizrt最高責任者：　Micheal Hallen
・Vizrt米国社長：　Daniel Nergard
・VizrtR&D社長（元NT社長）：　Dr. Andrew Cross
LW開発を担う直接の責任者はAndrew Crossです。
この方は過去（大昔）LWに精通してた人ではありますが、LW専任の役職では無いので今後どのレベルで開発に介入されるのかは未知数です。ですが、取り合えず長らく空席になっていたLWGの責任者が正式に決定した事で当面LWGropuは継続されるってことでしょう。それはそうと、Chuckさんの立ち位置がどうなったのか。。気になります（笑。

DPontさんのプラグインにDP_Text Genと、Rman Collection（プロシージャルテクスチャ＆ノード）に幾つかの新プロシージャルが追加されたのでピックアップしてみます。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

●Grass

https://dpont.pagesperso-orange.fr/plugins/Textures.htm

草や芝（繊維）のようなテクスチャを描画します。

・Color・・草の色
下図100％の草は該当Colorの単独色で割り当てられた草です。Noneの草は該当Colorの設定色が全く割り当てられていない草です。それ以外の草はColor1、Color2、Tip Colorそれぞれの色の合成色です。

Color1の設定色は多数の草に割り当てられる為、Color1の設定色が草全体の色相に最も影響を与える色です（図 Color 1 参照）。
Color2の設定色が単独で割り当てられる草は少ない為、Color2の設定色はColo1やTip Colorが割り当てられた草の色と合成されることになります(図 Color 2 参照）。
Tip Colorはその名称から草先端部の色のはずですが、そのようには見えません（Tip Colorバグの可能性も有り）。Tip Colorの設定色が単独で割り当てられる草は存在しない為、Tip Colorの設定色は必ずColor1,2の設定色と合成されます（図 Tip Color 参照）。
尚、各色の合成処理は加法混色で行われます（図 A～F 参照）。


以下、単位面積（1㎡）での設定。

・Spacing・・草が生える密度
値が小さくなると密度が上がり、値が大きくなると密度が下がります。

・Jitter・・草の配置のバラツキ度合
値が小さい程、バラつきは小さくなり、値が大きい程バラツキは大きくなります。尚、バラツキが大きくなると、それぞれの草の間隔が広がり単位面積当たりの空間が広がる為、上記Spacingパラメータの密度（空間配置）からは乖離します。　

・Length・・草の長さ

値が小さいほど草の長さが短くなり、値が大きい程、草の長さが長くなります。

・Width・・草の幅

値が小さい程細くなり、大きいほど太くなります。0.0は草が消滅するので無効値です。

・Bending・・草の曲げ度合
値が大きくなると草の曲がりが強くなります。0.0は曲がりません。10.0が規定の上限値。それぞれの草には向きがある為、全ての草が曲がったように描画される訳ではありません。又、値を上げてもカール(360°）するような極端な曲げは出来ません。

・Speed・・草の揺れる速度

値が大きい程、速く揺れます。Bendingの値が大きい程大きく揺れます。
Speed1.0/Bending1.0

Speed10.0/Bending1.0

Speed10.0/Bending10.0

・Evaluation Area・・草の描画精度（評価）

値が低いと草の描画が端折られますが、レンダリングは速くなります。見た目の許容範囲内で出来るだけ値を下げた方が良いと思います。下図では値が低い程、黄色丸箇所の草の描画が端折られている事がわかります。デフォルトは5に設定されていますが、試した感じだと3～5辺りがレンダリング速度と品質のバランスが取れているように思います。

・Cut Grass・・先端をカットした草
人工芝やテープのような表現に使えるオプションです。

・Seed・・描画パターン

設定値はパターン数を表します（0はオリジナルのパターン）。全てのパラメータの設定条件のまま異なるパターンに変更したい時に触るパラメータ。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿


●Tile Mixer

https://dpont.pagesperso-orange.fr/plugins/Textures.htm

通常シームレスな画像（左図）をタイリングすれば模様は規則的にパターン化します（右図）が、Tile Mixerを使う事でこのパターンを不規則にすることができます（下図）。

メモリ節約の為に低中解像度テクスチャを使ったタイリングによる模様のパターン化を回避します。

※本家サイトには詳細な解説が無い為、以下の解説の多くは自分が試した推測になりますので注意下さい。

・Tile Offset：
合成する画像の位置をオフセット（移動）するパラメータです。
値を上げれば斜めY方向にオフセットする感じです。尚、Seed値が0だと元画像はオフセットしません。Seed１以上で元画像もオフセットするようです。
・Mixer Power：
Mixer Powerが0.0～1.0の範囲では画像のピクセル輝度を透明度に置き換えて合成してるように見えます（0.0で透明、1.0で不透明って感じです）。Mixer Powerが1.0以上になると合成エリアをプロシージャルテクスチャの模様で区分けされ、プロシージャル模様の個々のグラデーションエリアに対して画像合成用のレイヤーが割り当てられる感じがします。グラデーションエリア単位の合成を行うことで模様のランダム性は向上しますが、同時に値を上げ過ぎると元画像の模様は破壊されて行きます。尚、Tile Offsetが0.0の時はMixer Powerによる効果は現れません。

合成処理は1パターンの模様単位でランダムに移動や拡縮や向き（回転）を変えたり、と言ったようなパターン単位のオフセット合成処理は出来ません。
以下は各パラメータをアニメーションさせた動画です。

使用した画像

・Tile Offset値とSeed値による画像の変化を確認してみます。

動画ではTile Offsetを0.0～3.0に変化させ、Mixer Powerは1.0で固定、Seedは0に設定しています。Seedが0の時は合成用の画像はオフセットしますが、元画像はオフセットしません。

次に上の動画の設定からSeedを1に変更したのが下の動画です。

Seedを1以上に設定することで、元画像もオフセットしてることが確認出来ます。

・Mixer Power値による画像の変化を確認してみます。

Tile Offsetを1.0、Seedを0.0、Mixer Powerを0→1.0へアニメーションさせた動画です。

各ピクセルの輝度値を透過度として合成してるように見えるので、画像内の輝度が最も高い白矢印は合成の不透明度が最も高くなっているように見えます。
上の動画では0.0透明↔1.0不透明という画像全体で同じ合成が行われていますが、Mixer Powerが1.0を超えるとどうなるでしょうか？以下の動画ではMixer Powerを1.0→3.0にアニメーションさせています。

Mixer Powerが1.0を超えると、合成範囲にプロシージャルのグラデーション模様が適用されていることがわかります。と書きましたが、そうは見え無いと思うので、更に値を上げ、Mixer Powerを1.0→30.0にアニメーションさせた動画が以下になります。

Mixe Powerの値を上げるとプロシージャルのグラデーション模様がハッキリと確認出来ます。このグラデーションが合成範囲を区分けしている為、Mixer Power値が高くなれば、それだけプロシージャルの密度も上がり、合成範囲の区分けが増えることにより、画像の模様のランダム性が増幅されます。

最後にMixer Power 50.0に固定し、Tile Offsetを1.0→3.0へアニメーションさせた動画です。

プロシージャルのグラデーション模様間で白矢印が出たり消えたりしています。これにより、グラデーション模様の区分毎に合成処理が行われている事がわかります。
これらの挙動を参考にすれば、Tile Mixerのパラメータを調整し易いかもしれません。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

●DP Text Gen

https://dpont.pagesperso-orange.fr/plugins/DP_Text_Gen.html

・フォント形式はTrueTypeをサポートしています。
・テキスト(.txt)ファイルの文字を読み込む事が出来ます。
・文字が拡縮でジャギったり潰れたりしませんが、２バイト文字（日本語等）に非対応なので（日本人的には）なんとも微妙ではあります（笑。

左がメモ帳の入力文字で右がDPTextGenで表示した文字（２バイト文字（日本語全角/半角）は文字化け）

・文字の属性に関するアニメーション(Eボタン）が可能です。
以下のテスト動画は主にこのツールの文字属性を使ったアニメーションですが、動画後半のカウンターアニメーションに限ってはノードによる工夫なので、ツールのネイティブ機能ではありません。

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

●Torch
https://dpont.pagesperso-orange.fr/plugins/Textures.htm
4つのタイプの炎（Flame/Torch/Campfire/Fire)が選択出来ます。
何れのタイプもパラメータ数は少ないので設定は非常にシンプルです。
以下動画内の左側はデフォルト設定の炎で、右側がノード合成した炎になっています。

（尚、LWはv2019.0.3の体験版を使用している為、保存が出来ません。よって、ノードはほぼ一発設定なのでクオリティは緩い目で見てやって下さい。）

タイプ：Torch
・規定では煙の質感がマットで味気ないので、ノイズ系のプロシージャルを煙にノード合成してます。
・規定では炎と煙との境界で輝度がグラデーション分離していますが、炎が時間軸上で上下方向に揺れているのに対して、輝度の境界は静止（固定）したままなのが不自然に見えるので、輝度の境界位置にノイズを合成して不自然さを軽減させています。

タイプ：Flame
・規定では炎の周囲にグロー？があるように見えますが、グローは本来レンズエフェクトなので外したいのですが、仕様としてグローを外すボタンが無いようです。よって、Function入力を使ってグロー領域をクリッピングしています。
・蝋燭の炎として、色温度をノード合成しています。

・タイプ：Fire

・規定では炎の背景にグラデーション（黄色系）が設定されていますが、黒に変更してます。
・煙のディテールと色を追加合成してます。

・タイプ：Campfire
・焚火(Campfire)には見え難いので、炎下部をスケールで縮小して規定のシルエットを変更しています。只、シルエットを変える加工をやり過ぎると素のCampfireの表現から遠ざかって行くので、あまり良い方法では無いかもしれません。
・縮小により炎の下部が収束した違和感を緩和させる為に収束箇所にノイズを合成して誤魔化しています。
・炎の色はオレンジ系に色相で変更しています。
・Flamesパラメータを上げれば炎のディテールが細かくなりますが、同時にレンダリングが重くなります。右側では140に設定していますが、リアリティが今一の割には他の炎タイプよりもレンダリングが数倍重くなるので、個人的には一番使いにくいタイプかと思います。