Unity preferred file format?

I know Unity reads pretty much every mesh format in the book, but is there one in particular that it likes most? Something that seems to work great every time? Maya, Collada, obj files...
Can someone please enlighten me as to Unity's default file preference?

Thanks.

Mark

 

Very 'Aras' response, so thanks for that ;-)

I guess my question would really be "which file format most closely approximates Unity's optimized internal format and is least likely to express unwanted results upon import?"

It sounds like the answer is Maya ( since Maya is native)? Does that mean that assets are converted to Maya upon import? Is that about right or am I a mouth-breathing idiot (entirely possible if not outright likely)?

Thanks, especially to Aras for your swift response. Seriously.

Mark

 

Nope, and nope...there isn't any single right answer. Maya is one answer, but so is Blender, and Cheetah 3D (I gather; haven't actually used it).

--Eric

 

Ive used Maya and Unity together, but cheetahs got to be my fav. Its slicker and as far as I can see, full-featured, with lightmapping, character animation and native file support.

"Just works"

It splits your animations up automagically which Maya doesnt seem to do (Though I dont know all the ins and outs of Mayas character sets)

I would guess for bigger scenes with heaps of objects Maya might work better, but for individualised asset creation, Cheetahs fantastic.

My understanding is that they all get converted to fbx internally, yes?

AC

 

As Aras said, "All file formats are converted into internal optimized representation by Unity." FBX is a text-based format and is FAR from optimized. Rather, it's made more for flexibility. Take a look at a simple cube exported as FBX; it's like 64K.

--Eric

 

So, what IS that internally optimized representation? Is it a Unity specific format or is it based on a more familiar format?

I really do have a reason for asking, it's not just curiosity ;-)



M

 

I imagine that it's some kind of Unity-specific binary format. Anything used with other 3D apps is going to be designed with at least a certain amount of flexibility and portability in mind. That stuff adds overhead that's unnecessary in Unity, since end-users never even see the Unity 3D files.

Do tell.

--Eric

 

That would be giving it away. ;-)

M

 

Aras and the other powers that be, can you give us any more information on this topic or is that something that would compromise the integrity of the "Unity Advantage" (something none of us want, to be sure).

If you can provide a bit more clarity without giving away the store, I'd appreciate it.

Thanks.

M

 

It seems that the docs that you mention above are not entirely in sync with the Unity3d marketing material (see table at bottom of page). For example, from the docs it looks like Unity3d may not support Cheetah3D's bone-based animations, but the marketing suggests that it does. Also Modo 201 is mentioned in the docs, but not in the marketing. Is Modo 301 supported? Are animations in Modo 301 supported? It would be nice to see these documents brought in sync with each other.

 

Interesting, Aras.

So am I correct in surmising that

" For most scenarios, native importing works perfectly (internally it exports to FBX or Collada in the background), "

meaning fbx and collada are the nearest approximations to the optimized internal format? I have to admit I don't really understand the technical differences between the formats so my questions may seem uneducated (it's because they are).

I'm really just trying to find a way of creating assets that will be the most reliable and predictable upon import. Things that will work "first time, every time" and if there is a way of assuring that through using a format that needs the least optimization internally.

Thanks for the information, everyone.

Mark

 

Interesting. So the Unity importer culls the information it finds useless (using the fbx example of viewport config, etc.) and creates it's 'optimized' internal format? That makes perfect sense, of course, for the web player in particular.

Have you ever considered creating a simple application that can manipulate 3D data in the optimized format you use internally? I realize it would probably be used only for creating Unity assets, but who cares about anything but Unity anyway, right? )

Nicely done, Aras. Thanks for the clear and lucid explanation.

Mark

 

Since everything ends up in that format anyway, there's no point to something like this.

--Eric

 

Why not? Blender (to me) is really frustrating to use and everything else costs the end user money. I use C4D which is great for me, but if Unity is going to be adopted on a large scale, why not have something like that? Simple, free and bundled. A turnkey solution.

Besides, as Aras pointed out, not all formats behave predictably on import (missing features, etc.) I think he used 3DSMax as an example?

