Jump to content

  • Log In with Google      Sign In   
  • Create Account


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 Solid_Spy   Members   -  Reputation: 357

Like
0Likes
Like

Posted 09 December 2013 - 05:08 AM

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.



Sponsor:

#2 Nanook   Members   -  Reputation: 431

Like
0Likes
Like

Posted 09 December 2013 - 05:24 AM

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..



#3 morbik   Members   -  Reputation: 363

Like
1Likes
Like

Posted 09 December 2013 - 07:33 AM

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.



#4 L. Spiro   Crossbones+   -  Reputation: 9732

Like
5Likes
Like

Posted 09 December 2013 - 07:36 AM

I want to discuss whether or not it is worthit[sic] to write an exporter for a custom file format for a video game.

It is necessary.  Your engine should never load a model file that was not specifically designed for your engine.
 
 

I have tried writing my own Exporter for blender

I might try writing a converter for .x format,

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. You should use an interchange format such as COLLADA or FBX; .X files are not interchange formats.
I recommend .FBX as it is the most mature in terms of SDK support and documentation.


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#5 Solid_Spy   Members   -  Reputation: 357

Like
0Likes
Like

Posted 09 December 2013 - 04:36 PM

 

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 :/



#6 Solid_Spy   Members   -  Reputation: 357

Like
0Likes
Like

Posted 09 December 2013 - 04:38 PM

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.



#7 L. Spiro   Crossbones+   -  Reputation: 9732

Like
1Likes
Like

Posted 09 December 2013 - 07:42 PM

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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#8 Bluebat   Members   -  Reputation: 246

Like
1Likes
Like

Posted 10 December 2013 - 03:48 AM

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.



#9 Sponji   Members   -  Reputation: 1007

Like
0Likes
Like

Posted 10 December 2013 - 05:35 AM


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.

Each node has separated keys for position, rotation and scaling: http://assimp.sourceforge.net/lib_html/structai_node_anim.html


Derp




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS