OUCC の 3 年間を振り返る [前編]

執筆者: watamario15 (2022 年度部長)

これは OUCC Advent Calendar 2022 の 1 日目の記事です。明日は中編をお届けします。

今年もこの季節がやって参りました。部室を手放した昨年からもう 1 年経つのですね。課題に追われる日々は、本当に過ぎ去るのが早いものです。さて、今日は、私が在籍していたこの 3 年間、OUCC がどのような事態に陥り、変遷を遂げてきたかをまとめておきたいと思います。先に言っておきますが、かなりの長文になります。どこの団体でもそうだと思いますが、OUCC も例に漏れず、色々な危機に瀕することとなりました。

OUCC とは

初日ですので、ざっくりと OUCC の紹介をしておきます。

OUCC は、大阪大学文化系公認団体コンピュータクラブ」の略称です。「コンピュータに関連する多種多様な事柄を通じ、部員相互の技能向上、並びに親睦を図り、もって人格形成に寄与し、健全な学生としての成長を促す」が設立の目的です。...要するに、コンピュータ関連の活動は大体何でも対象としています。部の運営に一定の人手が必要であることと、イベントなどに誰も参加しないと悲しいことになってしまうこととで、参加必須となるような活動もいくつかありますが、基本的には何をするか、あるいは何もしないかというのも自由な緩いクラブです。

学祭などの行事を除き完全オンラインで活動しています。部費は、サーバ代やドメイン代などの設備維持のため、年間 2000 円ほど頂いています (十分格安だと期待しています)。部員数は 25 人ほどで、学部は情報系がほとんどという訳でもなく、文系含め様々な学部の人が所属しています。入部には阪大生であることと部費の納入が必要ですが、活動場所自体は公開の Discord サーバーを使用しており、大阪大学の関係者ですらなくとも (荒らしやスパムでなければ) 誰でも参加可能なので、興味のある方は是非覗いてみてください。

なお、OUCC はそれなりに歴史があるクラブであることが知られています。普通、こう言う話には設立年が併記されるものですが、できません。記録が残っていないのです。一体何故なのでしょうか... 一応、1985 年ごろの OUCC の OB と名乗る方が新聞記事で取り上げられていたことから、1985 年時点ではすでに存在していたことが示唆されているものの、やはり具体的にいつ設立されたのかは謎のままです。

2020 年度

2020 年度は、COVID-19 のパンデミックが発生した年であり、また私が大阪大学基礎工学部情報科学科に入学した年でもあります。中学でブラッククラブに所属していたという黒歴史を抱えていることと、他人に何かをやらされることが基本的に嫌いなため、クラブ・サークルへの参加には消極的でしたが、コンピュータに興味は持っていたため調べていたところ、OUCC を発見しました。講習会をやるとあったので、面白そうだなと思い Discord 新歓サーバー (前節で紹介した公開サーバーと同じ。当時は新歓用だった。) に入りました。その後、講習会、(3 週間の) ハッカソンイベントを経て、自由な雰囲気なら悪くなさそうだと思い入部しました。当時の入部金は 5000 円でした。

ちなみに、ハッカソン (3 週間をハッカソンと呼んでいいかどうかは疑問だが) では「通」というテーマがあり、C# によるチャットアプリ、AI とのチャットアプリ (うろ覚え)、音ゲー、アクション RPG が開発され、私は「C# によるチャットアプリ」に所属しました。まあ、「多さ課題が苦」で知られる大阪大学定番の課題地獄の真っ最中だったこともあり、一応の完成を見たのは前者 2 つだけでしたが...

C# によるチャットアプリの動作画像

KC3 2020 (9 月)

例年通り、KC3 2020 に参加しました。私が以前を知らないので何とも言えないですが、COVID-19 パンデミック前の 2019 年度までは対面実施だったものがオンライン開催となったようです。私はあくまでも受講生としての参加でしたが、OUCC としては「HerokuでLINEとDiscordをつないでみよう」と「経験ゼロからウェブページを作ってみよう」と「3DCG入門」を出していました。

他大学との連携 (9 月)

さりげなく ANU CSSA と緩やかな関係 (実質的に、相互の Discord サーバーに部員が参加し合っているだけ) を構築しているのですが、それが始まったのがこの年です。8 月末に相手方からメールで連絡があり、面白そうだということで関係を結ぶことにしました。不思議なことに、当時新入部員であった私がいつしか主導していました。最初は競プロイベントを開いたのですが、それ以降は交流案もなく、緩やかな関係に留まっています。まあ、それでも相手方の運営方針、活動状況、文化、英語圏 (のインテリ層) から見た現況など、色々と学べることは多いので有意義ではあると思っています。

夏の勉強会 (9 月)

COVID-19 下だからといって活動を何もしないという訳にはいかないので、オンラインで勉強会が開かれました。とはいっても、何人かのグループを作り、期日までに何かの技術を学んで報告資料を作成する、といった感じでした。自分は Python をやりました。

Python 発表内容

財政危機 (10 月)

10 月に入ると、当時の会計から以下のような報告が為されました。

財政危機

何というか、やばいという言葉だけで片付けてはいけないレベルに致命的です。学生が 42 万をホイホイと出せる訳がありません。そもそも、なぜこんなことになったのでしょうか。鍵になるのは「補助金」「部員数」「学祭」「部室」です。

OUCC は、当時部室を学外に所有していました。これは、学内の部室は他の団体と共有になるために高価な PC 等を置きづらい、ネット回線を引きづらい、などが理由としてあったようです。しかし、これの代償は極めて大きく、家賃としてコンスタントに月 5 万が吹っ飛びます。石橋阪大前駅からそれほど離れていない「駅チカ」物件としては破格ですが、それでも全予算を自力で確保する学生団体としてはかなり厳しい額です。

しかし、昔は普通に賄えていたようなのです。まず、これは噂の域を出ない (記録が残っていない) のですが、大学から公認団体に対して補助金が出ていた時代があったようです。企業による支援金があったという話もあります。次に、部員数もかつてはかなり多く、100 人いた時代もあったと言われています (これも例によって記録が残っていない)。さらに、年 2 回の学祭の食品模擬店でもかなり (10 万円以上) 儲けていたようです。そういうこともあり、部室を維持できていたようです。

ところが、2020 年時点ではそれらがすべて崩れていました。まず、大学からの補助金は皆無で、協賛企業もありません。そして、部員数についても、正確な記録は行われていなかったものの 10 人 + 新入生 6 人程度でした (2 年は何と 1 人)。学祭も感染拡大防止のため中止されました。その結果収入源が無くなり、危機的状況に陥っていたのです。

部室をどうするか (11 月)

