1
$\begingroup$

I am using a 3D scanning app that can export to the following formats:

  • FBX - Supported by most 3D software and game engines
  • OBJ - Text-based 3D model format
  • GLB - Open 3D format for the web (binary GLTF)
  • USDZ - Best for ARKit and sharing to iPhones
  • STL - Stereolithography file
  • PLY - High-density color point cloud
  • LAS - Georeferenced color point cloud

From the standpoint of an artist planning to work with the scanned models in Blender, what are the minimum formats to export to, to avoid wasting storage space, but also to avoid throwing away any relevant data destructively?

Because if I can generate a GLB later from an OBJ (for example), then there is no need to export a separate GLB. Get my logic?

Furthermore, I will be cleaning up the mesh data in Blender after scanning. By cleaning up, I mean deleting geometry from background objects that happened to get captured, and fixing non-manifold geometry when necessary. Of course this type of work takes time, so I don't want to have to repeat it.

When working with formats besides .blend, I usually have done so in .obj or .stl (and a little bit of .glb) So I am in not familiar with every single file type listed, or how much feature overlap there is between them.

As for color point clouds, I can't imagine many situations in which I would need the raw color point cloud data. For this reason, I think I can scratch .ply and .las off the list of formats to export to. I do need to keep the color texture data, which I believe is initially generated from the color point clouds.

From what I gather, the app's native data is stored in some proprietary format or combination of formats, only usable in that form by the app itself. And I don't think there is an option to archive the app's original data and load it back into the app later. Besides, even if that were possible, there is still the aforementioned issue of not wanting to have to clean up the mesh data more than once.

The reason for needing to delete the original (native format) scan data is simply storage constraints. A single scan typically ranges more or less from 100MB to 2GB, depending on the detail and size of the subject.

So of the listed formats, is there one that could be considered for use as a "master format" from which the others can be derived (re-generated by exporting)? The 3D data will be primarily for rendering and animation work, and in that sense the ultimate destination format will be .blend, but of course I want that file to contain as much of the original scan data as possible (while still practical). 3D printing work (if any) would be an afterthought, not the main purpose. With this sort of use case in mind, which format(s) should I be sure to export to before deleting the native scan data within the app to free up space? Thanks.

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ From my different explorations of the subjects over the past few months I have elected on always using glb / gltf. It's a de facto import/export format from sketchfab, and it imports / exports really well from Blender. That was the format that gave me the most satisfying results on file size, texture fidelity, vertex colors and geometry preservation. However I don't think it's possible to canonically answer this question, it's all a matter of preference and really depends on your input data and your end goal. $\endgroup$
    – Gorgious
    Commented May 4, 2023 at 11:10
  • 1
    $\begingroup$ I can just confidently say as you pointed out that any point cloud format like e57, point cloud ply and las will lose you information if you have already converted your scan to a mesh. All the other formats have their pros and cons, but that's like asking if svg, dxf, dwg, png or exr is better. It depends on your usecase, the price you want to pay for vendor specific software, the time you have on your hand to tweak it, if you're going to be rendering the item from up close or in the background, in a AAA movie or in a mobile game app, etc. $\endgroup$
    – Gorgious
    Commented May 4, 2023 at 11:11
  • $\begingroup$ @Gorgious Thank you for sharing your thoughts and a link to your explorations. I get what you mean, that a canonical answer may not be possible, and that the best file format comes down to the use case. That's why I tried to frame the question in within the context of use within Blender - although there are admittedly many ways one can use 3D data within Blender. Nonetheless, studying what others are doing, and coming to understand the logic in their decision-making that lead them to a certain format or workflow - is helpful. I could accept an answer comparing the various formats' strengths. $\endgroup$
    – Mentalist
    Commented May 4, 2023 at 18:17
  • $\begingroup$ One point I noticed, with regard to workflow, is that USDZ is the only one of these formats that macOS Quick Look can display including a model's color textures. OBJ and displays as white with shading. STL displays as a solid white silhouette with no shading (pretty useless). And the others presently do not render in Quick Look at all. (Unless there in some 3rd-party Quick Look plugin to enable it that I'm unaware of - haven't explored that far.) So this might be one reason to include USDZ in the exported file formats, if the ability to quickly preview the files is desired. $\endgroup$
    – Mentalist
    Commented May 6, 2023 at 4:20
  • $\begingroup$ Update: I found that a .ply file generated from another app could be previewed in Quick Look (as a color point cloud), so some of this may depend on how the files are generated and whether they include the data necessary for previewing. $\endgroup$
    – Mentalist
    Commented May 6, 2023 at 11:56

