Ah, I see. It's now on the developer to handle writing the output file with assistance from the helper methods. It's more work than I thought it would be, especially after seeing the FBXExportOptions class. That's fine. I'm pretty new to the Revit API, but not to related tools, so thanks for the insight.
Just so I understand the current API a bit better, is this statement true? In Unity and several other apps, you can export a scene/view/etc to an FBX in a couple lines:
That used to be the case in the Revit API:
But FBXExportOptions is obsolete, so people now use CustomExporter. The flip side is that this class doesn't understand the output specifics of particular file types, so the developer has to handle that themselves. Löbel's export approach is much more code than using filetype-specific exporters. In short, the Revit API moved away from filetype-specific exporters. The developers now need to understand the specs of the file type to export to. Is that a correct understanding? It's fine if so. It's just a lot more code that I would have thought.
I can see the flexibility in that file-agnostic approach. I can export exactly how I want without being limited to the configuration of the method params. But for this tool, I'd take the old FBXExportOptions or Unity-style approach to FBX-specific exporters if that's available in the current Revit API (with materials working).