Sign in to follow this  
grazing

Unity FBX Models

Recommended Posts

Hi,


I've read several topics from years ago up until recently and I can't find what I call an honest answer.

What are the drawbacks from using FBX internally in your program? E.g. load the FBX file like one would with .x or any other model format?
I've heard countless comments of "it's slow" "it's not meant for that" etc. Can anyone point out why it's "slow" for loading or "not meant for use
in a 3d game engine" over say .x format?


You can save FBX as ASCII and look at the contents in notepad which don't look any more "complex" than .x. (yet no "don't use .x!!!")
You can strip the file down during export to contain only the mesh, normals, UV mapping and animation so is it really "that bad" if you use a FBX model during "run time."

Maybe these thoughts are from people who years ago (I don't know) had bad experiences with it. Also I used their FBX SDK
([url="http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=7478532"]http://usa.autodesk....3112&id=7478532[/url]) (which they are maintaining and updating regularly) and creating a simple loader I can load a 4800 poly mesh in less than
0.2s in debug build. So *scratches head*


Another question I have is XNA uses FBX, Unity has a default FBX importer built in (so you can just drop fbx models into unity and they'll work properly). Maybe
I'm just misinformed .. Also browsing through some top games game content packs (the model viewers) e.g. for. WOW or TorchLight I see it's littered with FBX models.
So uh ... these games are actually saving the FBX model to disc, loading them and then saving them again in another format? That doesn't sound very "AAA" company like ..(?)



Maybe I'm missing something somewhere as I never dealt with this aspect and curious for some[b] feedback from people who actually know what is going on[/b], thanks!

Share this post


Link to post
Share on other sites
I am also thinking to use fbx format in the future.

The big pros I can see with it is that:

- many modelling programs support it (especially Autodesk softwares of course), this gives you a wide range of tools to use already and you aren't tied to one program
- programs are able to load .fbx files too
- it is been developed actively
- SDK is available with pretty good examples
- format supports binary / ASCII modes

So if you don't have much resources to use (time), I think it would be worth to use .fbx format (or another equivalent format)

Best regards!

Share this post


Link to post
Share on other sites
[quote name='kauna' timestamp='1311071371' post='4837306']
I am also thinking to use fbx format in the future.

The big pros I can see with it is that:

- many modelling programs support it (especially Autodesk softwares of course), this gives you a wide range of tools to use already and you aren't tied to one program
- programs are able to load .fbx files too
- it is been developed actively
- SDK is available with pretty good examples
- format supports binary / ASCII modes

So if you don't have much resources to use (time), I think it would be worth to use .fbx format (or another equivalent format)

Best regards!
[/quote]



Hi!




Thanks for your feedback! It's really appreciated! :)

But I definitely do agree with you. There are massive pro's to using FBX. Just trying to see if anyone with [b]valid hard facts[/b] to "not use it" can shine some light on the con's.

Some of the "bigger complaints" I've read is that it's not an "open" source.
OK I understand this but how many people are using PhysX? It's not exactly an "open" source either. Yet ... too many to list AAA game companies are using this bad boy.
Also they (Autodesk) mentioned that they would be making more "private" details more public in future releases of the FBX SDK. So I too agree and think this is the way I want to go.
Not only because Autodesk is supporting and keeping it updated, all their modeling packages from 3ds max, maya, motion builder, etc use FBX natively.

Recently attempted to export a Biped animated model to .x format and well lets just say it's not pretty. Thinking either way I go I'll have to spend several days 'fixing' an
issue with the .x exporter or just wrap up and create my own .fbx loader with the SDK. And well all the pros listed above seems to be the FBX format loader is the way I should be heading.

Share this post


Link to post
Share on other sites
Hi, I've recently added FBX support to a preprocessing tool, and this is what I think.

If you only want to load models, it's decent. If you just want to load polygons, normals, etc. then you can do it pretty easily and without concerns about speed. It may take some time getting used to the SDK, but support is good and I think it's worth it.

Now the ugly part comes with the animations. In a debug build a file with a single animation can easily take more than 2 seconds*. The humanoid.fbx that comes with the SDK takes more than 8 seconds. In release it's pretty much instant (didn't time it) so it may not really be a concern. I also should mention that some malformed files caused the SDK to crash.

Now speed aside, I went into a lot of troubles because each program likes to export things... differently. Let me explain. At least in the files I used, the animation keyframes in a file exported with version 6 would contain absolute values for the translations and rotations, whereas a file exported with version 7 would contain values relative to the previous keyframe. And even worse, files from Maya have to be loaded differently than files from Max. ([url="http://download.autodesk.com/us/fbx/20112/FBX_SDK_HELP/index.html?url=WS1a9193826455f5ff1f92379812724681e696651.htm,topicNumber=d0e7429"]see here[/url]) **

I wouldn't use it directly in an engine, but that's mainly because I prefer having a private format that I can load safely.

* [size="1"]At least in my experience. Opening the file and calling Import() is what causes the big slowdown. However be advised that my implementation may be faulty and I may be loading more than I should, even if I'm setting most options to false.[/size]
** [size="1"]You can avoid this by having the SDK evaluate the complete transformation at a given time.
[/size]

Share this post


Link to post
Share on other sites
Using FBX is not bad, but it [u]could [/u]be slow. There could be two performance issues:
1. reading and parsing text based formats is slower than its binary counterparts. This might not be an issue with lowpoly models, but what happens when you need to read a scene of a few 100k polygons, lot of animation data etc. ?
2. Postprocessing:
Eventually you need to transform your model data into some binary form you want to use in your renderer/physics engine. To do so you often want to "optimize" it for your engine, i.e. removing duplicated vertices, smoothing normals, adding metainformations etc. FBX or collada are model formats, written for modelling tools and not with performance or special rendering engines in mind. At first this might not be an issue, but later in development you want to add more features/optimizing which adds to the postprocessing stack resulting in a potential performance issue.

Loading time is often a point of annoyance and it will sum up (reading audio,texture,model, script loading and compiling, shader compiling etc). Even when you don't see the impact of 2s to 10s as problematic, it is a 80% performance save you will eventually need to decrease loading time to be acceptable.

My sugguestion is to write a FBX-to-your-game "compiler". This could be integrated into your engine first:
[code]
read FBX ==compile==> binary ==readFromMemory==>interal data
[/code]
Later on you could implement it as stand-alone compiler/converter:
[code]
compile: read FBX ==compile==> binary ==> write to disk
game: readFromDisk==>interal data
[/code]

Share this post


Link to post
Share on other sites
[quote name='grazing' timestamp='1311070012' post='4837298']
I've heard countless comments of "it's slow" "it's not meant for that" etc. Can anyone point out why it's "slow" for loading or "not meant for use
in a 3d game engine" over say .x format?  
You can save FBX as ASCII and  look at the contents in notepad which don't look any more "complex" than .x. (yet no "don't use .x!!!")

Another question I have is XNA uses FBX, Unity has a default FBX importer built in (so you can just drop fbx models into unity and they'll work properly). Maybe
I'm just misinformed ..   Also browsing through some top games game content packs (the model viewers) e.g. for. WOW or TorchLight I see it's littered with FBX models.
So uh ... these games are actually saving the FBX model to disc, loading them and then saving them again in another format?  That doesn't sound very "AAA" company like ..(?)
[/quote]
Performance is relative. Something that's fast for someone can mean slow for someone else.

FBX stored in ascii format, (just like .x can be ascii or .obj can be ascii) has the advantage that it is easy to parse (== easy'ish to write a loader for, and can be debugged/modified using notepad to some extent), but for runtime loading purposes, ascii formats are suboptimal compared to binary formats.

A good development file format can be different than a good end-use release file format. At development time, it is useful if you can load files of any types. For Unity and other middleware, it is advantageous to have loaders for about everything, so that the user has the flexibility to produce content in whatever format their CAD packages can provide. In Unity, for the shipped release version, the input files are run through a content builder, which packages the data to a format that is optimized for loading into Unity mesh buffers.

To get an optimal performance format, the usual simple mechanism is to generate a file format that is just a dump of the raw data you feed to your internal Mesh/Texture/Shader/... data structures. To load these binary files, you don't do much else than a single fread() to stream in the header, followed by a fread() to read in the actual per-vertex data, and that's it. Because this method will not involve any kind of per-element parsing (e.g. ascii->binary) and is not filled with small-sized file loads (e.g. fscanf to get individual lines at a time), loading is an order-of-magnitude faster.

Binary formats do have their drawbacks, e.g. supporting multiple versions can be more difficult than with ascii data.

Someone mentioned 0.2s loading times for .fbx meshes. If that sounds adequate, then it probably is. If you're looking to stream in meshes at runtime, that's most likely not enough (0.2s == 12.5 application frames if running at 60Hz).

For FBX, I'll restate these two comments from the previous posts:

"Some of the "bigger complaints" I've read is that it's not an "open" source."
"I also should mention that some malformed files caused the SDK to crash."

This can be a huge deal for some cases, or depending on your game, it might not mean a thing.



Share this post


Link to post
Share on other sites
First off awesome responses so far thank you everyone :)!



[quote name='clb' timestamp='1311076586' post='4837329']
Performance is relative. Something that's fast for someone can mean slow for someone else.

FBX stored in ascii format, (just like .x can be ascii or .obj can be ascii) has the advantage that it is easy to parse (== easy'ish to write a loader for, and can be debugged/modified using notepad to some extent), but for runtime loading purposes, ascii formats are suboptimal compared to binary formats.
[/quote]
Understood. But I was just pointing out when exported into ascii to view the contents it's not much different than .x in ascii. You can export FBX into binary :)


[quote]
To get an optimal performance format, the usual simple mechanism is to generate a file format that is just a dump of the raw data you feed to your internal Mesh/Texture/Shader/... data structures. To load these binary files, you don't do much else than a single fread() to stream in the header, followed by a fread() to read in the actual per-vertex data, and that's it. Because this method will not involve any kind of per-element parsing (e.g. ascii->binary) and is not filled with small-sized file loads (e.g. fscanf to get individual lines at a time), loading is an order-of-magnitude faster.
[/quote]
Awesome! I've wondered what magic was going on for such "per engine custom formats" hah nothing more than a simplistic read header read info based on header settings! :) Here I was fathoming some huge magical dragon .. haha.


[quote]
Someone mentioned 0.2s loading times for .fbx meshes. If that sounds adequate, then it probably is. If you're looking to stream in meshes at runtime, that's most likely not enough (0.2s == 12.5 application frames if running at 60Hz).
[/quote]
Agreed and understood, but my comment about the load of less than 0.2s was refering to ascii and debug release. I'm sure it'll be much quicker in a release build and binary format however your point is heard, some more food for thought for me. Thank you.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Announcements

  • Forum Statistics

    • Total Topics
      628294
    • Total Posts
      2981882
  • Similar Content

    • By CpawsMusic
      Hey there! My name is Cpaws and I compose music, sound effects and overall sound design for video games and film. I'm looking to work on a horror game mainly for fun and as an addition to my portfolio. I've used Unity & Wwise before for audio implementation.
      If you're interested in working together, don't hesitate to contact me at cpawsmusic@gmail.com
      Here's a few demo reels of my past projects: 
      Here's some snippets of some quick game music I've composed: https://soundcloud.com/cpawsmusic/sets/cpaws-video-game-film-music
      Here's my portfolio/website: https://CpawsMusic.com/
      E-mail: cpawsmusic@gmail.com
    • By muhamad rabee
      My first mobile game made by unity

      iphone: https://itunes.apple.com/us/app/aa-countdown/id1314223584?ls=1&mt=8

      android: https://play.google.com/store/apps/details?id=com.mr.AACountDown

      I appreciate every suggestion
    • By Simplepg
      https://play.google.com/store/apps/details?id=simple.gplay.GamesInABox
    • By Simplepg
      https://play.google.com/store/apps/details?id=simple.gplay.GamesInABox
    • By ForgedInteractive


      Who We Are
      We are Forged Interactive, a small team of like-minded game developers with the sole purpose of making games we love! We're a team of artists, animators, programmers, level designers, writers, composers, producers, and other creative minds. We want to make games that you, the modern gamer want to play! We hope to build a community that enjoys our games as much as we love creating them. With your feedback and support we will be able to achieve that.

      About the Game
      GAME NAME is a fun, action-packed army builder with unique characters, challenges and engaging levels. Set forth on an adventure to protect friends, family and countrymen from new adversaries. Once defeated your enemies turn coat and join you in your adventures. Players can enjoy a range of troops and abilities based on their gameplay style which become more important as maps introduce more challenging terrain, enemies and bosses. Strong orc knights, dangerous shamans, and even a dragon are out on the prowl. Knowing when to fight and when to run, and how to manage your army is essential. Your actions alone decide the fate of this world.

      Previous Work by Team
      Although we are working towards our first game as a team, our team members themselves have past experience in the industry.
      This includes members who have worked on titles including:
      Final Fantasy Kingsglaive, FIFA, Xcom 2 and Civilization.

      Who are we looking for? 3D Modellers Concept Artists Marketing Specialists Level Designer

      What do we expect? Reference work or portfolio. Examples what have you already done and what projects you have worked on academic or otherwise. The ability to commit to the project on a regular basis. If you are going on a two-week trip, we don't mind, but it would be good if you could commit 10+ hours to the project each week. Willingness to work with a royalty based compensation model, you will be paid when the game launches. Openness to learning new tools and techniques
      What can we offer? Continuous support and availability from our side. You have the ability to give design input, and creative say in the development of the game. Shown in credits on websites, in-game and more. Insight and contacts from within the Industry.
      Contact
      If you are interested in knowing more or joining. Please email or PM us on Skype. Myself or Colin will reply to you within 48 hours.

      E-mail: Recruitment@ForgedInteractive.com
      Skype: ForgedInteractive

      Regards,
      David and Colin

      Follow us on:

      Facebook: https://www.facebook.com/ForgedInteractive/
      Twitter: @ForgedInteract
      Youtube: https://www.youtube.com/channel/UCpK..._as=subscriber
      Reddit: https://www.reddit.com/user/Forged_Interactive/
  • Popular Now