Export painted project as FBX

[justaviking]

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? 

Thanks.

[justaviking]

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 ____________



MORE BACKGROUND AND INFO:

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)?

[o.chabrand89]

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!

[justaviking]

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.

[o.chabrand89]

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.

[justaviking]

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.

[o.chabrand89]

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

[justaviking]

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.)

[justaviking]

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

I was reading the brand new request about GLTF support here:
https://forum.allegorithmic.com/index.php/topic,18579.0.html


Quoting from this page:  https://godotengine.org/article/we-should-all-use-gltf-20-export-3d-assets-game-engines

FBX

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.

[xCyborg]

This is so frustrating, first there is still no way to merge all the different sets into one at export, and to make matters worse all the mesh export options in Painter (dae, obj and gltf which is broken) export only the mesh with no texture info.
How is this logic in a painting app?
Now I have to go to Photoshop and import the UV layout and try to stitch all the different sets for each map.
Then go to my DCC to link all the maps together with the mesh.
Those are things that could easily be done in Painter (either in FBX or glTF) and simple script for sets merge, you should have thought about that before implementing cutting edge stuff like the quasi useless physics painter... very basic stuff missing.

[o.chabrand89]

This is so frustrating, first there is still no way to merge all the different sets into one at export, and to make matters worse all the mesh export options in Painter (dae, obj and gltf which is broken) export only the mesh with no texture info.
How is this logic in a painting app?
Now I have to go to Photoshop and import the UV layout and try to stitch all the different sets for each map.
Then go to my DCC to link all the maps together with the mesh.
Those are things that could easily be done in Painter (either in FBX or glTF) and simple script for sets merge, you should have thought about that before implementing cutting edge stuff like the quasi useless physics painter... very basic stuff missing.

Why are you not simply making it so that each uv set in painter already uses (and exports) the full map? I understand if you are NOT working with UDIM workflow you may want to export a mesh with materials assigned (thus breaking up your model in many UVSets) but if you are merging the textures into a single UV space that seems redundant. Why not just assign a material per uv set (uv tile, or basically each full image output space, or just a single material for the whole model basically)
You can bake material IDs using a separate "high res" mesh with the different materials in them and bake  from that.
It sounds like your issue could be resolved not by painter exporting a different mesh but by you importing the mesh differently into painter

[xCyborg]

Nice try to dodge the real issue, what if my 3D app doesn't support UDIMs or if ID maps are not an options?
What if I want a single texture space for all of my model? when did that become so radical of a request?
And what about FBX or glTF with texture export?
The issue is Painter CANNOT export a mesh with the texture info that you see in its 2D UV view, you can't even export what you see.

[o.chabrand89]

Nice try to dodge the real issue, what if my 3D app doesn't support UDIMs or if ID maps are not an options?
What if I want a single texture space for all of my model? when did that become so radical of a request?
And what about FBX or glTF with texture export?
The issue is Painter CANNOT export a mesh with the texture info that you see in its 2D UV view, you can't even export what you see.

Sorry, I must be missing something. But I did not suggest you have to use UDIMS or ID maps. But my questions is why can't you make your model use a single texture space already? Painter is certainly capable of that. I always set up my models so that the texture set uses all the UV space. So I never do any manual stitching, and that's not in UDIM models.
You said (I think in a different post) that you have 20 texture sets per UV tile... My question is why do you need to do this?  is it just a visibility issue- so you can hide and unhide parts of the mesh?
Like I mentioned before, if you export your model with a single material assigned then it will all go into a single texture set. If you have multiple texture sets per model, but all are in UV space 0,1 Then you can assign a material for every desired texture image (UV space 0,1). This way Painter will export the full texture space with everything in it.
You really don't have to separate meshes per material in Painter (if that's what you are doing) since using PBR you are perfectly capable of texturing a whole range of materials (leather, metal, etc) using the same maps and same shader.
So if you are separating your metals into one texture set, and your leathers into another (even though they share UV space 0,1) well I am trying to tell you you don't have to. Separating materials in Painter is as simple as putting them in their own folder.
It just sounds like a classic mistake I see people do all the time which is just not setting up your mesh to work with painter properly when importing into Painter. Most people just grab whatever mesh and throw it into painter expecting it to be fine but in reality, there is some setup required for complicated models. Especially how you assign materials in your mesh, Painter will read these tags and assign a texture set per material. Sometimes you don't actually want this. So you just assign a single material or a few temporary materials for every desired texture space.