- What is the purpose of OMA?
-
OMA is a project attempting to create a conversion layer between 3D model formats. An extension of this effort is to allow developers to load model formats into their own software easily. When I talk about 3D model formats, I am speaking only about the geometric data and information detailing their use. I do not include information on a model's interaction with its surroundings, texture pixmaps, et cetera.
- What platforms does it build and/or run on?
- Versions 0.1.x:
- I've tested the library mostly in Debian Linux (IA-32, IA-64).
- Versions 0.0.x:
- I've tested the library mostly in Debian Linux (IA-32, Alpha). Version 0.0.17 seems to work in FreeBSD (IA-32), Solaris (SPARC), MacOS X (PPC), and Windows (IA-32; using MinGW32, at least) as well.
- All of these tests have been with GCC 3.x; 3.x because GCC 2.95.x is missing a couple C99 features that libomapi relies upon.
- If you have results on other platforms or compilers that you'd like to give me, please do (especially if they're failures).
- What type of person does OMA target?
- There are two main audiences actually, depending upon which part of OMA you're referring to. The majority of the project ends up being aimed at developers. All of the work by developers using the project and the tools creating as part of OMA are aiming at anyone interacting with 3D models: artists, engineers, designers, et cetera.
- How far along is OMA?
- Most of the foundations for further growth are setup. Now the major need is for more model formats to become supported. I don't have a whole lot of free time for this project. If you'd like to help, please see the documents page.
- When will binaries be provided?
- The latter half of the beta stage, probably.
- What model formats are supported?
- For input:
- Autodesk's FBX (ASCII support only)
- 3D Studio Max's 3DS format (partial support only)
- WaveFront's OBJ format (partial support)
- OMA's binary OMA format (full support)
- OMA's XML-based OMX format (full support)
- Quake II's MD2 format (partial support)
- Quake III's MD3 format (partial support)
- For output:
- WaveFront OBJ format (full support)
- OMA's binary OMA format (full support)
- OMA's XML-based OMX format (full support)
- Why don't you support import/export of model format X?
- Probably because I don't have a lot of time, and it takes me a while to figure out each model format I have to support. However, the internal format (most easily 'seen' through the OMA and OMX formats) doesn't support everything (yet :)), so a required feature may be missing, preventing full or any support for a format.
- Can I help you out?
- I'd love for people to help out. If you need information for programming something, email me and yell at me to write some up-to-date documentation so you can.
- Why did you make a native XML model format?
- Largely because it allows you to use a text editor to modify and debug your models.
- I've seen you use the acronym OMAPI in some places. How is it different from OMA?
- It really isn't. Since the project is named 'OMAPI' on SourceForge, I decided to completely rename OMA to OMAPI, but later changed my mind. In the source code OMAPI is being used to refer to the base code, and OMA is used to refer to the developer front end.
- What external libraries does OMA rely on?
- Versions 0.1.x:
- Versions 0.0.x:
- OMA optionally uses Expat for parsing XML.
- If it counts: OMA embeds Trio to work around out-of-date C runtime libraries present in certain environments.
- Have you written a DTD or a Schema for the OMX format?
- The copyright in the files refers to the "OMA Group", who makes up this "OMA Group"?
- How safe is your code from buffer overflows and other such 'attack through a file' nonsense?
- Somewhat. There is only a degree of sanity checking and sanitation of input files.
- Have any of these questions really been asked?
- No; but labeling it "FAQ" makes me feel special.
