Jump to content
  • Advertisement
Sign in to follow this  
irreversible

Unity Asset format support (esp. for all you development kit users out there)

This topic is 2463 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

I'm not working on a big engine or anything, but it nevertheless is an engine that comes with its own editor. So far I've been ignoring proper asset format support - if needed, static geometry can be imported via obj files, which are simple and effective to handle. The imported meshes are then stored in a proprietary format.

However, I'm looking for the best extensible solution that wouldn't be awkward or foreign to use for people that already have experience with industry standard suites. I need to have support for animated geometry and character animation roughly with the same kind of complexity that obj support is for static meshes and md5 support is for models.

I've been doing some digging and it seems that for instance UDK has settled on fbx being their standard format. Unity as well seems to be going roughly in the same direction.

Now, since I've never really used fbx before for anything myself and since it's a closed format, I'm not sure whether it's the best solution for a small-scale application such as my own. As such, I'd like to get some feedback from people who do have this experience or who can suggest the most convenient/effective workflow from both the artistic side as well as the programming side.

So yeah - suggestions and thoughts are welcome! :)

Share this post


Link to post
Share on other sites
Advertisement
I don't know how experienced you are, but you can always roll your own. Obviously this will take extra time as you need to support both the importing and exporting of the models.

If you don't mind adding a library to your project, you can look at assimp which supports a good range of different formats. If you don't want to rely on a library you can perhaps check out Collada, I personally don't like it at all, but it gets the job done.

Share this post


Link to post
Share on other sites
Personally I'm building my 'content pipeline' around FBX; most if not all modelers export to it, the SDK is one download no mucking about with external libs, is pretty well documented and pretty much does what you need 'out of the box'.

I'd start with code which imports a simple series of test models first and then expand and refactor as required going forward.

Share this post


Link to post
Share on other sites
Hidden
It seems this is a VERY common question/problem. If you would like you can check out my topic if you haven't already: http://www.gamedev.net/topic/621731-3d-model-loading-choices/
Basically either you can use assimp like Reloadead_ suggested, or you can make your own. The latter seems to be the preferred solution. It's faster, easier (to read/write), smaller (file size), more convenient, more professional, and more secure. But the former does have its own advantages.

Share this post


Link to post
Xarles; you are convoluting two aspects here.

The OP is talking about having an editor and being able to import existing models in an interchange format into the editor; at a later point these models will be converted into the runtime asset.

This is a good approach as it allows you to work "directly" with the art package output in the editor where assets are likely to change often before doing a 'data build' to reduce the required assets down to 'run time' formats which can be quickly loaded.

Our pipeline at work works along those lines;

Artist work flow is;
[max] -> {output to custom 'interchange' format} -> [world editor]

Game data flow is;
{custom interchange format} -> [pipeline] -> {run time formats/files}

The former can be done in a matter of seconds and allows for quick reloads, the later can take a few minutes (depending on data pipeline work load) but loads quickly 'in game'.

Share this post


Link to post
Share on other sites

Personally I'm building my 'content pipeline' around FBX; most if not all modelers export to it, the SDK is one download no mucking about with external libs, is pretty well documented and pretty much does what you need 'out of the box'.

I'd start with code which imports a simple series of test models first and then expand and refactor as required going forward.


This is actually precisely the kind of feedback I was looking for. I was simply mildly concerned there might be some caveats regarding fbx (in terms of whatever from licensing to integration). Thank you!

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!