Sign in to follow this  
grazing

Unity FBX Models

Recommended Posts

grazing    108
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
kauna    2922
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
grazing    108
[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
kauna    2922
Yes, I'd like to hear some real world experiences too on the FBX SDK. Otherwise, I'll be able to tell them in few weeks :)

Cheers!

Share this post


Link to post
Share on other sites
Gaenor    212
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
Ashaman73    13715
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
clb    2147
[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
grazing    108
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  

  • Similar Content

    • By drcrack
      Hey
      I'm developing a game inspired by World of Warcraft PvP
      Key features:
      — It's not an MMORPG, you don't need to level up and gear up your characters
      — Many different rated and casual gamemodes: duels, 2v2 and 3v3 arenas, battlegrounds, deathmatches
      — Built-in voice and matchmaking without a party (if you don't want to push serious rating)
      — Non-targeting combat system
      Sign up for beta here: https://goo.gl/forms/IYSAQtiRXQVY2B192
      Duels:
      3v3 with bots: 
      More videos coming soon!
    • By Affgoo
      About us:
      We are a team of 14 developers developing multiple mid scope games both are over halfway complete. We polish all of our games and focus on quality.


      We are a small team, everyone currently on the team and future teammates must be interested in game development as a whole and not just one role, being a small indie company it is very important that you can wear a few hats and not just one. Everyone on our team is a game dev.

      looking for:
      3d Artist (hand painting a huge plus)
      3d Animator
      entry level Software engineer with reasonable skills in c# / shaders. 

      ^ requirement for all positions: A true love of game development and to be very self motivated.
      We are a very active team, you must be too. 


      If interested or for more information add me on skype: nicholas.boucher4


      Atlas Sentry art style: (art complete)(code complete)
      http://www.slidedb.com/games/atlas-sentry

      Rat n Gat art style: In Devlopment

    • By EvaBalikova
      Main menu in Feudal Alloy. 
      twitter
    • By Jcyshadow97
      Hi guys,i m looking for someone that can work with me on a "top-down" multiplayer fps as 2d and 3d artist.I used photon server and i can take the part of programming.For now i made only the basic gameplay of the game that include shooting,switch weapon and and damage player.If someone can help me please contact me via e mail: 270514974@libero.it.
      I really appreciate your collaboration and hope you have a good day.....
      Thanks for you time to read the post
      At the bottom i attach some screenshot of the current game,i m sorry that i can't attach a video...



    • By Raptor42
      I'm looking to form a new game development team, mostly for training purposes.
      About me:
      I'm a student - Unity C# developer, who worked part-time in this industry for a couple of years already. I've been a lead developer in many "random collab groups" as well as a few companies. I specialize in creating 2D games for Android, but I'm looking forward to trying out new things - especially 3D development.
      Currently, I've got one Android game close to a release so I'd work for this team in my spare time. 
      About the project:
      I've been thinking about creating a simple tycoon-like simulation game for Android (and PC eventually), inspired by the Game Dev Story (initially released by Kairosoft in 1997) https://en.wikipedia.org/wiki/Game_Dev_Story 
      I haven't done much planning though, therefore I'm looking forward to hearing out your ideas.
      Right now, I've only created a test 3D scene using placeholder models and implemented a simple pathfinding system for me to play around with:
      https://i.imgur.com/xAd0l4o.png
      https://i.imgur.com/nHZerOT.png
      I'm looking to work with people who are:
      - willing to take a position of a: 3D modeller/2D artist/Designer
      - not necessarily very experienced, but eager to learn and improve their skills
      - active - check in at least once a day
      If you'd like to apply for a different position which I didn't list here, you are welcome to contact me as well.
      While this project is created mostly for learning purposes, if we ever get to release it and generate any revenue - you will recieve a certain percentage of it.
       
      To Apply:
      Send an email to rk.softwaredev@gmail.com
      Introduce yourself and attach an example of your work (if you have any)
  • Popular Now