Irrlicht's OWN file formats?

[Radikalizm]

I wasn't talking about files without a footer, I was talking about vertex injection just like you
Look, if you store an offset to your footer inside your header you can jump to the location where the footer is supposed to be, if it isn't there then you know there's something wrong. So if anyone adds data to the file it means that the footer offset defined in the header will not be correct anymore, and the loader can easily see this by doing this jump before loading in any data

[christianclavet]

Hi, I was just reading some part of the discussion. Please if you design a new binary format, I would like it support more than skeletal animation, but also vertex animation (morph, facial animation, and also texture/material animation), it would also be nice if that format would also support scenes and like a zip or a BSP, embed files (as textures, shaders scripts) inside them.

[Mel]

To be able to store shaders inside a file, would need that Irrlicht isolated OpenGL and DirectX shaders from the user, so there was a unified shader frontend that Irrlicht was able to understand, and that later could be translated into the corresponding OpenGL or DirectX equivalent. But embedding texture files isn't hard at all.

[Radikalizm]

I've been pondering about a custom shader system as well, but wouldn't it just be easier to move to Cg then? It pretty much has everything we need in a shader system, and we won't be forced to have to take care of shader separation

[3DModelerMan]

I tried to write a shader compiler that works for both HLSL and GLSL. It was NOT pretty. I've been looking into Cg too though, and it looks like it would do everything great.

[REDDemon]

great. Cg sounds very good. anyway actually morph animations are supported for the file format wich is a WIP for now.

[bitplane]

Re-joining this party late, haven't had as much time as I would have liked so can't really contribute to this at the moment.

However, I was browsing this thread and would just like to pipe up and say that if a future binary mesh format is going to include other files like textures and shaders, I think it would make much more sense to use some already existing archive format with the mesh data as a separate entity inside. Compression-less ZIP files or TAR archives wouldn't add much overhead, but would mean that the package could be edited with standard tools, reading it could be done using existing code. At first glance this may not seem like a huge advantage, but when you want to touch up that texture or make a one line change to that shader, you'll be glad you can just open it up and do so without messing around with whatever specific content creation pipeline tool becomes the standard.

[Radikalizm]

Re-joining this party late, haven't had as much time as I would have liked so can't really contribute to this at the moment.

However, I was browsing this thread and would just like to pipe up and say that if a future binary mesh format is going to include other files like textures and shaders, I think it would make much more sense to use some already existing archive format with the mesh data as a separate entity inside. Compression-less ZIP files or TAR archives wouldn't add much overhead, but would mean that the package could be edited with standard tools, reading it could be done using existing code. At first glance this may not seem like a huge advantage, but when you want to touch up that texture or make a one line change to that shader, you'll be glad you can just open it up and do so without messing around with whatever specific content creation pipeline tool becomes the standard.

Agreed, compiling assets like textures and shaders directly into the mesh file wouldn't really make that much sense anyway for the reasons stated

[ACE247]

Im with Radikalizm & Bitplane.

Oh wait... 'Bitplane' just reappeared again?