Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualL. Spiro

Posted 22 December 2012 - 07:56 AM

Whats the reason to why you never want to do that?

Because those file formats were intended from the start to serve a different purpose. They are meant to provide a means of transferring data from Autodesk® Maya® to Autodesk® 3ds Max®, for example. As such they contain all possible data you could imagine that should be shared between 3D-authoring tools.

 

This is not desirable in a game-oriented format.

Your files should contain no more data than your engine can load and use.  Imagine loading a gloss map when your engine can’t actually use gloss maps.  It doesn’t make sense.  You should only use a format that was designed for your engine, and .OBJ, .FBX, and .DAE were not.

 

Furthermore, since these file formats were designed to transfer data between 3D authoring tools, they do not store their data in a game-friendly format.

In other words, a game-friendly format would allow your engine to load the vertex buffers directly into memory with no processing.  On the other hand, .OBJ, .DAE, and .FBX require that you parse faces, index into vertex/normal/UV pools, and construct the final vertex buffers that you need.

This is obviously undesirable overhead for games.

 

Then there is the idea of distribution.  Do you want your engine to rely on Assimp or do you want your tools to rely on it?  It is easy to make tools that rely on loaders—you don’t need to distribute those with your games so their licenses don’t matter at all (literally there is no way to prove how your own files came into existence so no matter what technology you use to make your own format there is no possibility of ramifications, hence there is no such thing as a license that burdens you based off how you created your own file format).

But if it is your engine that requires X library to load its 3D format you had better check the conditions under which you can distribute said loader.  If you made your own format, this will never be a problem.  If not, this will always be a problem.

 

 

Then there is loading time.  My converter uses the Autodesk® FBX® SDK to load .FBX files.  That in itself takes over 2 seconds on some files and is out of my hands.  Those same files converted to my engine format take 0.2 seconds to load.

 

 

Basically, .OBJ, .DAE, and .FBX were not meant to be loaded directly into games.  They were designed for a specific purpose and should be used for that purpose.

The things you load into your engine should have been designed for loading into your engine.

 

 

L. Spiro


#2L. Spiro

Posted 22 December 2012 - 07:56 AM

Whats the reason to why you never want to do that?

Because those file formats were intended from the start to serve a different purpose. They are meant to provide a means of transferring data from Autodesk® Maya® to Autodesk® 3ds Max®, for example. As such they contain all possible data you could imagine that should be shared between 3D-authoring tools.

 

This is not desirable in a game-oriented format.

Your files should contain no more data than your engine can load and use.  Imagine loading a gloss map when your engine can’t actually use gloss maps.  It doesn’t make sense.  You should only use a format that was designed for your engine, and .OBJ, .FBX, and .DAE were not.

 

Furthermore, since these file formats were designed to transfer data between 3D authoring tools, they do not store their data in a game-friendly format.

In other words, a game-friendly format would allow your engine to load the vertex buffers directly into memory with no processing.  On the other hand, .OBJ, .DAE, and .FBX require that you parse faces, index into vertex/normal/UV pools, and construct the final vertex buffers that you need.

This is obviously undesirable overhead for games.

 

Then there is the idea of distribution.  Do you want your engine to rely on Assimp or do you want your tools to rely on it?  It is easy to make tools that rely on loaders—you don’t need to distribute those with your games so their licenses don’t matter at all (literally there is no way to prove how your own files came into existence so no matter what technology you use to make your own format there is no possibility of ramifications, hence there is no such thing as a license that burdens you based off how you created your own file format).

But if it is your engine that requires X library to load its 3D format you had better check the conditions under which you can distribute said loader.  If you made your own format, this will never be a problem.  If not, this will always be a problem.

 

 

Then there is loading time.  My converter uses the Autodesk® FBX® SDK to load .FBX files.  That in itself takes over 2 seconds on some files and is out of my hands.  Those same files converted to my engine format take 0.2 seconds to load.

 

 

Basically, .OBJ, .DAE, and .FBX were not meant to be loaded directly into games.  They were designed for a specific purpose and should be used for that purpose.

The things you load into your engine should have been designed for loading into your engine.

 

 

L. Spiro


#1L. Spiro

Posted 22 December 2012 - 07:50 AM

Whats the reason to why you never want to do that?

Because those file formats were intended from the start to serve a different purpose. They are meant to provide a means of transferring data from Autodesk® Maya® to Autodesk® 3ds Max®, for example. As such they contain all possible data you could imagine that should be shared between 3D-authoring tools.

 

This is not desirable in a game-oriented format.

Your files should contain no more data than your engine can load and use.  Imagine loading a gloss map when your engine can’t actually use gloss maps.  It doesn’t make sense.  You should only use a format that was designed for your engine, and .OBJ, .FBX, and .DAE were not.

 

Furthermore, since these file formats were designed to transfer data between 3D authoring tools, they do not store their data in a game-friendly format.

In other words, a game-friendly format would allow your engine to load the vertex buffers directly into memory with no processing.  On the other hand, .OBJ, .DAE, and .FBX require that you parse faces, index into vertex/normal/UV pools, and construct the final vertex buffers that you need.

This is obviously undesirable overhead for games.

 

Then there is the idea of distribution.  Do you want your engine to rely on Assimp or do you want your tools to rely on it?  It is easy to make tools that rely on loaders—you don’t need to distribute those with your games so their licenses don’t matter at all (literally there is no way to prove how your own files came into existence so no matter what technology you use to make your own format there is no possibility of ramifications, hence there is no such thing as a license that burdens you based off how you created your own file format).

But if it is your engine that requires X library to load its 3D format you had better check the conditions under which you can distribute said loader.  If you made your own format, this will never be a problem.  If not, this will always be a problem.

 

 

Then there is loading time.  My converter uses the Autodesk® FBX® SDK to load .FBX files.  That in itself takes over 2 seconds on some files and is out of my hands.  Those same files converted to my engine format take 0.2 seconds to load.

 

 

Basically, .OBJ, .DAE, and .FBX were not meant to be loaded directly into games.  They were designed for a specific purpose and should be used for that purpose.

The things you load into your engine should have been designed for loading into your engine.

 

 

L. Spiro


PARTNERS