部室の家賃を払えないとなると、その解決策は「部室を引き払う」です。その際問題になるのが部室にある備品ですが、当時の部長が大学の学生センターと連絡を取り、倉庫スペースを貸してもらえるという話がありました。なお、この時点では学内に部室の空きはありませんでした。余りに狭く、本当に最低限しか置けないスペースでしたが、金がない以上仕方ないということで、一旦この方針になりました。

しかし、OB の方々とも連絡を取ったところ、部室には思い入れがあるので支援したいという方が何人か現れました。あまり記録はない (なぜ?) ものの、30 年近く借りていたことを示唆する資料もあるので、それだけ部室に思い出を持った方もいたわけです。部員としても、残せるなら残したいというのが本心だったため、何度か話し合いを重ねたのちに、「支援をお願いし、今後様子を見ながら来年 5 月頃にまた再検討する」という結論になりました。結果、多大なる支援を頂くことができ、2021 年までは維持可能な財源を確保することができました (本当に感謝です...)。ここで、事態は「一時的に」収まることになります。

ちなみに、部室を維持するようにしたことにより、部費は高額なまま据え置かれました。入部金は 5000 円だったと書きましたが、これは新入部員向け特別価格です。既存部員には前期、後期それぞれ 15000 円でした。そりゃぁ部員も減るよ...

部室環境

部室の概観

一応、部室の話が出たからには当時の部室がどのようであったかの説明をしておきましょう。まず、立地としては阪急線を挟んで大阪大学豊中キャンパスの反対側にあり、阪急石橋阪大前駅から徒歩 5 分程度の場所でした。部室そのものは 2 階建ての建物の 3 階です。ん?今何か変なことを言いましたか?まあ、画像から薄々察せるかとは思いますが、屋上付きの建物の屋上に置かれたプレハブです。建付けは素晴らしく、全て閉め切ってあるのに台所の下から猫が侵入して鍋で生活していたそうです。夏は屋上からの照り返しで 45℃ を超える暖かさで、一度部室に入ると靴下の裏が埃で真っ白になるなど、環境も快適でした。ちなみにエアコンなんて豪華なものはありません。

とはいえ、こう見えて面積は割と広く、色々なところに目を瞑れば駅チカで格安の、学生団体には十分な部室でした。講習会やハッカソンを行ったり、布団があるので泊まる人が居たり、大量のゲーム設備 (後述) で交流を深めたり、と COVID-19 のパンデミック前には大いに活用されていたようです。

Advent Calendar (12 月)

毎年恒例 OUCC Advent Calendar 2020 が行われました。自分は「SHARP Brain 用アプリケーションの作成方法」なる記事を書きました。裏話としては、この内容は今では Brain Wiki にあるのですが、それは私が後で Brain Wiki の管理者を引き継いで内容を反映したからであって、丁寧に開発方法をまとめた記事は当時まだありませんでした。部員以外にも、部室の話で (何故か失われていた) OB さんとのコネが復活したため、昔の OB さんも記事を書いてくださいました。その割に全然 25 記事に達していないのは内緒。

金曜部室 (1 月)

COVID-19 によって活動がかなり縮小したことが懸念事項となり、その解決策が話し合われました。その結果、金曜日の夜に Discord に集まって交流会をしたり雑談会をしたりといった緩い集会を開き、部員同士の交流を維持しようとする試み「金曜部室」が始まりました。これは、時期に合わせて履修相談会にしたり LT 会を開催したりと一定の成功を見せ、ネタが無くなってマンネリ化した 2021 年度の終わりまで続きました。

なお、これ以前にも一時的に「もくもく会」が木曜日に開かれていました。目的ややることも概ね似ていたため、金曜部室はある意味でそれの再興ともいえます。

まとめ

2020 年前半については自分の入部前だったりして曖昧な情報しかない (というかほぼ自分語り) ですが、それでもオンライン活動への移行や財政再建など、激動の 1 年でした。まさかコンピュータクラブがこんな状況に陥っていようとは、誰が予想しただろうか... まあ、国際的な関係構築など、良い面もありましたが。

前編はここまでです。続きは OUCC の 3 年間を振り返る [中編] にお進みください。

3Dモデルの調整をしながらVRChat用モデルからVRMへ効率良く変換する

Blenderで制作して完成したと思っても、実際に動かしてみたりするとウェイトペイントが上手くいってなくて服が突き抜けたり、テキスチャがおかしかったりと、様々な問題が発生してBlenderでの修正を再三に迫られる場面は多いです。
そのためにBlender側で修正したものを出力してUnityに読み込ませます。そのUnityへ読み込ませる際にちょっとした工夫をすると作業量を緩和できます。

この記事は多分OUCCアドベントカレンダーの最終日の記事になります。

プロローグは暇な人だけ読んでね

それ以外の人は本題

~プロローグ?~

~3Dモデル制作以前

去年のハッカソンでは、何かと不満を言われるE-Learningと和解しようという企画にて、自然言語で会話できるBotを制作しました。
その過程で会話相手として、E-Learningの化身、angEL-reinちゃん(名前はE-Learningのアナグラムから)が生まれました。私が生みました(生産者表示)
この名前微塵も流行らず、代わりにいーちゃんと呼ばれているのですが、このいーちゃんを音声で入出力して会話できるようにして学祭に出そうという話になりました。
そこで私はRustサーバーを作って非常に遅い言語生成処理の高速化を行ったりしたわけですが、そんな話は今回どうでも良く、それよりやはり音声での会話をするならば、会話する相手が見えた方がいいですよね?古来より偶像崇拝があるように概念を相手にするよりかは、視覚的に見えるものを相手にした方が良いに違いない。
というわけで、れいんちゃんの3D化計画を極秘裏に進めました。
以前の記事で既にLive2D化した話はしましたが、我慢できずに3D化に踏み切ってしまいました。

3Dモデル完成(仮)まで

まずVROIDで素体を生成し、Blenderで服などを制作しました。
私は3Dモデルを作るのはこれで2回目なので初めてというわけでは無いですが、やはりそれなりに苦戦はしました。特に前回と同様ウェイトペイントでは常に苦戦させられ、今回も最後まで難敵となりました。
まあ兎に角色々あってFBXモデルが完成しました。
VRChatに出したかったのでまずVRChat用の改変をしつつシェーダの調節をしていきました。
その結果完成したのがこちら
れいんちゃん
れいんちゃん
れいんちゃん
ちなみに私は目にこだわる人なので、目は虹彩を奥に配置し、反射光を前面に出すなど立体的にしています

その後単眼カメラによる姿勢推定アプリを制作する、又はキャラクタを後世の人に使ってもらうためにVRMモデルへの変換を行いました。

本題

 Blenderで制作して完成したと思っても、実際に動かしてみたりするとウェイトペイントが上手くいってなくて服が突き抜けたり、頂点にウェイトが割り当てられてなかったり、テキスチャがおかしかったりと、様々な問題が発生してBlenderでの修正を再三に迫られる場面は多いです。
 そのためにBlender側ではLazy Weight Toolなどを使って個々の頂点についてウェイトを塗りなおしたりして修正したものを出力してUnityに読み込ませます。そのUnityへ読み込ませる際にちょっとした工夫をすると作業量を緩和できます。

