Author Topic: Export painted project as FBX  (Read 269 times)

Maybe I'm missing something.
Maybe this is a stupid question/request.
(Feel free to inform me either way.)

Can Painter export your project to an FBX file?
- If yes, I'm missing something obvious, so how?
- If no, then my request is to be able to do that.

I have an application that can easily import an FBX file, so it's already painted.  I don't need to go through the arduous task of loading texture after texture after texture.  It seems like it would be very convenient to simply export my Painter project to an FBX file which I could then easily import into another application.

I can understand not being constrained to that as your only export option. If it really is not a feature, is there some compelling reason for it to be exclude? 


For educational purposes, could a "real user" add a note or two?  Something like one of these:
a) Great idea, I would love it and I fully support it
b) Bad or useless idea, because ______________
c) Attractive idea, but technically improbable because ____________


My target application is usually iClone (a 3D animation application that supports Substances and PBR).

I did a little bit of testing, and with (almost) literally two clicks I can import an FBX file via their import/export tool and send it to iClone as a fully textured object.  It won't have smart Substances that way, but it sure is a lot more convenient than having to connect the various textures to their correct channels.  Import to 3DXchange, export to iClone.  Click click done.

I also tested importing into Blender, and though it took a minor effort in Blender to made the texture appear, it did a decent job of using the textures that were inside the FBX file.  Very convenient.

So that is the backstory to this request.  Why not enable Painter to export an FBX that contains the mesh *and* the textures (at a resolution you specify during the export process)?

Last Edit: August 08, 2017, 05:59:38 pm

This doesn't really make a lot of sense in my opinion.  For starters, Painter does not export "smart substances" at all, just image files.  Secondly, there is a countless amount of renderers or workflows that people use those images in- that's why the export dialogue is so complex. There are many many ways those images can be interpreted by many many different types of render engines or real time (game) engines.
I am not 100% on the limitations of FBX files, but as far as I know, they can only hold basic material info in them. I can export a basic standard material from Maya with basic colors and textures in it, but I can't export a custom RenderMan shader in Maya with all sorts of custom options within my FBX export. Basically, all that shader info is lost. Yet Painter can export images that work flawlessly with the latest renderman, vray, arnold, etc, etc.

So I can only imagine it would be pointless to have an FBX export option just so the 3-4 images you create in painter are plugged into the corresponding channels, and trying to figure out the bazillion different shaders people MIGHT use in their renderer of choice and prepare for that in Painter.  Just so you can save the few clicks of grabbing a diffuse/rough/metalness and plugin into those channels on your own.
Not to mention the  FBX format itself wouldn't even support most of those shaders anyway.

Probably more useful and cooler is what they are already doing with the "live link" feature to game engines in the latest release (currently only with unity I believe). I doubt we will see this feature in most or any regular render engines, but game artists must be excited about it. Can't wait of the unreal live link plugin myself!

I mean don't get me wrong, it would be cool having an awesome one click "link" option ala GoZ (in zbrush) but I don't think you'll see that through FBX. Maybe the "live link" update will eventually get there, but I wouldn't hold my breath unless it's for a game engine!
Last Edit: August 08, 2017, 11:34:30 pm

Thank you for the feedback.  That is very much what I was looking for.

It is exactly because Painter exports "just image files" that I thought the idea maybe had some value.  Simply embedding those images in the FBX file (properly tagged) didn't sound too complicated.

I understand it is merely a "convenience" request, but if you have lots of texture sets, it can be quite a bit more than just three or four images to plug in.  It's not a Herculean effort, but the ability to do a one-step load seemed attractive.

My understanding is OBJ files are the limited ones, basically holding only the mesh, I think.  The FBX format is much more flexible, being able to hold rigging and even animation data, but not everyone adheres to universal, rigid standards.  But for embedding the texture outputs from Painter, it seemed like a good format to target.

Thanks again for the thoughtful feedback.  I love "educational" discussions like this, and if anyone else would like to add to this thread (with questions or comments), please do.

Did you know that if you have a lot of texture sets as UDIMS you can import all your UDIM images as a sequence? so that if you have diffuse.1001, diffuse.1002, etc they can all be imported as diffuse and plugged in that way? This is the standard udim workflow in most 3d packages.
That might save you some time if you are having trouble importing a whole lot of texture sets. So essentially you only need one UDIM "sequence" per channel. (of course that depends on your materials, etc)

And you are correct that FBX can save a whole lot of animation, camera, scenes info but when it comes to shaders it's more limited.
It would be nice if painter handled 3d scenes better, like also being able to import meshes after you started working on a project and saving your entire scene with different materials in it. But I think the reason why it doesn't is because of it's completely non-destructive workflow and it's ability to reproject your brushstrokes (and being resolution independent).
So they probably need to do some serious re-writing for something like that.

I've never used UDIMS yet, but I do read a lot of threads about them here (and that is 95% of my knowledge about them).

Back to my feature request ("question"), it's looking like it probably doesn't have much value.  It was one of those things that occurred to me, and seemed so basic (and potentially convenient) that it made me curious why Painter doesn't already do it.

I've had other "dumb questions" find their way into products before.  In fact, I was struggling with translucency and refraction in Iray (with Painter), discovered my model was physically huge, and that lead to them adding a "size" display in Painter.  The data was already there, they just never thought to display it for the user.  So you just never know if something simple and "obvious" merely needs to be brought to the developer's attention, or if there is a good reason for it not being in the product already.  In this case, it may not offer the value I thought it would, and I can live with that.

UDIMS, yeah, I should play with them some time, if for no other reason that to expand my education.

Hey man I'm not a developer, just a guy with an opinion! So maybe they will like the idea regardless.

Hey man I'm not a developer, just a guy with an opinion! So maybe they will like the idea regardless.

At least you are rational and articulate while expressing your opinion, which can be a rarity on some forums.  (Not here, though.  Lots of high-quality members, truly.)

Some "technical reasons" not to have Painter export to FBX...

I was reading the brand new request about GLTF support here:,18579.0.html

Quoting from this page:

One would assume (given its popularity) that FBX is pretty much the industry standard... except there isn't any standard published by Autodesk about it.

FBX is used via the FBX SDK, which has a very restrictive license. This license makes it very hard to use in open source projects (an EULA must be accepted by the user unless a special license is purchased from Autodesk).

Besides the legal issues, implementing the library is rather difficult and suffers many of the same format ambiguity issues Collada does. One could argue, though, that the main technical advantage about it (besides working with the most popular 3D modelling applications) is that the file format is binary, so parsing it is fast.

That said, as an industry, we should look for true standards to work with. As useful as FBX may be, Autodesk alone controls its future.