3ds support

[Lucifer]

http://lib3ds.sourceforge.net/

I have a high suspicion now that the .ase format doesn't store the information that's needed to animate a model.

[joda.bot]

I'm not sure about this, but 3ds is a propertary format (or was) and I'd rather something that is better docuemnted... I have no suggestions at the moment ... X3D http://www.web3d.org/x3d/ is still to new to be well supported thus I won't recomment it.

[Lucifer]

The only reason I'd support 3ds over blender is because there's a library right there that can do it.

Idealy, we'd move on to support blender, and wavefront, and a whole slew of other formats. I can't think of any reason not to....

[joda.bot]

Commerical game's usally use their own format which is basically a memory dump of the renderer's datastructures thus models can be loaded fast.

The game uses a custom converter from a well known format to it's own datastructure dumps.

[Lucifer]

I don't have an objection to having our own internal model format, but I have a few caveats.

* Many model makers prefer 3dsMax to make models. So we need to convert them to our own format, we don't really have a choice. If we want people to make custom models, we have to do it.

* Many people (myself included) would make models if Blender were supported. So again, we'd need to convert it to our own format.

* Many other people would make models if they had a tool they could use to do it. Blender's Free (with a capital F). If we support blender, this problem is solved.

* To animate custom models, we need to be able to translate the tool's internal animation information to something we understand. In Blender, animation is stored as functions that transform the model itself, and the function is a curve called ipkey. I assume "ipkey" is a fairly standard word because people understand it when I say it. So we need to support *that*. Recent tests me and Supertard did have determined that .ase doesn't have that information in it. Supertard says he might have screwed up, so we'll have to see about it.

* If we support wavefront models, then we get closer to being able to support GLTron's artpacks, which means when people tell us GLTron has better moviepacks, we can tell them to use them instead, they're supported.

So we have two choices, then. Support loading different model formats on the fly, or build a converter tool to do it. I prefer the on the fly solution, but I can see how having our own special format could help for really crazy models (not that we have any really crazy models).

If we have a converter, when do we do the conversion? Does the model maker do the conversion before distributing their new model? Or do we have an --install mode for stuff and do the conversion when the resource is installed? Or do we do the conversion the first time the model is loaded? It would be absolutely the best if model makers can just put up the file they saved from their tool without having to do any extra work, and the work we'd have to do is arguably not significant to support that, so why don't we do it? Answer to the last one: we should do it.

[hang3r]

I can tell you first hand that ASE does not store any animation information (I used to work with it in my own game). Vertices, normals and texture coord's are all it has to offer

Lucifer: Most animators will understand ipkey as it’s a fairly common word shared amongst most 3d design software. In 3D Studio Max its "keys" or "Key frames" IIRC.

I support your suggestion for using lib3ds. If you choose to use the 3ds file format, then not only will people using 3D studio max be able to make small animations, but so will people wanting to use blender (I remember a friend exporting files as 3ds).

[joda.bot]

@lucifer: if a custom format is used the conversion should be done by the modeller with a tool provided by ArmagetronAd ... I guess the ipkey concepts used in Blender might be too complex for us... but well you can always use a smaller subset of features.

I don't like 3DS that much, as all the readers I've seen so far were quite messy. (Still have to see a tidy 3d file parser, I guess )

What kind of storage concept does Ogre use ?
... ah about Wavefront OBJ files... they have the severe problem of not support different pivot points. OBJ does allow geometry grouping but all share (0,0,0) as the origin/pivot, thus it is not suited for animations.

Did anyone ever work with MD3 ?

[Lucifer]

If the ipkey concepts in Blender are too complicated, what does the alternative look like?

Looks like Ogre either supports on-the-fly conversions or uses its own internal format, or both.

* Flexible mesh data formats accepted, separation of the concepts of vertex buffers, index buffers, vertex declarations and buffer mappings
* Export from many modelling tools including Milkshape3D, 3D Studio Max, Maya, Blender and Wings3D
* Skeletal animation, including blending of multiple animations, variable bone weight skinning, and hardware-accelerated skinning
* Biquadric Bezier patches for curved surfaces
* Progressive meshes (LOD)
* Static geometry batcher

Of course, the advantage to having the model maker do the conversion is that he gets to do some QA on the model he's going to distribute with a reasonable certainty that it will behave as expected for everyone. He should do this anyway, but I've seen enough programs save their files differently with minor changes that broke other tools using the same file. (Word being a notorious example, and a word processing document is arguably significantly less complex than a model)

[Luke-Jr]

I don't have an objection to having our own internal model format, but I have a few caveats.

* We might have platform problems
* We're locked to a data structure

[Lucifer]

Luke: Both of those go away (and a number of my own caveats) when/if we pick a standard model format, such as the X3D joda linked, or some of the others. (Blender exports to X3d, I think, I remember seeing it in the list, anyway) The assumption being that the model format we pick does everything we need it to do, everything users want it to do, is more than just reasonably cross-platform, and I forgot the last one. But then, if we use such a format, and we have a converter, why not just load the models from their native formats anyway? We can do like we're doing in the music player. We ship our own music in one format chosen for lots of good reasons, but we support other formats people might want to use in the code.

I'm going to play the "just because everyone else does it doesn't mean we have to" card, and I'm going to follow it up with my "the community keeps asking for this" card. Then I'm going to ask the dealer for more cards.

[joda.bot]

@lucifer: A general problem with 3D formats is that most software does only support a partial set of the format's features. The conversion might even swap/fail to convert front and back facing triangles.

IMHO Support only one 3D file format, but really support it well .
(Converters must be available then, otherwise it is the wrong format )

About the ipkeys, if you're only doing path animations I'm fine with that, but usually Blender and 3Dsmax also support inverse kinematics etc. ... I guess those won't be needed.

[Luke-Jr]

Luke: Both of those go away (and a number of my own caveats) when/if we pick a standard model format, such as the X3D joda linked, or some of the others.

They don't go away-- they just never exist in the first place. My intention was to argue against just dumping data structs into files.

But then, if we use such a format, and we have a converter, why not just load the models from their native formats anyway?

What if one converter/loader has a bug? If we support only one format, that's only one format to test-- convertor bugs can be fixed in the conversion program later.

We can do like we're doing in the music player. We ship our own music in one format chosen for lots of good reasons, but we support other formats people might want to use in the code.

That works... but I hope you're using some kind of existing code for codecs like gstreamer or such?

[Lucifer]

Heh, yeah, you know, generally just dumping data structures into files might be considered offensive in some parts.

Models are a bit different than audio codecs. Luckily, SDL_mixer is handling the different formats for us. I'm just about convinced we should run with OpenAL eventually, though. That means we'll need to pick out an mp3 library, link to libvorbis, and also link to libsndfile. libmad is an excellent mp3 library for our purposes. I think those three will cover just about everything under the sun, not sure about flac. We can throw on flac.

Anyway, point is, this lib3ds is the very first library I've seen tht just supports one model file. Sure, switch out the rendering engine and we probably get model loaders for free. Otherwise, we're either writing our own loaders, or we do the old "beg, borrow, or steal".

[Z-Man]

I'd favor focussing on a single, well supported format. That keeps our code clean and small. Loader libraries for different formats are likely to produce different data structures and we'll need to convert them in our code, it's not like in the audio stream case where we get all the formats basically for free.