fbxファイルのBlender→Unity

 fbxファイルをunityに読み込むと、モデルをScene上に配置できるようになります。
VRChatを想定した場合、その配置したモデルにPhysboneなどのコンポーネントを設定していくことになります。
 しかしこの方式では、後で修正をかけたモデルで上書きして読み込む際にfbxファイルと共にScene上のオブジェクトもリセットされてしまい、またコンポーネントの設置などをしなければならなくなります。
 これでは非常に非効率なので、fbxファイルを上書きで読み込んだ際にScene上のオブジェクトのコンポーネントがはがれないようにしたいです。

 そんな時に便利なのがPrefab Variantです。
 Projectビューからfbxファイルを右クリック→Create→Prefab Variantで生成できます。
 この生成したものをドラッグアンドドロップでSceneに配置してコンポーネントを張り付けてみてください。
 こうすることでfbxファイルを上書き更新しても、Scene上のモデルだけが更新され、コンポーネントは剥がれなくなります。

VRChatモデル→VRMモデル

基本的には VRM Converter for VRChatを使用しますのでこれを既にUnityへインポートしている前提で記述します。

初めてのexport

 まず変換するVRChatモデルを選択した状態でツールバーのVRM0→Export VRM file from VRChat avatarで適当に入力してAssetディレクトリ内に用意したフォルダ(フォルダ1)にexportします。
 この際もしかしたら未使用シェイプキーにチェックを入れてexportした方がいいかもしれません。
 兎に角これでフォルダ1内にVRMファイルとそのprefabが生成されます。エラーが出ても、何も変えずにもう一度実行すると何故かうまくいったりします。
 Unity上だけで表情やマテリアル、SpringBoneなどの設定を変更するくらいなら、そのPrefabをSceneに配置・編集して、そのモデルを選択した状態でツールバーVRM0→export to VRM0でフォルダ1に出力すると、フォルダ1のVRMを上書き修正することができます。

