Jump to content
  • Advertisement
Sign in to follow this  
QQemka

Mesh format?

This topic is 749 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello. Been lookin on google for answer, which format for meshes is best when it comes down to runtime performance? Right now i habdle simple format where user supplies vector of vertices+color and indices and the basic mesh is created this way. But i would like to import existing meshes from known formats that graphics desginer are using, but im completly green when it comes down to that. Can anyone give me a clue?

Thanks!

Share this post


Link to post
Share on other sites
Advertisement

On top of what Hodgman said, I might add that the .FBX format is an AutoDesk property. They don't want anyone to know how it works. So, they provide their own library to allow you write code that accesses their files. As Hodgman said, it's an extremely bloated file format and there's a ton of stuff in it that is useless for what we're doing with it. I figured that I could spend a month learning their library or a month learning Python so that I could write my own custom model exporter directly from the Blender data. I wrote my own.

 

Something else I might point out is that a binary format is largely pointless because you are going to read the data and throw it away unless you export directly to your own binary format.

 

You can export a human readable format that can be examined when need be. Then you're going to use that to feed your model class the data it needs which will be populating all its variables and such. You're probably going to want to then basically serialize the model class and save a new binary file that is optimized to load the data straight into your model class with the exact data types C++ or whatever needs.

 

Anyway, if you're interested, I have the entire Visual Studio project that I did posted on my website. You're welcome to download it and see how I exported the data from Blender including the model file, the python code, the textures, and all the code. It also might help even if you don't want to do it that way in understanding what is actually in a model file. Other formats will need to contain basically the same data because they will be basically drawing the same model.

 

I believe this is how the big boys do it anyway; I think they write their own exporters for Blender, Max, Maya or whatever they are using so they have complete control over what data they are pulling. What I've got here is just a starting point; there's a lot of other data Blender may have that I may want to use in the future like skinning data, normal maps, and other maps. I didn't include any of that, but this is a good foundation to start from.

Share this post


Link to post
Share on other sites

Hodgman and BBeck already answered your question regarding the format and performance. I just wanted to give you another point of view about file format converters. I started months ago developing my own video game including my own game engine and when I came to the point where I needed to import models, I was thinking about writing an exporter for 3D tools to write the information I need into my own custom file format.

 

I liked this idea very much, but I didn't do it! Instead, I wrote a small application which reads files I need and converts them into my own file format. I chose this option, because I suck in 3D modelling. I knew from the very beginning, that I will need to buy the models I need online or to hire 3D artist to do stuff for me. My game and its engine is still in development, i.e. while adding new features to the game I sometimes need to add features to the game engine. When you have a FBX file from an artist which contains everything you might ever need (mesh, texture and material information, skeletons, animations, lights, cameras, ...) you can keep the single file as a data source and adjust your file format converter over time. When you need something new, you can improve your converter and re-run the application and you are done.

 

If you want to use an exporter for 3D tools, you must make sure that your exporter works with the tools your artists are using. And when you need new data in your game (engine) and you adjust your exporter, you need to re-export all your models. This is fine, if you have all 3D projects on your machine. But this could be a problem, if you don't have access to the projects.

 

I my case, I am still convinced, that writing a converter was the right choice for me. I am currently stuck in the animation part of my game engine (see my other thread). But since I am getting my assets from online stores and external artists, I can use my file format converter in a batch to update all my assets at once.

Share this post


Link to post
Share on other sites

There are four times as many mesh formats as there are graphics coders in the world. (may be even more :( )

 

Every time you write code to display a mesh you have different requirements than the last time you did it, so you end up with a different format.

 

The key is to use a base format that works with your tool chain, and then write a converter. This can either be a stand alone program, or more commonly a plugin for whatever 3D editor you are using.

Share this post


Link to post
Share on other sites

Something else I might point out is that a binary format is largely pointless because you are going to read the data and throw it away unless you export directly to your own binary format.
 
You can export a human readable format that can be examined when need be. Then you're going to use that to feed your model class the data it needs which will be populating all its variables and such. You're probably going to want to then basically serialize the model class and save a new binary file that is optimized to load the data straight into your model class with the exact data types C++ or whatever needs.

I'm currently using COLLADA, which is a human readable format, and has a published specification (as a free PDF) so you can very easily write your own parser instead of using a closed-source autodesk library :wink: Yep, there's been more than one occasion where I've confirmed an "art bug" by opening a model in a text editor and tweaking some values, which is very handy :D
...but one downside is that I have a lot of models that are 100MB as text, and 2MB as binary.
This actually isn't too bad, because most source control systems will compress text files before they send them across the network, and these files only exist on developers machines (not actually part of the game install)... but it's still something to be aware of -- e.g. Your developers may need to work from a 1TB HDD instead of a 128GB SSD.

 

It's not overly popular yet, but a good text-based model format is: http://opengex.org/

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!