Bebelと組み合わせることで、Bezierのパスから厚みのあるObjectを作成できます。
しかし Mesh法線が反対になっていることがあります。
法線は ViewPortOverray / Geometory / Face Orientation で確認できます。
通常Objectであれば、EditMode でMesh>Normals>Filpで反転して修正することができます。
ですが BezierのパスにはMeshがないためかMeshのメニューが表示されず反転操作ができません。
解決策ですが、厚みを作っているBebelに指定したBezierObjectの回転方向を逆にします。
（Bezierを構成する点に番号が振ってあるとして、それを逆にするイメージ。）
最初の画像と次の画像で選択しているのは同じ点で、位置を画像のように移動することで、法線の向きが解消されています。
（ただし中心位置から形状がずれたので、下のパスObjectの形・位置も少し変わっている。）
前のブログ記事では、数字をあらわす漢数字と大字の文字列について、あつかうための前処理とパタン、また変換のさいに考慮しなければならない細則について書きました。
ここから実際に文字列から数値へ変換をおこなっていきます。
daisy WarekiConv 和暦を西暦へ自動変換するFireFoxアドオン
daisy WarekiConv 和暦を西暦へ自動変換するChromeアドオン
JavaScriptにない機能を実装していくことになります。
つまり、parseInt()の漢数字版のようなものを、自分で実装することになります。
つまり、こういうことになります。
- 文字列中にある漢数字による桁と数を、それぞれ数値と桁のべき指数に変換する。
- それを順に足し合わせるなどして、文字列全体が表す数を得る。
- なお、漢数字文字列の桁のありなしを判定して処理をわける。
## 桁ごとの桁文字、数字文字の変換
'百'、'千'といった桁の文字、'壱'、'九'といった数字の文字を、それぞれ桁や数に変換します。
漢数字による数字文字の変換は、とうぜんJavaScriptの言語機能にはないので実装しています。
なお今回のプロジェクトでは、
- 数字文字の変換は cKanSuuzi2Int()
- 桁文字の変換は cKanSuuziKeta2Int()
で行っています。
// 漢数字（桁漢字なし）
```
function cKanSuuzi2Int(cKanSuuzi)
{
const res0 = kanSuuziNumChars.indexOf(cKanSuuzi);
if(-1 !== res0){
return res0;
}
const res1 = daiziNumChars.indexOf(cKanSuuzi);
if(-1 !== res1){
return res1;
}
const res2 = daiziNumOtherCharPairs[cKanSuuzi];
if(undefined !== res2){
return res2;
}
const res3 = kanSuuziOtherCharPairs[cKanSuuzi];
if(undefined !== res3){
return res3;
}
return -1;
}
```
番号に並べてindexOfで返ってきた値をそのまま使う、というのがC言語ネイティブの書いたC的コードという感じがします。
（意味としては違うが数字は合っている。）
桁の変換も同じです。
桁の場合は、10のべき乗ということで、べき指数を返させています。
たとえば’千’の場合は3を返させて、使う側は10の3乗をして1000を得る、といったやり方をしています。
(JavaScriptでは`10 ** 3`という記法でべき乗計算できる。)
## 漢数字文字列を実際に数値へ変換する
『桁の有無』はこれにより数値への変換ロジックを切り替える必要があり、重要です。
判定方法としては、これもまた単純に、桁の文字を変数にあつめておいて正規表現で検出です。
ひとつでも桁を表す文字が含まれていれば桁有り、そうでなければ桁なしです。
『漢数字』『大字』は同じ数字表記のなかで混交しない雰囲気なのですが、分けておかなくても困らないのでチェックはせず、そのまま混在で判定しています。
### 桁なし漢数字文字列の変換
単純に、頭から１文字ずつ数値変換しながら10をかけて桁上がりさせていくだけです。
途中にゼロが入っていたりしても、専用の分岐処理がいりません。
コードも必要ないけれど全文引用してしまうくらい短いです。
```
function convKanSuuziStr2Int(sKanSuuzi)
{
let val = 0;
for(let i = 0; i < sKanSuuzi.length; i++){
const num = cKanSuuzi2Int(sKanSuuzi[i]);
if(-1 === num){
// 変換を打ち切って結果を返す
return val;
}
val *= 10;
val += num
}
return val;
}
```
変換の打ち切りのところは、アドオンの実装上で末尾に『年』の文字がついた文字列が渡されてくることがあるのをナアナアで処理しているものです。
今回の用途では不正な文字列が入ってくることはないのですが、汎用をにらむと漢数字以外が混ざっていたら不正と判定するように変えるべき箇所ではあります。
後ろから処理していく方法でもよく、桁が最初から自明という利点もあるのですが、今回は頭から処理で実装しました。
こういうところの判断になんというべきか、今回のコードはJavaScriptで書いていますが全体的にCライクな空気があります。
### 桁あり漢数字文字列の変換
桁ありの場合、文字列の中に『数桁数...』と並んでいることになります。
前述のとおり数が１のときに『桁数桁』から数が省略されて『桁桁』になる場合もあります。
今回の実装は以下のようにしました。
頭から処理して『数』であれば数値に変換して変数にしまう。
桁であればべき指数Nに変換してから、10のN乗で値に展開します。
(’千’の場合は桁であるNは3、10の3乗で1000が得られる)
変数から数をとりだしてかけ合わせれば、その桁の値ができあがるので、結果をしまう変数に足しこみます。
これを漢数字文字列の最後まで行い、すべての桁を足し合わせることで数値変換を実現しています。
ここで主要なトリックは、数の変数を用意しておきあらかじめ１を入れておくことです。
桁桁と続いたときに、省略された１がそのまま存在するので、専用の分岐処理がいりません。
数の変数は、取り出して使ったら１に戻しておきます。
### 細則の、'20'を表す文字などについて
"参廿"で3*20=60、"廿十"で20*10=200とかやられる心配はしなくてよさそうなので、そのまま加算しています。
----
## おわり
というわけで、以上のことを考慮し、複数の記法に対応しているという意味で、いくらか現実世界に対応できるであろう変換機能を書いた次第です。
＞『しかし輝く宝石の完璧さは、私たちがMozillaを書いたときの目的ではなかった』
「ストラテジーレターIV: ブロートウェアと80/20の神話(ジョエル・スポルスキ / 翻訳: 青木靖)」より
というやつかなと思いながらコードを書いていました。まあこの程度の内容はまったく複雑とは言わないわけではありますが。
今回、とりあえず不要として不正な文字列の検出を適当にしています。
年号を書き間違えているときにできることは大してないので、とりあえずいいだろうとしたのですが。
そのうち機会があればきちんとするかもしれません。
ブラウザアドオンを開発した際に、漢数字の文字列から数値への変換を実装しました。
せっかくなので何をしたのか、必要な知識などをまとめた次第です。
(Chromeにも対応。)
昭和や皇紀といった和暦で表記された年号を、頭で計算しなくても西暦に自動計算して表示してくれます。
このとき、和暦は年が漢数字で表記されていることが多かったため、漢数字文字列の変換が必要になった次第です。
なおソースコードをgithubのWarekiConvプロジェクトページにて公開しています。
（`kanNum.js`というファイルが漢数字変換なのですが、名前を変えるかもしれないので直リンクはしていません。）
実際に変換を行うまえに、まず必要な前処理から。
現実では解説などの文字列のなかに対象が埋まっており、漢数字部分だけ綺麗に存在するわけではないので抽出が必要です。
方法としてはあまりに単純、すべての漢数字文字を変数にあつめておき、これで作った正規表現でマッチをかけます。
```
const rsRekiStrNum = `元年|\\d+年?|[${wideNumAllChars}]+年?`;
```
全角数字は
`１０２４`
くらいしかパタンがないのですが、漢数字はいくつかのパタンがあり、ちょっとした細則も持っています。
漢数字の場合は、以下のパタンが考えられます。
`一〇二四`
`千二十四`
`壱阡弐拾四`
`壱阡廿四`
大きなパタン分類として『桁の有無』、桁を書く場合と書かない場合があります。
-- 桁を書く場合、数がゼロの桁は桁の文字を省略する。
-- 桁を書かない場合、数がゼロの桁は`〇`。
さらに、以下のようないくつかの細則があり、またバリエーションが生まれます。
- 桁の数字が`１`のとき、文字を省略する場合としない場合がある。
- 『漢数字』と『大字』２種類の文字がある。
（この説明では、記述により多くの場合は両方まとめて漢数字と呼びながら書いています。）
- 『漢数字』『大字』では、同じ数字を表す文字が１つではない場合がある。
- 桁と数が一緒になっている文字もある(例：'卄'が20を表すなど)。
桁の数字が`１`のときというのは、たとえば1000の場合、
`千`
`壱阡`
のどちらでもかまわないということです。
漢数字、大字はそれぞれ
'〇一二三四五六七八九'
'零壱弐参肆伍陸漆捌玖'
というやつです。
同じ数字をあらわす文字として、たとえば以下はすべて『２』です。
'二弐弌貳貮弍'
----
以上、本記事では数字をあらわす漢数字と大字の文字列について、あつかうための前処理とパタン、また変換のさいに考慮しなければならない細則について書きました。
その２では実際に文字列から数値へ変換をおこなっていきます。
その１ではフルスクラッチで最初の大まかなモデリングと、3Dプリンタでの出力までを行いました。
この記事ではその続き、スジボリなどによるディティール追加と、量産、ついでに色つけについて書く予定です。
## スジボリなどによるディティール追加
最初は脚部のために、画像の通り腹を上に向けて出力していたのですが、スジボリを入れはじめた時にスジボリが綺麗にでるよう腹ばいに変更しました。
そのままの向きでは、スジボリの交点に下端が発生するため主翼の平面上にランナーが生えて、きれいに切り取るのが大変になります。
下付きだと脚にランナーがはえますが、細長いパーツのため、ランナーを外す作業中に折れてしまいます。
実際作業中に何度か折ってしまい、そのつど強度不足ということで脚太さを修正しています。
特に震電は特徴的な後部脚が翼から生えており、
事前に見えづらい箇所に支持枝をデフォルメした補強を入れていたのですが、これもつど厚く大きく変更していきました。
あわせて全体の形状も、当初の実機に近い形状から、どんどんデフォルメを強めています。
とはいえ丈夫であるにこしたことはないので、後脚を太くするたびにこちらも太くしていきます。
（前脚は後脚より細いという実機の関係が保たれていれば、外観としても太さを合わせたほうが見た目がよく思います。）
スジボリについて、1/700 ではこれくらいだと全然スジボリが出なくて、かなり強くデフォルメが必要です。
3Dプリンタの解像度の限界を思い知りました。といってもこちらは設定の追い込みとかすれば違うのかもしれません。
とはいえ思っていたよりもずっとよいものが出来たので、pixiv/BOOTHで「震電 局地戦闘機 1/700 モデル」出力した模型を販売することにしました。
局地戦闘機『震電』の1/700スケール模型を作成した際の作業記録です。
無料の3Dモデリング ソフトであるBlenderでデジタル制作して、3Dプリンタで出力しています。
（3Dプリンタで作ってみた系のブログ記事はけっこうありますが、
観測範囲では内容はほとんどがプリンタの精度の話などで、ノウハウについても出力失敗時の硬化時間の工夫くらいで、
出力するためのモデルの作り方とか、実際に作っているときのトライアンドエラーの話はあまりされていないような気がしていたので、
そういう内容をいくらか含んでいます。）
『震電』は第二次世界大戦時に大日本帝国海軍により試作された局地戦闘機で、
前翼型（エンテ型）・推進式（プッシャー式）の、めずらしい形をした高速戦闘機となっています。
試作のみで終戦を迎え、実戦では使用されていません。
今回はこの『震電』を、艦船模型など組み合わせやすい 1/700 スケールで作成しました。
似たようなものには、艦船模型と合わせるための 1/700スケール 戦闘機の、
- ピットロード 1/700 スカイウェーブシリーズ 世界の現用戦闘機セット
(F-15C, F-15J, タイフーン等)
- 静岡模型教材協同組合 1/700 ウォーターライン 日本艦載機 前期型
(零戦21型、99艦爆、97艦攻、彗星)
などが模型メーカから出ています。
主な仕様：
- 艦船模型と合わせやすい1/700スケール
- 艦船模型と合わせるので脚ありの接地モデルとする
- プロペラあり
- 船体外板のラインを入れて、ある程度ディティールをもたせる
- 3Dプリンタ出力と、塗装などの加工作業、移動や輸送を気軽にできる丈夫さ
- 扱いやすく手間のかからない一体型
（注意：足が折れやすいと思われるので対処が必要）
資料：
「異端の空」（文春文庫/渡辺洋二）
「幻の戦闘機」（光文社NF文庫/碇義郎）
参考：
wikipediaの震電のページ
https://仮想艦隊.jp/cms/blog5.php?itemid=139 の「震電オリジナルの図面」
震電の翼は翼端20度取り付け15度になっていましたので、翼をそのように作成。
とはいえ模型として作るぶんには外観が合っていれば取り付け角はどうでもよいため、このあとの作業での微調整では取り付け角はいいかげんに扱っています。
給気口、操縦席、各翼を追加していきます。
操縦席は悩みましたが、1/700スケールの必要ディティールと出力可能精度から、一体の塊としました。
ざっくりと足を追加。
electron12対応へ、前回は
右クリックメニュー(ContextMenu)カスタム処理をmain-processへ移動した（electron 12対応）
まで。
nodeIntegrationはともかくmoduleは将来廃止になるとのこと。
npmパッケージで逃げることもできるが、まとめて移行することに。
つまりいろいろなものをrender-processからmain-processへ移動することになり、ContextBridgeの導入を避けることができない。
これまではrender-process側の適当なjsファイル内で完結する下記２行程度の記述で ダイアログを表示することができたのだが、ようはこれが使えなくなる。
``` js/mypage.js
const {dialog} = require("electron").remote;
dialog.showMessageBoxSync(null)
```
エラーメッセージによると、ContextBridgeを使うには、contextIsolationを有効化しなければならない
（electron12からデフォルトでtrue)
ContextBridgeでmain-processへ飛ばしてそこからrequest('electron').dialogを呼ばなければならない。
```
MN@daisy-bell:lina_dicto/$ git diff lina_dicto/js/index.js }catch(err){
- message_dialog('error', 'user preference error', "user preference load error:\n" + err.message);
+ window.myApi.message_dialog('error', 'user preference error', "user preference load error:\n" + err.message);
}
}, false)
```
最初はpreload.js内でdialogを呼ぼうとしたのだが、なぜかrequire('electron')からcontextBridge, ipcRendererのようにdialogを取り出すことができない。
（preload.js内でcontextBridge, ipcRenderer以外が使えないということかもしれない。
後のContextBridgeのサンプルコードなども、見る限りpreload.js自体はrender-process側ということのように見えるし。）
諸々の非同期を経由で呼び出しているが、 dialog.showMessageBoxSync()はウィンドウを渡せばウィンドウはモーダルに動作する（意図どおりブロックする）ように見える。
（まあとりあえずエラー通知にしか使ってないのでそこはどちらでもよしとする。 ）
ページ上のjs -> preload.js上のcontextBridge -> main-processのjs と飛ばす。
``` js/index.js (renderer-process)
window.myApi.message_dialog('error', 'HELLO', 'hello!');
```
```preload.js
const { contextBridge, ipcRenderer, } = require("electron");
contextBridge.exposeInMainWorld(
"myApi", {
message_dialog: (strtype, strtitle, strmessage) => {
ipcRenderer.invoke('tomain-message-dialog', strtype, strtitle, strmessage);
```
``` index.js(main-process)
const { ipcMain } = require('electron');
ipcMain.handle('tomain-message-dialog', async (event, strtype, strtitle, strmessage) => {
const { dialog } = require('electron');
dialog.showMessageBoxSync(
// win, // ここmain-processで生成したwindowを指定できる
{
type: strtype,
buttons: ['OK'],
title: strtitle,
message: strmessage,
});
});
```
TODO: 確認ダイアログを出してOK,NGを同期で返す。
（現行の互換動作。あるいはこれは諦めてもいい。今は不要なので）
TODO: ファイル読み出し結果を戻す
TODO: ところでcontextIsolationが有効な時に nodeIntegration: trueが 無効になってない？
右クリックメニュー(ContextMenu)カスタム処理をmain-processへ移動した。
electron 12へ移行するための対応の一部。
（移行作業としてはelectron11で移行作業をしてから12にアップデートするつもり）。
``` エラーメッセージ
Uncaught ReferenceError: Menu is not defined
```
Menuはmein-processでいじるものになっていた模様。
ApplicationMenuカスタム処理をmain-processへ移動した（electron 12対応）
を参照 。
main-processのindex.jsの先頭付近に移動した。
```
7 require(path.join(__dirname, 'main-process/application-menu.js'))¬
8 require(path.join(__dirname, 'main-process/context-menu.js'))
```
electron-api-demosでは` Menu.setApplicationMenu()`はコールバックに仕込んでいたが、コンテキストメニューではしていないので、踏襲してそのまま呼び出しで済ませることにした。
```
10 const {Menu, MenuItem, app, ipcMain} = require('electron')¬
11 let menu = new Menu();¬
12 ¬
13 menu.append(new MenuItem({¬
14 >-------label: 'Copy',¬
15 >-------accelerator: 'CmdOrCtrl+C',¬
16 >-------role: 'copy'¬
17 }));¬
```
またコンテキストメニュー表示のコールバックも、 renderer-processでしていたのをelectron-api-demosの通りにmain-processへ移した。
rendererとmain-processでイベント が違う。
Before:
``` (renderer-process)
11 >------->-------window.addEventListener('contextmenu', function (e) {¬
12 >------->------->-------e.preventDefault();¬
13 >------->------->-------menu.popup(remote.getCurrentWindow());¬
14 >------->-------}, false);¬
```
After: 'main-process/application-menu.js'(main-process)
```
app.on('browser-window-created', (event, win) => {
win.webContents.on('context-menu', (e, params) => {
menu.popup(win, params.x, params.y)
})
})
ipcMain.on('show-context-menu', (event) => {
const win = BrowserWindow.fromWebContents(event.sender)
menu.popup(win)
})
```
ApplicationMenuのときと同じく、Rendererに持たせたmoduleを呼び出す機能は動作しない。
そちらは後でpreload.js, ipcRendererなどを使う方式へ移行する。
カメラ性能がどうとかスペック比較がどうとか、そういう一変通りな評価ブログ記事ははっきり役に立たないので、本当のスマホ端末の評価ブログ記事というものはこう書くのだという記事を自分で書いた。 スマホ端末レビュー記事で一番大事なのはちゃんと筆者の自分語りがされていること。なぜならスマホ...
