hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
日野・リエッセ いすゞ・ジャーニーJ
2003年11月発売、いすゞ自動車へジャーニーJとしてOEM供給を開始。型式はKK-RX4JFEJ。ラインナップはリエッセと同一。
2004年8月のマイナーチェンジで平成15年排出ガス規制に適合、国土交通省「超低PM排出ディーゼル車」85%低減レベルの認定を受けた。型式はPB-RX6JFAJとなる。以降はOEMから統合車種の扱いとなる。
2007年6月にもマイナーチェンジが行われ、平成17年排出ガス規制に適合、国土交通省「低排出ガス重量車」（平成17年基準NOx／PM10%低減）に認定。型式はBDG-RX6JFBJとなる。
2011年8月、リエッセと同様にポスト新長期規制（平成22年排出ガス規制）をクリアすることなく製造中止となった。貸切や自家用向けは事実上、ジャーニー（日産・シビリアンのOEM車）がカバーすることになるが、小型路線バスおよび小型ディーゼルバスはいすゞのラインナップから消滅した。いすゞ・ジャーニーはガソリンエンジンのみの設定となった後、日産・シビリアンとともに2021年に販売を終了した。
ピエール・アベラール
ピエール・アベラール（Pierre Abélard 、1079年 - 1142年4月21日）は中世フランスの論理学者・キリスト教神学者。「唯名論」学派の創始者として知られ、後にトマス・アクィナスらによって集成されるスコラ学の基礎を築いたとされる。弟子であるアルジャントゥイユのエロイーズとのロマンスでも有名。ラテン語式のペトルス・アベラルドゥス(Petrus Abaelardus)という名前でも知られる。
ピエール・アベラール 生涯
アベラールはナントに近いパレ（Pallet）で生まれ、音声言語論者ロスケリヌス（Roscelinus 1050?-1123?）と実在論者のギヨーム・ド・シャンポー（Guillaume de Champeaux 1070?-1121）に師事、パリのノートルダム大聖堂付属学校で神学と哲学の教師となって非常な名声を博した。
ピエール・アベラール 生涯
1117年頃、アベラールはノートルダム大聖堂参事会員フュルベールの姪エロイーズ（1101-64）を知った。エロイーズは容貌もよく、学問に優れていたため国内でも有名であった。アベラールはエロイーズに魅力を感じ、フュルベールに住み込みの家庭教師となることを申し出た。20歳以上年の離れていた2人は熱烈な恋に陥り、やがてエロイーズは妊娠した。アベラールはエロイーズをひそかにブルターニュの妹のところに送り、そこで男の子アストロラーベ（船乗りが航海で使う天文観測器の意）が生まれた。このスキャンダルに叔父フュルベールは激怒したが、アベラールは和解を申し出て、エロイーズと秘密の結婚をした。しかし叔父が和解の条件を守らないことやエロイーズを虐待することなどから、エロイーズをアルジャントゥイユ修道院に移した。これにフュルベールは激怒し、縁者らにアベラールを襲撃させ、睾丸を切断させた。アベラールは後にこれを「罪を犯したところに罰を受けた」といっている（後出の第一書簡）。実行犯2人は捕らえられ、眼をえぐられ、陰部を切除された。この事件の後、アベラールはパリを離れてサン・ドニ修道院に移り、修道士となり、エロイーズはアルジャントゥイユ修道院の修道女になった。
ピエール・アベラール 生涯
アベラールは学問においては自説を決して曲げない性格であり、間違っていると思えば己の師ですら罵倒し、論破した。この性格のため、碩学であったが多くの敵対者を生んだ。サン・ドニでは当時修道院で信じられていた、修道院の創設者聖ドニ（デニス）が『使徒行伝』のアテナイのディニュシオスであるという通説を論破して修道士たちを激怒させた。この頃アベラールは『三位性と一位性について』を著し独自の三位一体解釈を行ったが、これはソワッソン公会議（1121年）で問題とされ、その教説は異端宣告を受けた。そのため、パラクレトゥス聖堂に移ると修道院付属学校を自ら開いて教え、1125年には招かれてブルターニュのサン＝ジルダ＝ド＝リュイス修道院の院長となった（のちにエロイーズはパラクレトゥス聖堂の敷地内に女子修道院を建てて院長となった。）1132年頃、エロイーズとの恋などを記した自伝的な書簡を友人あてに記した。
その後、アベラールは再びパリに戻るが、一連の普遍論争においてクレルヴォーのベルナルドゥスと対立し、サンス公会議（1140年）でも異端とされた。晩年はクリュニー修道院ですごし、サン・マルセル修道院でその生涯を閉じた。遺体はエロイーズの願いに応じてパラクレトゥスに埋葬され、1164年に彼女が亡くなると同じ墓に葬られた。（19世紀になって2人の遺体はペール・ラシェーズ墓地に改葬されたという。）
ピエール・アベラール 思想・著作
アベラールは普遍論争では唯名論者に位置づけられる。普遍論争はもともと普遍は実在するか（実在論）、名目だけのものか（唯名論）を巡って行われたもので、普遍は実在しないとする唯名論を突き詰めてゆけば、教会（カトリック=普遍）、ひいては神を否定する思想にもつながりかねない。アベラールの三位一体論の思想は異端視されたが、唯名論としては折衷的、穏健なものであり、神の意志の中に普遍は存在するとしていた。アベラールの思想はやがてスコラ学の基礎となり、トマス・アクィナス（実在論者とされる）により大成された。
アベラールの主な著作は以下のようなものである。
『アベラールとエロイーズ』 沓掛良彦・横山安由美訳、岩波文庫、2009年（旧版は畠中尚志訳） 
二人の往復書簡集の体裁を取る。第一書簡は1132年頃（サン・ジルダ修道院長時代）にアベラールから友人あてに書かれた。内容は自己の生涯を振り返るものでエロイーズとの恋の話も含む（これが『災厄の記』"Historia Calamitatum" か）。これをエロイーズが読み、長い間音信がないことを切々と訴える第二書簡が書かれた。第二書簡から第五書簡までは「愛の書簡」ともいわれ、以後はアベラールがエロイーズの信仰を励ます内容に移り、「教導の書簡」ともいわれる。
OpenGL
OpenGL（オープンジーエル、英: Open Graphics Library）は、クロノス・グループ (英: Khronos Group) が策定している、グラフィックスハードウェア向けの2次元/3次元コンピュータグラフィックスライブラリである。SGI社内で自社のCGワークステーション向けにクローズドに策定されたAPI仕様が改良されて公開され、後に大きなシェアを持つに至った。現在は多様な描画デバイスを包括するグラフィックスAPIのオープン標準規格として策定が行なわれている。
OpenGL 概要
OpenGLは、SGIをはじめ、ヒューレット・パッカード (HP)、サン・マイクロシステムズ（現オラクル）、IBM、SONY-NEWSなどのUNIXワークステーションのほか、Linux、FreeBSDなどのPC UNIXに加え、Windows、macOS等で使用できるクロスプラットフォームなグラフィックスAPIである。また、モバイルデバイスや家電など組み込み用途向けのサブセット版であるOpenGL ES (OpenGL for Embedded Systems) 規格も存在する。そのほか、航空機や車載ソリューションといったセーフティクリティカルシステム向けのOpenGL SC規格も存在する。
OpenGL 概要
オープン標準として公開され、幅広い処理系に対応しているため、家庭用・業務用問わず広く普及している。描画デバイスの実装を隠蔽する抽象化層として機能するため、移植性が高い。また、描画演算処理をOpenGLに対応する専用ハードウェア (GPU) に委ねることで非常に高速に動作し（ハードウェアアクセラレーション）、CPUのみによるソフトウェア描画と比較して高いフレームレートを維持したまま高解像度かつ複雑な3Dグラフィックスをリアルタイム描画できる。有償・無償の豊富な補助ライブラリがあることも特色として挙げられる。Windows, Mac OS, Linux, BSD等の様々なオペレーティングシステム (OS) の上で利用可能であり、個人でも無料のソフトウェア群のみでGPUの能力を活用した3Dプログラミング環境を整備できる。開発・実行環境として広範なプラットフォームをサポートすることから、3次元コンピュータグラフィックスの学習や学術研究、クロスプラットフォームなクローズドソース/オープンソースソフトウェア開発などにも適している。
OpenGL 概要
OpenGL APIはC言語関数群の形で提供され、またクロノスグループが策定・公開しているのは、OpenGL API仕様のドキュメントおよびC/C++用のヘッダーファイルだが、FortranやJavaなどの他言語向けのラッパー／バインディングも存在する。OpenGLの実装は、主にハードウェアベンダーまたはオペレーティングシステム (OS) によって提供されるデバイスドライバーである。
OpenGL 概要
OpenGLの最初の仕様では、テクスチャマッピングが標準的にサポートされておらず、1997年のOpenGL 1.1でようやく拡張機能から必須機能に格上げとなるなど、ゲーム開発によく使われるようなエフェクト処理のサポートが弱かった。2004年に発表されたOpenGL 2.0で高水準シェーディング言語 (GLSL) を標準化したが、その後もDirectX (Direct3D) と比べて標準化が遅く、必須機能としてのサポート追加は数年遅れとなることが多かった。しかし、OpenGL 4.0のリリース以降はGPUの進化に合わせたOpenGL APIの対応が進み、主要な機能に関しては、OpenGL 4.3以降とDirectX 11 (Direct3D 11) 以降との差異はほとんど無くなっている。とはいえ、OpenGLとDirect3Dは、その設計思想の違いから1対1で対応するものではないため、移植性は完全ではなく、また性能面ではハードウェアおよびドライバーのOpenGL/Direct3D最適化レベルに依存するため、利用分野やプラットフォームに応じた住み分けも依然として根強く残っている。
OpenGL 概要
しかし、OpenGLは根本的なAPI設計が古く、すでに最新のCPUやGPUの性能を十分に引き出すことができなくなっており、またデバイスドライバー実装の品質管理などにも問題を抱えている。2016年に後継のVulkanが発表された後は、OpenGLのバージョンアップはほとんどなされていない。また、標準化に時間のかかるオープン仕様のAPIよりも、MetalやDirect3Dといった特定のプラットフォーム専用APIのほうがOSのアーキテクチャと親和性の高い独自機能あるいは先進的機能を導入しやすく、性能や安定性の面でも有利であるため、OpenGLは非推奨扱いになったり、ドライバーが提供されなくなったりしている環境も存在する。後述の#Vulkan、#macOSでの非推奨化、#ARM版Windowsでの利用も参照のこと。
OpenGL 概要
なお、例えばOpenGLプログラマブルシェーダーを利用するには特定のバージョン以降のOpenGLに対応したハードウェアが必要であるなど、OpenGL対応を謳っているデバイスでも最新のOpenGL機能が使えるとは限らない。また、Intel GMAやIntel HD Graphicsなどのように、DirectX 9.0c（シェーダーモデル3.0）には対応するがOpenGL 2.0には対応しなかったり、DirectX 10（シェーダーモデル4.0）には対応するがOpenGL 3.2には対応しなかったり、DirectX 11（シェーダーモデル5.0）には対応するがOpenGL 4.3には対応しなかったり、さらにはOSによってOpenGLの対応バージョンに違いがあったりと、DirectXと比べて同等世代のOpenGLへの対応が遅い環境も存在する。
OpenGL 概要
もともとOpenGLはワークステーション発祥のグラフィックスAPIであり、工業製品などの設計・製造の過程で用いられるCAD/CAM/CAEで必要となる正確・高精度なモデル描画を最優先の用途としていた。また、ポリゴンの頂点座標変換や陰影計算などのジオメトリ処理を当初からグラフィックス処理専用チップに実行させることが前提であったため、OpenGL対応ハードウェアを利用することで大量のポリゴンの高速な描画を実現することができた。一方、Direct3Dでは当初ジオメトリ処理にCPUを用いており、ハードウェアT&Lに対応したのは1999年リリースのDirect3D 7以降である。またDirect3Dは正確性よりも描画速度が優先されるゲームグラフィックス用途に最適化されていたため、きわどい位置でポリゴンが交差した場合など、描画結果が正確でない場合があった。そのため、利用者からはOpenGLのほうがCADや3次元可視化などの業務用に強いという見方がなされていた。
業務用の製品として、正確なモデル描画や安定した動作を保証したビデオカード（グラフィックスカード）が存在し、これらは主にハードウェアやデバイスドライバーがOpenGLに最適化されていることが謳われている。ただし、Direct3D 11.xとOpenGL 4.xの違いはすでにほとんどなくなっており、Direct3Dであってもドライバーレベルの対応によってOpenGL同様の高精度・高安定性を実現できるようになっていること、またDirect3D 12に至っては両者をしのぐ機能や速度性能を実現していることから、業務用のアプリケーションソフトウェアであってもWindowsではOpenGLによる描画モードのサポートを終了し、Direct3Dのみをサポートする事例も増えている。詳細は後述の#DirectXとの関係を参照のこと。
のちにWindowsだけでなくmacOSやLinuxなどにも移植あるいはマルチプラットフォーム展開されるPCゲーム開発でもOpenGLが利用されるようになった。AndroidやiOSといったモバイルOSで利用可能なOpenGL ESは、OpenGLと類似のAPIであり、異なるOS間でコードを相互移植・流用しやすいというメリットもある。しかし、Windows以外のプラットフォームでもVulkanやMetalといった後発のローレベルAPIによる置き換えが進んでいる。Linux上でWindowsアプリケーションを直接実行させるためのWindows APIエミュレーションレイヤーであるWineでは、従来はDirect3D互換実装のバックエンドにOpenGLが使われていたが、Vulkanをバックエンドに使うライブラリも開発されている。Unreal EngineやUnityといったゲームエンジンでは、ゲーム開発者はグラフィックスAPIを直接利用する必要がなく、実行環境に応じて自動的に最適なAPIによるレンダリングバックエンド実装が使われるが、従来のOpenGL/OpenGL ESに加えてローレベルAPIのサポートも追加されている。
クロスプラットフォームなアプリケーションフレームワークでも3Dグラフィックス機能のサポートにOpenGLが使われることが多く、例えばQtはバージョン5.xまでOpenGLに依存していたが、バージョン6.0にてWindowsではDirect3Dを、macOSではMetalをデフォルトのレンダリングバックエンドとして利用する抽象化レイヤーが導入された。
OpenGL 歴史
元々はSGIが自社ワークステーションで使用していたIRIS GLというライブラリを改良し、移植性を高めたものである。
1992年以降は、OpenGL Architecture Review Board (ARB) により監修されることとなる。このARBには、3Dlabs、Apple、AMD（旧ATI）、デル、エバンス・アンド・サザランド（E&S）、HP、IBM、インテル、Matrox、NVIDIA、シリコングラフィックス、サン・マイクロシステムズ（現オラクル）が参加している。2006年9月21日以降からは、100以上の企業で構成される標準化団体クロノス・グループ (The Khronos Group) へ管理が移行し、OpenGL ARB Working Group (OpenGL ARB WG) となった。
オープンな仕様であるため、各種OSに移植または互換GLが作成され、またグラフィックチップベンダーもオープンソースOS用のドライバーを用意するなど汎用性に富むライブラリとなっている。ベンダー独自の機能にも、「拡張」（Extension）という形で柔軟に対応できるため、いち早く最新の3Dグラフィックスハードウェアによる先進技術を利用できる反面、ハードウェアを限定した汎用性のないアプリケーションも開発できてしまう。ベンダー拡張の中には、のちに標準仕様として取り込まれたものもある。
OpenGL 歴史
OpenGLの標準化はDirectX (Direct3D) と比較すると遅い傾向にある。OpenGL 3.0以降、仕様の更新頻度は高まり、テッセレーションの標準化（DirectX 11.0とOpenGL 4.0）に関してはリリース時期にそれほど時間差はなかったが、コンピュートシェーダーの標準化（DirectX 11.0とOpenGL 4.3）に関しては時間差が大きかった。しかし、OpenGLのほうが先行して導入・標準化し、のちにDirectXが追従した機能もいくつか存在する。ASTCやETC/EACのようにOpenGL/OpenGL ESでしかサポートされていないものもある。
OpenGL 特徴
OpenGLは画面（フレームバッファ）に描画することを前提に設計されている。3DCGを描画できると言っても、オフラインレンダラー（POV-Rayなど）のようなレイトレーシング法は標準ではサポートされておらず、ポリゴンなどのプリミティブ形状をリアルタイムに順序をもってラスタライズ（画素化）して合成することで3DCGを描画する。そのため、形状同士が反映し合うような鏡のような反射、ガラスの屈折、投影、交差した半透明形状などを表現するには、そのためのアルゴリズムを実装する必要がある。効率良く描画を行わせるためには、アルゴリズムの特性を理解した高度なプログラミングが必要とされる。
柔軟な画像処理を行うために、奥行き情報を記録してZバッファ法などに利用できる「デプスバッファ」、形状のインデックスを記録してマスク処理などを行える「ステンシルバッファ」、高精度なカラー合成などを行える「蓄積バッファ」など、特殊な画素情報がサポートされている。また、元来OpenGLやGPU内で固定的に処理されてきた頂点データやフラグメント（ラスタライズにより生成される画素）の処理をGPUの強力な処理能力を活かしつつプログラミング可能にするプログラマブルシェーダーの登場と、それを制御するシェーディング言語GLSLの採用により、さらに多種多様な表現が可能になった。
OpenGL 特徴
また、OpenGL 2.0ではパーティクル機能を主眼に置いたポイントスプライトをサポートしている。一般的にパーティクルや2次元画像のオブジェクトを3次元空間に合成する場合は、平板なポリゴンにテクスチャを張り、常に視点と平行になるよう調整する「ビルボード」と呼ばれる手法が使われているが、ポイントスプライトを使うことでビルボードに代わり、座標計算やプログラミングのコストを軽減できる。
なお、OpenGL 2.xまではプリミティブの描画を記録・再生するDisplay Listと呼ばれる機能や、Begin/Endブロックによるプリミティブ描画コマンドのCPUベース記述モードといった上位レベル機能が存在したが、OpenGL 3.0のコアプロファイルでは廃止予定の非推奨機能となった。
OpenGL コード例
C/C++向けのOpenGLコード例を示す。
他にも、ユーザーメモリ頂点配列／エレメント配列（CPU側データ）や、頂点バッファ／エレメントバッファ（GPU側データ）を利用した、より高速な描画方法がある。なお、Direct3Dの頂点宣言・頂点レイアウトに似た機能として Vertex Array Object (VAO) および Vertex Attribute が存在するが、Direct3Dのように頂点バッファと頂点属性を完全に分離して扱えるものではない。頂点宣言・頂点レイアウトの互換機能 GL_ARB_vertex_attrib_binding が標準化されているのはOpenGL 4.3/ES 3.0以降である。
プログラマブルシェーダーを利用する場合は、GLSL言語等を使いシェーダープログラムを別途作成して、glUseProgram()関数を使ってあらかじめレンダリングコンテキストにプログラムオブジェクトをセットしてから描画関数を呼び出す必要がある。
OpenGL 補助・拡張ライブラリ
OpenGLそのものは、ハードウェアおよびデバイスドライバー層に近い低次のライブラリである。そのため、よりアプリケーションソフトウェア層に近い、多くの高次の補助・拡張ライブラリが存在する。主に、3D描画機能を簡易化・拡張するもの、ウインドウシステムをサポートするもの、グラフィックス面以外の機能を付加するものに分けられる。
C/C++以外の主要なOpenGL言語バインディング（ラッパー）とライブラリには以下のようなものがある。
その他の言語バインディングについては、Language bindings - OpenGL Wikiを参照のこと。
なお、WebGLはJavaScript向けの単なるラッパーや言語バインディングではなく、OpenGL ES派生の別規格である。
OpenGL 補助・拡張ライブラリ
DirectXやVulkanとは異なり、具体的な公式ソフトウェア開発キット (SDK) や開発者向けのソフトウェアスイートは提供されていない。KhronosによるOpenGL SDKのサイトでは、APIリファレンスへのリンクや、補助ライブラリおよび開発ツールへのリンクが記載されているのみである。NVIDIAのように、自社GPU向けのOpenGL拡張ヘッダーや開発ツールを含むSDKを提供しているベンダーもある。Microsoft Windows SDKにはWGLとともに、OpenGL 1.1およびGLUのヘッダーとインポートライブラリが含まれている。
OpenGL バージョンの変遷
テクスチャに対応。Windowsの標準ドライバーおよびWGLで標準サポートされているのは、このOpenGL 1.1である。
2003年にリリースされたOpenGL 1.5では、拡張機能としてプログラマブルシェーダーのための高級言語（GLSL 1.0）に初めて対応した。
2004年にリリースされたOpenGL 2.0では、シェーディング言語GLSLのバージョン1.1対応が標準仕様として盛り込まれた。
全般的な機能はDirect3D 9のシェーダーモデル2.0および3.0世代に相当する。
2008年にリリースされたOpenGL 3.0では、肥大化したOpenGL APIセット自体のシェイプアップを目的として2.x以前の世代を切り捨てる大幅なアップデートが行われ、多くの機能が非推奨・廃止予定になった。翌2009年3月に発表されたOpenGL 3.1では固定機能シェーダーが標準仕様から取り除かれ、拡張機能扱いとなった（GL_ARB_compatibility）。また同年8月に発表されたOpenGL 3.2では、コアプロファイルと互換プロファイルの概念が導入されたほか、Direct3D 10で導入されたジオメトリシェーダーに正式対応した。互換プロファイルでは固定機能シェーダーが含まれるように再定義されたが、互換プロファイルをサポートするかどうかは実装に依存する。
OpenGL バージョンの変遷
固定機能シェーダーの廃止やジオメトリシェーダーの対応などは、Direct3D 10の仕様と合致しており、シェーダーモデル4.x世代に相当する。
2010年3月11日に OpenGL 4.0 を発表。Direct3D 11のハル シェーダー、テッセレータおよびドメイン シェーダーに相当する、テッセレーション制御シェーダー、テッセレーション プリミティブ ジェネレーターおよびテッセレーション評価シェーダーが搭載された。
2010年7月26日に OpenGL 4.1 を発表。シェーダープログラムバイナリの取得やビューポート配列の対応など。
2011年8月8日に OpenGL 4.2 を発表。シェーダーにおけるアトミックカウンターの実装など。
2012年8月6日に OpenGL 4.3 を発表。Direct3D 11のコンピュート シェーダーと同様のGPGPU用演算シェーダーが追加搭載された。また、次世代テクスチャ圧縮技術であるASTCのサポートが公式拡張として定義された。
2013年7月22日に OpenGL 4.4 を発表。バッファ制御や非同期クエリ対応など。
2014年8月11日に OpenGL 4.5 を発表。Direct State Access (DSA) 対応など。
OpenGL バージョンの変遷
2015年8月10日にOpenGL 2015 ARB Extensionsとして、OpenGL ES 3.2互換機能やシェーダーの並列コンパイル機能などが拡張として追加された。
2017年7月31日に OpenGL 4.6 を発表。SPIR-Vの導入、Vulkan/Direct3Dとの相互運用性の強化など。
以前はOpenGL仕様のアップデートの速度や頻度はDirect3Dに比べて非常にゆっくりとしたものであったが、OpenGL 4の機能の中にはDirect3D 11と同等あるいはそれ以上に素早く追加されたものもある。全般的な機能はシェーダーモデル5.x世代に相当する。
SIGGRAPH 2014で、レガシーな設計が蓄積しているOpenGLをリセットし、ゼロから構築し直して刷新する、次世代の標準3D API規格（OpenGL Next Generation, glNext）の策定が始められることがアナウンスされた。このとき、マルチスレッド対応やシェーディング中間言語などの近代的な技術が導入されることが発表された。
OpenGL バージョンの変遷
GDC 2015では、新規格の名称が"Vulkan"（ドイツ語で"火山"）となることが発表され、Direct3D 12同様のコマンドキューベースのマルチスレッドレンダリング機能や、OpenCLとのプログラミング基盤共通化をもたらすSPIR-V中間表現を導入することが明らかにされた。また、VulkanにはAMD独自のローレベルグラフィックスAPIであるMantleが要素技術として取り込まれることが発表された。
2016年2月16日、Vulkan 1.0の正式仕様がリリースされた。
なお、Vulkanはハードウェアの詳細な制御を可能とするローレベルAPIであるため、習得難易度が高く、アプリケーションコードの記述量が増えるというデメリットも存在する。一方、従来のOpenGLはCPU-GPU間の同期などの煩雑な処理を自動で行なってくれる上位層のAPIであり、Vulkanと比較すれば習得も容易である。膨大な過去のコード資産やノウハウも蓄積されている。そのため、OpenGLは今後もメンテナンスおよびアップデートが継続されることになっている。ただし、2017年にリリースされたOpenGL 4.6を最後にOpenGLのバージョンアップは止まっており、以降は仕様書のメンテナンスだけにとどまっている。
OpenGL 問題点
OpenGL 3.xで固定機能を分離するなどのシェイプアップは図られたが、しかしOpenGLは互換性維持という名目で、1.xや2.x時代に設計された古いAPI構造の大部分をいまだに踏襲している。一方で競合APIのDirect3Dは互換性を切り捨てながらも思い切った仕様変更により、APIをその当時の技術トレンドや先進技術に即した形で洗練してきた。またDirect3Dは公式ドキュメントが充実していることや、習得がしやすいことも評価されている。実際にOpenGL仕様そのものに対して、開発者から不満の声も上がっている。ここではOpenGLの弱点や問題点、および不足機能に関して記述する。なお、これらはOpenGLだけでなくOpenGL ESにも共通して言えることである。
OpenGL 問題点
OpenGL単体では、WindowsのGDI/GDI+やmacOSのCore Graphicsのような上位レベルの文字列描画用APIが用意されていないため、あらかじめ文字が描画されたテクスチャを（画像ファイルから読み込むなどして）利用するか、プラットフォーム依存の上位レベルAPI（例えばWindowsの場合はwglUseFontOutlines()関数など）と連携する必要がある（クロスプラットフォームのユーティリティライブラリであるGLUTなどを使用すると、文字・文字列を描画することができるが、その機能はごく限られており、あくまでデバッグ用途などの簡易的なサポートにとどまる）。NVIDIA拡張としてはGL_NV_Path_Renderingが存在し、高度なプリミティブ描画のGPUアクセラレーションやフォントもサポートするが、標準化はされていない。
OpenGL 問題点
なお、Direct3Dも同様に文字列描画が弱点であるが、Microsoft Windows 7に搭載されたDirectX 11以降ではDirect2DやDirectWriteといった複雑な2D描画や文字列描画に特化した上位レベルの派生APIや、DXGIを経由したDirect3Dとの相互運用・連携機能も整備されている。また、WPFではハードウェアに応じてDirect3Dが使用されるが、Direct2D/DirectWriteのようにAPIが高度に抽象化されており、複雑な2D描画や文字列描画にはDirect3DやOpenGLを直接使用するよりも向いている。
OpenGL 問題点
Direct3DではDXGIアダプターを列挙することで、複数のGPUを搭載したシステムにおいて任意のGPUを選択的に使用することが可能となっている。これにより、Direct3Dのコンピュートシェーダー（DirectCompute）ではCUDAやOpenCLのように複数のGPUを利用して各々にGPGPU演算処理を分散実行させ、アプリケーションソフトウェアの並列処理性能を向上させるといった使い方ができる。一方、OpenGLで複数のGPUを選択的に使用したり、それぞれのGPUに対してレンダリングコンテキストやリソースを作成したりする機能はOpenGL 4.6時点でも標準化されていない。Windows環境においては、2006年にNVIDIAからWGL_NV_gpu_affinity、2009年にAMDからWGL_AMD_gpu_associationというWGL拡張がそれぞれ提供されているが、AMD拡張のほうはRadeonでもFireProでも使用できるものの、NVIDIA拡張のほうはGeForceでは使用できず、Quadroのみの対応となっている。Windows以外のプラットフォームではAMDによるX Window System向けのGLX拡張GLX_AMD_gpu_associationのみで、NVIDIAからは提供されておらず、アプリケーション側からリソースを割り当てるGPUを個別に指定する手段がない。
OpenGL 問題点
なお、NVIDIA SLIに対応した複数のGPUを用いてSLI構成を行なうことによりGPUドライバー側で分散処理を実行させることはできるが、SLIは主にOpenGLやDirect3Dにおけるグラフィックスフレームのレンダリングを自動的に分散処理して高速化する技術であり、SLI環境下でのGPGPU分散処理を行なう場合は注意点や制約が存在する（NVIDIA GPUにおけるGPGPUはすべてCUDA基盤を利用しているため、このSLI環境における制約はCUDA/OpenCL/DirectCompute/OpenGL Compute Shaderを問わない）。同様にAMD CrossFire (CrossFireX) も分散レンダリングのためのマルチGPU技術であり、またDirect3D 9/10/11およびOpenGLアプリケーションでCrossFireを利用するにはフルスクリーンモード（排他モード）で動作している必要がある。さらに、AMDマルチGPU環境でOpenCLを利用したGPGPU分散処理を行なう場合、CrossFire (CrossFireX) をOFFにすることが推奨されている。なお、SLIやCrossFire/CrossFireXではメモリのミラーリングが行なわれるため、複数のGPUを搭載していても、使用できるメモリ総量は各GPUメモリの合計値とはならない。一方、DirectX 12（WDDM 2.0）ではSLIやCrossFireといったベンダー独自技術に依存しない形でマルチGPUにネイティブ対応し、標準で分散レンダリングを可能とするほか、複数GPUのビデオメモリを単一のメモリプールに統合することも可能となっている。
OpenGL 問題点
また、Adobe PhotoshopではバージョンCS4以降、OpenGLによるハードウェアアクセラレーションが導入されているが、マルチGPU環境は推奨されていない。
OpenGL 問題点
DirectCompute (Direct3D 11/12) ではCUDAおよびOpenCL同様に、OSのウィンドウシステム（ユーザーインターフェイス）とは直接関連しない完全なオフスクリーンオブジェクトであるDirect3Dデバイスおよびデバイスコンテキストを作成するだけで、コンピュート機能を利用することが可能となっている（コンピュートシェーダーの実行つまりコンピュートカーネルの発行には、DXGIスワップチェーンの作成およびプレゼンテーションは不要）。一方、OpenGL APIは必ずレンダリングコンテキストを作成してから使用する必要があり、また描画命令を発行するためにはレンダリングコンテキストをバインドするサーフェイスを、OSのウィンドウシステムに関与するAPIを利用して作成する必要がある（例えばWindowsの場合はウィンドウDCまたはメモリDCといったGDIのデバイスコンテキストが必要）。OpenGL 4.3では汎用計算向けのコンピュートシェーダーが搭載されたが、この制約のためにOpenGLでコンピュートシェーダーを利用する場合は必ずOSのウィンドウシステムへのアクセスが必要となってしまう。シミュレーションの可視化など、OpenGLコンピュートシェーダーを必ずグラフィックス連携用途に使うことを前提としている場合は大きな問題にならないが、完全なオフスクリーンで純粋にコンピュート機能を利用しようとする場合には障壁となりうる（OpenGL 4.6時点での代替策、すなわち完全オフスクリーンでのコンピュート実行はOpenCLに頼らざるを得ない）。
OpenGL 問題点
Direct3D 11ではイミディエイトコンテキスト／ディファードコンテキストという形で、マルチコアCPUにおいてマルチスレッドを活用して描画パフォーマンスを向上する仕組みが導入され、Direct3D 12ではさらにコマンドキューベースのマルチスレッドレンダリング機能による描画効率の向上が図られているが、OpenGLでは4.6時点で相当機能をサポートしていない。また、Direct3D 11ではデバイスインターフェイスのメソッド呼び出しがスレッドセーフであり、サブスレッドからのリソース生成や複数のスレッドからのリソース同時生成に標準で対応している（同時利用可能なスレッド数はドライバーに依存する）が、OpenGLではレンダリングコンテキストを作成したスレッドのみがリソースを扱えるようになっているため、サブスレッドでリソース生成を行なうにはwglShareLists()関数やglXCreateContext()関数といったプラットフォーム依存のAPIを利用して明示的にコンテキスト共有を行なう必要がある。OpenGL 4.6ではGL_KHR_parallel_shader_compileとして複数のシェーダーの並列コンパイルに対応したが、コア機能ではなく拡張扱いである。
OpenGL 問題点
Direct3D (Windows) にはWHQL (Windows Hardware Quality Lab) というドライバー品質保証の仕組みが存在するが、OpenGLコミュニティ総体にはそういったドライバー認証システムは存在していなかった 。またDirect3Dとは違ってOpenGLおよびOpenGL ESドライバーはベンダーや個々の製品によって出来不出来の差が激しく、このドライバー品質問題に関して開発者やユーザーから不満の声が上がっていた。さらに、GLSLのリファレンスコンパイラー実装はKhronosグループによって提供されているものの、OpenGL/OpenGL ESにおいてはシェーダープログラムの共通バイトコード仕様が定義されていないためにGLSLオフラインコンパイラーは存在せず、シェーダープログラムのコンパイルはベンダーごとのドライバーに実装されたGLSLオンラインコンパイラーによって実行時になされる。しかし、OpenGL仕様にはエラーハンドリングなどに関して厳密に規定されていないあいまいな部分が存在することから、現実問題としてベンダーごとにコンパイラーの挙動が異なるという処理系依存動作を許可してしまっているのが実態であり、これがアプリケーション開発者の負担増加につながり、またドライバーやアプリケーションプログラムにおけるバグの温床となってしまう。
OpenGL 4.4以降においては、Khronosグループによる品質保証制度を新設し、品質問題の改善を進めることとなった。また、OpenGLの後継APIとなるVulkanでは、前述のようにシェーダープログラムの中間言語としてSPIR-Vを採用している。OpenGL 4.6ではSPIR-Vのサポートがコア機能として組み込まれた。
GoogleによるANGLEプロジェクトはもともと、Direct3Dなどの他のグラフィックスAPIをラップしてOpenGL ES APIをエミュレートすることで、ブラウザのWebGLの実装に利用するためのライブラリだったが、ネイティブのOpenGLドライバーやOpenGL ESドライバーの品質問題を回避する目的でも使われている（Windows上ではDirect3DがプライマリAPIであり、ドライバー品質もOpenGLより安定している）。ANGLEプロジェクトでは他にも、Vulkan APIをラップしてOpenGL ES APIをエミュレートすることで、OpenGLドライバーの品質問題だけでなく、パフォーマンスを改善する取り組みが行なわれており、WindowsだけでなくLinuxやAndroidでも利用できる。後述のようにOpenGLやOpenGL ESが非推奨となってしまったmacOS/iOS上で、Metal APIをラップしてOpenGL ES APIをエミュレートする取り組みも進められている。
OpenGL DirectXとの関係
OpenGLは3Dグラフィックスを専門的に扱うライブラリである。対してMicrosoft DirectXは、ゲーム開発での利用を主な用途としており、グラフィックスのみならずサウンドや入力関連のAPIを含んでいる点で性質が異なる。
なお、OpenGLと直接比較されるべきAPIは、DirectX製品の一部、グラフィックスを司るDirect3Dである。
DirectXは主にWindowsやXboxプラットフォームでのゲーム開発等で多く用いられる（Linux上でDirectXを動作させるCedegaなどの例もある）。対してOpenGLはクロスプラットフォームであり、Windowsだけでなく様々なOSに実装が提供されている。Windows環境ではDirectXとOpenGLを両立させることも可能である。
OpenGL DirectXとの関係
発祥がワークステーションであることやクロスプラットフォームであることから、CADや工業デザイン、科学技術計算や医療での視覚化等の業務分野では、クロスプラットフォームなアプリケーションに限らずWindows専用アプリケーションであっても、Direct3D等のエンタテインメント用途重視のグラフィックスAPIよりもOpenGLが用いられることが多い。そのため、ワークステーションや業務向けのGPUやビデオカード製品には、OpenGLに最適化された仕様のものが販売される傾向がある。OpenGL向けと称されているGPUにはNVIDIA社の『NVIDIA Quadro/NVIDIA RTX』シリーズや、AMD (旧ATI) の『AMD FirePro/AMD Radeon Pro (旧ATI FirePro/ATI FireGL)』シリーズが存在し、デバイスドライバーを含めた仕様がOpenGL用に最適化されている。しかしその反面、これらの製品はDirectX (Direct3D) への最適化が甘く、DirectXを使用したアプリケーションにおける性能が芳しくない傾向もある。なお、業務用アプリケーションソフトウェアの中には、ドライバーの品質や安定性などの観点から、OpenGL/Direct3Dを問わず、これらのプロフェッショナル向けグラフィックスハードウェア製品のみ動作保証しているものもある。例えば、Windows版のAutoCADはかつてOpenGLを使用していたものの、バージョン2008以降はWindows VistaではDirect3Dが使用されるようになり、またバージョン2022以降はDirect3D 12が優先的に使用されるようになっているが、テスト済みの認定ハードウェアにはゲーミング用途のコンシューマー向け製品は含まれておらず、プロフェッショナル向け製品のみである。
OpenGL DirectXとの関係
後発のローレベルAPIが台頭してOpenGLの進化が止まり、将来性が見込めなくなったことなどを受けて、業務用やデザイン用途のソフトウェアでもOpenGLのサポートを打ち切るケースも出ている。Windows版のShade3Dは、かつてプレビュー表示においてOpenGL/Direct3D両方に対応していたが、OpenGL対応はバージョン17が最後となり、バージョン18以降はDirect3D対応のみとなった。Vectorworksはバージョン2022以降、OpenGLの代わりにDirectX/Metalを使用するようになった。
GeForceやRadeonのようなコンシューマー向けGPUのWindows版ドライバーは、OpenGLではなくDirect3Dに最適化されているが、コンシューマー向けGPUとWindows版ドライバーによるOpenGLが、常にDirect3Dよりも遅いわけではない（場合によってはOpenGLのほうが高速になることもある）。
OpenGL DirectXとの関係
なお、WindowsだけでなくLinuxおよびMac (macOS) に対してもGPUベンダーからOpenGL対応のドライバーが供給されているが、Macに関してはWindowsおよびLinuxと異なり、そもそもベンダーが正式対応しているハードウェアが限られている。
シリコングラフィックスとマイクロソフトはかつてOpenGLとDirect3Dの統合を目標として、Fahrenheitと呼ばれる3DグラフィックスAPIの共同開発を1997年に開始したことがあるが、1999年の末までに計画は事実上頓挫している。また、マイクロソフト社はOpenGL ARBの設立時のメンバーでもあったが、2003年に脱退した。その後、シリコングラフィックスの倒産やOpenGL仕様のKhronosグループへの移管など紆余曲折を経て、2014年にはOpenGL 4.5の発表とともに、マイクロソフトがKhronosグループに参加することが明らかになった。
OpenGL OpenCLとの関係
OpenGL仕様を管理しているKhronosグループによって同様に管理されているオープン仕様のAPIとして、GPGPUを含む異種計算資源混在環境（ヘテロジニアス環境）用の並列コンピューティングAPIであるOpenCLが存在する。OpenCLにはDirect3DおよびOpenGLのグラフィックスリソースを扱うことのできる相互運用機能が存在するが、一方でOpenGLはバージョン4.3でDirectX同様にGPGPU用の演算シェーダーを導入している。ただし、OpenCLは依然としてヘテロジニアス環境に特化した幅広いプラットフォーム対応APIであるが、OpenGLの演算シェーダーはよりグラフィックス用途に特化したGPGPU用のものとなり、競合するというよりはむしろ相補的な役割を担うことになる。
OpenGL macOSでの非推奨化
2018年6月5日、AppleはWWDC 2018でOpenGL/OpenCLの非推奨化を発表し、macOS Mojaveにおいて（サポートはまだ打ち切られないものの）OpenGL/OpenCLは非推奨APIとなった。macOSがネイティブにサポートするOpenGLのバージョンは4.1が最後となっている。
OpenGLの代替として推奨されているAPIはMetalであるが、MetalはVulkan同様、OpenGLよりもハードウェア層に近いローレベルAPIであり、アプリケーション開発向けというよりミドルウェア開発向けに位置する。
OpenGL ARM版Windowsでの利用
Microsoft Surface Pro Xのように、ARMアーキテクチャベースのWindows環境では、opengl32.dllやglu32.dllのネイティブバイナリは用意されているものの、通例GPUベンダーのOpenGLドライバーが提供されておらず、OpenGL 1.2以降の機能を利用することができない。マイクロソフトはARM版のWindows 10/Windows 11向けに、OpenCL/OpenGL/Vulkanアプリケーションを動作させるための互換機能パック（Compatibility Pack）を提供している。これはDirectX 12上に構築されたマッピングレイヤーであり、Mesaからフォークしたライブラリなどが含まれる。2024年6月現在、OpenGL 3.3以前のAPI互換機能がサポートされている。
クアルコムのSoCであるSnapdragon X Elite内蔵のAdreno GPUでは、マッピングレイヤーを介したOpenGL 4.6のサポートが予定されている。
日本橋駅 (大阪府)
日本橋駅（にっぽんばしえき）は、大阪府大阪市中央区日本橋一丁目にある、大阪市高速電気軌道（Osaka Metro）の駅である。本稿では、ほぼ同位置に所在する近畿日本鉄道（近鉄）の近鉄日本橋駅（きんてつにっぽんばしえき）についても述べる。
両社の駅は連絡運輸を行っており、近鉄はOsaka Metro日本橋駅への乗換案内を行っている。
日本橋駅 (大阪府) 利用可能な鉄道路線
Osaka Metro
堺筋線 - 駅番号はK17。
千日前線 - 駅番号はS17。
近畿日本鉄道
A 難波線（奈良線に直通） - 駅番号はA02。
なお、Osaka Metro中央線と近鉄けいはんな線の連絡乗車券を購入した場合は長田駅経由で乗り継ぎを行う事となっているため、当駅での乗り継ぎは出来ない。
日本橋駅 (大阪府) 駅構造
堺筋線は地下1階で相対式ホーム2面2線を有し、千日前線は地下2階で島式ホーム1面2線を有する地下駅。改札・コンコースは堺筋線ホームと同一フロアで、両ホームに1か所ずつある。千日前線ホームは堺筋線ホームの下のフロアにあり、乗り換えがしやすい構造となっている。2012年現在、火災対策工事で駅舎改造を行っており、同時進行で国立文楽劇場との連絡通路や駅舎壁面、なんばウォーク入口付近の売店（PiTaPaが利用可能になった）がリニューアルされている。また、堺筋線ホーム階には上下線とも多目的トイレが設置された。
堺筋線北行きホームは、改札を隔ててなんばウォークと同一フロアであるが、南行きホームは千日前線ホームあるいは堺筋線上下線の下にある連絡通路を経由する必要がある。隣の谷町九丁目駅の近鉄大阪上本町駅連絡通路も、これらと同様な構造となっている。
当駅は日本橋管区駅に所属しており、同管区駅長により自駅のみの単駅管理となっている。
トイレは地下通路・各堺筋線ホームにある。
出口は合計で9箇所あり、近鉄の駅と共用されている。
2009年3月20日の阪神電気鉄道阪神なんば線開業に合わせ、両隣の近鉄難波駅と上本町駅がそれぞれ「大阪難波駅」、「大阪上本町駅」に改称されたが、当駅については変更は見送られた。なお、自動放送においては社名を省略し「日本橋」と案内されている。
日本橋駅 (大阪府) 駅構造
相対式ホーム2面2線を有する地下駅である。ホームは地下3階にあり、有効長は10両編成分である。真上地下1階にOsaka Metro堺筋線のホームが、斜め上地下2階に千日前線のホームがある。ホームの柱の色はオレンジ。
改札口は地下2階に2箇所設けられているほか、地下1階にも昼間時のみ（12時から20時まで）開放の改札が1箇所あり、なんばウォーク（地下街）に直結している。地下2階コンコースへの入口はOsaka Metro日本橋駅の地下1階（堺筋線フロアの改札外）に設けられており、地上への出入口はOsaka Metroと近鉄で完全に共用されている。
大阪難波駅管理の有人駅で、PiTaPa・ICOCA対応の自動改札機および自動精算機（回数券カードおよびICカードのチャージに対応）が設置されている。定期券・特急券は専用の自動発売機で購入が可能。
日本橋駅 (大阪府) 利用状況
2024年11月12日の1日乗降人員は75,137人（乗車人員：37,333人、降車人員：37,804人）である。堺筋線が乗り入れる駅では堺筋本町駅・南森町駅に次ぐ第3位、千日前線が乗り入れる駅では難波駅に次ぐ第2位の乗降人員である。
各年度の特定日利用状況は下表の通り。なお1969・1995年度の記録についてはそれぞれ1970・1996年に行われた調査であるが会計年度上、表中に記載の年度となる。
1969年度のデータは堺筋線のみ。
最新の路線別データである1998年調査によると、千日前線側の乗降人員は少なく、堺筋線側に利用者が大きく偏っている。堺筋線のみの乗降人員は堺筋本町駅・北浜駅に次いで3位である。
千日前線については、降車人員に極端に偏っている年度が複数みられる。
2024年11月12日の乗降人員は45,920人である。近鉄全駅中では大阪阿部野橋駅・鶴橋駅・大阪難波駅・近鉄名古屋駅・京都駅・大阪上本町駅・近鉄奈良駅に次ぐ第8位で、特急通過駅では最多である。近年における1日乗降人員の推移は下表の通り。
日本橋駅 (大阪府) 隣の駅
大阪市高速電気軌道（Osaka Metro）
堺筋線
長堀橋駅 (K16) - 日本橋駅 (K17) - 恵美須町駅 (K18)
千日前線
なんば駅 (S16) - 日本橋駅 (S17) - 谷町九丁目駅 (S18)
近畿日本鉄道
A 難波線（奈良線）
■快速急行・■急行・■準急・■区間準急・■普通
大阪難波駅 (A01) - 近鉄日本橋駅 (A02) - 大阪上本町駅 (A03)
括弧内は駅番号を示す。
加越能鉄道伏木線
伏木線（ふしきせん）は、かつて富山県高岡市の米島口停留場から伏木港停留場までを結んでいた加越能鉄道（現在の加越能バス）の軌道路線。線籍上は高岡軌道線の一部であった。1971年に廃止。
加越能鉄道伏木線 歴史
1948年4月10日、富山地方鉄道により地鉄高岡 - 伏木港間 7.3 kmの高岡軌道線の一部として開業した。1951年、途中の米島口停留場から射水線新湊駅（現・六渡寺駅）へ伸びる 3.6 kmの路線が開業してそちらが本線のようになり、米島口 - 伏木港間 2.9 kmは事実上支線扱いとなっていった。1959年、高岡軌道線は加越能鉄道（1950年設立、現在の加越能バス）に譲渡され、支線区間は伏木線となった。
高岡から伏木へは国鉄（現・JR西日本）氷見線もあったことやモータリゼーションの進行により旅客数は見込めず、その割には支線があることで高岡軌道線の運用が煩雑になっていたこと、また、道路交通の障害になるという高岡市からの要請もあり、1971年9月1日をもって廃止された。
宇野自動車
宇野自動車株式会社（うのじどうしゃ）は、岡山県東部をエリアとする一般路線バス専業の会社である。通称は宇野バス。
宇野自動車 概要
岡山市東区（瀬戸・上道地域）、赤磐市を中心に、県東部の備前市・瀬戸内市・美作市・美咲町に路線網を展開する。創業以来路線バス事業のみを展開するバス事業者で、一時期運行していた定期観光バスを除けば、高速バスや貸切バス等の運行を行ったことがない。
社名は創業家である宇野家に因んでおり、県南部の地域名である玉野市宇野地区とは無関係で、宇野家による同族経営が行われている。社紋は「うの」を図案化したものが使われている。
「日本最低運賃」を目指し、対キロ区間制運賃を採用している30両以上保有のバス事業者の中で鹿児島市交通局に次いで2番目に安い（民間事業者では最安）基準賃率23円20銭を1994年（平成6年）以来採用しながら、回送を極力減らすなどの企業努力により、運行にかかる補助金を受け入れず無借金経営を持続している。ただしその反面、補助金なしでは収支均衡の見込めないエリアからの撤退は躊躇なく行い、備前市や美作市などでは既存路線の大半を廃止、現在の運行エリアは岡山市内とその隣接市町のみにほぼ絞り込まれたが、ほぼ岡山市内に路線を絞り込んだ中鉄バスに比べると廃止路線は少ない。
宇野自動車 概要
岡山市中心部では同業他社と競合する区間もあるが、他社と一線を画す営業施策をとっているのも特徴の一つであり、他社との競合区間で1998年（平成10年）に規制緩和を求め、公共交通では異例の「運賃値下げ」申請を行ってい、2025年10月1日から行われる岡山市内の路線バス事業者による共同経営にも参加せず市内中心部の運賃を100円に据え置き、他社の160円と大きな差を付けている。また、岡山市の中心部である表町（北区）には、多くのバス路線が乗り入れる天満屋バスステーションがあるが、当社は天満屋バスステーションには乗り入れず、本社と同居する形で独自に設けた表町バスセンターに発着する。
非接触型ICカードシステムHarecaが使用出来るが、両備バス・岡山電気軌道・下電バスと異なりスルッとKANSAI協議会に非加盟のため、全国相互利用サービス対応のICカードは利用不可能。
2023年(令和5年)10月1日、鹿児島市交通局のバス運賃が全線均一230円になったため、名実ともに運賃の基準賃率が日本一安いバス会社となった。
宇野自動車 車両
地方の事業者にしては珍しく全車が新製であり、三菱ふそうならびに日野（ジェイ・バス）車を使用している。
前後の屋根上に取り付けられた5つの橙色マーカーランプが外見上の特色であり、車体後部にも乗務員名を車外名刺としてマグネットで取り付けている。また、ツーステップ車では、窓の配置や桟の位置を座席に合わせてカスタマイズし、内装はハイバックシートで片側2人掛け座席を採用していた。
2000年代に他社がノンステップバスやワンステップバスを増備するようになっても、長らく扁平タイヤ装備等によるツーステップバスの低床化で対応してきたが、障がい者団体から低床バスの導入を要望されたこと等もあり、2012年、新車として交通バリアフリー法に準拠したワンステップバス（三菱ふそう・エアロスター（QKG-MP35FM（前期）））が1台、2013年には宇野バス初となる日野車（日野・ブルーリボンII（QPG-KV234N3））が2台目のワンステップバスとして導入され、翌2014年にも同型車が1台増備、2015年には3月・5月・9月・11月の四度にわたって合計24台が増備され導入が本格化した。
宇野自動車 車両
2016年以降は再び三菱ふそう車が導入され、 2016年にQKG-MP35FM（後期）が1台、2017年にQKG-MP35FM（後期）が1台と2KG-MP35FMが2台、2018年には2KG-MP35FMが2度にわたって合計14台増備され、全車両のワンステップバス化を達成した。
過去に、台風の影響で他社のトラックの横転があったことを教訓に、原バス停（岡山市北区）、八日市バス停（瀬戸内市長船町）の屋根の上に風速計を設置し、台風シーズンの運行可否の判断材料としている。