• Advertisement
Sign in to follow this  

Unity FBX Models

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

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
Advertisement
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
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
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
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Now

  • Advertisement
  • Similar Content

    • By Affgoo
      https://play.google.com/store/apps/details?id=com.NE.Alien
      still a lot of work to do, but its pretty stable  please let me know what you think <3
      Atlas Sentry is a game of destroy everything. Using your turret, simply swivel and shoot your way to victory, upgrading your weapons to unleash destruction on the variety of spaceships. The bigger your combo’s the more score you get! Earn silver as you play and then purchase new weapons and abilities to better deal with your enemy. Different enemies use different tactics and weapons, work out your own priorities in their destruction order. 

      Features: 
      **2 different game modes 
      **A level select mode with 20 difficult levels including a final boss, can you defeat it? **Arcade mode of endless destruction, how long will you last? 
      **High scores to compete against others, see who can take the top spot. 
       
    • By Chamferbox
      Chamferbox, a mini game asset store has just opened with some nice game assets, 
      Here you can find a free greek statue asset 

      Also check their dragon, zombie dragon and scorpion monster out:



      They're running the Grand Opening Sale, it's 30% off for all items, but for gamedev member, you can use this coupon code:
      GRANDOPEN
      to get 50% off prices What are you waiting for, go to
      http://chamferbox.com
      and get those models now!

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
    • By DevdogUnity

      Ho ho ho
      Tis the season of Christmas surprises, and we have a awesome one for you! 🎅  
      Sponsored by all your favorite Unity Asset Store developers, Nordic Game Jam, Pocket Gamer Connects, and co-hosted by Game Analytics, we (Joris and I – Devdog) are launching the second edition of our yearly Christmas Giveaway Calendar for all Unity game developers!
      You can already now sign up right here.
       
      So what’s this all about?
      For the past weeks, we’ve been collecting sponsored gifts related to Unity (asset vouchers, product keys, conference tickets etc.), and throughout each day of December leading up to Christmas Day on the 25th, we will be sending out these sponsored gifts as early gamedev Christmas presents via e-mail to hundreds of lucky winners.
      The total prize pool is at $35,000, with over 1200 presents donated by the awesome sponsors!
       
      Merry Christmas from Devdog, Game Analytics, and every single one of the sponsors.

      View full story
    • By sveta_itseez3D
      itSeez3D, a leading developer of mobile 3d scanning software, announced today a new SDK for its automatic 3D avatar generation technology, Avatar SDK for Unity. The Avatar SDK for Unity is a robust plug-n-play toolset which enables developers and creatives to integrate realistic user-generated 3D avatars into their Unity-based applications. SDK users can allow players to create their own avatars in the application or integrate the SDK into their own production processes for character design and animation.
      “Virtual avatars have recently become increasingly popular, especially in sports games and social VR apps. With the advance of VR and AR, the demand to get humans into the digital world is only increasing”, said Victor Erukhimov, itSeez3D CEO. “Our new Avatar SDK for Unity makes it super-easy to bring the avatar technology into any Unity-based game or VR/AR experience. With the Avatar SDK for Unity now every developer can bring face scanning technology into their games and allow players to create their own personalized in-game avatars, making the gameplay much more exciting and immersive.”
      Key features of the Avatar SDK for Unity:
      Automatic generation of a color 3D face model from a single selfie photo in 5-10 seconds (!). Works best with selfies, but can be used with any portrait photo.
      Shape and texture of the head model are unique for each person, synthesized with a deep learning algorithm crafted by computer vision experts
      Head models support runtime blendshape facial animations (45 different expressions)
      Generated 3D heads include eyes, mouth, and teeth
      Algorithms synthesize 3D meshes in mid-poly resolution, ~12k vertices, and ~24k triangles
      Six predefined hairstyles with hair-recoloring feature (many more available on request)
      Avatar generation API can be used in design-time and in run-time, which means you can allow users to create their own avatars in your game
      Cloud version is cross-platform, and offline version currently works on PCs with 64-bit Windows (support for more platforms is coming soon)
      Well-documented samples showcasing the functionality.
       
      Availability
      The Avatar SDK for Unity is offered in two modes - “Cloud” and “Offline”. The “Cloud” version is available at http://avatarsdk.com/ and the “Offline” version is available by request at support@itseez3d.com.
      ###
      About itSeez3D
      At itSeez3D, we are working on the computer vision technology that turns mobile devices into powerful 3D scanners. itSeez3D has developed the world's first mobile 3D scanning application that allows to create high-resolution photorealistic 3D models of people's' faces, bodies and objects. The application is available for iOS and Windows OS mobile devices powered with 3D cameras. In 2016 the company introduced Avatar SDK that creates a realistic 3D model of a face from a single selfie photo. To learn more about itSeez3D scanning software and 3D avatar creation technology, please visit www.itseez3d.com and www.avatarsdk.com.

      View full story
  • Advertisement