こんにちは、R&Dチームの齋藤(@aznhe21)です。 さあみなさん、ついにこの時がやってまいりました。 本日2019/11/8にリリースされたRust 1.39により、あらゆる環境で最高速な非同期プログラミングが可能になりました。 新たな時代に乗り遅れないよう、今のうちにRustでの非同期プログラミングをマスターしておきましょう。 なお、この記事は、先日開催したOPTiM TECH BLOG Meetupの内容を大幅に加筆修正した上でエントリに仕上げたものです。 まず最初に伝えたいこと 非同期の歴史 Rustの非同期プログラミングの歴史 Rust 1.0以前 Rust 1.0 〜Rust 1.3 Rust 1.2あたり Rust 1.11あたり Rust 1.26あたり Rust 1.36 Rust 1.39 Rustの非同期プログラミングの特徴 ゼロコスト抽象化 プラットフォーム非依
2018 年、Unity はスクリプタブルレンダーパイプライン(SRP)というカスタマイズ性に優れたレンダリングテクノロジーを導入しました。この中には、ローレベルエンジン向けの新しいレンダリングループ「SRP Batcher」が用意されています。SRP Batcher を使うと、CPU によるレンダリング処理の速度がシーンに応じて 1.2 倍から 4 倍に向上します。この機能をフル活用する方法をご覧ください! このコンテンツはサードパーティのプロバイダーによってホストされており、Targeting Cookiesを使用することに同意しない限り動画の視聴が許可されません。これらのプロバイダーの動画の視聴を希望する場合は、Targeting Cookiesのクッキーの設定をオンにしてください。 Cookie settings 上記のビデオは Unity にとって最悪のシナリオを示しています。具
はじめに 以前、Lightweight Render Pipeline(LWRP)と呼ばれていたパイプラインが 2019.3(SRP 7.0.0)から、Universal Render Pipeline(UniversalRP / URP)と改名されました。 blogs.unity3d.com 私は LWRP 含む SRP をあまり調べていなかったのですが、配布しているライブラリの LWRP 対応要望もちらほら聞こえてきましたので、詳しく調べてみることにしました。が、いきなり体系的にまとめるのは自分も分かっていない点が多くかなり大変...なので、プロジェクトを作成し、以前のビルトインのパイプラインから変わったところ等を適当な順番で色々見ていくことにしました。本記事ではレンダリング回り(パイプラインやシェーダの変更点)について調べます(シェーダグラフは本記事では触れません)。URP そのもの
ゲーム攻略wiki風に物理を解説してる「物理攻略wiki」、自分の好みにドストライクでめっちゃ興奮してる https://t.co/pJ6oHXU5z6 https://t.co/c6CNlL5udy
Unity (ゲームエンジン) から Rust で書いたネイティブバイナリを実行する、という行為を試してみました。 サンプルコードは こちら。 なぜRust ? 以前、Unity上で、C#でプログラマブルに任意の形状のメッシュを生成するといったことをやってみました。 ( たとえばこういうふうに、実行中に入力から任意の形状を生成して、メッシュにして描画できると楽しい ) しかし、三角形分割などの幾何アルゴリズムをC#で素朴に実装してみたところ、本に載っているような計算量少なめのアルゴリズムに則ったとしても、(むしろ則ったせいで)、GCゴミの発生を抑えることの難易度がかなり高いな、という感想を持ちました。 こういう類のアルゴリズムは、計算途中の辺や点、面の情報を参照として持ち、それらの空間的なつながりの情報を可変長のコレクションに入れて管理するといったことがどうしても頻出するのではないかと思い
2019/04/18に株式会社gumi様で行ったデザイン講義のスライドです。 デザインとは何か?デザイナーは何を考えてデザインを作っているのか? という話から、実際にデザインを評価・検討するための言葉を紹介しています。 この 作品 は クリエイティブ・コモンズ 表示 - 改変禁止 4.0 国際 ライセンスの下に提供されています。 第二回「UIデザインをはじめよう」はこちら https://speakerdeck.com/kinakobooster/uidezainwohazimeyou 第三回「今日からできるUXデザイン」はこちら https://speakerdeck.com/kinakobooster/jin-ri-karadekiruuxdezain ※訪問講座のご案内※ あなたの会社に話しに行きます。料金表はこちら https://xemono.life/#/workwith/co
集団でソフトウェア開発をするときは、コードレビューをしたりされたりしながら進むのが当たり前となった昨今。 僕が自然と心掛けるようになったコードレビューお作法などをお気楽に書いてみます。 安易に「良い」とか「悪い」とか、一次元的な評価を下すのはよす他人のコードに対し、絶対的に「良い」とも絶対的に「悪い」とも、「大正義」とも言わないようにしている。 コードの書き方や設計の出来栄えは、評価するための色々な物差しがあって、「良い」「悪い」の2つに1つ、斬って捨てられるようなものではないと思う。(むしろ、そういう単純なものではないからこそおもしろいんじゃないだろうか……?) どのような指標をもちだすか、どういった利点/欠点に注目するのか、どんな畑で育ってきたプロダクトか、状況によって下すべき評価は変わるし、数えきれないほどある 設計パターンや慣習、従うべき原則、美的感覚のなかには、相反する「正しさ」
時代に合わせてバージョンアップを続け、モダンな言語もまだまだ彼の背中を追っている部分があると噂されたりしている言語、C#。 現状の利用シーンとして割と大きいめの Unity (ゲームエンジン) では、使えるC#のバージョンがぐいぐいっと上がりはじめて以降、そこそこ新しい書き方も認知されてきているようです。 しかし、個人的に注目している C#の新機能は、ショートハンドや関数型言語由来の機能よりもむしろ、C#自体のパフォーマンスを改善するような文法や標準ライブラリたちです。 ーーパフォーマンスを改善する言語機能って一体なんのことでしょう。 「C# なんて、ランタイムが勝手にJITで最適化した機械語にして走らせてくれるわけで、Unityの場合はc++にトランスパイルされるわけで、べつにプログラマがミクロなチューニングとか意識しなくても、夜、寝る前とかに祈ったり寄付とかをしていれば、ランタイムをつ
For fans of Nagano’s work, you’ll know that he has an incredibly involved and detailed approach to things. However, it’s interesting in how that manifested when he was growing up. “I am from Kyoto but not the city itself, outside the city, is an area called Maizuru. This is a town that has a Navy base, it's a port town. It was also really in the countryside, so information was pretty limited and a
アドベントカレンダーでもなんでもない記事 0日目です。 Unityで長らくゲーム開発をやっているけれど、Web界隈などで色々と発達しているアプリケーション設計パターンをおいそれと持ち込めば良いわけではないと感じているので、それについて考えてみようと思う。 ここでいう設計パターンていうのは、たとえばUIとかをつくるフレームワークの競争で発達してきた MVC派生 や ReactとかのElmアーキテクチャに影響を受けたものたち、はたまた、Webサーバ(HTTPサーバ) を書くときに 「良し」とされている 、DDD的な考え方の上での、抽象レイヤと実装レイヤの分け方を教条化するクリーンアーキテキクチャとかなんかそういうの。 追記: ゲームでも「ドメインロジックとプレゼンテーションの分離」はした方が良いと思っている。全体としては狭義でのMVPとかは自分もやってる。 こういった者達は、先人のアイデアや言
とあるスマートフォン向けMMORPGのプロジェクトで、アプリケーションサーバをほぼすべてGKE(Google Kubernetes Engine)に乗っけて動かしていました。 このゲームは、モバイル向けながら、複数プレイヤ間でそこそこリアルタイム性の高い同時プレイができるものでした。同じフィールドを誰かが歩けば、自分が見ている画面でもほぼ同時にそいつが歩いて横切っていく、同じ敵と皆で一緒に戦えば、誰かが繰り出した攻撃が参加者全員の画面に即同期される、もちろんチャットもできる、そんな具合です。今ではさほど珍しくないのかもしれませんが、PCのオンラインゲームのような機能を搭載した、リアルタイム性の高いモバイルゲームでした。 さて、こうなってくると、オーソドックスなWebサーバのような、HTTP/1でリクエスト/リプライを捌く、というサーバだけでは要件を満たすことができません。 複数プレイヤ間で
2019年にもなって未だに非同期I/Oを使わずPHP、Python、Ruby等でProcessを浪費しているサービスが増える理由とは!RubyPythonPHPRails非同期IO はじめに 間違えている箇所があれば指摘していただきたい 特にPHP,Python、Rubyを本格的に開発した経験が少なく 間違ってたら私のために教えていただきたい ただ1つ 私の中でも正しい用語定義がわからないので 非同期と書いたときは 非同期I/O、ノンブロッキングI/O 両方のことをさし マルチスレッドは並列などと表記する 現在の状況 2019年。Webサービスはどんどんローンチされている Java、nodeといった非同期のサービスも増えてきたが 未だに PHP、Python、Rubyといった非同期ではなくプロセスを立ち上げるサーバが多い (asyncioとかeventmachene等の非同期機能はあるが、
今年、Unty製プロジェクトのパフォーマンス改善をやる機会があったんですが、世の中のかっこいい事例に出てくるような、ハードウェアやVM/コンパイラの気持ちになったミクロなチューニング、フレームワークの制限を回避するための大胆な再実装…… そういうかっこいい作業、には思ったよりならず、なによりもまず先に、Unityを使っているが故の落とし穴から這い出る一本道の作業が多めになってしまった。 それというのも、Unityは非常に、そこそこのものを最小手順で 確認/動作できる、誰でもかんたんにモノをつくれる、という部分を大事にしているから、「パフォーマンスを考えると普通はこうなっていてほしいよね」といった部分が犠牲になっている、あるいは手が回っていない、という部分が実際まだまだあるように思えた。 simple よりも easy を取っているというやつだろうか。 仕事でやっていたプロジェクトは、まずコ
Unity(ゲームエンジン)とGoogle が パートナーシップを結んだぜ、みたいなニュースが記憶に新しいですが、 先月末くらいに、彼らのオンライン対戦FPSのサンプルコードについての詳しい解説動画が上がってました。 FPS Sample Game Workflows | Unity ちなみに、このゲームのソースコードは、 アセットも含めて全て Github で公開されています。 Unity-Technologies/FPSSample 動画のなかでも、とくにこれが興味深いです。 Deep dive into networking for Unity's FPS Sample game - Unite LA - YouTube UDPを使ったオンライン同期のサーバサイドの実装、とくに同期の詳細なメカニズムについて、ここまで噛み砕いた説明を見たことがなかったので、僕にとってはなかなかインパク
この記事は、これまでにおもちゃラボで紹介してきたUnityのシェーダ入門記事40本のまとめです。 1日に5記事読めば7日間で読み切れるはず...今のところ(笑) シェーダって時々聞くけど難しそう・・・というイメージをお持ちの方も多いと思います。でも、Unityを使えばかなりのメンドウな部分はUnityにおまかせできちゃうので、本当に必要な部分のシェーダを書くだけでイメージ通りの絵作りができるようになります。 使用するシェーダ Unityで使えるシェーダにはsurfaceシェーダと頂点/フラグメントシェーダの2種類があります。ここではこの2つのシェーダの他、ライティング・ポストエフェクトの内容も解説しています。それぞれの各記事へのリンクを下にまとめておきます。また、Unity2018からはノードベースでシェーダを作成できるShader Graphという機能も提供されるようになりました。これか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く