可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I'm writing a game in JOGL and need to represent the in-game character. I plan to use skeletal animation for the character movements, and of course the character will be skinned. I can't seem to find any good model loaders for JOGL so I plan to load the filetype myself, based on specs or something. I also plan to use Blender as my 3D modeler, so some type that exists in there would be best.

What filetype do you recommend I use? .blend? .x, .3ds, .md2/3/5, ...?? Remember I'd like something with a clear defined format so that I can write the loader without having to deobfuscate some random file format, and it needs to support the aforementioned features. Any other info you can give regarding why you chose it and why it's best would be very helpeful too!

Thanks!

EDIT: I will be writing a Blender MS3D exporter. When I'm finished I will post it here.

Meanwhile, see my marked answer below; but more has gone on since then. I'm not going to keep this updated with what I'm doing, but basically I found jMonkey Engine and it already has a ms3d importer and other subsystems which I had begun hand-writing. Despite the scenegraph stuff (which is why I was avoiding Java3D) I think it'll be my best bet to join forces with it, so that's what I'm up to.

回答1:

If you can live with just geometry, or are prepared to handle your own texturing, then .obj is probably the most straightforward and widely supported 3D file format. It's basically the ascii of 3D modelling.

Otherwise I'd tend towards vrml. It's well defined and there is at least some code around to get you started. I've successfully loaded vrml models into java3D using freely available code. Native file size tends to be large, but that can be solved by using a compressed format.

I would not recommend .3ds. The only time I've handled a reader for this format was in Delphi Pascal, and it's messy, ill-defined, difficult to process and tends to have lots of 'variations' such that although I managed to get my reader handling models exported from 3D-MAX itself just fine it rejected many models from other packages that claimed to be in 3DS format but were not properly formed.

ADDED: Also I'd recommend you take a look at the Java3D API and the O'Reilly book Killer Game Programming in Java as even if you don't go down the Java3D route it is likely to answer a lot of your questions.

回答2:

First of all, thank you to the other two answerers. Also basszero you were right about the blend file, and I should've checked Wikipedia first! It is a near-useless binary dump of Blender's memory.

Shortly after writing this question, I decided to go ahead and write an OBJ loader, because 1) it would give me the experience of loading a 3D file format and 2) it seemed a nice, commonly-used format but also easy to load. It ended up being a great decision, because it made me realize, I didn't actually know the difference between an object and a group, and I also didn't know much about materials. It helped me establish the code for these 3D structures.

Both answers recommend XML-based formats. I don't want an XML format. I do not believe this is the right place for XML. I believe those formats were created because XML is flexible, universal, and easy to create schemas for, but that's not what I'm looking for. I want a format that is fast to load (XML is not, relatively speaking), it does not have to be flexible or human-readable, and something that I can write an importer for, rather than relying on XML libraries. basszero even said, "at the cost of being XML," and he's completely right; it's a cost that I don't feel is worth the burden.

My OBJ loader is done. I separated it from the actual model classes, and implemented it with a MeshFactory interface so that I can in the future write a different loader if I wanted... Which is the plan. I have been doing more research the past couple days and decided on the ms3d format.

The ms3d format supports skeletal rigging (joints) and keyframe skeletal animation, and furthermore supports a texture map and alpha map. In addition, it is an easily-computer-readable binary format that wastes no space (like XML and OBJ do) with human readable tags and labels and such.

Blender, unfortunately, does not have a (working) ms3d export script, so I will be writing a script for it myself. Luckily, it's not a hard process, and you can read through Blender's documentation and use other exporters as examples. I'll have to brush up on my Python, but otherwise it seems very straightforward, from what I've seen of other scripts.

The Java side of things should be easy, in fact it will be even easier than the OBJ format because ms3d is more structured. I found specifications for the ms3d format online, in C style (genius!) so they are incredibly self-explanatory and I have no further questions about the format. I will be basing my implementation off of this spec, though I may at a later time implement my own variations; that's the great thing about writing my own importer and exporter, I can modify the format as I see fit.

All in all, I have decided this is the best solution.

And basszero, you are absolutely right, as I've seen from my OBJ loader: "Once you've got it all read in, organization of data (display list, textures, vertex array, vertex buffer, etc) and rendering are a completely different beast."

Cruachan: no Java3D for me, I'm sticking with JOGL. I do actually own that book (though it's not accessible at the moment) though I don't remember how he loaded models, but I'm pretty sure he used the Java3D format loaders which do it automatically. Not something I'm planning on using... Sorry!

-Ricket

回答3:

I believe .blend is mostly a binary dump of in memory structures from blender, not gonna help you much outside of blender. Use Blender to model, but export to a different format.

It may be a little verbose, but I've heard Collada wraps up 3D information very nicely (at the cost of being XML). The upside is that there is likely a propery schema definition which you could pass through JAXB resulting in a full parser w/ no work from you.

The .md* formats may also be a good alternative. They're from iD engines (q1,q2,q3,q4,doom3) and they're documented. They also contain animations sequences.

Once you've got it all read in, organization of data (display list, textures, vertex array, vertex buffer, etc) and rendering are a completely different beast.

回答4:

Woah, man, are you going to release the ms3d exporter when you finish it? And if so, how is it coming? I really need to get my hands on an exporter that works for animation and that Fragmotion uses, and it looks like what your doing is my last hope.