Wishful 3D file format

The Cheat
Unregistered
 
Post: #76
I must admit that I have only skimmed through this thread so this may have already been discussed. I do not see the point of this proposed magical "one size fits all" format. Many people have admitted they have created a custom format for their own projects complete with convertors. If the purpose of this universal format is to eliminate the need to create custom formats, I need to ask "why" because:

1. A custom format will always end up being exactly what you need because it was designed by YOU for YOUR needs.
2. Custom formats aren't really difficult to design or implement in code, nor is it particularly time-consuming to do so.

On the other hand, if the purpose of a universal format is to eliminate the need to use already existing (perhaps more specific) formats, again I must ask why? There are already tons of formats designed for different purposes, and there is usually always at least enough information to be able to write a basic importer or use already existing code. Either way, it shouldn't require very much time at all to implement.

If your needs are more specific, then you can always come up with a custom format. Again, it wouldn't take very much time compared to the total amount of time you will spend creating (and perhaps marketing) your game. Plus it just makes sense to remedy specific needs with a specific format rather than to adopt a more general universal format, doesn't it? If you don't want to "reinvent the wheel," well that's why we have the option of using a preexisting format.

I'm sure someone can enlighten me on these matters as they see fit. Blink
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #77
My goal is to have a file format which is by large interchangeable, and can grow with the needs of a developer. Say you only support polygons at first, and you later want to add support for bones and texturing. You shouldn't have create a completely new format for that, but simply add tags for the new features. Now, say you make the mentioned changes to your editor/exporter, you should still be able to load the files with your old game engine, as the new features are simply ignored, without interfering with loading the rest. Also, someone else who just started out could use your model with textures and bones and whatnot in his simplistic engine where only polygons are supported. I hope that makes sense.

Also, if you want to implement a special feature for your game, say pre-generating collision detection information, it can be put into the file without others having to worry about reading the file.
Quote this message in a reply
The Cheat
Unregistered
 
Post: #78
Okay, thanks. What you basically want is a flexible format. Flexibility is definitely a worthy thing for any format, and it's a shame that many formats just don't seem to have been designed with this in mind. There are some formats which are already pretty flexible, though. Even OBJ is flexible... it wouldn't be hard to implement key frames and bones, etc. on top of that format. Any decent OBJ loader is already designed to ignore unknown directives, so already-existing OBJ loaders would continue to work. This seems like the flexibility you are after. If not OBJ, there are probably other formats which are at least equally extensible you can use to build from. If you start from scratch you miss the benefit of there already being code/specs/examples for your base format, but whatever.

Then publish your extensions or new format specs along with sample code or whatever and you've got yourself a new format.

At the end of the day, the flexibility of the format to allow you to pick and choose what features of the file to use is really just a luxury. Not to say that creating such a format would necessarily be a waste of time, but our current situation really isn't too bad. My point is, it doesn't take very long to write importers or convertors for the formats already available to us. But if anyone designed a better (more flexible) model format and wrote good documentation on it, I would definitely look into it.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #79
I don't just want a "flexible" format. You can hack any format to contain additional stuff. What I have in mind is logically like a plist, with dictionaries and arrays and whatnot. With this approach, the parser can stay the same throughout, and you can just change what needs to be done with each tag to fit your engine.

This way, when additional features, which you don't support, are existant in a file, you won't even notice them. And with this approach, each tag can contain arbitrary data. In fact, using NSKeyedArchiver etc might just work, if its internal workings are documented somewhere.

It is also not about chosing what features to use, it is about being able to add custom features without reducing the useability of the given file.
Quote this message in a reply
The Cheat
Unregistered
 
Post: #80
But what you just described is exactly what a "flexible" format is, so it seems like that's exactly you want. Like I said before, many existing model formats are flexible in this fashion. You mentioned XML as an example of the flexibility, and there are many 3d formats which are based directly on XML. Have you looked at X3D, RZML, VRML, etc? Even OBJ is based off of the same principle (one directive with arbitrary values), though with a different syntax. The OBJ format itself defines certain directives and values that can be used, but there is no reason anyone couldn't make up their own.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  what's the most suitable graphic file format when deadling with OpenGL? anthony 8 4,839 Feb 16, 2007 06:25 PM
Last Post: PowerMacX
  Reverse Engineering 3d File Format nabobnick 1 3,014 Aug 13, 2004 12:11 PM
Last Post: nabobnick