LightWave3D・雑談スレ90
■ このスレッドは過去ログ倉庫に格納されています
>>138 言語はまあどっちでもいいんですが、blenderのapiマニュアルは英語で紹介も簡易的すぎてそっちが大変そうです LScriptの方が引きやすいですね 複数ポリゴンをランダム距離で押し出すことってできないのか? ビル群のアタリ用として直方体群をざっくり作りたいので、 全部を等しい長さで押し出すんじゃなくて、ランダムにばらけさせたいんだけど。 やっぱり1個1個高さ調整するしかない? そんなニッチな機能、外のツールでは標準装備されてるんだろうか。 まあ、スクリプト使うんだろうな。 あと、Pluginであるかも。メタセコにはサードプラグインでそんなのあったな。 押し出したポリゴン選択しっぱなで 移動ツール(プロシージャルテクスチャ使用) > 平坦化 で、いけないかな? 2018のプリミティブパラメトリックシェイプの出番じゃないか? まさにそれyoutubeで紹介されてたな アドレスみつかんない >>146 通常のベベルツールで出来ますよ。 ベベルのツールパネルのShiftの+/-値に数値入れて下さい その値の範囲内でランダムに押し出されます。 >>153 それですわ もっと単純でいいなら>>155 でよさげか >>153 これってVPR使わないと確認できないのが辛い でも、異常にポップアップ出してやべっ…お、落ちる!もう落ちる!大変!落ちますよ!!!!!あ、あ、あああああああああ!!!! って落ちるアピールしてから落ちても辛いでしょ? よっし! レンダリングするぞ。ポチッ 数分後・・・・ あれ? レイアウトが立ち上がってない・・・・。 レイアウトさんは自分が落ちた事にすら気が付いてないんだ・・・・。 皆さんありがとうございます。 >>154 うあぁぁ、探していたのはまさにこの機能です! そうかベベルで出来たのか…盲点でした。 感謝します! 変に耐えて固まって結局落ちるよりは、潔く落ちてくれた方が良いかな エッジウェイトって言われるほどみんな使っていない気がする キャットマル用だし 調べた限りそんな感じっすね ポイントウェイトよりエッジウェイトの方が狙ったラインが直感的にできるのに残念 エッジウェイト自体は素晴らしいものなんだけどちょっとLWのことが分かったら使わなくなる 実に残念 >>168 それこそが比較対象がブレンダになってしまう原因だいね 何もかもが一部未完成のまま放置で新機能実装(未完成のまま) カトマル実装したの何時だっけ? 今時、まともに動かないツールの方が少なくねえか・・・。 あいつらもうそんなもの実装したことも忘れちゃってるのかもしれないが。 >>170 >カトマル実装したの何時だっけ? v9.0の時。 LWのカトマルはモデラーシステムに根差した実装がされていないんだよね。 当時のモデラー担当者の能力不足が原因だけど、 根本はモデラーにブラックボックス的なマニアックな ソースがあって、それを解析出来ずに上辺だけの実装をしてしまったのが主因 と言われてる。なのでカトマルはジオメトリの増減ツール使うと破綻するし、 未だにSDSのUV補完も出来ないポンコツ仕様。 >>166 >治っていないのか 治すとかじゃなくて、 それLWのカトマルの仕様なので、 LWのジオメトリ増減ツールを全てカトマル対応に作り直さないと その問題は解決しません。 3dpowersのモデリングプラグインだけ 律儀にカトマル&エッジウェイトにも対応してる モデラーとレイアウトが別ソフトウェアだとやはりやりにくいですか? blenderもソフトは同じでも色々モードは切り替えないと使えませんが レイアウトモデラー両方立ち上げでhubで反映させるならタスクバーから切り替えるだけでそんな手間ではないのでしょうか? モデラーでサーフェスのプレビュー出来ないから不便だなと思うことはある レイアウトで設定して保存忘れとか >>175 手間の問題というより、 LWはモデラーとレイアウトが別ソフトだからそれぞれのデータはHubを介して 切り替える都度に、更新データをメモリへ読み書きしてる。 なので更新のデータ量が膨れれば切り替えによるタイムラグは発生するし、 切り替え時に強制更新が適さないデータもあるので、システムや フローも複雑になる。(例えば、追加レイヤーに新規作成したオブジェクトを レイアウトに送るか?送らないか?と言った更新の判断とか。) 一方ブレンダーのようなシステム統合型の3DCGソフトでは モデリング作業からアニメーション作業へ切り替えてるのは UIだけが切り替わってるだけで、LWのようにベースデータの受け渡しはしていません。 なので原則タイムラグは発生しないし切り替えによる更新データも存在しないので 試行錯誤やトラブルも発生しません。 >更新データをメモリへ読み書きしてる 訂正。 更新データをメモリへ読み書きしたり保存データからの読み込みをしたりしてる。 只、以前にもここで書いたけど、 LWはv10以降から、モデラーとレイアウトで共通するシステム(統合メッシュシステム) を開発して、おそらくv2018ではそのシステムが実装されているので、 今後のメジャーアップでモデリングとアニメーション間の境界が解消される 可能性があります。それが統合なのかどうかは別として。 分かれている利点は、 レイアウト以降はモデリングのことを考えなくて済む、 その「レイアウト」という名前から何をするソフトか分かる通り、 思考、段取りの整理が明確にできること。 とはいえ、考えなければいけない部分もあった。 ボーンの曲げ具合を見ながらウェイトの調整とか、 パースに合わせてモデリング等。 そこの整合性を取れれば、分かれている利点のみを残せる。 それ以外で頻繁にレイアウトとモデラーを行ったり来たりしている場合は、 そもそもフローの構築が間違っている等、ソフト以外の問題を疑う必要もある。 今回はバージョンアップ見送ろう。 モデラーとレイアウトが統合したらバージョン上げるわ。 昔のプラグインはソースを公開して有志にバグを直してもらったほうがいい blenderはオープンソースだからバグのフィックスが早い >>173 LWBrushのKnifeだと壊れてしまった それ以外はいけるっぽい 相性が良いってどういうことだ? 操作性が似ているとか? light(軽い)waveっていうぐらいだから、ソフト分離で軽さを重視していた伝統と、 今更、一から作り直すのがしんどいってのがあるんですかね。 追記 >>179 >おそらくv2018ではそのシステムが実装されている 今日この確認が取れました。 本日Chakが、統合メッシュシステムに関するコメントをしてます。 Yes, the implementation of the new geometry engine in Layout did happen; yes, it is exactly the engine that was discussed on the blog; yes it is responsible for a number of performance and capability improvements in LightWave 2018 and offers loads of opportunity for future enhancements. 「はい、(v2018では)レイアウトで新しいジオメトリエンジンの実装が行われました。 はい、それはまさに公式ブログで記載されてるエンジンのとです。 はい、それは、LightWave 2018の多くのパフォーマンスと機能向上を担い、 将来の機能拡張のための機会を提供します。」 これで間違いなく、v2018で統合メッシュシステムが 実装されていることが証明されましたね。 我らLIGHTWAVEを使い続ける最後に25人・・・。 補足: Chuckが言ってるブログとはこのことです https://translate.google.co.jp/translate?sl=en& ;tl=ja&js=y&prev=_t&hl=ja&ie=UTF-8&u=https%3A%2F%2Fblog.lightwave3d.com%2F2015%2F12%2Funified-mesh-system-part-2%2F&edit-text=&act=url >>189 あとどれくらい待つんでしょうかね・・・。 メッシュ確定っすか モデラー側さえ頑張ってくれればなんとでもなりそうだね それでも他のソフトと比べたら10週くらい周回遅れだけどな。 ヴィンテージ仕様なんだよ オールドファンの要望にあわせてあえてそうしてるんだろう >>197 オールドファンってスタートレックのプロデューサーのことか FenderやGibsonのギターをイメージして欲しい 時代遅れで使いづらいけど中高年に人気だろ >>199 あれは素材や製法、機能、記号としいぇのデザインが完成されてるから意味がある スパゲティでメンテも出来ない時代遅れじゃ良く言ってトラバントだろ 2018.0.1は上書きじゃなく新規インストールなのね LWって伝統的に新規になるけど こんだけ細かいバグフィクスバージョンは上書きでもいいのにと思う .1や.2じゃなく早くに.0.1を出して来たのは珍しい 性能は上がってるのかも知れないが、 モデラーとレイアウトの連携とか、 マテリアルの出来栄え確認とか、 劣化して不便に成ってる部分も目立つよね。 いや、マテリアルについては、劣化はしてなくないか…? 過去の資産が活かせなくなったのは痛いけど >>201 >>202 10もそうだったと思うけどうだったかな? かなりカスタマイズして使ってたんだけど9.6位までで面倒になってアップデートするのやめた コンフィグ読み込むにしても新しい機能確認しないと上書きして気が付かなくなるし億劫に感じたんだよね… むしろカスタマイズを辞めたわw プラグインだけはブランチインポートしたりライセンス入れ直したり面倒だけど 自分は2015のメニューコンフィグをそのままインポートしたら崩れたのでデフォに戻した キーボードのコンフィグはそのまま問題なかったけど 9.6からアップグレードするつもりで体験版ダウンロードしたけど、ブーリアンが使い物にならなくなってた 2015.3なんだけどいつからかグラフエディター開いたときに キー打ってあるチャンネルしかリストに拾わなくなってしまった グラフエディターのオプション一通りいじっても治らないし すごく不便だしなんなのこれ レイアウトがエラー落ちした前後からな気がするんだけど どなたか何か心当たりあれば教えて下さい。先輩どうかお願いします。 AP 2018 experimental ray traced previewer https://youtu.be/6QmPWOxs_20 Working on AP 2018 experimental previewer using NVIDIA's fabulous Optix GPU based ray tracing engine lightwaveってどの旧バージョンからでも最新版へのアップグレード価格って大差ないのでしょうか? バージョン縛りが、今、ギリギリ許せる範囲かな サブスクリプション方式にされたら、もうダメだろうな 質問させて下さい。 2018ではライトの明るさの単位がルクス(lx)になりましたが、 このライト(光源)の明るさにルクス(lx)を適切に用いるには どのように理解すれば良いでしょうか? 例えば、光源から被照射面迄の距離が3mとして、被照射面に500lxの照度を求めるには、 LWのライトには何ルクスの数値(lx)を入力すれば良いのでしょうか? (ライトのNormalizeはONで) 3dsmaxだとルクス値には被照射面迄の距離入力も可能になっているので、 適切な照度を得ることが出来るのですが、LWでは距離入力がありません。 LWのライトのルクス(lx)はどのように考えれば正解なのでしょうか? ご教示お願いします。 >>219 ttp://tomari.org/main/java/hikari.html >>220 そこのサイトは承知していますが LWのライトに何ルクス(lx)を入力すれば良いかがわかりません。 >>219 アホらしいけど、3ds max で計算した数値を入れるとかはどうだろうか >>221 距離が測れて光源の強さを設定出来るんだから距離から逆算した光源の強さを設定すりゃ良いじゃない >>222 内部変換して内部で光源の輝度を調光して照度を合わせてると思います。 ですので、変換された値というのは表示されませんし、 仮に光源の輝度値がわかったとしても、LWの入力単位(lx)と合致しません。 >>223 逆算というのは、 500*3^2ですか?それとも500/3^2でしょうか? どちらの値にせよ、正しい照度にはなりませんでした。 式が間違っているのであれば、式を教えてもらえないでしょうか? >>217 4月過ぎても永遠にキャンペーンしないと 誰もアプデに見向きもしないな Autodeskだってfbx運用優位性が崩れたら一編で飛ぶよ 時代はblender LightWave 2015からのライトの明るさの変換 ライトの明るさは、それぞれのライトタイプを元として調整されます。過去のパーセント表示から、下記のルールでルクスへ変換されます。 面(Area)ライト(100%) = 3.14 平行(Distant)ライト(100%) = 3.14 ドーム(Dome)ライト(100%) = 1.57 線(Linear)ライト(100%) = 3.14 多角形(NGon)ライト(100%) = 3.14 測光(Photometric)ライト 変更なし ポイント(Point)ライト(100%) = 3.14 球形(Spherical)ライト(100%) = 6.28 スポット(Spot)ライト(100%) = 3.14 サードーパーティ製ライト(100%) = 3.14 補足1:上記の各ライトで表記されている値は、以前のバージョンの100%と同じライトの値を出力します。 例として、以前のバージョンで80%に設定されていた平行(Distant)ライトはLightWave 2018では、2.512 lxに設定することで同じ値を出力することができます。 うーんわからん 3.14はみんなの大好きなパイだよ 6.28はパイが2つ フォトリアルでレンダリングすると表面がノイズがかったみたいに ざらざらしているのは仕様? >>227 全照明ボタンがなくなって、 100%にして影をなくすというのをどうやっていかわからない。 >>230 レンダリングプロパティ⇒大域照明で保管にチェックを入れて、 1次光源 ⇒ 128 2次光源 ⇒ 64 くらいに設定してみてはどーだろ? 数字に根拠は無くてオイラの山カンw あまりに値が大きいと時間が掛かり、あまり小さいとザラザラっぽい。 >>224 専門ではないから正しいかどーか解らないが・・・ 照明メーカーが出してる測光ライト・.iesデータを良く使うんだけど、 使う.iesデータに寄って答えはマチマチだよ。 恐らく減衰率とか照射角とか寄って、同じ光の強さでも、平米当たりの照度・照射面の明るさは一定に成らない。 そして答えは最大・最小・平均の3つぐらいは出て来るもんじゃないかと・・・。 んなもん現物の前で露出計で計ればいいのさ ただ、そうしてもメーカーやセンサーの世代とレンズの癖で経験頼みで調整しないと安定した写真や映像にならない ルクスついでに便乗で質問していいかな ライトのフォールオフなんだけど、どうもノードで設定する仕様みたいね ノード、今まであまり触ってこなかったつけがここにきてのしかかってきたよ 誰か分かる人いる? ちょっとレクチャーしてほしいですー ごめん 自己解決した! 一生懸命探したらlight falloffってノード発見した >>232 大域照明の補完にチェックで解決しました。 ありがとう。 左右対象でのモデリングは格段にヤりやすく成ったよね。 片方にナイフ・ツールを仕えば、反対側にナイフ・ツールが反映されるし、 ポリゴンを貼るのも、ポイントを結合するのも左右対象に反映される。 シンメトリーの右側を操作しようとしたらマウスの動きを逆にしないといけないから困る なんとかならないかなあ >>233 すみません。返事遅れました。 >平米当たりの照度・照射面の明るさは一定に成らない。 照度は単位面積当たりに入射する光束の量なので、 例えば、茶色のテーブルの上に白い紙があって、その上部からライトで照らした場合、 テーブルよりも紙の方が明るくなるので、明るさには差があるってことですが、 照度では、テーブルと紙を含む単位面積(1u)当たりの値(照度値)は変わりません。 テーブルは暗く紙は明るく見える差は、輝度(cd/u)(この場合、2次光源の反射率) の差なので照度の差とは違います。 どなたか、219の答えがわかる方がおられないでしょうか? あれから考えてみたのですが、 3.14(lx) = 180°って感じで、 被照射面の立体角を表す値(光束量)ですかね?・・ LW2018でTFDのシミュレーション結果が、テクスチャソリッドだと確認できるのですがVPRだと表示されません。 ヴォリュームメトリックまわりの設定が原因と 睨んでますが、知恵などいただけないでしょうか。 旧バージョンでユーザー登録してないやつなら今からでも登録してサポート受けられますか?アップデータとか質問とか認証とか 通常版かアカデミック版か不明な中古を買ってしまってもそのままユーザー登録して使って大丈夫なんでしょうか? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる