トップ > 交流 >雑談 >最新版の修正情報で気になったもの

Re: 最新版の修正情報で気になったもの

169件表示 すべてのコメント一覧へ

投稿ツリー


このトピックの投稿一覧へ

通常 Re: 最新版の修正情報で気になったもの

msg# 1.101
depth:
1
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2014/4/16 8:11
完全無欠猫  長老 居住地: 兵庫  投稿数: 750
Crash関係:
SHA-1: a15ae564217f2b47848c337e477068be0e150973
* Fix T39743: Crash when deleting faces in with new autosmooth.
　Odd I did not catch this one... :/

SHA-1: 97881d06b221fbe5db98c5e5b3d2b9ecd0a22b38
* Fix T39610: Shared mesh used for Mesh Deform causes crash
　For now disable using linked edit mesh in the meshdeform modifier.
　This is because editbmesh_get_derived_cage_and_final() might easily
　conflict with the thread which evaluates object which is in the edit
　mode for this mesh.
　We'll support this case once granular dependency graph is landed.

SHA-1: 4f1a5192c24595798942b6ce8d704031e9fda8de
* Fix T39742: Crash with Cycles + new autosmooth crash
　Nice little mistake, since the invalid mem access only happened once (the first time),
　was close to valid mem, and was only used to read, it would not crash often...

気になったもの:
SHA-1: d2a5ddb4ec12245b4d1580490d88e808a2a04761
* Optimisations for building "Long Keyframes"
　For a long time, one of the bottlenecks when drawing summary channels in the dopesheet
　(especially with many objects) was how the long keyframes feature (i.e showing holds
　between keyframes) got built. Specifically, it was the step where we check on the previous
　keyframe to see whether there's a hold between those two.
　The old code performed some elaborate checks, which made sense back when we used to handle
　certain summary channels (e.g. object-action/ipo, and groups IIRC) differently. However,
　nowadays, everything just does it by going over the FCurves one by one, so the offending
　code wasn't really providing much benefit. Unless I've forgotten some other reason why
　that old method is necessary, this commit should provide a decent speedup here, making
　things somewhat interactive now (if still a bit jerky).
　Other Tweaks:
　1) Introduced float-precision threshold when checking to see whether an existing long
　 keyframe could be reused. This should hopefully reduce the number of fp-jitter issues
　 when creating summaries for many channels, reducing the number of duplicates created.
　2) Precompute colours used for shading the long keyframes, instead of recomputing for
　 each block.

以下は個人的な印象なので無視してもらって構いません。
読み難くするために視認し難い色にしてあります。



システム開発に従事して来た者として、いつも思うことだがバグに関する対応が甘い様な気がする。
要件確認された成果物に対して不具合が見つかった場合それは確認項目に問題があると判断し項目自体の見直しから行われるべきで
対応が的確であると判断されるにはより多くの確認が成されるべきである。
しかし報告された箇所の検証がされただけで適用されているようにしか思えない・・・。
それ自体的に問題が内在している場合も過去に多々あったし・・・。
商業ベースの物との差と言えば・・・・・そうかもしれないが・・。
瑕疵認識が低いのは明確にドキュメント化されていないのが大きな要因だとは思う。
しかし波及効果は考慮されるべきだとも思うのだが・・。
個別事項に多くの時間を割けない現状もあるのだろうが・・。
しかし検証に時間を割き不具合を減らしてリリースするのが結果的には自分達の作業量の軽減に繋がるはずなのだが・・。
最終的な完成形が明確ではなく流動的なシステムの性かもしれないなぁ・・。


投票数:2 平均点:10.00

  条件検索へ

ログイン

ユーザ名:

パスワード:



パスワード紛失

クイックリンク

2021/07/01版
●Blender.org
BlenderFoundation
- Blenderのダウンロード
- 公式チュート等
- 公式マニュアル（和訳）

●ニュース(英文)
BlenderNation

●Blenderコミュニティ
blenderartists.org

●Blender Q&A
- Blender Stack Exchange

●テストビルド
Buildbot(自動生成)


●開発関連
公式開発サイト
Blender開発blog
Blender Wiki