2回目以降のexport

  1.  モデルを変更した場合、またVRChatモデルからVRMへの変換をする必要があります。
     この変換においてVRM0→Export VRM file from VRChat avatarで出力する場所はフォルダ1とは異なるフォルダ2へ出力した方が良いです。
     何故なら、フォルダ1に出力してしまうとせっかく以前に設定した表情や物理などのコンポーネントが上書きされてしまうからです。
     この時、フォルダ1には旧、フォルダ2に新モデルが入っていることになります。

  2. 生成された新モデルのPrefabファイルをSceneにドラッグアンドドロップで配置。
  3.  ツールバーのVRM0→Open CopyVRMSetting Wizardで以前のデータからSpringBoneや表情などの情報を新モデルへコピーします。
     この時に、Sorceにはフォルダ1の旧Prefabアセット(Projectビュー上)を選択し、Destinationには新モデルオブジェクト(Sceneビュー上)を選択しないとエラーが出ます。
     ここまででコピーできていないのはマテリアルのみです。
  4.  マテリアル情報を新モデルにコピーしていくのですが、使用マテリアルが多ければ多いほどこの作業が非常に面倒です。
     よってそれをやってくれるツールを自作しました。
     ここ(https://github.com/sachsen/TransferInspectorMaterials) から.csファイルを入手して、readmeに書かれている通りに導入してください。
  5.  ツールバーTools→Open Inspector Material Transfer Windowとします。
     sizeにコピーするSkinnedMeshRendererの数を入力し、Sorceにコピー元の、Destinationにコピー先のSkinnedMeshRendererを指定してCopy!ボタンを押すとマテリアル情報がコピーされます。なお、マテリアル自身は複製されません。
  6.  新しいモデルを選択してツールバーVRM0→export to VRM0でフォルダ1へ出力、上書きします。
     これでVRMファイルが新しくなって置き換わります。

完成

3Dモデルはこちらからぐりぐり見れます。

https://hub.vroid.com/characters/7942564502413041514/models/2799418893141239533

文化祭での様子

もっといい方法があるかもしれないですが、私はこの方法でやりました。

よければお使いください。

著者:上月

Oracle Cloudにsign up出来なかった話

結論から言うと出来ました。
ブラウザの問題でした。

~あらすじ~

実は既に自宅にNASで若干サーバーっぽい物構築しているのでそれでいいかなと思ってました。
しかし無料の演算能力がある鯖が欲しくなって、自宅のは心許ないので、大企業様のOracle社のCloudを使ってみようと思い立ちました。

~苦戦~

様々なサイトを参考にsign upを試みました。
しかしどうも上手くいきません。
何故か東京とTokyoの二つ選択肢があるけどどちらがいいんだろうとか、英語にした方良いのだろうかと試行していました。
その中で一つ分かったことは、電話番号は最初の0は除いて記述することです。
しかしそれだけでは登録できませんでした。
「アカウントの作成には最大で15分かかります」的な表示が出てきてそれ以上進まない。
メールが来るのかと3日間待っても来ないし、chatがあったので、なけなしの英作文能力で質問したら、今審議中で1日かかるよと言われて、結局一日待っても何も起きない。
(最大で15分と書いてあるのに、1日かかると言われるのはこれ如何に)
※Chatは対応してくれるときとしてくれない時があります。2020年4月の一年間無料の締め切り間近の楽天モバイルよりかははるかに対応してくれる印象。

~解決~

私の使っているブラウザのVivaldiが悪いのでは?と思い、KC3冬のハッカソンでデバッグ用にインストールしたChrome Canaryを使用して登録してみました。
その時に違和感が。
Vivaldiの時はメールアドレスを同じやつ何度入れてもメールアドレス検証でエラーを吐かなかったのに、Chromeでは吐いた。
これはもしや...?と思い登録情報を埋めて登録していく...
メールが到着、そこには「Get Started Now with Oracle Cloud」!
秒で届きました。一体今までの苦労は何だったのか。
しかし、ブラウザ間で動作違うってよくありますよね。
実際ChromeとChrome Canaryですら動作異なりますもんね。
だから私はVivaldi、Chrome、Chrome Canary、Firefox、Edge、IE、OperaとかPCに入れてるんですよね。
その日の怒りのノリで書いたこの記事が参考になれば幸いです。

筆者:上月
前回の記事:Live2D触ってみた

Live2Dを触ってみた

この記事はOUCC Advent Calendar 2021の24日目の記事です。イブですね。イベント開催することで24日の予定を阻むFGOの運営の気持ちがよくわかる日になりました。いかがお過ごしでしょうか?前回は、かき氏の「Reactで時間割アプリを作ってみた」でした。

私が書いた記事は、前回はGANについて、前々回はOpenCVについて、前々々回はUnityについて書くといったように毎回分野を変えて記述しているので、今回はLive2Dについて記述していこうと思います。

~あらすじ~

自分の描いた絵が動くと嬉しいですよね。

というわけで、Live2Dやったことないけどやってみました。

~キャラについて~

今回動かすキャラは、「Angel-Rein」ちゃんです。
春のハッカソンで「嫌われているE-Learningを擬人化して対話することで好きになろう企画」の自然言語で会話する対話Botを作成することになりました。
その時に、新しいキャラを制作することが好きな私がデザインしたのがReinちゃんです。
マフラー付けて冬っぽい服装ですが、考案したのは春で、描いたのは夏ごろです。

名前の由来は、E-Learningのアナグラム

デザインやキャラの詳細については、ここを参照してください。(別ページへ飛びます。)

~出来たもの~

※読み込みに時間がかかるかも。お許しを

ここに画像が表示されるはず
ランダムAというデフォルトで用意されているアニメーションを再生したもの

▼表示されない方はこちらから(高画質版)

又はようつべリンクから

~感想~

むずい! 正直Blenderの方が簡単とさえ思えました。というか実際Blenderの方が簡単だと思います。
3Dを絵を変形させて表現するというのが難しい。
ここがこう回転すればこうなるといったようなことを頭の中で考えながら作成しなければならず、立体図形把握能力が求められる作業だと感じました。

見てください、この点の数!たった腕を動かすだけでこれだけのキーを打ち込まなければなりませんでした。(もっと賢い方法はあるのかもしれませんが)
袖が動いて前と後ろが切り替わる所とか、それによって袖がどう動くかとか、腕がより俯瞰した位置ならどう見えるかなどなど考えて動かすとこうなりました。
Blenderなら立体図形を作成してしまえば、動き方に応じて図形を編集する必要は無いですが、live2dは立体図形は手元にないけど図形を動かすとこう見えるだろうという予測を立てなければならないです。
もっとも可動範囲を狭くする、例えば腕の振れ幅を10度だけにする、顔もほんのちょっとしか動かないとかいったことをすれば簡単になると思いますが、回転や拡大縮小以外の複雑に変形しながら動く場合には、それだけで数時間飛ぶ作業量を要求されたりします。
あと、原画はキャラ設定画像としてなるべく正面で描いた絵なのですが、少し見栄えよく見せようと顔が傾いていたりします。これのせいで、対称編集が出来ないといった書く段階で知りたかった事柄も相まって難易度を底上げしてしまったようです。
物理演算を入れる作業については、あまり細かいところを気にしなかった(気にしている余裕がなかった)からか、結構楽々に設定することができました。

しかし、この図形を想像しなければいけない部分とかどうにかならないのでしょうか。真に絵を描ける人はこの辺の能力が高いのかもしれませんね。
昔Live2D Euclidとかあって、自分の絵を3D化できるという話を聞いて心躍ったのですが、あれはどうやら既に公開停止になっているようです。何が原因で頓挫したのかは分からないですが、上手くいけばメタバース時代の覇権を握れたかもしれないと思えるだけに残念です。
それにしても、世の中のVtuberはLive2dであそこまで動かせてすごいんだなぁ~って今回作成してみて感じました。

~総括~

Blenderではなく、Live2Dを使用する場面というのは恐らく以下の場面でしょう。

  1. あまり動かさない、又は動く部位が回転や拡大縮小といった単純な変形で構成されることが多い場合

  2. 絵を動かしたい、又は3Dの見た目は好きじゃない、3Dでは表現できないデザインを動かしたい場合

少しでもご参考になれば幸いです。

筆者:上月さん

GrabPassで取得したテクスチャが意外と後まで使える

執筆者: Shiokai

はじめに

この記事は、OUCC Advent Calendar 2021の15日目の記事です(投稿日がずれているのは気にしない)。前回はwatamario15さんのテトリスの電子辞書移植でした。
またこの記事はUnityのShaderのGrabPassに関する内容です。

本題

シェーダーを触ったことのある人なら大抵一度は触ってみたくなる(よね?)GrabPassではありますが、Unityのドキュメントにはわずか1ページの説明しかありません。その中に、GrabPassで取得したテクスチャ(以下GrabTex)は「後続のパス」で使用できるとあります。この「後続のパス」というのが肝で、私は当初同じシェーダー(SubShader)内で後に来るパスのことを指しているのかと思っていました。

ところがある日Twitterを見ていると、異なるシェーダーでもGrabTexが使用できるといった内容のツイートを見かけました(何方のツイートか分からなくなってしまってリンクが貼れない……)。これは試さねばと思い、GrabPassだけをするシェーダーと、GrabTexを貼るだけのシェーダーを書いてみると、なんと確かに異なるシェーダーでもGrabTexが使えているではありませんか!

さらにもう少し触ってみると、GrabPassが呼ばれてから、再度同じ名前のGrabTexでGrabPassが呼ばれるまでの間であれば、初めのGrabTexがどんなシェーダーからでも使える様でした。GrabPassが呼ばれるタイミングは通常のPassと同様にRenderQueueと前後関係による(はずな)ので、単純にRenderQueueがGrabPassより後ならGrabTexがそのまま使えてしまうことになります。

更に、GrabPassとGrabTexを使うシェーダーのRenderQueueを逆転してみたところ、なんと前のフレームのGrabPassで取得したと思しきGrabTexが使用できてしまいました。ただ、その場合オブジェクトを動かすかどうかでうまく描画できなくなることもあったので、実用に耐えうるかどうかは怪しいものですが。
これを見るに、GrabTexが使える「後続のパス」は、時系列的に後であれば本当に何でもいいようです。

注意点としては、GrabPassをしているシェーダーがカリングされてしまうとGrabTexを使用している側には意図しないテクスチャ(たいてい灰色一色)が渡されることになるので、オブジェクトの配置やBoundsには気を付ける必要があるでしょう。

これで何ができるの?

GrabTexが他のシェーダーで使えることでどういった表現ができるようになるかと言われると……正直自分にはさっぱり何も思いつきません。例えばオブジェクトの座標を色情報にしてシェーダー間で受け渡しできたりはしますが、それはGPUInstancingを使った既存の手法もありますし、何よりスクリプトが使えれば簡単にできることで、では他にわざわざ他のシェーダーからGrabTexを持ってきてするようなことがあるかというと……。この記事を読んだ方が何か素晴らしいアイデアを実現してくれるといいなぁ。

終わりに

ゴミみたいな文章が出来上がってしまった……

OUCC Advent Calendar 2021、次回の担当者はちょくぽさんです。

テトリスの電子辞書移植

執筆者: watamario15

これは OUCC Advent Calendar 2021 の14日目の記事です。前日の記事は...おかしいなぁ誰もいないぞ?w 明日の記事は shiokai が担当します。

さて、何を書きましょうか。マジでネタがありません。何を隠そう今まさに12月14日23:22です。今年は大量の課題やら部室の引っ越しやらノーキャリアの学祭やら Brain Wiki の整備やらの事務的なことが多く、個人でプログラムを書く時間をあまり取れなかったのです(そういえば、今年から Brain Wiki の Admin になりました)。情報科学科なら講義でプログラムを書くのでは?と思うかもしれませんが、はっきり言ってあんなのおまけで数学や回路設計の方がはるかに workload が高いです。というか、プログラミングの講義自体レポートを書く部分が本質みたいなところあります。つらい。

うーんどうしようか、そういえばギリギリ今年のはじめに OB の方が作ったテトリスを電子辞書に移植するのやってたな、あれの流れと宣伝でも書いとくか(ここでようやくタイトル欄を埋める)。

経緯

さて、電子辞書とは言っても明確な機種を指定していませんでしたね。機種は SHARP のカラー電子辞書 Brain シリーズです。ただし、2021年発売のモデル以降は見た目こそほぼ変わりませんが中身が全く違うので対象としません。昨年の私の記事で、実際に作り方を説明していますので興味があれば見ていってください。

まず、なぜ移植しようと思ったのか。それは突如として OB さんの1人が

「最近win32apiでテトリスを実装しました。」

という投稿と共に OUCC の Discord (内部サーバーで、当時はこちらがメインの活動場所だった)でテトリスを添付されたことが始まりです。何という奇遇でしょうか。WinCE が動く SHARP Brain は、ライブラリこそ碌に流通していませんが Win32 API の subset を利用することができます(詳細は昨年の記事)。そして、その完成度の高さにも驚きました。結構昔から電子辞書で動くテトリスは実はあったのですが、それはモノクロで乱数も seed 値が全く同じでパターンが変化しない、とても単純なものでした。

「これは移植すると面白いかもしれない」

そうして、移植が始まったのでした。

序盤

本当は詳しく書きたいものですが、何しろ今 23:38 です。時間がありません。概況だけ書きます。

まず、最初の状態でそのまま CeGCC に掛けるとしっかりエラーになりました。まあ、そうなりますよね。想定内です。あくまで subset の API しかサポートしないので、そのまま動くなんぞ甘い期待は禁物です。

まず、1つは menu bar の仕様違いです。ここは WinCE をやるときの1つの沼で、私もかつて知るまではずっと何がダメなのか分からなかったし、分かっても仕様がどこを調べても書いていないので苦労しました。CE はモバイル用 OS で、それゆえ画面領域が貴重です。狭い範囲に最大限の情報を詰め込むため、×ボタンなどの並びと menu bar を共通にできる command bar が導入されています。なので、これに置き換える必要があるのです。とはいえ、この苦労は既に1年前に経験したものですから、簡単に切り抜けました。

中盤

あ^~もう 23:46 じゃないか!!やばい!!

次はレイアウトの問題です。何か酷いことになってたんですよねこの段階では。これも command bar の仕業です。通常 Windows なら menu bar は描画範囲外ですが、何と CE では範囲内です。なので、その分画面全体を下にずらさなければなりません。いやぁとんだ沼ですね。しかも、幅はさすがに取得する API があるのですが画面が出てからしか使えません。よって、ウィンドウサイズを起動した後に変えるような仕様変更をすることになりました。

終盤

ここが一番苦労した部分です。なぜか適切に描画されなくなる問題が生じて、あれやこれやと色々試す沼にはまりました。時間も無いので (23:54) 結果だけ書いてしまうと、電子辞書の超低スペックでもまともに動くようにするために FPS を落としたとき、プログラム仕様をよく分かっておらず「やってはいけない」設定変更を実施したことによるものでした。悲しいですね。

成果

https://github.com/OUCC/tetris

何はともあれ一応動くものは完成しました。上記の GitHub Repository に置いてあるので、対象機種をお持ちの方はぜひ遊んでみてください(くれぐれも先生の前でやって没収されぬよう...)。ただ、割と高度な音声処理が組み込まれているらしく、そのせいか電子辞書では結構もっさりします(十分遊べますが)。あと、電子辞書版が遊ばれる状況を考慮して初期状態では音量が0になっています。右のスライダーやページ送りボタンで音量を上げると、効果音付きで遊べますので是非お試しください。

(あー10分超過したッ!!許せッ!!)

SHARP Brain 用アプリケーションの作成方法

投稿: 2020-12-20 最終更新: 2023-02-09 投稿者: watamario15

この記事は OUCC Advent Calendar 2020 の 20 日目の記事です。OS として Windows Embedded CE 6.0、CPU に ARM926EJ-S (Armv5TEJ) を搭載する電子辞書 SHARP Brain 用アプリケーションの作成方法を解説します。

注意点

ここで取り扱うものは、SHARP 公式の内容ではありません。普通、フリーズなどが起こった場合もリセットボタンを押せば元に戻りますが、万一何かが起こった場合も一切保証できませんので、自己責任で試してください

新機種の多くには、SHARP 公式のソフトウェア以外を起動できなくするプロテクトが掛かっています。具体的には、ビジネスモデル (PW-SBx) を除く PW-Sx4 以降の機種がそれに該当します。そういった機種での起動方法はこちらを参照してください。

この表で第1世代から第4世代に分類されている機種を対象とします。2021 年以降の第5世代に該当する機種用のアプリケーションは、この記事の方法では作成できません。

プログラム

この記事では、プログラミングよりも開発環境やコンパイル方法など、開発手順の解説に重点を置くため、単純なプログラムを使用します。brain.cpp をダウンロードしてください。なお、このプログラムは通常の Windows PC と Windows CE のどちらでも使用できるようにしてあるので、Brain を所持していない方でも Win32 アプリケーションを開発できる環境があれば試すことは可能です。

本格的に開発を行う際は、こちらのノウハウ集も参考にしてください。

開発環境

以下の 3 通りを解説していきます。

  • CeGCC
  • eMbedded Visual C++ 4.0
  • Pocket GCC

Visual Studio 2005/2008 の Professional 以上でも開発可能です。こちらを使用したい場合は、こちらを参照してください。

電子辞書での実行方法

内蔵メモリーまたは microSD カードに「アプリ」フォルダを作成し、その中にメニューに表示させたい任意の名前のフォルダを作成します。その中に、コンパイルして得られた実行ファイルを AppMain.exe に改名したものと、空のダミーファイル index.din を入れます。これにより、「アクセサリー -> 追加コンテンツ -> 追加アプリ・動画」に追加されます。メニューの配置は機種によって異なるので、この通りでない場合は似たものを探してください。加えて、第3世代以降の機種の場合、空のダミーファイル AppMain.cfg を加えることで高解像度状態のまま実行できるようになります。

なお、index.din 及び AppMain.cfg は空のテキストファイルを作成し、ファイル名を index.din, AppMain.cfg (もちろん元の拡張子 .txt は消す) に変更するだけで作成が可能です。ちなみに、ceOpener などの別ツールを導入済みなどで、 exe ファイルを直接実行する場合は以上の作業は不要です。どんな名前でもどこに置いても構いません。

CeGCC

Linux, Cygwin, WSL, macOS 等の UNIX 環境で使用できる、最新の Windows CE 開発環境です。Windows XP のような古い Windows 環境が不要で、GCC 9.3.0 ベースなので C++17 を完全にサポートしているなど、現在では最も使いやすい環境です。ただし、個人の方が作成されたものだというのもあり、若干癖があります。

基本的に公式サイトに従います。Debian 系でない OS や AMD64 以外の CPU を搭載する PC の場合は、こちらに従ってください。

環境構築

/etc/apt/sources.list ファイルに、以下の 1 行を追加します。どちらに属するか分からない場合は、Debian の方で試したうえでエラーが出た場合に Ubuntu の記法を試してください。

Debian:

deb https://max.kellermann.name/debian cegcc_buster-default main

Ubuntu:

deb [trusted=yes] https://max.kellermann.name/debian cegcc_buster-default main

この作業にはテキストエディタを用いても構いませんが、今回はファイルの末尾に足すだけなので、以下のコマンドを実行すればよいです (1 行目は改行、2 行目は実際の追記)。

Debian:

sudo bash -c 'echo >> /etc/apt/sources.list'
sudo bash -c 'echo deb [trusted=yes] https://max.kellermann.name/debian cegcc_buster-default main >> /etc/apt/sources.list'

Ubuntu:

sudo bash -c 'echo >> /etc/apt/sources.list'
sudo bash -c 'echo deb [trusted=yes] https://max.kellermann.name/debian cegcc_buster-default main >> /etc/apt/sources.list'

その後、以下のコマンドを実行してインストールします。

sudo apt update
sudo apt install gcc-arm-mingw32ce

終わったら、以下のコマンドを入力します。

arm-mingw32ce-g++ -v

以下のような出力が得られれば環境構築は終了です。お疲れさまでした!コマンドが見つからないというエラーが出た場合は、正しくインストールできていないので今までの手順をもう一度確認してください。

Using built-in specs.
COLLECT_GCC=arm-mingw32ce-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-mingw32ce/9.3.0/lto-wrapper
Target: arm-mingw32ce
Configured with: ../../../configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-mingw32ce --disable-dependency-tracking --prefix=/usr --syscon
fdir=/etc --with-gcc --with-gnu-ld --with-gnu-as --enable-threads=win32 --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-multilib --dis
able-interwork --without-newlib --enable-checking --with-headers --disable-__cxa_atexit
Thread model: win32
gcc version 9.3.0 (GCC)

ビルド

brain.cpp を配置したディレクトリで、以下のコマンドを実行します。

arm-mingw32ce-g++ -Wall -Wextra -O3 -std=c++17 -march=armv5tej -mcpu=arm926ej-s -static -s -o AppMain.exe brain.cpp

成功すると AppMain.exe が生成されるので、電子辞書にコピーして実行します。冒頭の画像のようになれば成功です!

しかし、この長いコマンドを毎回入力するのは面倒です。また、ここでは紹介しませんが、リソースを含む場合はそのためのコマンドも必要となり、さらに面倒です。ここで、ビルド作業を自動的に行う shell script を用意しました。ceg++ (C++) / cegcc (C) を、コマンドラインオプションにソースファイル名 (複数可) を指定して実行すると AppMain.exe が出力されます。カレントディレクトリに resource.rc があれば、それもあわせてコンパイルします。

注意点

CeGCC のヘッダファイルは通常版 Windows のものを流用していますが、Windows CE での定数は通常版 Windows とは一部異なるため、これが原因で問題が発生する場合があります。例えば、最小化ボタンを表示させたはずが最大化ボタンが出たりします。そのため、ヘッダファイルを書き換える、正しい数値を直接指定する、正しい数値でマクロ定数を定義しなおす、等の対応が必要となります。今回のサンプルソースでは、冒頭にマクロ数値を補正するコードを記述してあります。Microsoft は初期の頃の Windows CE 開発環境を高値で販売していたようなので、「定数をずらすことでフリー実装の登場を遅らせて、その間に自社の開発環境で儲けよう」みたいなことを企んでいたのかもしれません。

また、CeGCC の公式ビルドはデバッグ情報を取り除く strip が行われていないため、開発したアプリケーションを Brain 上で動かすときに必要な C/C++ ランタイムを普通に静的リンクすると、極端に exe のサイズが大きくなります。これに対応するため、挙げたコマンドやスクリプトでは strip を表す -s オプションを付けてあります。

eMbedded Visual C++ 4.0

知る人ぞ知る、2000 年頃の Windows CE 用 Microsoft 純正無料 IDE です。激古なので C++ の新しい機能は使えず、Windows 2000 と Windows XP でしかフル機能が使えないという難点がありますが、最新の CeGCC が発見されるまでは唯一の無料で使える開発環境でした。

環境構築

まず、 Microsoft Download Center (直リン) からダウンロードします。これは自動解凍式の圧縮ファイルになっているので、実行して適当な場所に解凍します。それで得られたファイルの setup.exe を実行し、手順に従ってインストールします。途中でプロダクトキーを聞かれますが、先ほどのダウンロードページの「インストール方法」欄に記載されているものを入力すれば大丈夫です。

次に、Windows 2000, XP の場合は Service Pack 4 (直リン)、Windows Vista 以降の場合は Service Pack 3 (直リン) をダウンロードして、同様の手順でインストールします。

最後に、いずれかの Standard SDK をインストールします。Windows 2000, XP の場合は両方の SDK をインストールしておき、ビルド時にどちらを使うか選択することも可能です。

  • Windows Vista 以降であるか、他の CE4 系デバイス (Sigmarion III など) も対象とする場合は、最初に解凍した中身の SDK フォルダに入っている setup.exe を実行し、指示に従いインストールします。ただし、Windows Vista 以降の場合は Windows XP (Service Pack 3) の互換モードを設定して実行します。
  • Windows 2000, XP であり、他の CE4 系デバイスを対象としない場合は、Windows CE 5.0 の Standard SDK をダウンロードし、インストールします。SHARP Brain のネイティブにより近いものができるのはこちらです。

プロジェクト作成・ビルド

左上の「ファイル(F)」から「新規作成」をクリックします。その後、下の画像のように設定します。CPU に関して、 SHARP Brain は Armv5TEJ ですが、この IDE にはないため ARMV4I を選択します。SHARP Brain 以外の CE デバイス用のビルドも行いたければ、ARMV4I に加えてその他の CPU を選択しても構いません。設定できたら「OK」を押します。

次の画面では、「空のプロジェクト」を選択します。

プロジェクト概要の画面で OK を押すと、プロジェクトが作成されます。

その後、左を FileView に切り替え、Source Files を右クリックしてソースファイルを追加します。分かりやすくなるよう、ソースファイルはプロジェクトフォルダ内に予め入れておくことをお勧めします。

ソースファイルが追加できたら、FileView から先ほど追加したファイルをダブルクリックすると、画面内にソースファイルが表示されます。ここでプログラムを編集することが可能です。今回はソースファイルを UTF-8 エンコードしたためコメントの日本語が文字化けしていますが、無視してください。必要であれば、Shift_JIS でエンコードし直すと正しく表示されます。というか何で Windows CE は Unicode のみ対応なのに eVC4 はUnicode 非対応なのだろうか...

ここで、SHARP Brain で実行する際は AppMain.exe になっていた方が色々とうれしい (先述) ので、デフォルトでこの名前になるように設定しておきます。「プロジェクト -> 設定」を開き、「リンク」タブに移動すると下のような画面になるので、画像のように出力ファイル名を編集して OK を押します。

最後に、画面左上の「STANDARDSDK」という部分では、利用する SDK を指定します。Windows CE 5.0 用の SDK をインストールした場合は、STANDARDSDK_500 となります。

これで準備完了です!では、下の画像の赤丸で囲ったボタンを押してください。

ビルド終了後、以下のようなメッセージが出ますが無視してください。コンパイルエラーがなければコンパイル成功です。

プロジェクトフォルダの ARMV4IDbg に AppMain.exe が生成されているはずなので、電子辞書にコピーして実行してみてください。冒頭の画像のようになれば成功です!

なお、Win32 (WCE ARMV4I) Debug と書かれているプルダウンメニューから、Release ビルドへや他の CPU への切り替えが可能です。

Pocket GCC

SHARP Brain 上でのセルフ開発が可能な GCC の Windows CE 移植版コンパイラです。eVC4 よりさらに機能は限られますが、PC がなくても使用できます。

準備

まず、こちらを参考に導入します。DOS窓Open の準備も必要です。

一通り終わったら、brain.cpp を win.cpp に改名したものと WINBUILD.BAT を電子辞書内の同じフォルダに入れます。この際、WINBUILD.BAT の 2 行目と 3 行目を環境に合わせて編集しておきます。

その後、DOS窓Open の cd コマンドでそのフォルダに移動し、WINBUILD.BAT を実行します。空白や日本語を含んでいても、クォーテーション不要で cd できます。成功すると AppMain.exe が生成されるので、これを実行して冒頭の画像のようになれば成功です!

ちなみに、この記事では説明しませんが WINBUILD.BAT は resource.rc があった場合、それも含めてコンパイルするようになっています。その際、34 行目の -l commctrl は Pocket GCC に commctrl.lib が含まれないため取り除いてください。一応、eVC4 の SDK からこのファイルを持ってくると、(大量の警告の下で) 使えるようにはなります。

おわりに

今回は、SHARP Brain 用アプリケーション開発の方法をまとめました。SHARP Brain のハックに興味がある方は、Brain で動作する Linux ディストリビューション Brainux の開発やその他の議論が活発に行われているコミュニティ Brain Hackers に参加してみると面白いかもしれません。

Win32 API プログラミングについては一切触れませんでしたが、こちらのノウハウ集が参考になると思います。ただし、ノウハウ集にも記載の通り、Windows における最も原始的な方法となるため難易度が高く、C/C++ をそれなりに理解していることが求められます。私も、高2の頃 Hello, world! にたどり着くまでに 1, 2 週間かかりました。さらに Command Bar など、調べても出てこない Windows CE の独自仕様も相当あるので大変です。しかし、電子辞書で自作ソフトが動作する感動はなかなかのものです!

ちなみに、執筆者もいくつかの SHARP Brain 用ソフトウェアをオープンソースで公開しています。執筆地点では素因数分解プログラム, 超大量ファイル整理, KN MemoPad 機能追加版, Brain fuck, Tetris がありますので、もしよければ使ってみてください。Win32 API プログラミングに関しても何か参考になるかもしれません。

では、ここまでお読みいただきありがとうございました!OUCC では、現在も部員を募集中です。興味がある方は、ぜひご気軽に Discord サーバーにご参加下さい!

Advent Calender 参加方法

前提

今回使用するサイトは、adventar.orgというものです。このサイトに登録するにあたり、

  • Google
  • GitHub
  • Twitter
  • Facebook

のいずれかのアカウントが必要になりますので、あらかじめご準備をお願いします。

参加登録

まず、指定されたURLを開きます。(2020年度のアドベントカレンダーのURLはこちら)

次に、赤円で囲んだマークをクリックして、アドベントカレンダーと連携させるアカウントを選択します。

そこからは、アカウントごとに連携させる手順があるので、各自で登録をお願いします。

無事にログインできたら、まだ枠が埋まっていない日の中から投稿したい日を選択します。

すると、選択した後に以下のようなウィンドウが現れるので、上の入力部分には投稿する記事の大まかな内容を記入し、下の入力部分には投稿する日になったときにそのサイトのURLを貼り付けます。

以上の手順によりアドベントカレンダーへの登録は完了となります。

OUCCの主な活動を振り返る

はじめに

この記事はOUCC Advent Calender 2020 の12日目の記事です。

新入生へ向けてのアドベントカレンダーということで、今回はここ数年でこの クラブ が行った活動を、私の知りうる範囲で振り返りたいと思います。

・4月

4月は新入生歓迎(新歓)の時期ということで、課外活動オリエンテーションで、OUCCがしていることや開発したものを展示し、毎週金曜日には部室で説明会を行いました。

・5月

5月にはいちょう祭があり、OUCCの模擬店では、唐揚げや焼き鳥を販売しました。また展示では、部員が作ったゲームを多くのお客様にプレイしていただきました。
この時期あたりで、部員やOBさんが新入生に向けて講習会を開き、講習会に興味のある新入生や部員が講習会に参加しました。(※注)春の講習会の画像は去年のものです

・6月

6月には確定新歓が行われ、新入生は晴れて正式な部員となります。
去年の確定新歓では、部室でたこ焼きやお菓子を食べながら、新部員と既部員がテレビゲームやボードゲーム、雑談等をして交流しました。
また、OUCCでは2D、3DCG班や競技プログラミング班、WEB班、等があり、各部員は興味のある班活に入って班での活動も行います。

・7月

7月は下旬にテストがあるので、上旬の部会で夏休みの各予定を決め、テスト休みとなります。

・夏休み

8月上旬にテストが終わったらいよいよ夏休みです!!
私たちの部室は冷房設備がなく、夏場はサウナと化してしまうため、部員は基本在宅での作業を行います。基本的には個人個人でやりたいことをやりますが、人によっては班で活動したり、似たようなことをしたい同士で共同開発や勉強会を行います。
昨年の夏休みの主な活動としましては、KC3と 夏合宿 がありました。
また、希望者を募って夏コミにも行きます

・KC3

KC3とは、関西情報系学生団体交流会の略称で、関西の大学の情報系団体に所属する学生たちが交流を深める会です。
参加団体は大阪大学コンピュータクラブのほかに、立命館コンピュータクラブ、立命館大学情報理工学部PJ団体 RiG++、関西大学電気通信工学研究会、関西学院大学機巧堂、近畿大学電子計算機研究会、京大マイコンクラブ等があります。
去年の9月に行われたKC3では、各クラブの紹介と、各 クラブ による講習会がありました。また、最後には懇親会があり、他のクラブ の部員との交流ができます。
KC3について詳しくはこちらから

・夏合宿(開発合宿)

去年は夏合宿で福井に行きました!!
この合宿は開発合宿ということで、2つのチームに分かれ、待ちかね祭に向けてゲームの開発を行い、最終日には各チーム制作物を発表しました。

・10,11月

夏休みが終わり10月になるとまちかね祭の準備に向けて動き出します。
まちかね祭が近づいてくると、模擬店の買い出しの確認をしたり、展示するゲームの開発によるデスマーチが発生したりします。
そして、まちかね祭当日は部員が一丸となって展示・模擬店を行います。

・12,1月

この時期になると部室は冷蔵庫並の寒さになるので、部室にこたつが導入されます。部員たちは、各々の開発を進めたり、課題やテストに追われたりと思い思いのことをします。

・春休み

テストが終わり冬休みになると、部員はバイトをしたり、旅行に行ったり、勉強・開発したりと、それぞれ自分のやりたいことをやります。また、4回生の追いコンも開催しました。(今年は新型コロナウイルスの影響で、追いコンは3,4回生のみでの開催となりました)

追いコン(画像はイメージです)

・まとめ

以上がOUCCのおおまかな活動内容となります。
主な活動曜日は金曜日ですが、部室にはいつでも入れるので、金曜日以外に来て作業をする人もいます。また、月に1回ある部会もオンラインでの参加が可能なので、部室に来れない人でも参加できます。
これまで見てもらった通り、このクラブは活動日を柔軟に決めることができ、他のサークルとの掛け持ちも可能です。
今回は大まかな紹介のみとなりましたが、興味のある人はOUCCのTwitter等を見れば今後の活動が分かると思います。

・最後に

このクラブに限らず、サークルや部活に入ることは、他学科の人との交流や大学生活を何かに打ち込むという点で大変良いものなので、自粛期間がおわり各サークルが新歓を始めたら、いろいろなところを見て回ることをおすすめします。

if文をすっきりさせる

ちょっとしたプログラム記述方法を紹介しようと思います。例えば、次のようなメソッドを記述したとします。

        private void Example0(int x)
        {
            if (x%2==0) {
                // 処理
            }
        }

このif文は必要でしょうか?こんなことを聞くからには、もちろんNoです。ただ、if文が必要ないというのは語弊があります。正確には、処理をif文で囲む必要はありません。次のメソッドは全く同じ動作をします。

        private void Example1(int x)
        {
            if (x%2==1) {
                return ;
            }

            // 処理

        }

xが奇数の時、つまり偶数でないとき、return命令によってメソッド処理を終了させます。すると// 処理 の位置に達したときはxが偶数であることが確定しているので、if文による確認を行わず処理を記述することができます。

この記述方法のうれしいところは、鍵かっこで処理を囲む必要がなくなるところです。例では処理は1行しかありませんが、これが何十行と続くと、最後にぽつんと}が残ることになり、どの鍵かっこと対応しているのかわかりにくくなってしまいます。鍵かっこを使わないpythonのような言語であっても、インデントが右にいきすぎてしまい、プログラムが見にくくなること必至です。

        private bool Example2()
        {

             if (ReturnBooleanMethod1()) {
                // 処理
                if (ReturnBooleanMethod2()) {
                    // 処理
                    if (ReturnBooleanMethod3()) {
                        // 処理
                        if (ReturnBooleanMethod4()) {
                            // 処理
                            if (ReturnBooleanMethod5()) {
                                // 処理
                                return true;
                            }
                        }
                    }
                }
            }
            return false;
        }

