GG 文解というAEのスクリプトの生い立ちを解説する。8
閉じる
閉じる

GG 文解というAEのスクリプトの生い立ちを解説する。8

2019-12-31 03:29
    トランスフォームを変えると何故位置の打ち消しが上手く動作しなかったのか。
    答えは簡単です。シェイプコンテンツ内の座標系の倍率と、AE空間上の座標系の倍率が変わるからです。

    シェイプコンテンツ内でX+100とし、トランスフォームスケールでXを150%とすると、シェイプコンテンツ内では100しか進んでいないのに、倍率的に画面上では150進んだことになってしまったりします。
    ここを考慮していませんでした。
    でもここは案外簡単でした。位置の変動数値にスケールの倍率を掛けるだけで済んだので。
    回転は回転行列を使います。
    が、何処にこの回転行列を使うのかをしっかり考える必要があります。
    AEのトランスフォームの処理順はスケール→回転です。横に引き伸ばしたやつが回転されます。回転してから横に引き伸ばされはしません。
    なので、「(アンカーポイントの移動を打ち消す位置*スケールの倍率)*回転式」
    という順番で処理をしてあげる必要があります。
    回転式は実際はもうちょい複雑なので上みたいな書き方には出来ませんが、まあそういう順番で処理してあげるという事です。

    ここまで来てやっと、今のバージョンのGG 文解は完成です。

    そして悲しいことに、パスの塗りと穴が時計回りか反時計回りかがフォントによって違うという事実は、現実ではこのタイミングで発覚しました。
    めちゃくちゃ落ち込んだよね!!!!

    そんなこんなでGG 文解の生い立ちをざっくり解説しましたが、現在もGG 文解はバグに悩まされています。
    read me を読んでいただければ書いてあるのですが、"A-OTF UD黎ミン Pr6N"フォントの「の」という文字だけは、何故か構造分解時、処理が吹っ飛びます。
    理由は全く分かりません。このフォントの他の文字も、他のフォントの「の」も大丈夫なのに、この条件のみで動きません。

    誰かほかの条件で同じように処理が吹っ飛んだり、この現象の原因これじゃね?みたいな心当たりのある方のご助言、報告などをどしどしお待ちしております。
    他にも何かバグや仕様の不十分を見つけたという方の連絡もお待ちしております。


    長々と読んでいただきましてありがとうございました。
    広告
    コメントを書く
    コメントをするには、
    ログインして下さい。