August 10, 2006
Although I would certainly do things differently today, we did successfully license the technology. And working with the guys at VBlank was an amazing experience. Unfortunately, what we didn't do successfully was stay in business.
| ENGINE SPECIFICATIONS
Although the following is not a -complete- description of the features of MG5, we hope you will get an idea of the kind of technology our games will be using and what we can provide.
1. What is MG5?
MG5 is a PS2 specific set of offline tools and runtime data/functions for visibility, animation, rendering and collision. MG5 additionally has game-loop control data/functions, which are used to plug in other "engines" (sound, scripting, physics, networking, etc.)
The purpose of MG5 is to approach as closely as possible both the artistic and design visions of the game. It is our opinion that technology should not hinder art nor design anymore than the absolute limits of time and our programming efforts allow. It is also our opinion that because engineers continue to build new generations of machines capable of handling an evolution in both art and game-play, providing a mechanism to do less would be a disservice to those artists and designers.
MG5 will be used for our first PS2 title and is also available for licensing. Since we are focusing on a PS2 specific implementation we have the opportunity to build technology that takes advantage of the platform without being very concerned for its portability. Although there are many algorithms used throughout MG5 that are platform-independent, taken as a whole, it is -not- best suited for development teams looking for cross- platform solutions.
2. How many polys can it draw?
As always, this is a difficult question to answer specifically. Polygon throughput is affected by many factors like pixel fill rate, polygon type, animation type, texture usage, lighting, special effects, vertex count, pipeline usage, etc. But given that, for our action-adventure title, artists should expect:
- An average of between 25 and 35 million triangles per second. This is based on the assumption of a broad range of polygon types per frame, but much less range in polygon size and texture size/usage per frame (polygon size and texture size directly affect the GS's ability to draw a specific count of polygons, but an artist is -not- limited to any particular sizes, including power-of-two sizes). It is also assumed that near/important geometry shall receive the majority of effects (lighting, multi-texturing, complex animation) and far/less-important geometry can be optimized to reduce cost. Triangles are assumed to be "strip-able" in the general case, which is handled by the MG5 tool-chain, but non-strip-able geometry is valid.
On near/important polygons: highly detailed geometry, full lighting (colored-directional, point, spot, specular), detailed shadows, complex animation, multi-surfacing (reflection mapping, shadow-mapping, light-mapping).
On far/less-important polygons: reduced-cost animation, reduced multi- surfacing (approaching zero) / multi-surfacing approximations, reduced lighting (pre-calculated/estimated), reduced shadows, low-detail animation.
- For reference: (General case triangles after tool-chain conversion where pixel fill rate is not the bottleneck. All numbers are approximate)
Textured, gouraud shaded 3 colored directional lights, human-type bone animation with maximum of 4 influences* per vertex: Textured, gouraud shaded 3 colored directional lights*: Textured, gouraud shaded pre-stored color* per vertex**: Un-textured, flat shaded pre-stored color* per vertex**: * These numbers are for reference, and the features listed are not necessarily limitations of MG5, but serve to demonstrate example cases.
** It is our opinion that these cases are relatively straightforward and will become standard in the next generation of PS2 titles. The goal of MG5 was/is to provide more features (through lighting and surfacing) at similar cost/throughput to these "standard" numbers.
"What can I expect in a -real- game?"
VBlank is not in the demo business, and our main priority is not technology licensing, but game development. As such, the engine has been developed from the start with our specific game needs in mind, and this information (throughput, etc.) is exactly what our artists and designers should expect/use when building our titles.
As with any technology, there are many data sets which cannot or will not be optimized to maximize the output. MG5 is custom designed for VBlank's action-adventure titles and the likely data they will contain. No numbers can be guaranteed for -all- types of data.
If you have questions about a specific data set or example, please contact us, and we can try to give you a better idea of what you can expect from MG5 under specific circumstances.
3. What is the resolution/framerate?
Our game is 60fps (at about 500,000 textured/gouraud polys per frame) running at 640x448, but the resolution and framerate are independent of MG5. For example, you could run 1,000,000 textured/gouraud polys per frame at 30fps.
4. How is visibility handled?
Reduction of opaque overdraw is absolutely critical in making the maximum use of the throughput possible. A variety of techniques are used, some of which require additional art information, some can be automatically handled.
- Backface culling "Should I really backface cull?" - Portals Portals can be moved or created at runtime to support runtime geometry changes such as geometry destruction (holes through walls) or special effects. This effect will increase some calculation time.
- Object self-occlusion - Inter-object occlusion Among other features, MG5 will not support terrain-based visibility. Although this can be customized into the core engine (and is included as part of our long-term plan.)
5. What kind of lighting/texturing is supported?
Basic poly/vertex surface information: Additional lighting/texturing types will be made available*: And because of our method of caching lighting data, in most titles, it should be possible to additionally include one or more complex lighting models without affecting the overall poly draw count.
* Some of these techniques require redrawing the geometry and will affect the total "perceived" polygon throughput. Procedural textures will not be supported by MG5, although you can provide raw images you have created to the MG5 core for use as textures. 6. What kind of collision is supported?
MG5 geometry data* can be flagged to include data for any, all or none of the following collision types:
- simple (estimate) collision types - detailed collision types * Collision data can be included for display geometry or for separate (simpler) collision models.
7. What kind of LOD is supported?
Because of our pipeline design, MG5 is best suited for view-independent LOD. Multiple models can be provided or calculated at runtime from subdivision surface data. Artists have direct control over the LOD hierarchy.
It is possible, and increasingly common, for LOD geometry created by polygon reduction only, to either the same speed or actually slower than their higher resolution counterparts. This can be due to inefficient use of the drawing pipeline or reduced culling, for example. For this reason LOD generation is a complex topic in itself. LOD hierarchies can be created by the artists for static geometry which, rather than simply reducing object-poly count, can concatenate less detailed object-polys together into a larger object for optimization.
8. What kind of animation is supported?
1. Rigid geometry hierarchy animation (euler or quaternion) FFD will not be supported by MG5, but there is nothing in the MG5 design per-se limiting its use.
9. Please briefly describe the API...
MG5 is an almost completely data driven engine, so the API is minimal. Programmers will provide geometry, animation, and other data in MG5 format, and will have full access to the data at runtime. Helper functions exist to make common tasks simple (moving, rotating objects; changing animations; adjusting lights; etc.), but this should be limited to only a handful of functions.
The pipeline of MG5 is designed to allow us to customize most of the major graphics features. For example, adding new lighting styles or animation types is not a complex task. We are not big believers in data or code hiding so most of the features that exist in MG5 will serve as straightforward examples of how to implement your own features.
Also, features that you may not want that exist in MG5 are very simple to remove. And the MG5 file format is designed to allow you to decide which objects will require what kind of data (animation, lighting, collision, etc.) So that unused data and wasted time can be minimized.
We do, however, provide an API for creating geometry at runtime. These functions, while not nearly as fast as data pre-stored in MG5 format, will make creating custom geometry for menus or special effects fairly simple.
MG5 is written in assembly, vu microcode, our own custom macro language, and C. So for customization, a familiarity with PS2 core assembly and VU microcode is probably required. All API functions are C-callable, and we expect that game code will be written in C++.
10. What types of games is this technology best suited for?
The purpose of MG5 is to allow game designers and artists to take advantage of the PS2 platform. As such, it is not suited to games or development teams who wish or need to use techniques that are not well suited to the PS2. For example, engines which require use of an OpenGL stencil buffer, or which require use of alpha blending modes not supported by the hardware will not see the polygon throughput described above. In those cases, a different solution optimized for the features you require might be better.
The main goals of MG5 are...
1. Maximize polygon throughput 2. Minimize opaque overdraw 3. Maximize our familiarity with the PS2 hardware As you can see, texture throughput is not one of the main goals of MG5. Although we do support solid texture caching techniques and texture sorting techniques (to maximize the ability to strip geometry), MG5 is not -optimized- to support games with -very heavy- texture loading demands. In this case, we suggest evaluating your needs and goals before proceeding with MG5. We do not expect, though, that all textures will be available in the GS local buffer (VRAM) each frame.
Given that MG5 is specifically designed to support action/adventure style games; to maximize its use we expect a heavy mix of data types: For example, FPS, racing, and 3d-fighting games have somewhat similar requirements to an adventure title, but again, we would suggest that you evaluate your specific needs to determine if your game can take advantage of MG5, or whether you can customize it to fit your needs.
This technology was designed to be a good development platform for our internal games and we will not suggest that it is the best solution for -all- types of games. If you are interested, there are other 3rd party engine providers who do make that suggestion.
11. What about aliasing?
We are using the (now common) full screen blending solution to reduce aliasing. This is the same solution that Volition is using for Summoner and many interviews are available on it.
Gross polygon z-sorting is available to make the use of the PS2's edge anti-aliasing function somewhat viable, but it is not the recommended method.
12. What is the recommended pipeline?
Our art pipeline is separated into exchange (MGX) and runtime (MG5). We have a command line toolset to convert MGX data into MG5 data suitable for the game. MGX is an ASCII exchange format with a cross-platform (Linux, Windows) library. The MGX toolset does not include art content editors (modeling/animation package, etc.) Our current priority is continued development of our Alias/Wavefront Maya to MGX export plugin, but there is limited support for Lightwave 5, Lightwave 6, and 3DS file format conversion through the command line. The MGX library is designed to make the addition of description and conversion of any 3D graphics file format relatively simple.
MGX will be released as an "open" format and a full description made available. MG5 is a "closed" format and a full description will only be made available to the users of the MG5 engine.
We currently work with the Linux GCC release for the PS2 and Linux GCC and Microsoft Visual C++ for tools. Our MGX visualization/test tool uses OpenGL for display and is not optimized for speed.
13. When will it be available?
The current version supporting static geometry and bone-based animation should be available in May 2001. We have some availability during E3, so please contact us if you wish to schedule a conversation.
With the tool-chain and feature set constantly evolving, we expect that semi-continuous improvements/additions will be made through September 2001.
14. What kind of support will be available?
Full source code and a one-week training session will be given to licensees. During the training, a fully detailed description of the source and the algorithms and techniques used will be provided (i.e., full disclosure)
Our goal is share the knowledge we have accumulated and minimize your dependence on us. In the best case, programmers who attend the training will walk away with enough knowledge to completely rewrite the engine from scratch (if they wanted) with similar success and at the least be able to apply that knowledge to future products and/or customization of the current engine.
Email support will also be available.
15. What are the future plans for MG5?
Development of MG5 represents VBlank's first-generation graphic technology. Our five-year plan includes two succeeding graphic engines built or rebuilt on the existing technology and lessons learned in development. VBlank is committed to creating solid technology over the life of the PS2 platform.
16. More details?
We are more than happy to answer technology or business questions on the topic of MG5. Feel free to contact us by email using the information below.
Also, Mike Acton spoke at the SCEA development conference in 2000 and 2001. Videotapes should be available through SCEA. Although that information is not specific to MG5, some specifics to our approach and discoveries in researching and customizing display technology for the PS2 were described. Please also feel free to contact Mike if you have questions, comments or arguments related to those conferences.
Contact information:
For cost, licensing, and availability please contact: For technical questions please contact: EOF |
Mike has made regular appearances as a speaker at SCEA develpment conferences and other events. Mike Acton is not a framework-happy C++ programmer. He actually likes C. And assembly. In his spare time he develops hardware on FPGAs in VHDL.
He prefers vi.
Also check out the CellPerformance main site, which has additional articles written by Mike Acton.