Even with OpenGL you don't get multi-platform for free. Neither with D3D (PC and XBOX)
There are more important things to consider:
- Image compression supported (DXT vs. PVRTC vs. others)
- Type of rendering buffers supported and precision (stencil, z-buffer, etc)
- Features of the latter - can you do some prepass to skip pixel shaders?
- Normal map encoding and compression
- Primitive buffering (batching) - static, dynamic, or low-level if the platform allows it
- Minimizing state changes
- Organizing mesh data for most optimum cache
- Hardware level queries - "Did last primitive actually drawn something on the screen?"
So what the drawing api is of little importance for big AAA games. Data organization and features (what actually is supported on the HW, and which rendering paths are fast) is more important.
Now for CAD/3D Designer apps - you have more dynamic data - your meshes change too much, textures. You need very good looking wireframe antialiasing, etc.
For games - almost everything is precooked - starting from global illumination, meshes that have been cache optimized and had vertices welded where possible. Level maps optimized so that they draw faster, and batched so that with few draw calls you draw the whole level, etc.
My opinion is that OpenGL is really suitable for the latter, but it's also suitable for the former. Though D3D by not keeping much backward API compability can talk to the hardware in more straightforward talk, hence the API design:
OpenGL - functions with general types, not much if not at all structures. Easily to serialize (protocolize).
Direct3D - functions with very specific goals, using structures more or less tied to the hardware, or the operating system, hence less portability.
For example I can't see D3D as an API taking off the way webGL is doing, simply because it's hard to map it's API to a scripting language, while OpenGL can.
There are more important things to consider: - Image compression supported (DXT vs. PVRTC vs. others) - Type of rendering buffers supported and precision (stencil, z-buffer, etc) - Features of the latter - can you do some prepass to skip pixel shaders? - Normal map encoding and compression - Primitive buffering (batching) - static, dynamic, or low-level if the platform allows it - Minimizing state changes - Organizing mesh data for most optimum cache - Hardware level queries - "Did last primitive actually drawn something on the screen?"
So what the drawing api is of little importance for big AAA games. Data organization and features (what actually is supported on the HW, and which rendering paths are fast) is more important.
Now for CAD/3D Designer apps - you have more dynamic data - your meshes change too much, textures. You need very good looking wireframe antialiasing, etc.
For games - almost everything is precooked - starting from global illumination, meshes that have been cache optimized and had vertices welded where possible. Level maps optimized so that they draw faster, and batched so that with few draw calls you draw the whole level, etc.
My opinion is that OpenGL is really suitable for the latter, but it's also suitable for the former. Though D3D by not keeping much backward API compability can talk to the hardware in more straightforward talk, hence the API design:
OpenGL - functions with general types, not much if not at all structures. Easily to serialize (protocolize). Direct3D - functions with very specific goals, using structures more or less tied to the hardware, or the operating system, hence less portability.
For example I can't see D3D as an API taking off the way webGL is doing, simply because it's hard to map it's API to a scripting language, while OpenGL can.
Both are good :)