You guys got Unitron for scripting why can't we get a "Unitool" for this? Huh?!?

Oooh. "Unitool"... I like it! ;-)

Mark

 

Because UT doesn't have unlimited resources, and I'm pretty sure they'd much rather spend their time on Unity instead of making Yet Another 3D App, which would take an enormous amount of effort and just end up duplicating what's already out there. Consider also that quite a lot of Unity users don't do any modeling at all, so this would jack up the price of Unity for no good reason. And if you start including a 3D app, then logically you'd have to include a Photoshop clone, a sound editor, and so on.

No, it's FAR better just to let the user pick which 3D app he'd like to use.

Max isn't even a Mac application. Blender, Maya, Cheetah3D, etc. all work perfectly fine. I have to admit I can't figure out what your concern really is.

--Eric

 

Eric,
first of all, I'm really not trying to be contentious nor am I trying to waste Unity's resources. Still, I have my reasons for 'suggesting' something like that (not actually requesting it, mind you) but that's neither here nor there.

I don't actually believe that a Photoshop clone nor a sound editor are necessary additions (although to be honest, a true turnkey solution like that would absolutely justify extra cost to pretty much anyone) nor do I agree that a lot of Unity users don't model at all. I see a lot of call for coders in the forums, so I can only assume that there are users that model but not code. Make sense to me, anyway, probably because I do audio and not really either at least not well.

As for Studio Max, while it's not a Mac app it is the arguably the de-facto standard for game content creation in the PC world (the dominant platform for game creation) and as Unity hopes to have a PC port eventually the issue will likely raise it's head again somewhere down the line.

At any rate, I don't really think it's worth an argument. I am not a fan of things unnecessary and I think we agree on that. I am not concerned about Unity of it's functionality in the least. I love it and I use it.

It was just a thought, nothing more. 'Nuff said.

Regards,

Mark

 

Well, if you want in integrated modeler so bad, why don't you wrangle up some community minded programmers and make one in an editor script? I think this wouldn't even be that hard, to just get simple tools working.

 

(sigh)

Seriously, everyone, I'm not pushing for an integrated modeler. Really.

All I said was, "Have you ever considered creating a simple application that can manipulate 3D data in the optimized format you use internally?"

This all sprung from my curiosity at how models are imported into Unity and what the closest available format to that would be. If it uses a format that throws out unnecessary data points, maybe somewhere down the road the mother ship had considered putting something together that doesn't have to do that and writes the optimized files itself. Not unlike the very useful Unitron.

I have no doubt that it's my ignorance talking (since I don't program), and I have no idea what would actually be involved in doing this so forget I said anything. If someone wants to take it on, I'm game, but I certainly won't be able to contribute anything other than testing.

Tell you what, though. If I hit lotto or my current venture becomes really profitable, I'll spring for it myself. Modeler, texturer and sample editor. Maybe I'll even throw in a midi editor to boot. AND Unitree. How about that?

Any other feature requests the community thinks I should consider, now would be the time ;-)

Thanks to all for your useful information. Really. I've learned a bunch of good stuff.

Mark

 

Just FYI, Unitron is based on an open-sourced text-editor called smultron, so UT didn't have to put to much time into developing it

 

I think there's still some misunderstanding here. There is no "closest available format", and there's no point in an app that manipulates data in the internal optimized format, because all 3D files end up in this format anyway. The italics is just to emphasize; I'm not yelling or anything. There is literally no difference in a model made with, say, Maya, and a model made with this hypothetical app, once it's imported.

Moreover, I believe the only three formats that Unity actually reads are .fbx, .dae, and .obj. Everything else (Maya, Blender, etc.) are actually .fbx files accomplished by opening your 3D app in the background and silently exporting.

Skipping over the unnecessary stuff is basically irrelevant. Once it's imported, it's all the same, as I mentioned. So the only possible benefit would be maybe saving a few seconds when importing large models, but really, how often do you import 3D files?

Yeah, to extend what Jedd said, the equivalent would be essentially UT putting a "Uniblender" logo on Blender and bundling that. It's already about as tightly integrated with Unity as it can get anyway, so it would require even less effort than Unitron.

--Eric