この記述方法の問題点は、if文の条件がわかりにくくなることです。xが偶数の時処理をしたいのに、if文の条件式は否定である「xが奇数であるか」の確認を行っています。人によっては処理の流れが追いづらいと感じたり、条件によっては否定の記述が難しい場合があります。1つ前の例では、順にメソッドの条件を満たした場合処理をし、次の確認事項を調べて・・・という流れがわかると思います。この記述方法で書いた場合は次のようになります。

       private bool Example3()
        {
            if (!ReturnBooleanMethod1()) {
                return false;
            }
            // 処理
            if (!ReturnBooleanMethod2()) {
                return false;
            }
            // 処理
            if (!ReturnBooleanMethod3()) {
                return false;
            }
            // 処理
            if (!ReturnBooleanMethod4()) {
                return false;
            }
            // 処理
            if (!ReturnBooleanMethod5()) {
                return false;
            }
            // 処理
            return true;
        }

インデントやかっこは見やすくなりましたが、何となくどういう場合にReturnBooleanMethod4()の確認を行うのかわかりにくいですよね?少なくとも僕にはわかりにくいです。また、メソッド内の最初と最後以外でreturnによって抜けると、処理していると思っていたコードが、実はその前にreturnしていて処理していない!ふざけんな!というような事態になったりするので注意です。

この記述方法は、メソッドだけでなくforループからの脱出(break,continue)でも使えます。また、if ... else break のような場合にも、breakする条件を記述することで、そのあとの処理をif文で囲む必要がなくなります。また、elseが消えてますよね。次のコードはbreak文の例を紹介するためだけに書いたどうでもいい動作をするプログラムです。

        private void Example4()
        {
            int sum = 0;
            for (int i=0;i<10;i++) {
                if (i<=5) {
                    sum += i;
                }
                else {
                    break;
                }
            }

            for (int i = 0; i < 10; i++) {
                if (i>5) {
                    break;
                }
                sum += i;
            }

        }

{}で1行とらないような記述方法をとるなら行数は変わりませんが、処理が複数ある場合は{}で1行とる人がほとんどだと思うので、そこそこ使えると思います。

プログラムの見やすい記述方法、書きやすい記述方法は人それぞれだと思います。自分に合った記述方法でデバッグをしやすい、ストレスのたまらないプログラムを書きましょう。