Advertisement Jump to content
Sign in to follow this  
Solid_Spy

Writing a custom 3d file format, export from Blender?

This topic is 1869 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, I want to discuss whether or not it is worthit to write an exporter for a custom file format for a video game. I have tried writing my own Exporter for blender, and have had success with creating a mesh without animation support, however, as soon as I got into adding animation support, that really threw a wrench into things. I previously tried to write a file converter that converted collada files to my own custom format, however that resulted in duplicate UV coordinates, which I didn't want.

 

I'm thinking of giving up on writing an export script for Blender, since it doesn't have enough documentation or tutorials to do so. Looking at the other export scripts that come with blender doesn't seem to help much, and I feel that writing a converter would be more worthit. I might try writing a converter for .x format, but I want to know if anyone else has ever gone through this, and what your thoughts on the matter are.

Share this post


Link to post
Share on other sites
Advertisement

I wrote a converter using the assimp library.. Then you can use whatever file format you want and just extract the data you need using the assimp api..

Share this post


Link to post
Share on other sites

The way this is usually done is that you use some standard export format from the 3D tool to read it into your game.  In your engine, you should have some asset conditioning utilities, and this is traditionally where a conversion to a more efficient format takes place.  You bake all of the data down to a tightly packed binary file that you know the structure of.  This will remove all of the unneccesary information from the file, ensure that you can read the file in the order you initialize things, etc.

 

You can look into the FBX SDK from Autodesk, I've had some luck with that, or as Nanook suggests, Assimp is a good library that's really not difficult to use.

Share this post


Link to post
Share on other sites

 

You should work with a format that will be as widely used as possible. Making something for Blender is useless for people who use 3DS Max.

 

Ah yes, I agree. However this is just a solo project, and I don't have teh monies to afford 3ds Max so i'm stuck using Blender :/

Share this post


Link to post
Share on other sites

The way this is usually done is that you use some standard export format from the 3D tool to read it into your game.  In your engine, you should have some asset conditioning utilities, and this is traditionally where a conversion to a more efficient format takes place.  You bake all of the data down to a tightly packed binary file that you know the structure of.  This will remove all of the unneccesary information from the file, ensure that you can read the file in the order you initialize things, etc.

 

You can look into the FBX SDK from Autodesk, I've had some luck with that, or as Nanook suggests, Assimp is a good library that's really not difficult to use.

Yeah, I might just use assimp, that seems to me like a much better alternative from what i've researched.

Share this post


Link to post
Share on other sites

You should work with a format that will be as widely used as possible. Making something for Blender is useless for people who use 3DS Max.

Ah yes, I agree. However this is just a solo project, and I don't have teh monies to afford 3ds Max so i'm stuck using Blender :/

That wasn’t the point.
Don’t make exporters for a specific piece of software—make exporters for interchange formats such as COLLADA and FBX so that anyone using any software can make model files for your game, from Blender, Maya, whatever.
Put another way, if you make something for Blender, then you support only Blender.
If you make a converter for FBX, then you support Blender, Maya, 3DS Max, Cinema 4D, SoftImage 3D, Alias|Wavefront PowerAnimator, and NewTek LightWave 3D.

I’d recommend FBX over Assimp. While Assimp supports more formats than you would ever need, I believe the way it stores animations is lossy, storing them as keyframes of full-sized matrices rather than as individual tracks.
This might be part of a post-processing feature. Other post-processing features such as collapsing the scene graph are also undesirable if they end up being exported that way—you definitely want to keep the full scenegraph intact when you export to your own format.
I am also not sure how easy it is to do keyframe minimizing, etc., in Assimp.


L. Spiro

Share this post


Link to post
Share on other sites

Sure supporting an interchange format like FBX is a must in the future, if you expect other people to make models. However writing such a tool is easy and quick (once the custom format has been established), so it can be done when it's needed (later). Since he's working alone, he can do whatever's most useful now.

 

And in my opinion a Blender export plugin is something more than just format conversion. You can use built-in APIs to do model preprocessing - probably much nicer than writing it in c++. You can use Blender creatively to produce more data than just models and animations - adding custom properties to objects, (ab)using the video editor to design cutscenes, etc. It can make Blender a replacement for custom editors (which you would write if you were making a 'big' commercial engine).

I'm sure the FBX SDK supports most of this (like custom properties, action sequences), but my experience is that the compatibility is low, especially with FBXes created by Blender. When I was making a similar decision some time ago I tried both FBX and Collada with the Autodesk SDK and Assimp. Even the Autodesk converter lost animation-strip data when converting between those 2 formats (a sanity test) and Blender didn't support exporting animation strips to Collada. Sticking to Blender makes this kind of pain go away (replacing it with painful Blender API compatibility issues between versions...).

 

I guess what I'm trying to say is, don't complicate stuff, YAGNI. Use whatever you need at the moment, and since you're stuck with Blender, you could just as well make a good use of it.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!