About the IRRmesh format...

christianclavet · Post by **christianclavet** » Mon Mar 03, 2008 12:33 pm

HI, I was wondering if you were thinking of extending the format.. as:

- Embetting textures
- Havin a PK field so that the stream is saved as packed (smaller files)
- Embetting the bones and any IRRlicht animation infos (loops, animations, etc.) (Would be nice also if we could define animations loops give them a name and that be saved directly into the file. (Somewhat like like the MD2). (I would save a external file for this, but if this could be made inside the format directly it would be more efficient)

I have a question related to Mesh also (X Animated, or B3D) can have bone and Mesh Deformations (Morphs) in the file? I would like to know if we could do morph animations for expressions of the characters and they are saved in the .X .B3D files with the bone info...

Dorth · Post by **Dorth** » Mon Mar 03, 2008 6:11 pm

Why not add on the format how you think it should go based on what's there then submit that as a possible extension? A lot of language and file formats have been extended that way ^^

christianclavet · Post by **christianclavet** » Mon Mar 03, 2008 6:22 pm

From what I've read so far on the format, it's a kind of "meshbuffers" dump into a XML file. So pursue the same objective, by adding more of IRRlicht elements (dumping info about the Animated mesh, bones, types, etc.)

Since packing (PK Compression) is in a sub-component of IRRlicht I was thinking it was a good idea to use it to create a "compressed" dump (meshbuffers and other infos). Using this will make smaller files (but putting them in a ZIP file will not make them smaller)

Halifax · Post by **Halifax** » Tue Mar 04, 2008 1:55 am

Yeah, I think christianclavet's ideas a pretty cool. I wanted to see the bones in there too, but iirc bitplane stated that they won't be in there anytime soon due to some complications.

Also, embedding the textures wouldn't be a problem. All you would need to do is dump the texture into the file, make a local link to it in the texture tag, and then change how it is loaded by writing your own custom loader.

bitplane · Post by **bitplane** » Tue Mar 04, 2008 4:57 am

you can't dump binary data into an xml file format without first encoding it to text, which would be rather slow. This is why niko exports the textures of lightmapped meshes in irrEdit

Halifax · Post by **Halifax** » Wed Mar 05, 2008 2:12 am

bitplane wrote:you can't dump binary data into an xml file format without first encoding it to text, which would be rather slow. This is why niko exports the textures of lightmapped meshes in irrEdit

Yeah, I guess you got me there.

AlexL · Post by **AlexL** » Thu Mar 06, 2008 9:43 am

In embedding textures, do you mean embedding a link to where the texture is located in the file system or actually placing the image data within the model data?

I'm abits curious as to why you'd like to do this, as it could lead to multiple copies of the texture data in memory, instead of say loading it once at your game state initialization then simply applying it to the mesh, and any other meshes that share the same texture; saving you memory and time loading the texture instances.

I am not trying to say that it's a bad idea, or that if memory management was done correctly that it wouldn't be quite helpful, I'm more just bringing up points that would need to be looked into if you started implementing your own model format

christianclavet · Post by **christianclavet** » Thu Mar 06, 2008 12:45 pm

Ok, you've got 2 good points there. Yep. this would probably take more ressources in the end. (I was thinking simplicity first, a mesh would have all it need inside only it single file (Perhaps this could be used as an EXPORT feature, when for example someone would like to give it mesh to the community) He'd be sure if he see his mesh that the exported file will contain all (But then we'll need to re-save the file without them)

A better idea (When the filesystem will be updated) could be to create an archive (PK3 file) then put all the required files for that mesh inside that archive. So it's really easy to distribute. (Could be scenes also). For this to work, we'll need to load and save files for textures and meshes inside an archive...

matgaw · Post by **matgaw** » Wed Oct 01, 2008 8:29 pm

Will irrmesh format be expanded in the near future?

In 1.4 I found that writing and loading of these meshes is very time consuming in comprasion to other formats. It's so slow (I guess that it's because of xml format), that actually I don't see any purpose (and ability) to use it.

I think, that Irrlicht should have some binary or, other than xml, faster format, because in actual form it's almost useless.