FBX export in V6 doesn’t seem to work.
A made a simple cube with a texture and exported as FBX.
When I open this FBX in Rhino V5, I get absolutely nothing, and if I try to re-import it in V6, I can see the cube but the texture is gone.
I thought that FBX export now supported texture embedding, but that still seems to be science-fiction.
Ha! I think all saved views should be saved as cameras with a normal FBX save. I do not think including them when ‘geometry only’ is checked makes sense, since that should truly mean ‘geometry only’.
More importantly we should also address what happens with cameras already in an FBX when that FBX is imported. They should be imported as namedviews. if existing namedview are already in the file with same name, they should also be imported, but with an appended name.
while working on a crossplatform tool which requires to export as fbx in Rhino 6 and 7, i’ve stumbled over some of the already reported issues when exporting objects with material assignments from Rhino 6 (Windows).
For example, when i roundtrip an export (Rhino 6, Windows), emaps applied to the material are baked into color textures and saved in a temp folder with cryptic names if the material was of type Custom. All texture transforms are ignored.
Since the Rhino fbx exporter is a PlugIn, is there a chance these issues are fixed detached from a Service Release for legacy Rhino versions ? I mean, an option to just ignore materials or textures alltogether would be better compared to messing things up as it currently does.
It is indeed a plug-in, but currently distributed only as part of the main product. At present having it separate from the main installer hasn’t been discussed as far as I know, but maybe we want to move more of our plug-ins to yak. @will, @stevebaer, what do you think?
This would be change for changes sake at the moment. Eventually it may make sense to break down our distribution with discoverable and downloadable components, but that is not really the case just yet.
One issue that jumps out is that our open and save dialogs don’t know about formats that are not installed, but available via the package manager. For the majority of users who wouldn’t think to go to the package manager, they would think we dropped a feature. I know there are ways to solve this, but we don’t have it solved with the current shipping Rhino.
i understand doing distributions for legacy PlugIns could be a problem. The issue i reported above (unusable fbx export) applies not only to legacy Rhino 6, it is the case with Rhino 7 (Win and Mac) that material textures at least partially fail to roundtrip.
Why assigned emaps are getting “baked” as uv maps and are assigned as color texture at all ? Why are all mapping transforms eg. repeat values resetted ?
Would it help if i send you a rather simple example file to repeat the problem via pm or are you aware of these issues ?
If there is no way to improve the exporter, would it be possible to add a checkbox to just ignore materials and/or textures ? If i use the Exporter, when the prompt comes up for the filename, there is a checkbox “textures”. Unfortunately it’s check state is ignored, textures are exported even when the checkbox is OFF. It seems all the options in the save file dialog are the ones for writing 3dm files which is confusing for new users. Are you aware of this ?
_
c.
I’ll have to leave the answers to those questions to @nathanletwory and @tim as they actually work on FBX I/O. I don’t know enough about FBX to really comment.