2 Answers 2

Reset to default
2
$\begingroup$

From my experience, I can give sort out some formats:

  • OBJ - is a standard de facto. You should have no problems in using it with Blender and other apps
  • GLB - is usually a good choose, but not so widely supported as OBJ
  • USDZ - added in Blender recently, so it is kind of risky
  • FBX - you may face some problems due to proprietary origin of this format. Blender supports only binary FBX.
  • PLY, STL (and should be LAS also) - Can't store texture information, only geometry.

So try this formats in this order.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks :-) Can you please elaborate more on this point: "FBX - you may face some problems due to proprietary origin of this format. Blender supports only binary FBX." $\endgroup$
    – Mentalist
    Commented May 6, 2023 at 2:49
  • $\begingroup$ As I am reading up more on this issue, it seems that when a 3D modeling application is the destination, both FBX and OBJ are among the top choices, with FBX supporting the inclusion of more types of scene data. Here's a short reddit threat about it. (Not that reddit is an authoritative source, but the points brought up in the thread are worth noting.) $\endgroup$
    – Mentalist
    Commented May 6, 2023 at 2:55
  • $\begingroup$ I'm not expert but I think obj openly only supports ASCII file format, not binary so if you're short on disk space I wouldn't choose it. From fileformat.info/format/wavefrontobj/egff.htm "The binary format is proprietary and undocumented, so only the ASCII format is described here. " $\endgroup$
    – Gorgious
    Commented May 6, 2023 at 8:51
  • $\begingroup$ @Mentalist The .fbx ASCII format has been removed in Blender 2.8 projects.blender.org/blender/blender/issues/53877 $\endgroup$
    – Crantisz
    Commented May 6, 2023 at 20:14
  • $\begingroup$ @Crantisz Thanks for that tip. It appears a converter can be used to get MA (Maya ASCII) into MB (Maya Binary). Details here. And in case that page goes down, here's a direct link to the Autodesk FBX Converter DL page. But it looks like it's no longer being maintained. $\endgroup$
    – Mentalist
    Commented May 7, 2023 at 2:51
0
$\begingroup$

First, thanks to Crantisz, whose answer set me off on the right foot. (Consider upvoting that answer also if you like this one.)

Now, having used these formats a little more since I first posted, I have narrowed it down to 2 that have proven to be the most useful for me. I will share:

  • OBJ - In my tests, texture colors appear most vividly and fully when imported from OBJ. I don't know why, but if someone can explain, comments are welcome. This format is easy to import, yielding good results. If you're only going to capture in one format, OBJ is it.
  • USDZ - While not directly useful in Blender, depending on your hardware it can be very helpful for workflow in 2 ways: for Mac users, Finder's Quick Look (spacebar) can be used to quickly preview .usdz files. So even if you only use .obj to work from, by keeping a corresponding .usdz of the same name for each of your scans you can save a ton of time when browsing through a long list of scan data. The second way USDZ is useful is if sharing to an iPhone or other device that supports it. (USDZ can be sent through AirDrop and iMessage.) For example, sharing a .usdz file is a convenient way to get feedback on a scan before starting to work with the OBJ version in Blender.

Anyone who has found additional use cases for formats in the list, please share your findings.

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .