Irrlicht's OWN file formats?

[hybrid]

I already implemented an OpenCTM loader as part of the irrExt project...

[RdR]

I already implemented an OpenCTM loader as part of the irrExt project...

Why are some of those not implemented trunk / SVN btw?

[hybrid]

Because openctm requires the additional openctm library (and hence will never move to the core engine, unless the format becomes a major standard somewhere). And which one else?

[RdR]

Because openctm requires the additional openctm library (and hence will never move to the core engine, unless the format becomes a major standard somewhere). And which one else?

Ah didnt know that.
The FBX format is not included in the trunk if i'm correct.

Edit:
Perfect timing to post

[xirtamatrix]

The way to do this is to understand Irrlicht core-structures first. So whoever works on that will have to start there.

Very well said. This is not just about writing code, but comming up with a very comprehensive list of "requirements" which directly depends on the way core structures have been implemented in Irrlicht.
As you probably realize thats a gigantic task for any one person. Different devs and users have different areas of expertise, so what is needed here is efficient pooling of information/knowledge and good team-work.
That will not be easy to achieve, but if we all work together in an organised manner we might pull this off.

Here is a rought project plan which might take us some way. Feel free to add your reccomendations.

1. At the moment, we're educating ourselves regarding how other formats handle data, what data-structures are used and how or why one works better than other. As bitplane pointed out, this requires reading a library's worth of documents. We'd surely not be able to do all that reading anytime soon but hopefully, in a week or two we shall have a reasonably good understanding of the issues involved.

2. Next, we plan to:
- 2.1 post the structures of publicly available document formats on the forum
- 2.2 put together a basic list of what we think is required for Irrlicht's own formats
- 2.3 present a very basic set of formats which can serve as our starting point and ask the community to help refine the set of requirements and make reccommendations.
This shall give a chance to developers of various expertise, with better understanding of various core systems of Irrlicht, to pitch in and help out.

3. Assuming we get a basic set of requirements put together which is generally acceptable by all, we then take perhaps another few weeks to study-up and prepare before any coding starts.

4. From there on, its going to be RUP-style iterative process of defining a concrete deliverable every couple of weeks, developing and testing it, then going back to adding/enhancing the set of requirements and defining the next deliverable and so on.

EDIT: In regards to 4. above, its not just about developing the format but potentially also making changes to Irrlicht's core. I'm probably the most inexperienced person and thus not suitable to lead that. So I'm hoping at that point, one of the core-team devs would step in and take the lead. =) Anyone feeling up to the job?

[Virion]

maybe you can put a list on your first post of the features that collected from the replies.

- binary mesh format for fast loading speed
- mesh streaming?
- bone animation with blending/animation mixing
- lip sync/morphing
- material file which linked to shader

feel free to add in what you think is important for the format

[fmx]

Whatever you plan to do with the proposed format, be sure it strikes a good balance between flexibility and speed.

IMO an irrlicht-file-format needs to fulfill 3 criteria, when compared to other established multipurpose format such as FBX or DAE:
1. allow 1:1 copy of irrlicht scene nodes "loaded" or active, whether default nodes or custom
2. would need to save and/or load as quick as (or quicker than) those other formats
3. have both an ascii and binary variant, possibly with optional compression and encryption features too

Unless the new format can meet those needs, there would be very little reason for programmers to adopt a new format for their irrlicht projects

[hybrid]

Because openctm requires the additional openctm library (and hence will never move to the core engine, unless the format becomes a major standard somewhere). And which one else?

Ah didnt know that.
The FBX format is not included in the trunk if i'm correct.

Yes, the FBX implementation was added very early, without even material support. Now we have that, but we need to add animation also before it will move to core.

[christianclavet]

Wow! FBX will be added to the core!? That is excellent!
With Collada and FBX, if we later add our own format, that will be excellent to import stuff from tools, tweak it in Irrlicht and save them in a native format! Now if we could support animation also... (Seem that will be there for FBX... Hope we get it also with the collada format)

[Cube_]

yet again... wasn't it mentioned that collada is bad...

well for furhter elaboration on why I want *.blend

can be opened by blender, good modding support
has animation
baking textures is possible
can contain it's own lightsource (eg enemy with a flashlight)


bad parts...

contains a lot of unimportant data... thus making the filesize larger than what irrlicht would need.

[hybrid]

Moreover, .blend will change significantly on each blender update. Which makes it largely impossible to maintain within the engine core. And Collada and FBX are not just bad. It depends on the requirements one have. Since both formats are also quite elaborated, they are loading slow. Not best option for in-game use, but still possible. As I already mentioned, we will keep and maintain those formats, and even add more if we get good loader implementations. Of course we would also support good formats tailored especially for Irrlicht.

[Cube_]

oh well, I will personally implement *.blend for my project.... if I have the time...
what is the best format supported following these criterias:

Irrlicht supports it (duh)
Bone animations
Fast loading
Baked textures (not necessary, but a nice feature!)

[hybrid]

There was already a loader for this format, using libblend or something like that. I guess you'll find some heads up when searching for blend

[Cube_]

yeah, but is there a better format that supports all of that?

[Virion]

.blend is quite huge in size because it saves a lot of extra information in it.