MIM is Murphy's Irrlicht Mesh file format. The major design concept is to mirror Irrlicht's internal workings such that anything that can be put into an Irrlicht meshbuffer ... you should be able to set up from a MIM.
Quick Overview
- XML based.
- Attempts to mirror Irrlicht's internal structure (i.e. meshbuffers, materials, etc. exist as XML elements).
- Supports all Irrlicht material types.
- Supports storage of lights (not truly a property of a mesh, but handy).
- Converters exist for OBJ (including a second OBJ for a lightmap), OpenBSP, DMF (DeleD Map File), CSM (Cartography Shop).
- Does not support animation (see below for more info).
Where can I get it?
Unfortunately, if you don't already have it (it was released to a few people for testing and experimentation) -- there's no way to get it at the moment. It's coming as soon as I can manage to get some time to work on it, but there are a number of obstacles keeping me from doing so just now.
What about a converter from DirectX X file format?
Doing a simple conversion of the geometry would be easy, but nobody has yet proposed a workflow that requires it (that is, one of the existing converters could be used instead). For info on animation, see below. As for lightmaps... I've never seen a proper X file with two sets of texture coordinates and two sets of materials. Most packages don't actually seem to do this. Some packages export a textured X and a lightmapped X, but nobody has pointed out such a package that can't also export two OBJs or some other supported format.
What about a converter from <some other 3D file format>?
B3D support is coming. If you want another format supported, let me know. I'd like to support as many good workflows as possible.
On the other hand, nobody is stopping you from writing your own converter or exporter -- it's not that difficult. For that matter, I wrote most of the converters really quickly and mostly just to do what I wanted them to. As features in a particular format may not map exactly to Irrlicht features, I guessed at what would be good and useful. If I was wrong, you can modify the converters (when source is available) or request an improvement.
Why are only static meshes supported?
This is because MIM attempts to mirror Irrlicht's internals, and Irrlicht doesn't really have a generic animation implementation -- animation is implemented by the loaders, etc.
I'm willing to entertain suggestions on this. One thought is to wait and see if Irrlicht develops a generic animation implementation (this is something that has been talked about for NX). Another is to support Blender's or some other package's animation through a converter or exporter. Another is to implement a very flexible bone animation system and do the best convertors I can within the amount of time I'm willing to put in.
Original first post:
So I've written a loader for what I call "Murphy's Irrlicht Mesh" format or MIM.
It's an XML-based format which I think is a pretty direct representation of how Irrlicht actually uses the information.
I've also written a (rather incomplete) converter that converts from DeleD's DMF format to MIM.
Here's a screenshot of the "Waterworld" DeleD map, complete with lightmaps:
Here's a little snippet of the MIM file:
Code: Select all
<?xml version='1.0'?>
<MIrrlichtMesh>
...
<meshBuffer>
<material backfaceCulling='true' lighting='false' materialType='EMT_LIGHTMAP' textureFile1='Textures\Wood\Wood01.jpg' textureFile2='Textures\LightMaps\Waterworld\LightMap0.bmp' textureCreationFlags2='-ETCF_CREATE_MIP_MAPS' />
<polygon winding='counterClockwise'>
<vertex x='-768' y='256' z='-256' u1='-3.036' v1='0.1438' u2='0.627' v2='0.002' />
<vertex x='-256' y='144' z='-256' u1='-1.012' v1='0.1438' u2='0.6855' v2='0.002' />
<vertex x='-256' y='144' z='-352' u1='-1.012' v1='-0.177' u2='0.6855' v2='0.0605' />
</polygon>
<polygon winding='counterClockwise'>
<vertex x='-768' y='256' z='-256' u1='-3.036' v1='0.1438' u2='0.6895' v2='0.002' />
<vertex x='-256' y='144' z='-352' u1='-1.012' v1='-0.177' u2='0.748' v2='0.0605' />
...
Oh, the format can also store lights. The loader loads them as an array of SLights, but there's currently no way to access them.
).