Comprehensive Guide To 3D File Formats

3DM File Format Details

Overview

The 3DM file format is the native file format developed by Robert McNeel & Associates for Rhinoceros 3D. It is widely utilized for exchanging precise 3D model data, particularly NURBS geometry, across CAD, CAM, CAE, and computer graphics software.

What It Stores

It primarily stores precise NURBS (Non-Uniform Rational B-Splines) curves and surfaces, analytical shapes, and polygon mesh data. Additionally, it can contain model organization data such as layers, object names, materials, lighting, annotations, dimensions, and custom user data.

Primary Use Cases

• Industrial and product design modeling.
• Architectural concept development and BIM integration.
• Marine design and aerospace engineering documentation.
• Exchanging precise geometry between CAD systems via the openNURBS initiative.

Strengths

• High precision for complex curved geometry and mathematical surfaces.
• The openNURBS toolkit supports third-party reading and writing of Rhino 3DM files without licensing restrictions.
• Comprehensive data preservation, including layers, object naming, and technical dimensions.

Limitations

• Large file sizes when embedding high-density polygon meshes.
• Not natively optimized for real-time game engines without optimization or mesh conversion.

Common Software Support

Supported natively by Rhinoceros 3D. The openNURBS toolkit allows third-party applications to read and write Rhino 3DM files, and 3DM import/export support varies across CAD, DCC, and visualization workflows depending on application version, plug-in, or translator support.

3DS File Format Details

Overview

The .3DS format is a legacy 3D file format originally created for Autodesk's 3D Studio DOS. Although superseded by the .MAX format as the native scene format, it is still supported and used as an interchange format for low polygon models in various 3D applications.

What It Stores

It stores mesh geometry (limited to triangles), vertex positions, UV mapping coordinates, material definitions, and basic keyframe animation data. It does not support complex rigging or modern PBR materials.

Primary Use Cases

• Exchanging static models and scenes between legacy 3D software.
• Distributing assets on online 3D marketplaces.
• Storing low-poly assets for older game engines.

Strengths

• Broad compatibility across many legacy and modern 3D applications.
• Lightweight file sizes due to its binary structure.
• Straightforward geometry data that is easy to parse.

Limitations

• Limited to 65,536 vertices and faces per mesh.
• Texture filenames are limited to DOS-style 8.3 filenames.
• Object, light, and camera names are limited to 10 characters.

Common Software Support

Historically associated with Autodesk 3D Studio DOS and supported by Autodesk 3ds Max for import and export. It became widely used as an interchange format for transferring models between 3D programs, although current support varies by application and version.

ABC File Format Details

Overview

The Alembic (ABC) format is an open-source interchange file used extensively in high-end visual effects and animation. It was developed to facilitate the efficient exchange of complex 3D data between different software platforms.

What It Stores

Alembic distills complex animated scenes into baked geometric results. It stores baked mesh data, point clouds, particles, curves, and camera information, but typically does not preserve most material data, lighting, and rigging logic.

Primary Use Cases

• Transferring complex simulations from Houdini to Maya or 3ds Max.
• Exchanging character animations between studios.
• Archiving production-ready geometric data.
• Facilitating collaborative pipelines across different applications.

Strengths

• Highly efficient at handling massive datasets.
• Platform-independent, supporting consistent geometric playback across applications.
• Supports non-uniform topology and high-density vertex animation.

Limitations

• Large file sizes due to baked data.
• Does not store full shader networks, lighting setups, or skeletal rigs, though it may include basic material assignments and UV data.

Common Software Support

Widely supported in Autodesk Maya, 3ds Max, SideFX Houdini, Cinema 4D, and Unreal Engine.

AEP File Format Details

Overview

Developed by Adobe, AEP (After Effects Project) is the native file format for Adobe After Effects. It is an industry standard for saving motion graphics, visual effects, and compositing projects across film, television, and web production workflows.

What It Stores

An AEP file stores project metadata, timeline structures, layer configurations, keyframe animation data, expressions, and effects parameters. It does not embed actual video or audio media, instead storing paths to link external footage assets.

Primary Use Cases

• Managing motion graphics templates and lower thirds.
• Compositing multi-layer visual effects shots.
• Coordinating complex keyframe and expression-based animations.
• Exchanging dynamic templates via Adobe Dynamic Link.

Strengths

• Retains non-destructive editing workflows.
• Deep integration with Adobe Creative Cloud applications.
• Precise control over complex keyframe interpolation and expressions.

Limitations

• Susceptible to broken links if asset directories change.
• Not backward compatible with older After Effects versions.

Common Software Support

Primarily supported by Adobe After Effects. It integrates with Adobe Premiere Pro and Media Encoder via Dynamic Link, and Maxon Cinema 4D via Cineware.

ASS File Format Details

Overview

Arnold Scene Source (ASS) is a proprietary, high-level format used by the Arnold renderer to store entire 3D scenes. It serves as a renderer-specific scene description format that allows different DCC tools using Arnold to pass data to the Arnold engine.

What It Stores

These files contain comprehensive scene data including geometry, lighting, camera settings, and shader networks. They can store procedural stand-in definitions, while animation is typically represented as sequences of .ass files rather than embedded timelines.

Primary Use Cases

• Rendering heavy production scenes via stand-ins.
• Transferring complex shaders between Arnold-compatible plugins.
• Distributing render tasks to farm nodes without opening the source software.

Strengths

• Native integration with Arnold's architecture.
• Supports massive datasets through procedural delayed loading.
• Human-readable text format option for debugging.

Limitations

• Specific to the Arnold renderer; not a general-purpose interchange.
• Can result in large file sizes for dense geometry.

Common Software Support

Supported by Arnold Standalone and Arnold plugins for major DCC applications, including Maya, 3ds Max, Houdini, Cinema 4D, and Katana.

AVT File Format Details

Overview

The AVT file format is a native format developed by CLO Virtual Fashion and used by CLO3D and Marvelous Designer for saving and loading avatar data.

What It Stores

AVT files store avatar-related data such as mesh/model information, skeleton rig data, sizing data, pose, motion, accessories, bounding volumes, and arrangement points. They also contain specialized metadata like arrangement bounding volumes, points, and default poses or motions.

Primary Use Cases

• Digital garment fitting and draping.
• Customizing human body measurements for virtual sizing.
• Consistent avatar handling within CLO workflows.
• Saving preset avatar poses and hair/accessory configurations.

Strengths

• Native integration with CLO3D and Marvelous Designer.
• Preserves avatar-related data such as sizing, poses, motions, bounding volumes, and arrangement points.
• Stores sizing data that can be used to adjust avatar proportions within CLO workflows.

Limitations

• Proprietary format with limited support in general-purpose 3D software.
• Motion or avatar interchange with other 3D tools may depend on external formats such as FBX or COLLADA rather than AVT alone.

Common Software Support

CLO3D, Marvelous Designer, and CLO-SET 3D Viewer.

BIP File Format Details

Overview

The .BIP format is an Autodesk Biped motion file used by Character Studio / Biped in 3ds Max. It is the standard format within 3ds Max for saving and loading animation data for Biped objects.

What It Stores

It stores comprehensive animation data, including keyframes, footsteps, and limb rotations for Biped hierarchies. It does not contain mesh geometry, textures, or rigging constraints outside of the specific Biped skeletal structure.

Primary Use Cases

• Storing motion capture (mocap) data for character animation.
• Transferring complex movement sequences between different 3ds Max scenes.
• Building animation libraries for reusable character behaviors.
• Managing Footstep based animation sequences within Character Studio.

Strengths

• Designed to store complete Biped motion data for reuse in 3ds Max.
• Seamless integration with the 3ds Max Biped system.
• Supports retargeting between Biped rigs, though results may require adjustment for differing proportions.
• Works with Biped's animation layering and Motion Mixer tools for non-destructive editing.

Limitations

• Proprietary and primarily supported within 3ds Max, with limited third-party support.
• Incompatible with standard Bone systems or custom rigs without conversion.

Common Software Support

Native creation and editing are exclusive to 3ds Max. Motion data can be exported to other engines via FBX conversion, but the raw .BIP remains local to 3ds Max.

BLEND File Format Details

Overview

The .BLEND file format is the native format used by Blender, an open-source 3D creation suite. It acts as a single project file that can store scenes, data blocks, and many production assets used by Blender.

What It Stores

It stores full scene hierarchies, polygonal geometry, animation data, rigging, materials, textures (when packed), physics configurations, compositing nodes, and custom UI layouts.

Primary Use Cases

• Full-scale 3D animation and modeling production within Blender.
• Archiving comprehensive scene data, including lighting and render settings.
• Direct asset linking and appending across local project files.

Strengths

• Comprehensive data retention saves project data in a single, organized file.
• Forward and backward compatibility layers generally handle software version disparities well.
• Can be highly compressed and lightweight compared to open interchange formats.

Limitations

• Limited native interoperability; requires conversion to export to other DCC tools or game engines.
• Prone to file bloat if external high-resolution textures are frequently packed.

Common Software Support

Primarily supported by Blender. Increasingly accommodated by secondary tools and engines like Unity and Godot via automated background FBX/GLTF conversion pipelines.

BR5 File Format Details

Overview

BR5 is a Bryce 5 scene file used for 3D landscape and environment projects. It stores Bryce scene data for 3D environments, including terrain, objects, and scene settings.

What It Stores

These files store 3D terrain data, object positions, and atmospheric settings like lighting, and other Bryce-specific settings. They may include Bryce-specific material, sky, and tree-related scene data, depending on the content saved in the scene.

Primary Use Cases

• Archiving complex fractal landscape projects.
• Sharing Bryce scene files that include environment and sky settings.
• Transferring scene assets into newer versions like Bryce 7.1.

Strengths

• Can store complex procedural terrain scenes in a compact project file.
• Able to retain Bryce-specific scene settings, including tree, sky, and lighting-related data.
• Compatible with later versions within the Bryce ecosystem.

Limitations

• Extremely limited support outside of Daz 3D/Corel Bryce software.
• Because BR5 is proprietary, it usually needs conversion to interchange formats compatible with modern engines.

Common Software Support

Primarily supported by Bryce 5 and later versions.

BR6 File Format Details

Overview

The BR6 file format is a Bryce 6 scene file format for saving 3D scenes and projects. It stores Bryce scene data such as terrain, lighting, and objects used in landscape-focused projects.

What It Stores

These files can store scene data such as terrain and heightfield data, sky, lighting, and material information used by Bryce.

Primary Use Cases

• Archiving complex 3D landscape projects within Bryce 6.
• Transferring environmental scene data between legacy Bryce installations.

Strengths

• Stores a complete Bryce scene, including lighting and other environmental settings in a single file.
• Designed to handle Bryce's terrain-focused scene workflows.
• Preserves scene structure used for editing Bryce projects.

Limitations

• Limited interoperability with modern industry-standard software like Blender or Maya.
• Proprietary nature makes it difficult to recover data without the original software.
• Does not support modern PBR (Physically Based Rendering) workflows.

Common Software Support

This format is natively supported by Bryce 6 and later versions. Bryce includes import support for a limited set of formats, but modern compatibility is limited.

BR7 File Format Details

Overview

The BR7 format is the native scene file type for Bryce 7, a 3D modeling and animation software specialized in fractal landscapes. Developed by DAZ 3D, it is used to save entire 3D environments, including terrain, skies, lighting, water, and other environmental elements.

What It Stores

It contains scene data such as terrain, objects, lighting, environmental settings, and some animation information.

Primary Use Cases

• Creating complex fractal-based digital landscapes.
• Archiving full 3D scene environments for re-editing.
• Generating photorealistic outdoor renders.

Strengths

• Saves detailed scene state, including environmental settings used in the Bryce scene.
• Handles Bryce scene data, including terrain and landscape elements generated within the application.
• Supports full animation timelines and material lab settings.

Limitations

• Proprietary Bryce scene format with limited interoperability outside Bryce and DAZ applications.
• Large file sizes for complex scenes.

Common Software Support

Primarily supported by Bryce 7 and Bryce 7 Pro.

BVH File Format Details

Overview

The Biovision Hierarchy (BVH) is a widely adopted format for storing motion capture data. Originally developed by Biovision, it is widely used for transferring skeletal animation between different 3D software and game engines.

What It Stores

BVH files contain a joint hierarchy with offsets and channels, followed by per-frame motion data. The root joint often includes 3 translation and 3 rotation channels, while non-root joints typically include only rotation channels, though the format itself permits other channel configurations.

Primary Use Cases

• Transferring motion capture data to 3D characters.
• Storing and exchanging skeletal animation sequences.
• Exchanging character movement between specialized mocap software and DCC tools.

Strengths

• Simple, human-readable ASCII text structure.
• Efficient and well-suited for representing skeletal movement without mesh data.
• Broad compatibility across major 3D animation suites.

Limitations

• Does not store geometry, materials, or skinning weights.
• Lack of standardized axis conventions can lead to rotation and orientation issues during import, and unit mismatches can also cause scale problems.

Common Software Support

Supported by Blender, Cinema 4D, and MotionBuilder.

C4D File Format Details

Overview

.C4D is the native file format for Maxon Cinema 4D, a leading software suite for 3D modeling, animation, and motion graphics. It is used to save complete 3D scenes, including models, animation, lighting, and other scene data.

What It Stores

It stores geometry, animation, lighting, cameras, materials, and full scene hierarchies. The format also preserves procedural systems native to Cinema 4D, including MoGraph setups, generators, deformers, and field-based workflows, along with rigging data and simulation or cache data where applicable. Support for certain cached or simulated elements may vary depending on the scene configuration and software version.

Primary Use Cases

• Broadcast motion graphics and television identity design.
• Visual effects (VFX) asset creation and motion design elements.
• Product visualization, advertising, and marketing content.
• Architectural visualization and rendering.
• Integration with Adobe After Effects via Cineware.

Strengths

• Preserves complex scene hierarchies and procedural workflows natively.
• Tight integration with Adobe After Effects through Cineware for motion graphics pipelines.
• Supports non-destructive workflows using generators, deformers, and layered scene structures.

Limitations

• Proprietary format with limited native compatibility outside the Cinema 4D ecosystem without conversion.
• Procedural setups may require baking or conversion when exported to other formats.
• Cross-application workflows often rely on interchange formats, which may not preserve full scene fidelity.

Common Software Support

Supported natively by Maxon Cinema 4D. Direct integration with Adobe After Effects is available via Cineware. For use in other applications such as Unreal Engine, content is typically exported using interchange formats like FBX, Alembic, or Datasmith.

CASC File Format Details

Overview

.CASC is the standard scene file format for Cascadeur, a standalone 3D animation software developed by Nekki. It is designed specifically for physics-based character animation within Cascadeur, allowing artists to save complex animations that incorporate the software's physics tools.

What It Stores

The format stores skeletal hierarchy, joint rotations, character rig data, and baked or keyframed animation sequences. It also stores physics-related data used internally by Cascadeur, such as center of mass calculations and motion balancing.

Primary Use Cases

• Storing character animation sequences as part of a game development workflow.
• Saving scenes that include physics-assisted action and stunt-style animations.
• Exporting animation data (typically via FBX or similar formats) to external DCC applications.

Strengths

• Retains native physics data and control rig behaviors.
• Optimized for seamless iteration inside Cascadeur.
• Preserves animation timing, transitions, and constraint behavior within Cascadeur.

Limitations

• Restricted ecosystem with limited direct support outside Cascadeur.

Common Software Support

Supported natively within Cascadeur. Export pipelines allow animation data to be transferred via FBX for integration into tools like Autodesk Maya, Blender, and game engines such as Unreal Engine and Unity.

CCAVATAR File Format Details

Overview

CCAVATAR is a 3D character format developed by Reallusion for its Character Creator (CC) ecosystem. It serves as a specialized container for highly detailed, animatable digital humans used in real-time applications.

What It Stores

The CCAvatar concept in Reallusion's ecosystem encapsulates body mesh topology, skeletal rigging, facial blend shapes, PBR-style materials, and texture references. For external tools, this data is typically exported via FBX plus associated texture maps and material definitions.

Primary Use Cases

• Exporting base characters for high-fidelity sculpting in external tools.
• Developing custom avatars for social VR platforms like VRChat.
• Transferring fully rigged assets into game engines like Unreal or Unity.
• Managing character presets within the Reallusion content library.

Strengths

• Optimized topology designed specifically for natural joint deformation.
• Unified bone structure compatible with standard motion capture data.
• Seamless integration with iClone's real-time animation pipelines.

Limitations

• Native editing is primarily limited to Reallusion software unless characters are exported to formats such as FBX.
• Requires specific plugins for full functionality in external DCC tools.

Common Software Support

Primarily supported by Character Creator and iClone. It is compatible with Unity, Unreal Engine, and Blender via Reallusion Auto Setup tools and plugins, which help transfer CCAvatar'based characters through standard FBX plus engine-specific assets.

CCPROJECT File Format Details

Overview

The CCPROJECT format is the primary project container used by Reallusion's Character Creator software. It serves as a comprehensive archive for storing 3D character design data, environment settings, and lighting configurations within a single workspace.

What It Stores

This format stores character-specific data including head and body morphs, skin textures, and clothing assets. It also retains scene information such as lighting setups, camera positions, and material parameters.

Primary Use Cases

• Saving work-in-progress character designs.
• Archiving high-fidelity 3D human models with morph, skin, clothing, props, and environment data.
• Exporting assets to iClone or game engines for animation.

Strengths

• Maintains non-destructive editing for all character parameters.
• Packages geometry and textures into a single, organized file.
• Seamlessly integrates with the Reallusion ecosystem for real-time rendering.

Limitations

• Proprietary format restricted primarily to Reallusion software.
• Does not support native playback in standard 2D animation or general-purpose 3D viewers.
• While it stores character data, users must export to FBX or OBJ for external engine compatibility.

Common Software Support

Character Creator and iClone are the primary applications supporting this format.

COA File Format Details

Overview

The .coa (Caligari Object ASCII) format is the plain-text version of trueSpace's .cob 3D object format. It stores static geometry, vertex, and material data in human-readable ASCII instead of a compiled binary structure.

What It Stores

The .coa (Caligari Object ASCII) format is the plain-text counterpart to TrueSpace's binary .cob file. It stores static 3D geometry—including vertices, polygon faces, and UV texture coordinates—along with basic material properties, all written in a human-readable text structure.

Primary Use Cases

• Bridging the interoperability gap between early 3D software applications lacking support for compiled binary formats.
• Allowing technical artists to open 3D models in standard text editors for manual debugging and data inspection.
• Serving as an accessible format for developers writing custom pipeline scripts and conversion utilities.

Strengths

• Human-readable text structure eliminates the need for specialized software to view the raw data.
• Highly accessible for programmers parsing 3D geometry without needing to reverse-engineer binary code.
• Immune to the cross-platform byte-order compatibility issues common in legacy binary formats.

Limitations

• Results in massively bloated file sizes due to storing floating-point math as plain text.
• Significantly slower for applications to parse and load, making it highly inefficient for complex or high-polygon meshes.

Common Software Support

Native support was largely restricted to Caligari TrueSpace and specialized 3D conversion suites of the era, such as Okino PolyTrans or Deep Exploration. Today, the format is entirely obsolete in modern digital content creation software, requiring community-written legacy plugins to import into programs like Blender.

Additional Notes

The .coa format is a relic of an era when proprietary 3D ecosystems were heavily siloed. Much like the enduring Wavefront .obj format, text-based object formats were a necessary, albeit inefficient, fallback to ensure 3D geometry could be transferred between competing software packages before modern open standards existed.

COB File Format Details

Overview

The .cob (Caligari Object) format is TrueSpace's proprietary 3D container. It stores static geometry—like vertices, faces, UV coordinates, and basic material properties—to define individual 3D assets.

What It Stores

The .cob (Caligari Object) format is TrueSpace's proprietary, compiled binary 3D container. It is used to store static 3D geometry, explicitly saving data such as vertices, polygon faces, UV texture coordinates, and basic material properties to define individual 3D assets.

Primary Use Cases

• Saving and loading individual, modular 3D assets quickly within the TrueSpace environment.
• Distributing and sharing standalone 3D models and props across the TrueSpace user community.
• Acting as the foundational geometric building blocks that are later assembled into larger scene (.scn) files.

Strengths

• The compiled binary structure results in highly compact file sizes compared to plain-text alternatives like .coa.
• Extremely fast read and write speeds when parsed by the native TrueSpace rendering and modeling engine.
• Preserves TrueSpace-specific material parameters, smoothing groups, and proprietary shading data accurately.

Limitations

• As a proprietary, closed-source format, it is notoriously difficult to reverse-engineer or open natively outside of the Caligari ecosystem.
• It is strictly a static object container and completely lacks the ability to store complex rigging, skinning, or keyframe animation data.

Common Software Support

Native support was strictly limited to Caligari TrueSpace and a few specialized, legacy 3D conversion suites like Okino PolyTrans or Deep Exploration. Today, the format is completely obsolete in modern digital content creation tools and requires specialized, community-built legacy plugins to import into software like Blender.

Additional Notes

The .cob format serves as a perfect example of legacy asset management, where 3D workflows relied on separating individual static assets from the master scene hierarchy. Artists would model static geometry as .cob files, but orchestrate, rig, animate, and render them within the overarching .scn container.

DAE File Format Details

Overview

The Digital Asset Exchange (DAE) format, also known as COLLADA, is an XML-based schema designed for seamless data transport between 3D software. Originally created by Sony Computer Entertainment and now managed by the Khronos Group, it serves as a bridge for complex assets across various production pipelines.

What It Stores

It stores comprehensive scene data, including polygonal geometry, UV maps, materials, and lighting. Crucially, it supports skeletal animation, skinning, and hierarchical scene structures, making it more robust than basic mesh formats.

Primary Use Cases

• Transferring animated characters between DCC tools.
• Importing assets into game engines like Godot or Unity.
• Exchanging complex scene data for architectural visualization.
• Archiving 3D assets in a human-readable, open-standard format.

Strengths

• Supports complex animations and rigging data.
• Open-standard, XML-based structure allows for manual editing.
• Historically widely supported, though modern workflows often favor FBX or glTF due to more consistent interoperability.
• Supports scene hierarchies and transformations, though accuracy depends on software implementation.

Limitations

• Large file sizes due to verbose XML text formatting.
• Often slower to parse than compact binary formats, though performance varies by implementation.
• Inconsistent implementation across different software versions.

Common Software Support

Widely supported by Blender, Autodesk Maya, 3ds Max, and Cinema 4D, though often with limitations and secondary to formats like FBX or glTF. It is also compatible with major game engines and CAD software, though support is often limited or being phased out.

DUF File Format Details

Overview

The .DUF (Daz User File) format is the native scene and asset configuration format developed by Daz 3D for its Daz Studio software. It serves as the primary standard for saving, loading, and exchanging content within the Daz ecosystem.

What It Stores

It stores comprehensive scene data, including character rigging, morph targets, posing data, camera setups, lighting configurations, and material definitions. It utilizes a JSON-based structure to reference external geometry and texture assets rather than embedding them directly.

Primary Use Cases

• Saving complete 3D scene layouts and environments.
• Distributing character presets, poses, and shaping morphs.
• Packaging clothing and hair assets for digital figures.
• Transferring complex asset configurations between Daz Studio users.

Strengths

• Highly optimized for complex character rigging and morph data.
• Human-readable JSON-based DSON structure, allowing for manual text editing or scripting.
• Efficient, lightweight file sizes due to external asset referencing.

Limitations

• Poor native compatibility with external 3D suites without specialized bridges.
• Dependency on absolute or relative asset paths, which can break material links.

Common Software Support

Daz Studio natively supports the format. Bridges and plugins exist to import .DUF content into Blender, Maya, Unreal Engine, and Unity.

DWG File Format Details

Overview

The DWG format is a proprietary binary file type used by Autodesk as the native format for AutoCAD and AutoCAD-based products. It is the industry standard for storing highly precise 2D and 3D design data, metadata, and technical drawings.

What It Stores

The format contains complex vector geometry, including lines, arcs, circles, and 3D solid modeling data. It also stores layer information, coordinate systems, and references to external attachments (Xrefs) or images.

Primary Use Cases

• Architectural blueprints and construction documentation.
• Mechanical engineering and part design.
• Civil engineering and mapping (GIS).
• 3D modeling for industrial design.

Strengths

• Extremely high precision for engineering tolerances.
• Small file size relative to the complexity of the data.
• Robust support for metadata and organizational layers.
• Universal recognition within the CAD and AEC industries.

Limitations

• Proprietary nature can lead to compatibility issues with non-Autodesk tools.
• Frequent version updates require conversion for older software.
• Complex internal structure makes it difficult for lightweight viewers to render fully.

Common Software Support

Primarily supported by Autodesk AutoCAD, Civil 3D, and Revit. It is also compatible with Rhino, SolidWorks, and various specialized CAD viewers like DWG TrueView.

DXF File Format Details

Overview

The Drawing Interchange Format (DXF) is an openly documented format, with published specifications, developed by Autodesk to enable interoperability between AutoCAD and other software. It is a widely used de facto interchange format for 2D CAD drawings and some 3D data across engineering and design software.

What It Stores

DXF files primarily store vector-based information, including points, lines, arcs, polylines, and complex curve entities such as splines. While it supports limited 3D geometry such as 3D faces and wireframes, it has limited or no practical support for rendering features like textures, lighting, and advanced materials.

Primary Use Cases

• CNC machining and laser cutting path generation.
• Interchange of 2D architectural blueprints between different CAD suites.
• Transferring schematic layouts for PCB design.
• Importing vector paths into 3D modeling software for extrusion.

Strengths

• Widely supported across many CAD and vector software packages, though compatibility varies by application and feature set.
• ASCII versions are human-readable and easily parsed by custom scripts.
• High precision for technical measurements and coordinates.

Limitations

• Lacks support for modern 3D features like rigging, animation, or shaders.
• File sizes can become massive when using ASCII encoding for complex models.

Common Software Support

Supported in varying degrees by Autodesk AutoCAD, Rhino3D, Blender, Adobe Illustrator, and CorelDRAW. It is also widely supported by CAM software for manufacturing workflows.

E3D File Format Details

Overview

The E3D format is a 3D engineering design file used primarily within AVEVA E3D Design software. It is the industry standard for large-scale industrial projects in the marine, power, and process plant sectors.

What It Stores

It contains complex plant engineering data, including 3D piping layouts, structural steel frameworks, equipment models, and detailed metadata for project lifecycle management.

Primary Use Cases

• Designing offshore oil and gas platforms.
• Engineering complex power generation facilities.
• Detailed maritime vessel systems and offshore marine structures.
• Generating automated 2D engineering drawings from 3D models.

Strengths

• Handles massive datasets with thousands of intelligent components.
• Enables multi-user real-time collaborative design.
• Integrates engineering rules to prevent physical clashes.

Limitations

• AVEVA-specific project/model data; typically requires AVEVA software or compatible tools to open or access fully.
• Limited interoperability with general-purpose DCC tools like Blender or Maya.

Common Software Support

Primarily supported by the AVEVA suite, including E3D Design (successor to PDMS), with limited third-party tools.

FBX File Format Details

Overview

FBX (Filmbox) is a popular proprietary 3D file format developed by Kaydara and now owned by Autodesk. It is widely used as an interchange format for transferring complex 3D data smoothly between different modeling, rendering, and game development applications.

What It Stores

FBX files store comprehensive scene data, including polygonal meshes, NURBS curves, materials, and textures. Crucially, they support skeletal rigging, morph targets, camera and lighting setups, and complex transform animations.

Primary Use Cases

• Transferring animated character rigs between specialized software.
• Importing complete 3D assets into game engines like Unity and Unreal.
• Exchanging architectural scenes with integrated lighting and cameras.
• Archiving full 3D scenes with layout hierarchy preserved.

Strengths

• Supports both ASCII (human-readable) and binary (optimized file size) formats.
• Excellent preservation of complex animation, skeletal rigs, and scene hierarchies.
• Broad integration across major industry-standard 3D software packages.

Limitations

• Proprietary format controlled by Autodesk, occasionally leading to version compatibility issues.
• Files can become bloated and heavy compared to lightweight geometry formats.

Common Software Support

Supported by Maya, 3ds Max, Blender, Cinema 4D, Unreal Engine, and Unity.

GLB File Format Details

Overview

GLB is the binary version of glTF (GL Transmission Format). It can pack the JSON scene description, binary buffers, and texture images into a single, self-contained file. GLB is often described as the "JPEG of 3D" because it is designed for compact, efficient delivery.

What It Stores

It encapsulates 3D scene hierarchies, mesh geometry (vertices, normals), PBR material properties, animations, and skeletal rigging. By embedding textures directly, it can eliminate external file dependency issues during asset transfer.

Primary Use Cases

• Real-time web-based 3D viewers and product configurators.
• Augmented Reality (AR) experiences on Android and iOS.
• Efficient asset streaming in game engines.

Strengths

• Single-file portability prevents broken texture paths.
• Optimized for fast GPU loading with minimal processing.
• Native support for PBR (Physically Based Rendering) workflows.

Limitations

• Difficult to edit directly once packed.
• Binary format is not human-readable compared to standard glTF.
• Can become large if high-resolution textures aren't compressed.

Common Software Support

Supported by Blender, Unity, Unreal Engine, and Godot. It is widely used by Google Scene Viewer, Microsoft 3D Viewer, and web frameworks such as Three.js and Babylon.js.

GLTF File Format Details

Overview

.glTF (GL Transmission Format) is an open-standard specification developed by the Khronos Group for efficient transmission and loading of 3D scenes and models. Designed for runtime performance, it acts as a streamlined bridge between authoring tools and real-time engines or web applications.

What It Stores

The format uses JSON to define scene hierarchies, nodes, cameras, and PBR material parameters. It can reference geometry data through external binary buffer files and textures through standard image formats. These assets can be stored as external files, embedded in a .gltf file, or packaged into a .glb binary container.

Primary Use Cases

• Web-based 3D model viewers and configurators.
• Augmented Reality (AR) experiences on mobile devices.
• Asset streaming for real-time engines and virtual worlds.

Strengths

• Optimized for rapid GPU uploading and minimal CPU processing.
• Extensible design supports extensions such as Draco mesh compression and KTX textures.
• Maintains consistent visual appearance via standardized PBR workflows.

Limitations

• Managing multiple external dependencies (.bin and images) can be cumbersome.
• Limited support for advanced, non-standard material nodes or complex shader graphs.

Common Software Support

Widely supported in Blender, Unity, and Unreal Engine, often through built-in features or plugins. Widely utilized in web frameworks like Three.js and Babylon.js.

Additional Notes

While .gltf often uses separate files, .glb is the binary form of glTF and can package the JSON and resources into a single file for easier distribution.

GSM File Format Details

Overview

The GSM file format is the library part format used by Graphisoft's ArchiCAD, a BIM (Building Information Modeling) software. These GDL (Geometric Description Language) objects contain 2D symbols, 3D geometry, and parametric data used primarily in architectural design and construction documentation.

What It Stores

GSM files store parametric 3D geometry, 2D drafting symbols, and object data such as manufacturer information or fire ratings. They utilize GDL scripts to define how an object behaves when its dimensions or materials are modified by the user.

Primary Use Cases

• Distributing architectural components like windows, doors, and furniture.
• Creating intelligent, parametric BIM library parts for ArchiCAD users.
• Standardizing manufacturer-specific building products for digital construction.

Strengths

• High level of parametric flexibility via GDL scripting.
• Lightweight file size due to script-based geometry generation.
• Stores both 2D and 3D representations within a single file.

Limitations

• ArchiCAD-specific library part format with limited editability outside of ArchiCAD.
• Requires knowledge of GDL scripting for advanced customization.

Common Software Support

Graphisoft ArchiCAD is the primary host. Limited import/conversion via other BIM tools or specialized converters (e.g., IFC workflows).

HDA File Format Details

Overview

Developed by SideFX, HDA is a Houdini Digital Asset library format used to package Houdini node networks, logic, and geometry into reusable, high-level tools. It allows artists to encapsulate complex procedural networks into a single asset with a simplified interface.

What It Stores

The format stores procedural node networks, custom parameters, Python scripts, and embedded or referenced geometry. It functions as a container for the logic required to generate or modify 3D data dynamically.

Primary Use Cases

• Creating procedural environment tools for level design.
• Packaging complex VFX simulations for lighting artists.
• Developing custom modeling tools for pipeline integration.
• Facilitating cross-application workflows via Houdini Engine.

Strengths

• Non-destructive, procedural nature allowing infinite iterations.
• Encapsulation of complex logic into user-friendly interfaces.
• Compact file size relative to the complexity of the output.

Limitations

• Requires a Houdini License or Houdini Engine for full functionality.
• High technical entry barrier for asset creation.

Common Software Support

Natively supported in SideFX Houdini. Compatible with Unreal Engine, Unity, Maya, and 3ds Max via the Houdini Engine plugin.

HIP File Format Details

Overview

The HIP file format is the native scene file for SideFX Houdini, a procedural 3D animation and VFX software. It is primarily used to store the complex node networks and procedural logic required for high-end visual effects and dynamic simulations.

What It Stores

These files store node-based architectures including geometry networks (SOPs), dynamics (DOPs), and lighting (LOPs). They also contain VEX scripts, Python expressions, keyframe animation data, and references to external geometry or texture caches.

Primary Use Cases

• Generating procedural environments and assets for games.
• Simulating complex physics like fluids, smoke, and destruction.
• Managing large-scale scene assembly and USD-based lighting.
• Creating custom procedural tools via Houdini Digital Assets.

Strengths

• Fully non-destructive workflow allows for infinite iterations.
• Compact file size as it stores procedural logic rather than raw data.
• Robust integration with industry-standard scripting languages.

Limitations

• Proprietary format with limited direct interoperability.
• Requires Houdini or Houdini Engine API workflows to load or use HIP scene data outside Houdini.
• Steep learning curve due to the complexity of node dependencies.

Common Software Support

Exclusively supported by SideFX Houdini. HIP files can be loaded through the Houdini Engine API, while interoperability with Maya, Unreal Engine, and Unity is typically handled through Houdini Engine workflows or exported formats.

HIPLC File Format Details

Overview

The HIPLC format is the Limited Commercial scene file format for Houdini Indie, a version of SideFX Houdini designed for independent artists. It contains the procedural logic and node networks required to generate complex 3D scenes and simulations.

What It Stores

It stores procedural setups and may include embedded geometry and simulation data, though large caches are often stored externally and referenced. While it saves the entire scene hierarchy, it includes licensing information that Houdini uses, along with its licensing system, to enforce Limited Commercial restrictions.

Primary Use Cases

• Developing procedural assets for indie games.
• Creating VFX for small-scale commercial productions allowed under the Houdini Indie license.
• Authoring Limited Commercial Digital Assets (HDALC) for use with Houdini Engine Indie in game engines.

Strengths

• Nearly full Houdini procedural toolset with some licensing and pipeline limitations.
• Conversion to standard HIP files requires SideFX's approved conversion process when upgrading to a commercial license.

Limitations

• HIPLC files cannot be opened in commercial versions of Houdini without conversion.
• Not directly compatible with commercial pipelines unless converted using appropriate licensing upgrades.

Common Software Support

Primarily supported by SideFX Houdini Indie and Houdini Engine Indie.

HIPNC File Format Details

Overview

The HIPNC format is the non-commercial scene file format used by Houdini Apprentice. It serves as a scene file that contains the procedural node networks and logic used to generate 3D content. The format is tied to Houdini Apprentice's non-commercial file restrictions and cannot be used in the same pipeline as commercial versions of Houdini.

What It Stores

It stores scene data such as procedural networks, geometry, simulation settings, lighting, cameras, and other project parameters. Because it is procedural, it primarily stores the recipe for the scene rather than just raw mesh data.

Primary Use Cases

• Learning Houdini through the free Apprentice version.
• Personal (non-commercial) portfolio projects and experimental CG art.
• Creating procedural assets for non-commercial educational purposes.

Strengths

• Provides free access to Houdini for learning and non-commercial use, subject to license restrictions.
• Procedural scenes can often stay compact because the file stores setup and parameters rather than only baked outputs.

Limitations

• Restricted to non-commercial use only.
• Rendering is resolution-limited and watermarked.
• Apprentice cannot be used in the same pipeline as commercial versions of Houdini unless files are converted through SideFX's approved conversion process.

Common Software Support

Primarily supported by Houdini Apprentice. HIPNC files are part of SideFX's non-commercial Houdini file formats.

HRC File Format Details

Overview

The HRC file format is a legacy Softimage, 3D model file format used to store model geometry and hierarchy information. It defines complex 3D models by organizing objects into a structured parent-child hierarchy, preserving hierarchy and spatial relationships.

What It Stores

The format stores model geometry, material references, texture mapping coordinates, and hierarchy information, including transformation data. It does not store camera or lighting data.

Primary Use Cases

• Archiving legacy Softimage, 3D assets.
• Describing hierarchical bone or object structures used in animation pipelines.
• Transferring Softimage hierarchy data through specialized converters.

Strengths

• Efficiently represents complex nested transformations and object relationships.
• Preserves Softimage, 3D model hierarchy for conversion or archival workflows.

Limitations

• Modern DCC support is limited without specialized converters.
• Lacks the modern ecosystem support and performance optimizations found in USD or glTF.
• Primarily restricted to older animation pipelines.

Common Software Support

Legacy support is centered on Softimage, 3D and older Autodesk Softimage versions with the SI/3D Scene/Model importer. Conversion support is documented through Okino PolyTrans.

IAVATAR File Format Details

Overview

The IAVATAR file format is a Reallusion avatar file format used by Character Creator and iClone. It is used to save or export characters for creating animations in iClone. Reallusion workflows commonly allow users to export, load, or drag iAvatar characters into iClone for animation.

What It Stores

These files store Reallusion character data for use in Character Creator and iClone, including character details and texture settings. Depending on the workflow, iAvatar files may also be used with remeshed character versions and morph data.

Primary Use Cases

• Real-time 3D character animation in Reallusion iClone.
• Storing customized digital humans created in Character Creator.
• Rapid prototyping of humanoid actors for previz and filmmaking.

Strengths

• Seamless integration across the Reallusion software suite.
• Allows characters exported from Character Creator to be used in iClone.
• Supports Reallusion workflows such as remeshed iAvatar export and morph data workflows.

Limitations

• Reallusion avatar format with limited native support in external 3D software.
• Requires export to supported formats such as FBX for use in other game engines.

Common Software Support

Primary support includes Reallusion iClone and Character Creator. Earlier conversion workflows used Reallusion 3DXchange, which has been discontinued, with related features integrated into iClone 8 or Character Creator 4.

IGES File Format Details

Overview

The Initial Graphics Exchange Specification (IGES) is a vendor-neutral file format used to exchange digital information between CAD systems. Established in 1980, IGES is a legacy CAD exchange standard used mainly for transferring 2D geometry, curves, and 3D surface models across engineering systems.

What It Stores

IGES files primarily store geometric data such as wireframes, curves, surfaces, and some solid representations. It focuses on precise geometric shapes rather than textures, rigging, or animation data.

Primary Use Cases

• Exchanging complex CAD data between different engineering software.
• Exchanging 2D technical drawings and schematics between CAD systems.
• Providing surface geometry that can be used in CAM and some manufacturing workflows.

Strengths

• Widely supported by many professional CAD and CAM applications.
• Good for representing smooth curved surfaces using mathematical geometry such as NURBS.
• ASCII-based structure allows for manual inspection of geometric data.

Limitations

• Files can become extremely large compared to modern formats like STEP.
• Translation between systems may result in gaps or broken surfaces.

Common Software Support

Supported by many CAD systems, including Rhino, SolidWorks, CATIA, and some Autodesk products, depending on version and workflow.

IGS File Format Details

Overview

The Initial Graphics Exchange Specification (IGES) is a vendor-neutral file format used to exchange digital information between CAD systems. Established in 1980, IGES is a legacy CAD exchange standard used mainly for transferring 2D geometry, curves, and 3D surface models across engineering systems.

What It Stores

IGES files primarily store geometric data such as wireframes, curves, surfaces, and some solid representations. It focuses on precise geometric shapes rather than textures, rigging, or animation data.

Primary Use Cases

• Exchanging complex CAD data between different engineering software.
• Exchanging 2D technical drawings and schematics between CAD systems.
• Providing surface geometry that can be used in CAM and some manufacturing workflows.

Strengths

• Widely supported by many professional CAD and CAM applications.
• Good for representing smooth curved surfaces using mathematical geometry such as NURBS.
• ASCII-based structure allows for manual inspection of geometric data.

Limitations

• Files can become extremely large compared to modern formats like STEP.
• Translation between systems may result in gaps or broken surfaces.

Common Software Support

Supported by many CAD systems, including Rhino, SolidWorks, CATIA, and some Autodesk products, depending on version and workflow.

IPROJECT File Format Details

Overview

The iProject format is the proprietary project file format used by Reallusion iClone. It stores saved iClone project scenes for real-time animation, cinematic production, and character-driven storytelling workflows.

What It Stores

This format stores iClone project scene data, including characters, props, cameras, lights, animation data, materials, and other scene elements used in an iClone project.

Primary Use Cases

• Real-time cinematic previz for film and television.
• Character animation for indie game development.
• Rapid creation of social media and marketing content.

Strengths

• Optimized for high-performance real-time playback.
• Streamlined integration with motion capture hardware.
• Keeps full iClone scenes reusable for later editing, rendering, and animation refinement.

Limitations

• Proprietary format restricted to the Reallusion ecosystem.
• Large or complex iProject files can load slowly, fail to load, or crash if temporary disk space or system resources are insufficient.

Common Software Support

Primarily supported by Reallusion iClone. External workflows use supported export formats such as FBX, Alembic, OBJ, or USD/Omniverse workflows, depending on version, edition, and plug-in support, or dedicated bridge/live-link tools such as iClone Unreal Live Link.

Additional Notes

While iProject is a proprietary iClone project format, Reallusion provides Live Link and export workflows for moving characters, cameras, lights, props, and animation data into supported external pipelines.

LS File Format Details

Overview

The LS format is the un-compiled LScript file format used within LightWave 3D to automate complex tasks and extend software functionality. It serves as a scripting solution for artists to streamline repetitive modeling and rendering workflows.

What It Stores

The format contains un-compiled LScript code, including commands, logic, and interface definitions. It stores scripting instructions that manipulate geometry, scene hierarchy, surface properties, and custom expressions, but does not contain raw 3D mesh data or vertex information.

Primary Use Cases

• Automating rendering and scene setup tasks.
• Building custom UI panels for tool interaction.
• Batch processing object transformations.
• Exporting or processing scene data when supported by the script and host application.

Strengths

• Human-readable code facilitates easy debugging.
• Seamless integration with LightWave 3D's Layout and Modeler.
• Supports custom panels and user interface elements for scripts.

Limitations

• Largely lacks cross-platform portability beyond LightWave 3D, though the files themselves are plain text and platform-agnostic.
• Slower execution compared to compiled C++ plugins.
• LScript is deprecated as of LightWave 2020.

Common Software Support

Primarily supported by LightWave 3D and its associated utilities.

LW File Format Details

Overview

The LW format is a native object file type for LightWave 3D, a long-standing suite used in visual effects and broadcast animation. It is primarily designed to store high-quality individual 3D objects and their properties, rather than entire scenes.

What It Stores

It stores 3D mesh data, including points, polygons, and surfaces. An LW object file may also contain one or more surface definitions.

Primary Use Cases

• Creating assets for television VFX and film production.
• Developing detailed 3D models for visualization workflows, including architectural visualization.
• Game asset authoring prior to engine export.

Strengths

• Stores connected or disjointed meshes as a single logical object.
• Supports surface definitions within the object file.
• Useful for complex polygonal modeling.

Limitations

• Primarily an object format; full scene layouts and most animation data are typically stored in separate LightWave 3D scene files.
• Compatibility can vary when converting to non-native software or workflows.

Common Software Support

Natively used in LightWave 3D. Some third-party tools can support LW through built-in support, plugins, or conversion workflows, but compatibility varies by version and software.

LWO File Format Details

Overview

The LightWave Object (LWO) format is a file type developed by NewTek for its LightWave 3D software. It is a 3D object format used in LightWave workflows and some third-party pipelines for detailed assets. LWO files are typically used in conjunction with LightWave Scene (LWS) files, where LWO files usually store object geometry and surface data, while LWS scene files store scene layout and environment settings.

What It Stores

LWO files primarily store geometry such as points and polygons, along with surface and mapping data.

Primary Use Cases

• Some production workflows, especially within LightWave-based pipelines.
• Storing detailed 3D object assets, including static environment props.
• Polygon-based modeling workflows, including models that may be edited with subdivision-oriented tools.
• Saving and exchanging 3D object assets within LightWave workflows.

Strengths

• Supports surface and mapping data within a compact binary object format.
• Supports modern polygon modeling workflows, including subdivision-oriented asset creation depending on LightWave version and toolchain.
• Supports layers, points, polygons, surfaces, and vertex map data.
• Preserves surface and material information well within LightWave workflows.

Limitations

• Skeletal animation and rigging are often handled in the LightWave scene/workflow rather than as core object data.
• Limited interoperability compared to universal formats like FBX or USD.

Common Software Support

Native to LightWave 3D. Supported via import/export plugins in Blender, Modo, and various third-party conversion tools like PolyTrans.

LWS File Format Details

Overview

The LightWave Scene (LWS) format is an ASCII-based scene file format developed by NewTek. It acts as a scene file that defines how various assets, such as objects, cameras, and lights, are arranged and animated within a 3D environment. LWS files act like a scene or master file that references external object files, commonly LWO, rather than embedding geometry.

What It Stores

LWS files store scene hierarchy, object positions, rotations, scaling, and keyframe animation data. They also contain light and camera properties, scene-level settings, and references to external LWO mesh files.

Primary Use Cases

• Defining layout and composition for 3D renders.
• Managing complex character and camera animations.
• Archiving lighting and environment setups for visual effects.

Strengths

• Human-readable text format allows for easy manual editing or scripting.
• Separate scene/object-file structure can keep scene files relatively compact while managing complex setups.
• Long-term continuity across LightWave versions, though compatibility depends on the specific version and features used.

Limitations

• The format does not embed geometry and instead references external object files.
• Path-dependent architecture can lead to broken scenes if linked assets are moved.

Common Software Support

Primarily used in LightWave 3D. Also supported by some conversion tools and interoperability software.

LXO File Format Details

Overview

The LXO format is the native scene file format for Foundry's Modo, a 3D modeling, animation, and rendering application. It can include lighting, camera settings, materials, and other scene-specific render information.

What It Stores

An LXO file can store geometry, UV maps, materials, lights, cameras, and animation data for a Modo scene. It can also preserve Modo Shader Tree information related to materials and textures.

Primary Use Cases

• Native project saving and asset management within Modo.
• High-fidelity 3D asset creation in Modo for modeling, animation, and rendering workflows.
• Character rigging and animation production.
• Saving and transferring Modo scene files, using Foundry's Consolidate Scene command to copy associated linked files and adjust internal file links to relative paths.

Strengths

• Retains Modo scene data and can preserve many Modo-specific project elements.
• Supports scene consolidation for transferring Modo scenes and associated linked files between workstations.
• Efficiently handles complex scene hierarchies and item relationships.

Limitations

• Native Modo scene format limits direct compatibility with other 3D software without conversion.
• Can be less interoperable than interchange formats like OBJ, though file size depends on scene content and settings.

Common Software Support

Primarily used in Foundry Modo. Limited support and import capabilities in third-party tools and converters.

MA File Format Details

Overview

The .MA (Maya ASCII) format is a native Autodesk Maya scene file saved in a human-readable text format. It is widely used in professional film, television, and game development for complex scene management and pipeline integration.

What It Stores

It stores comprehensive scene data, including polygonal and NURBS geometry, complex rigging systems, keyframe animations, lighting, shaders, and Maya-specific dependency graph nodes.

Primary Use Cases

• Professional character rigging and animation pipelines.
• Version control and collaborative environments where text-based diffing and change tracking are beneficial.
• Recovering corrupted files by manually editing the ASCII code.

Strengths

• Human-readable format allows for text-based editing and scripting.
• Editable file structure can help resolve some version compatibility issues.
• Robust support for complex, nested scene hierarchies and reference systems.

Limitations

• Significantly larger file sizes compared to the binary .MB format.
• Slower to save and load due to the parsing of text-based commands.

Common Software Support

Primary support is Autodesk Maya. However, it can be parsed by custom pipeline scripts or imported into some specialized 3D tools and game engine exporters.

Additional Notes

Because it is human-readable and script-based, .MA files are commonly preferred for troubleshooting, pipeline debugging, and version-controlled production workflows.

MAX File Format Details

Overview

The .MAX format is the proprietary scene file format for Autodesk 3ds Max. It acts as a complete scene format for complex 3ds Max scenes, preserving scene data including objects, modifiers, materials, and controllers.

What It Stores

It stores geometry, advanced modifiers, rigging, animation, lighting, and camera data. It also contains plugin-specific information, material editor settings, and particle system configurations.

Primary Use Cases

• High-end architectural visualization production.
• Asset creation for film and television VFX.
• Complex character rigging and animation workflows.

Strengths

• Retains the "live" modifier stack for non-destructive editing within 3ds Max.
• Saves workspace states, including viewport layouts and certain UI configurations.
• Supports data from native 3ds Max tools and compatible plugins.

Limitations

• Heavy dependency on specific software versions and installed plugins.
• Limited interoperability outside 3ds Max, as most other 3D applications cannot natively read .MAX files.
• Often larger file sizes compared to interchange formats due to embedded scene and application data.

Common Software Support

Natively supported only by Autodesk 3ds Max.

Additional Notes

To move data to other platforms, users typically export to supported interchange formats such as FBX or USD.

MB File Format Details

Overview

The .MB (Maya Binary) format is a proprietary file type developed by Autodesk for Maya. It uses a compact binary encoding to efficiently store complex 3D scenes, making it a common choice in production-heavy environments.

What It Stores

It captures comprehensive scene data, including polygonal geometry, NURBS, rigging systems, animation keyframes, and lighting. It also stores Maya-specific dependency graphs and shader networks.

Primary Use Cases

• High-end character animation for film and television.
• Complex architectural visualizations.
• Proprietary asset management within Maya-centric pipelines.
• Game asset authoring before export to runtime formats.

Strengths

• Significantly smaller file sizes compared to ASCII (.MA) versions.
• Faster load and save times for massive scene files.
• Native support for all Maya-specific features and nodes.

Limitations

• Proprietary format with limited support outside Autodesk Maya.
• Binary data is not human-readable, making manual corruption recovery difficult.

Common Software Support

Primarily supported by Autodesk Maya. Limited interoperability is available via specific plugins or conversion tools for other Autodesk products.

MDL File Format Details

Overview

The MDL format is Valve's proprietary model format used by the Source engine, with a related MDL format also used by GoldSrc. It serves as the final compiled format for characters, props, and environmental assets within games like Half-Life 2 and Counter-Strike.

What It Stores

It defines model structure, animation data, bounding boxes, hitboxes, material references, mesh information, and LOD information, while some vertex or hardware-optimized mesh data may be stored in companion files such as VVD and VTX. Additionally, it stores animation sequences and hitboxes, and references external material VMT files, which in turn reference VTF texture files.

Primary Use Cases

• Storing compiled model data for real-time rendering within the Source engine.
• Character performance and skeletal animation for gameplay.
• Defining collision physics and hitboxes for in-game objects.

Strengths

• Highly optimized for real-time performance and skeletal deformation.
• Supports flex-based facial animation and coordinates with companion physics data when present.
• Efficiently packages multiple Levels of Detail within the model structure.

Limitations

• Proprietary nature makes it difficult to edit without decompile tools.
• Largely limited to the Source ecosystem; lacks native interoperability with modern general-purpose engines.

Common Software Support

Valve Source SDK, HLMV (Half-Life Model Viewer), and Blender (via community-developed plugins).

MHB File Format Details

Overview

The MHB format is a MetaHuman Creator file used to export and import the data defining a MetaHuman character. It is primarily used for sharing MetaHumans between MetaHuman Creator users or accounts, rather than for direct import as a standard Unreal Engine asset.

What It Stores

It stores MetaHuman character definition data used by MetaHuman Creator, rather than full Unreal Engine-ready character asset data. This data represents the character setup needed by MetaHuman Creator to recreate or continue the MetaHuman design.

Primary Use Cases

• Sharing MetaHuman characters between MetaHuman Creator users or accounts.
• Archiving specific MetaHuman character definitions for later import into MetaHuman Creator.
• Transferring MetaHuman Creator character data before using supported Unreal Engine delivery workflows.

Strengths

• Lightweight sharing format for MetaHuman Creator character definitions.
• Allows MetaHuman character definitions to be shared between users or accounts.

Limitations

• Intended for MetaHuman Creator workflows, not as a general-purpose 3D interchange format.
• No direct compatibility with standard 3D DCC tools like Blender without first being processed through Unreal Engine or other tools.

Common Software Support

Primarily supported by web-based MetaHuman Creator. Unreal Engine workflows use Quixel Bridge in older MetaHuman workflows, while newer workflows use MetaHuman Character assets and MetaHuman Assembly workflows.

MS3D File Format Details

Overview

The MS3D format is the native model file format for MilkShape 3D, a legacy low-polygon modeler. It gained popularity in the early 2000s for low-polygon game asset creation and modding communities, especially around older PC games and engines.

What It Stores

MS3D files store 3D model data including vertices, triangles, texture coordinates, groups, materials, joints, and keyframe animation data. They can also store vertex assignments used for skeletal animation.

Primary Use Cases

• Creating assets for legacy game engines (e.g., GoldSrc).
• Developing low-poly character models for older game engines or for export into other formats used in modern pipelines.
• Modding classic PC games by editing MilkShape 3D models and exporting them to game-specific formats.

Strengths

• Simple, lightweight structure that is easy to parse and well suited to low-poly workflows.
• Support for skeletal rigging and keyframe animation.
• Works well for legacy game asset workflows and format conversion pipelines.

Limitations

• Designed for low-polygon content and relatively basic material handling compared with modern formats.
• Lacks support for modern features like PBR materials or complex shaders.

Common Software Support

Natively supported by MilkShape 3D. Blender support is available through community import/export add-ons, while use in modern engines such as Unity or Unreal Engine typically requires conversion to another supported format.

MTLX File Format Details

Overview

MaterialX (MTLX) is an open standard originally developed at Lucasfilm for representing rich material and look-development content in computer graphics, using an XML-based file format. It facilitates the transfer of rich material data between different applications and renderers within a production pipeline.

What It Stores

The format stores node graphs, material definitions, shader references, texture file paths, material assignments, geometry properties, and shading parameters such as roughness or index of refraction. It captures node-based material and look-development data without being tied to a specific renderer's proprietary shading language.

Primary Use Cases

• Standardizing look development across multi-studio pipelines.
• Facilitating material transport between DCCs and renderers that support MaterialX, such as Houdini Solaris, Maya LookdevX, Arnold, Karma, RenderMan, and Omniverse.
• Defining shaders for USD (Universal Scene Description) workflows.
• Archiving production-ready material libraries.

Strengths

• Platform-independent standard for exchanging material and look-development content across applications and renderers that support MaterialX.
• Open standard with an open-source library, widely used in VFX and animation pipelines.
• Hierarchical structure allows for easy overrides and variations.

Limitations

• Requires compatible applications or renderers that support the MaterialX specification.
• Higher complexity compared to simple image-based texture sets.

Common Software Support

Strong integration via plugins or render-specific workflows in SideFX Houdini (Solaris), Autodesk Maya (e.g., through LookdevX and Arnold), and NVIDIA Omniverse. Supported by renderers such as Arnold, Karma, and RenderMan.

MXS File Format Details

Overview

The MXS format is the Maxwell Render scene file format. It is designed to store a complete 3D scene description, acting as a bridge between 3D modeling applications and the standalone Maxwell rendering engine.

What It Stores

It contains comprehensive scene data including geometry, camera settings, Maxwell materials and material assignments, instancing data, and Multilight setup information. Textures used in materials and HDR/MXI textures used in the scene are referenced, not embedded.

Primary Use Cases

• Transferring production-ready scenes to standalone render nodes or farms.
• Managing complex architectural visualization scenes with physically accurate lighting.
• Iterative lighting adjustments using Multilight technology by changing individual light intensities during or after rendering without rerendering the scene.
• Archiving finalized 3D assets with their specific material and lighting context.

Strengths

• Maintains high fidelity of Maxwell physically based rendering parameters across Maxwell Render workflows.
• Can use referenced MXS files to reduce main scene file size and export time for repetitive or complex static geometry.
• Allows lighting adjustments during or after rendering when Multilight is enabled.

Limitations

• Proprietary format is primarily intended for the Maxwell Render ecosystems.
• Files can become extremely large depending on scene complexity and embedded geometry.

Common Software Support

Primarily supported by Maxwell Render, Maxwell Studio, and Maxwell plugins for applications such as 3ds Max, Maya, Cinema 4D, Rhino, SketchUp, ArchiCAD, and formZ.

OBJ File Format Details

Overview

OBJ is a geometry definition file format originally developed by Wavefront Technologies for The Advanced Visualizer. It is a universally accepted industry standard used for exchanging static 3D polygonal geometry across various modeling, rendering, and animation applications.

What It Stores

The format stores 3D geometric data, including vertex positions, polygon faces, texture coordinates (UVs), and vertex normals. It relies on a companion Material Template Library (.mtl) file to reference external texture maps and define basic material properties.

Primary Use Cases

• Transferring static mesh assets between different 3D sculpting and modeling software.
• Exporting digital assets for 3D printing workflows.
• Distributing individual 3D models on online marketplaces.

Strengths

• Open, simple, and human-readable text-based format.
• Universal compatibility across nearly all 3D graphics applications and game engines.
• Reliable preservation of basic mesh geometry and UV layouts.

Limitations

• Lacks native support for animation, rigging, bone hierarchies, or cameras.
• Splitting geometry and material data into separate files can cause broken links and missing textures.

Common Software Support

Supported by major 3D tools like Blender, Autodesk Maya, 3ds Max, and ZBrush, as well as Unreal Engine and Unity.

ORBX File Format Details

Overview

The ORBX file format is a container format developed by OTOY for the OctaneRender ecosystem. It serves as a scene exchange format designed to preserve scene data and improve render consistency across supported Octane workflows. ORBX is essentially a self-contained scene/container format that stores geometry, textures, render settings, and referenced assets together.

What It Stores

ORBX files store complete scene data, including complex geometry, materials, high-resolution textures, and lighting. It also supports sophisticated data like OpenVDB volumes, camera parameters, baked animations, and OSL (Open Shading Language) scripts.

Primary Use Cases

• Transferring fully shaded scenes between different DCC plugins.
• Uploading assets to the Render Network for cloud rendering.
• Packaging self-contained 3D scenes for transfer or reuse.

Strengths

• Cross-platform parity helps preserve scene fidelity across supported Octane workflows.
• Designed to be an efficient container for transferring complex scene data.
• Encapsulates all dependencies into a single file to prevent broken paths.

Limitations

• Proprietary format primarily restricted to the OctaneRender ecosystem.
• Intended for scene exchange and rendering workflows rather than general-purpose modeling.

Common Software Support

Native to OctaneRender Standalone. Supported through OctaneRender plugin workflows in applications such as Cinema 4D, Houdini, Maya, 3ds Max, and Blender.

OTL File Format Details

Overview

The Operator Type Library (OTL) is a legacy file format used by SideFX Houdini to store Houdini Digital Assets (HDAs). It functions as a digital asset library file, storing reusable custom nodes created from Houdini node networks.

What It Stores

OTL files contain digital asset definitions, including node contents, parameters, parameter interface definitions, scripts such as PythonModule sections, help, and embedded files or other section data used by the asset.

Primary Use Cases

• Packaging procedural modeling tools for studio-wide distribution.
• Creating reusable simulation assets for VFX pipelines.
• Version-controlling specific tool iterations within a production environment.
• Using Houdini Digital Assets in game engines or DCC applications through Houdini Engine.

Strengths

• Efficiently encapsulates complex logic into a single, manageable file.
• Allows for consistent tool updates across multiple scenes and projects.
• Facilitates modularity and collaborative workflows in large-scale pipelines.

Limitations

• Superseded by the (HDA) format in modern Houdini versions.
• Library files can become large if substantial internal data is stored inside asset definitions.

Common Software Support

• Primarily supported by SideFX Houdini. Houdini Digital Assets can also be used in supported host applications through Houdini Engine, including Autodesk Maya, Unreal Engine, and Unity.

Additional Notes

Modern Houdini stores digital assets in digital asset library files with the .hda extension, while older versions used the .otl extension. Houdini can still load assets from .otl library files.

PLASTICITY File Format Details

Overview

The PLASTICITY file format is the proprietary native format for Plasticity, a direct modeling CAD software tailored for artists and designers. It is designed to save precise geometric data for hard-surface modeling workflows.

What It Stores

It stores Parasolid-based solid and surface geometry, curves, object organization, and related model data used by Plasticity. It supports direct editing of curves, surfaces, faces, edges, and solid bodies, but does not store parametric construction history, rigging, animation, or texture-based rendering data.

Primary Use Cases

• Saving in-progress hard-surface concept designs.
• Archiving editable 3D CAD assets.
• Inter-software workflow preparation prior to mesh conversion.

Strengths

• Retains precise CAD curves, surfaces, and solid body geometry.
• Smaller file sizes compared to dense polygonal meshes.
• Supports direct editing of curves, surfaces, faces, edges, and solid bodies.

Limitations

• Not supported natively by standard DCC apps or game engines without export conversion.
• Lacks animation, rigging, and texturing capabilities.

Common Software Support

Primarily supported by Plasticity. Plasticity exports to formats such as OBJ, STL, STEP, Parasolid X_T/X_B, 3MF, SVG, and, in Studio workflows, SAT and IGES for external pipeline compatibility.

PLY File Format Details

Overview

The Polygon File Format, also known as the Stanford Triangle Format (PLY), is a 3D file format developed at Stanford University for storing data from 3D scanners. It is primarily used to represent digitized objects and point clouds in scientific and academic research.

What It Stores

PLY files store vertex coordinates, face definitions, normals, and color information. They support both ASCII for readability and binary for performance, allowing for custom properties such as transparency or surface confidence values.

Primary Use Cases

• Archiving high-density 3D scanning and photogrammetry data.
• Storing point cloud data from 3D scanning, depth sensing, and LiDAR capture workflows.
• Interchange format for scientific visualization and mesh processing.

Strengths

• Supports extensible elements and properties for storing additional per-object, per-vertex, or per-face data.
• Efficient binary encoding for large, dense datasets.
• Simplicity of structure makes it easy to parse for custom tools.

Limitations

• Lacks support for animation, rigging, or scene hierarchies.
• Material support is limited to basic color and attribute data without standardized PBR or texture workflows, and is non-standardized compared to modern formats.

Common Software Support

Supported by Blender, MeshLab, CloudCompare, and Rhino. It is also a standard format in libraries like Open3D and Point Cloud Library.

PZ3 File Format Details

Overview

The PZ3 format is the native scene file type for Poser, a 3D software package for posing, animating, and rendering 3D figures. It acts as a project container that preserves the specific state and configuration of a Poser scene.

What It Stores

It stores figure posing data, joint rotations, dial settings such as morphs, and scene information. It also contains lights, cameras, rendering settings, background settings, and material information, while typically referencing external Poser library assets for geometry and textures.

Primary Use Cases

• Saving complex character compositions and poses.
• Archiving scene setups for digital illustration and comic art.
• Distributing pre-configured 3D sets and lighting environments.

Strengths

• Extensive support for complex rigging and inverse kinematics.
• Retains detailed morph and expression data.

Limitations

• Proprietary nature limits native interoperability with other 3D suites.
• Relies heavily on external file paths, risking broken links if libraries are moved.

Common Software Support

Primarily supported by Poser software. Daz Studio can import PZ3 files.

RFA File Format Details

Overview

Revit Family (RFA) files are loadable family files used in Autodesk Revit projects. They are primarily used to create and store parametric 3D content, such as furniture, lighting, or mechanical equipment, meant for use within a Revit project. (RFA) files are reusable family definitions that can be loaded into RVT project files. When loaded into a project, they create family instances, and edits to the family definition can be propagated to placed instances.

What It Stores

RFA files can store geometry, parameters, materials, metadata, constraints, visibility settings, and category-specific properties, depending on the family. Crucially, they hold parameters that allow users to adjust dimensions and properties dynamically within a project.

Primary Use Cases

• Creating manufacturer-specific BIM components for architects and engineers.
• Building reusable asset libraries for consistent construction documentation.
• Creating MEP families such as HVAC, plumbing, and electrical fixtures, where supported by the family's parameters and connectors.

Strengths

• Supports parametric behavior, allowing family dimensions and properties to change based on defined parameters.
• Integrates with Revit documentation and schedules when families are properly categorized and parameterized.
• Often smaller than full project files, though size varies by component complexity.

Limitations

• Proprietary Autodesk format primarily used within the Autodesk ecosystem, with limited support in some third-party tools.
• Not backward compatible with older versions of Revit software.

Common Software Support

Primarily supported by Autodesk Revit and Revit LT. RFA files can also be viewed or converted through some third-party BIM tools and plugins, depending on the product and workflow.

RFT File Format Details

Overview

The Revit Family Template (RFT) format is a family template file used within Autodesk Revit to start the creation of parametric 3D components. These files serve as the starting point for building Revit Families (RFA), ensuring consistency in data structure and hosting behavior. They are family template files used to create new families, and in typical Revit workflows the result is saved as an RFA file.

What It Stores

RFT files can contain predefined parameters, reference planes, and category-specific settings. They can include hosting conditions, visibility settings, reference geometry, and parameters that drive family behavior.

Primary Use Cases

• Standardizing the creation of custom architectural components.
• Establishing hosting behaviors for MEP fixtures and equipment.
• Defining parametric constraints for furniture and cabinetry.
• Creating consistent title blocks and annotation symbols.

Strengths

• Ensures specific Revit categories are correctly assigned from the start.
• Provides a reference- and constraint-based structure to support parametric behavior.
• Streamlines BIM workflows by pre-loading commonly used parameters and settings.

Limitations

• Proprietary format restricted almost exclusively to the Autodesk ecosystem.
• In normal Revit workflows, families are saved as RFA files rather than back into the original RFT template.

Common Software Support

Primarily supported by Autodesk Revit. Some third-party BIM tools may use Revit templates in automated workflows, depending on the product.

RS File Format Details

Overview

The RS format is the Redshift Proxy File (.rs) format used by the Redshift rendering engine. It allows users to export complex geometry and scene data into an external file that is loaded only at render time.

What It Stores

It can store Redshift scene data ranging from simple objects to complete scenes, including geometry, materials, shaders, lights, cameras, animation, global render options, and AOV setup. The exported proxy data is generally non-editable in the host application and changes usually require editing the original source scene and re-exporting the proxy.

Primary Use Cases

• Managing massive scene complexity and high poly counts.
• Standardizing assets for use across different host applications.
• Accelerating viewport performance by using lightweight placeholders.
• Often used in workflows that involve repeated assembly of complex environment assets.

Strengths

• Reduces scene memory usage by keeping proxy geometry unloaded until needed at render time.
• Supports interoperability across DCCs like Maya, Houdini, and Cinema 4D.
• Allows efficient loading during the render phase.

Limitations

• The exported data is non-editable; changes require re-exporting the original source.
• It is a Redshift-specific proxy format and is not intended as a general interchange format for other render engines.

Common Software Support

Supported in Redshift workflows for Cinema 4D, Houdini, Maya, 3ds Max, Katana, and Blender, with feature support varying by host application.

RTE File Format Details

Overview

The RTE format is a Revit Template file used in Building Information Modeling. It serves as the foundational starting point for new projects, ensuring consistency across architectural, structural, and MEP designs.

What It Stores

These files can contain predefined settings such as view templates, units, line weights, and pre-loaded families, and may also include levels or other starter project elements depending on the template. They store project standards, styles, settings, and starter content, but are intended as starting files rather than completed project models.

Primary Use Cases

• Standardizing company-wide BIM protocols.
• Initializing new RVT project files.
• Defining discipline-specific environments (e.g., Structural vs. Mechanical).

Strengths

• Ensures workflow uniformity and prevents repetitive setup tasks.
• Automatically generates a new, unsaved RVT file upon opening to protect the original template.
• Streamlines asset management through pre-loaded families.

Limitations

• An RTE file is used to start a new project, which is then saved as an RVT project file.
• Revit files are generally version-sensitive, and compatibility between newer and older versions should be checked for the specific template and Revit release.

Common Software Support

RTE files are native to Autodesk Revit and are primarily used within Revit-based workflows.

RVT File Format Details

Overview

RVT is the proprietary native project file format for Autodesk Revit, a widely used Building Information Modeling (BIM) application. It is widely used by architects, structural engineers, and MEP professionals to design, track, and manage comprehensive building projects.

What It Stores

RVT files store 3D parametric geometry, building components, materials, schedules, and project data. They can also include site or location-related information depending on the project.

Primary Use Cases

• Centralized architectural and engineering design coordination.
• Generation of construction documentation, drawings, and material takeoffs.
• Cross-discipline clash detection and coordination.

Strengths

• Maintains intelligent, parametric relationships between 3D objects and components.
• Automatically updates schedules, sections, and elevations when model geometry changes.
• Holds large datasets containing geometric, graphical, and project metadata.

Limitations

• Proprietary Autodesk format with limited direct interoperability outside Autodesk and supported BIM workflows.
• Complex projects can become large and may be demanding on hardware and performance.

Common Software Support

Primarily supported by Autodesk Revit, with limited viewing or import capabilities in Autodesk Navisworks and some BIM viewers.

SAT File Format Details

Overview

The Standard ACIS Text (SAT) file format is a 3D geometric modeling file format developed by Spatial Corporation. It is primarily used to store and exchange precise CAD data across different engineering and manufacturing platforms.

What It Stores

It stores precise 3D geometric data, including solid geometry, topology, curves, and surfaces. Unlike polygonal mesh formats, it represents shapes using Boundary Representation (B-Rep) modeling.

Primary Use Cases

• Interchanging data between CAD/CAM/CAE systems.
• Storing precise 3D CAD models for mechanical engineering and related design workflows.
• Transferring precise solid geometry for downstream CAD and manufacturing workflows.

Strengths

• High accuracy with mathematical geometric descriptions.
• Strong interoperability among ACIS-based software.

Limitations

• Designed for CAD solid modeling and is not intended for animation or rigging workflows.
• Based on exact boundary-representation geometry rather than polygonal meshes, so it often requires conversion before use in many non-CAD tools.

Common Software Support

Supported by CAD tools such as AutoCAD and SOLIDWORKS for cross-platform CAD exchange. Rhino supports export to SAT, while SAT import may require third-party conversion tools or plugins.

SBS File Format Details

Overview

The SBS format is the native, non-destructive project file for Adobe Substance 3D Designer. It utilizes a node-based graph system to author procedural materials, allowing artists to create complex textures that remain fully editable.

What It Stores

It contains package resources such as graphs, functions, bitmap resources, 3D scene resources, dependencies, metadata, node connections, and parameters used to generate textures.

Primary Use Cases

• Authoring procedural PBR materials.
• Creating custom filters and generators for Substance 3D Painter.
• Developing reusable texture libraries for studio pipelines.
• Prototyping complex procedural materials for game engines.

Strengths

• Fully non-destructive and highly scalable procedural workflow.
• Extremely modular, with node-based graphs and reusable graph components.
• Small file footprint when built primarily from procedural graphs and linked resources rather than embedded bitmap data.

Limitations

• Proprietary format requiring Substance 3D Designer to open.
• Intended as an editable Substance 3D Designer package, not as the primary published asset format for deployment in other supported applications.

Common Software Support

Adobe Substance 3D Designer is the primary host. It integrates with Substance 3D Painter and other Substance 3D tools through SBSAR and related workflows.

SBSAR File Format Details

Overview

The SBSAR format is a published Substance 3D asset file used by Adobe Substance 3D. It serves as an archive file for procedural materials, allowing for dynamic texture generation across various 3D applications and game engines.

What It Stores

It contains compiled versions of Substance graphs, their resources such as bitmaps and fonts, presets, metadata, and exposed parameters for customization. It can include outputs and parameters used in PBR workflows, such as base color, roughness, metallic, and normal-related data, along with adjustable resolution settings.

Primary Use Cases

• Real-time texture generation in game engines.
• Parametric material libraries for architectural visualization.
• Widely used asset exchange format for look development.
• Dynamic surface weathering and detailing in DCC tools.

Strengths

• File sizes are often smaller than baked texture sets.
• Real-time parameter tweaking without re-exporting.
• Broad interoperability across Substance 3D applications and supported third-party integrations.

Limitations

• Proprietary format that typically requires Substance software or a Substance integration for full use.
• Compiled files cannot be edited at the graph level.

Common Software Support

Support exists in Adobe Substance 3D applications and in third-party tools that provide Substance integrations, including Unreal Engine, Unity, Maya, 3ds Max, Cinema 4D, Houdini, Blender, MODO, Lumberyard, and CRYENGINE.

Additional Notes

The format is the published version of an SBS package, intended for distribution and use in Substance 3D applications or supported third-party applications.

SCN File Format Details

Overview

The .scn (Caligari Scene) format is TrueSpace's master container. It stores the complete scene graph, including lighting, cameras, skeletal hierarchies, rigging, and keyframe animations, linking individual .cob assets into a final scene.

What It Stores

The .scn (Caligari Scene) format is TrueSpace's master scene container. Unlike formats that only hold geometry, .scn stores the complete scene graph, encompassing multiple 3D objects, lighting setups, camera positions, hierarchical linking, skeletal rigging data (bones and IK constraints), and keyframe animation tracks.

Primary Use Cases

• Saving fully composed 3D environments and complex multi-object scenes.
• Storing comprehensive character animation data, including skeletal rigs, skinning, and keyframe timelines.
• Preserving render settings, global lighting rigs, and animated camera paths for final rendering output.

Strengths

• Acts as a comprehensive container capable of holding every element required for a final rendered image or animation sequence.
• Accurately retains TrueSpace's proprietary Inverse Kinematics (IK) solvers and vertex weighting for character rigs.
• Utilizes an efficient binary structure optimized for loading complex scene hierarchies and animation data natively within the software.

Limitations

• Deeply coupled with TrueSpace's internal memory state, making it incredibly difficult to export animated, rigged characters to other 3D applications.
• Highly proprietary structure that is completely inaccessible and unreadable without specialized conversion software or TrueSpace itself.

Common Software Support

Native support was virtually exclusive to Caligari TrueSpace. Because it stores complex, proprietary scene graphs and mathematical solvers rather than just raw geometry, third-party support was extremely rare. Even professional conversion tools of the era, such as Okino PolyTrans, often struggled to translate .scn rigging and animation data without breaking the hierarchy.

Additional Notes

The .scn format perfectly illustrates the "walled garden" architecture of 1990s 3D software. By tightly coupling geometry, rigging, and animation into a single, highly complex proprietary file, Caligari ensured optimal internal performance but inadvertently created massive interoperability bottlenecks for artists trying to move assets into early game engines or competing pipelines.

SCN File Format Details

Overview

The SCN file format is SceneKit's native scene format developed by Apple, used for 3D scenes in Apple apps on supported Apple platforms.

What It Stores

It can store SceneKit scene graphs, including node hierarchies, geometry, cameras, lights, materials, animations, and physics-related properties; SceneKit also supports physically based material and shading features.

Primary Use Cases

• Native Apple-platform SceneKit scene development for games and interactive 3D apps.
• Storing interactive 3D UI elements and animations for Apple ecosystem apps.
• Archiving SceneKit scene hierarchies, with Apple tooling supporting SceneKit asset preparation and optimization.

Strengths

• Integrated with Xcode's built-in 3D scene editor.
• Optimized for Apple graphics APIs and Apple's SceneKit renderer.
• Retains SceneKit scene data such as physics-related properties and other serialized scene objects.

Limitations

• Apple-specific and primarily supported in Apple tooling, so cross-platform support is limited.
• Unsupported by third-party engines like Unity or Unreal Engine.

Common Software Support

Supported natively by Apple Xcode's Scene Editor and the SceneKit framework for Swift and Objective-C apps.

SKP File Format Details

Overview

SKP is a native proprietary file format associated with Trimble SketchUp. It is designed for fast 3D modeling, especially in architectural workflows, and stores polygonal model data such as edges and faces.

What It Stores

It stores 3D geometry such as edges and faces, materials, textures, groups, components, and component-related attributes. It can also store scene-related data such as camera views, styles, shadow settings, section cuts, tag visibility, and geolocation information.

Primary Use Cases

• Architectural and interior design visualization.
• Generating construction floor plans.
• Rapid 3D prototyping for woodworking and fabrication.
• Asset creation for geolocated site-context and location-based visualization projects.

Strengths

• User-friendly handling of components and groups.
• Generally small file sizes for complex architectural layouts.
• Integration with Trimble's ecosystem and LayOut for 2D documentation.

Limitations

• Proprietary format often requires plugins, import support, or conversion for use outside SketchUp workflows.
• Performance can degrade significantly with high-poly organic meshes.

Common Software Support

Native to SketchUp. Supported via plugins or direct import in Lumion, V-Ray, Enscape, Twinmotion, and Autodesk Revit.

SLDASM File Format Details

Overview

The SLDASM file format is a native SolidWorks Assembly file used in computer-aided design (CAD). It references component part files and subassemblies to define a multi-component CAD assembly.

What It Stores

It stores spatial relationships, mates, component hierarchies, and design metadata. It primarily stores assembly definitions and references external component files; correct display usually depends on access to those referenced files.

Primary Use Cases

• Managing mechanical engineering assemblies.
• Defining parametric constraints between CAD components.
• Generating or supporting CAD-based bills of materials (BOMs) for assemblies.

Strengths

• Assemblies reference part files instead of duplicating full geometry, which can help keep files more manageable.
• Preserves complex parametric relationships and mates.

Limitations

• Requires external part files to display the assembly correctly.
• Limited native interoperability outside SolidWorks without conversion.

Common Software Support

Supported by SolidWorks, Autodesk Fusion through AnyCAD workflows, and specialized CAD viewers.

SLDPRT File Format Details

Overview

SLDPRT is the native 3D parametric part file format created by Dassault Systemes for SolidWorks. It is widely used in mechanical engineering, product design, and CAD workflows to build individual components.

What It Stores

It stores 3D part geometry and related design data such as features, materials, and metadata; in SolidWorks, it can also preserve parametric history and sketch-based feature definitions.

Primary Use Cases

• Parametric 3D part modeling and engineering.
• Creating components for larger CAD assemblies (SLDASM).
• Used in manufacturing workflows and often exported to neutral formats for CNC machining.
• Source data for high-fidelity 3D printing conversion.

Strengths

• Can preserve editable parametric history and feature definitions when opened in compatible SolidWorks tools.
• Stores exact CAD geometry rather than only mesh triangles.
• Supports precise CAD geometry suitable for manufacturing workflows.

Limitations

• Proprietary format with restricted native editability outside SolidWorks.
• Most slicers and mesh-based 3D tools require SLDPRT files to be converted first.

Common Software Support

Supported by SolidWorks, eDrawings Viewer, Autodesk Fusion, and Autodesk Inventor.

SPP File Format Details

Overview

An SPP file is the native proprietary project format used by Adobe Substance 3D Painter, the industry standard for 3D texturing. It is a non-destructive project file used to texture 3D models with PBR workflows.

What It Stores

The format stores project information such as the processed source mesh, baked mesh maps, materials, layer data, texture data, and resources used by layers, presets, or brush strokes. High-poly meshes are not included in the project file and are only linked.

Primary Use Cases

• Texturing game-ready assets and cinematic 3D models.
• Authoring PBR material maps for export into external pipelines.
• Storing baked maps used for texture painting.
• Saving production texture-painting projects for later use in studio pipelines.

Strengths

• Non-destructive layering supports iterative edits and texture resolution changes within project limits.
• Stores project information, including meshes, textures, and related metadata, in a proprietary project file.
• Supports non-destructive painting workflows that can be adapted to different texture resolutions.

Limitations

• Proprietary format limits direct editing outside compatible Substance tools.
• Large projects can become storage-heavy because they may include substantial project data and textures.

Common Software Support

SPP files are primarily authored and edited in Adobe Substance 3D Painter. SPP files may be tracked in production pipelines using asset-management tools.

SPZ File Format Details

Overview

SPZ is Niantic's compressed file format for 3D Gaussian splats, designed to make splats smaller, easier to share, and faster to load on web and mobile platforms.

What It Stores

The format stores 3D Gaussian splat data, including positions, alphas/opacities, colors, scales, rotations, and spherical harmonics.

Primary Use Cases

• Real-time web-based 3D visualization.
• Mobile and spatial-computing viewers that support Gaussian splats.
• Efficient distribution of large 3D Gaussian splat scenes.

Strengths

• Achieves file sizes roughly 10x smaller than uncompressed PLY files.
• Compresses 3-5x faster and loads 1.5-2x faster end-to-end than older iterations.
• Significantly reduces bandwidth requirements for spatial computing.

Limitations

• Lossy compression can slightly degrade visual fidelity compared to raw PLY data.
• Compatibility in traditional DCC applications may require plugins, importers, or conversion tools.

Common Software Support

Supported by Niantic's open-source SPZ library, Niantic Spatial and Scaniverse workflows, Niantic's web-based SPZ Converter, and PDAL's SPZ reader and writer.

STEP File Format Details

Overview

The Standard for the Exchange of Product model data (STEP) format is an ISO 10303 standard designed for the neutral exchange of product model data. It is widely used for sharing precise 3D CAD data between different modeling and manufacturing software applications. The format is commonly saved with either the STEP or STP file extension; these extensions are interchangeable and refer to the same underlying format.

What It Stores

It stores highly accurate 3D geometry, including boundary representation geometry, surface data, assembly hierarchies, and, in some application protocols, product manufacturing information. It is not primarily a polygon, texture, or animation format; its main focus is CAD geometry and product data.

Primary Use Cases

• Interoperable CAD data exchange between different software suites.
• Mechanical, product, and structural engineering design sharing.
• Manufacturing and CNC machining preparation.

Strengths

• High geometric precision using mathematical curves rather than polygonal approximations.
• Standardized, platform-independent ISO framework.
• Preserves complex assembly structures and component hierarchies.

Limitations

• Can produce large files, especially for complex geometry or assemblies.
• Not designed for textures, rigging, or animation workflows.

Common Software Support

Supported by major CAD platforms like Autodesk Inventor, Autodesk Fusion, SolidWorks, CATIA, Rhino, and FreeCAD.

STL File Format Details

Overview

STL (Stereolithography) is a widely used 3D file format originally developed by 3D Systems. It is a widely supported de facto standard in 3D printing and additive manufacturing workflows.

What It Stores

The format stores only the surface geometry of a 3D object using triangular facets. It can contain vertex coordinates and facet normals, but omits standard support for color, textures, material properties, rigging, animation, or scene hierarchy data.

Primary Use Cases

• Exporting digital assets for 3D printing slicing software.
• Rapid prototyping and manufacturing industrial components.

Strengths

• Widely supported across most 3D printing slicers and many 3D modeling tools.
• Simple, lightweight file structure that is easy to parse and process.

Limitations

• No standard support for materials, colors, or advanced scene information.
• Geometric precision is constrained by the density of the triangulated mesh.

Common Software Support

Supported by major CAD applications like SolidWorks and Autodesk Fusion, slicing engines like Cura and PrusaSlicer, and general 3D software tools like Blender.

STP File Format Details

Overview

The Standard for the Exchange of Product model data (STP) format is an ISO 10303 standard designed for the neutral exchange of product model data. It is widely used for sharing precise 3D CAD data between different modeling and manufacturing software applications. The format is commonly saved with either the STEP or STP file extension; these extensions are interchangeable and refer to the same underlying format.

What It Stores

It stores highly accurate 3D geometry, including boundary representation geometry, surface data, assembly hierarchies, and, in some application protocols, product manufacturing information. It is not primarily a polygon, texture, or animation format; its main focus is CAD geometry and product data.

Primary Use Cases

• Interoperable CAD data exchange between different software suites.
• Mechanical, product, and structural engineering design sharing.
• Manufacturing and CNC machining preparation.

Strengths

• High geometric precision using mathematical curves rather than polygonal approximations.
• Standardized, platform-independent ISO framework.
• Preserves complex assembly structures and component hierarchies.

Limitations

• Can produce large files, especially for complex geometry or assemblies.
• Not designed for textures, rigging, or animation workflows.

Common Software Support

Supported by major CAD platforms like Autodesk Inventor, Autodesk Fusion, SolidWorks, CATIA, Rhino, and FreeCAD.

TBSCENE File Format Details

Overview

The TBSCENE file format is the proprietary Toolbag Scene format used by Marmoset Toolbag to save all objects and data in the active Toolbag scene. It is used by 3D artists for real-time rendering, material editing, baking, and look development.

What It Stores

It stores Toolbag scene data, including scene objects such as meshes, materials, lights, cameras, texture projects, bake projects, shadow catchers, turntables, backdrops, and fog. It can also store mesh attributes such as animation, normals, UVs, vertex color, N-Gons, Sub-D, and displacement, while scene bundles can include referenced assets such as materials, meshes, textures, and skies.

Primary Use Cases

• Real-time look development and portfolio rendering.
• Managing high-to-low poly texture baking workflows.
• Creating real-time 3D presentation scenes.
• Authoring physically-based rendering (PBR) materials.

Strengths

• Preserves complex, real-time lighting and post-effect configurations.
• Centralizes PBR material setups, lighting, and baking parameters efficiently.
• Designed for Marmoset Toolbag's native scene workflow.

Limitations

• Proprietary format with limited native interoperability outside the Marmoset ecosystem.
• Referenced assets such as materials, meshes, textures, and skies may need to be bundled or kept in place to avoid missing asset paths.

Common Software Support

Marmoset Toolbag natively supports this format. Scene data can be exchanged with other 3D applications through supported import and export formats such as USD, FBX, OBJ, Alembic, DAE, PLY, STL, and Marmoset Mesh.

Additional Notes

Rather than serving as a cross-platform asset format, TBSCENE functions as a Toolbag scene file intended for rendering, baking, texturing, and look development within Marmoset Toolbag.

TSCN File Format Details

Overview

The Text Scene (TSCN) file format is a mostly human-readable file format native to the Godot Engine. It represents a single scene tree inside Godot, storing node trees, layouts, and configuration data within a project.

What It Stores

It stores node hierarchies, node properties, script attachments, animation-related scene data, connections, and references to external resources such as meshes, audio files, and textures.

Primary Use Cases

• Defining game levels and UI layouts in Godot.
• Facilitating version control and merging of scene structures in collaborative team workflows, though complex edits can still lead to merge conflicts.

Strengths

• Text-based format makes scene files easier to inspect and manage in version control.
• Easily readable and editable directly in a standard text editor.
• Lightweight and modular, with each TSCN file representing a self-contained scene that can be instanced or nested into other scenes.

Limitations

• Exclusive to the Godot Engine ecosystem.
• Loads slower than binary scene formats for massive or complex scenes.

Common Software Support

Natively supported by Godot Engine. Text editors such as VS Code and Notepad++ can open and edit TSCN files as text, but full scene interpretation and validation require Godot.

U3D File Format Details

Overview

Universal 3D (U3D) is a standardized, compressed file format designed for the exchange and visualization of 3D data. Developed by the 3D Industry Forum consortium, it is primarily recognized for its ability to embed interactive 3D models directly into PDF documents.

What It Stores

The format stores vertex-based geometry, colors, textures, lighting, shading, bones, and transform-based animation. It can also represent related scene information for downstream visualization.

Primary Use Cases

• Embedding interactive 3D content in Adobe PDF files.
• Sharing and visualizing engineering designs for downstream use and non-technical stakeholders.
• Technical documentation that includes embedded interactive 3D visuals.
• Used in some biomedical visualization workflows.

Strengths

• Compressed, streamable 3D data suitable for document embedding and downstream visualization.
• Supported for interactive 3D viewing in Adobe Acrobat and Reader when embedded in PDF.
• Standardized by ECMA-363.

Limitations

• Lacks support for complex rigging or modern shader systems.
• Support across 3D authoring tools has been uneven and is now limited.
• Often considered a legacy format compared to glTF or PRC.

Common Software Support

Supported in Adobe Acrobat and Adobe Reader for interactive 3D PDF viewing, Bluebeam Revu for creating 3D PDFs from U3D files, DAZ Studio for U3D export, and specialized CAD or 3D conversion tools such as CAD Exchanger.

UASSET File Format Details

Overview

The UASSET file format is a container used by Unreal Engine to store package data for many engine assets. These files store Unreal Engine asset data generated or saved by the editor from imported or created content, supporting engine-specific runtime and editor workflows.

What It Stores

It acts as a package file for diverse asset types, including static and skeletal meshes, textures, materials, Blueprints, and physics assets. It also retains metadata, serialized object properties, and references or dependencies to other project assets.

Primary Use Cases

• Managing project assets within the Unreal Engine Editor.
• Packaging optimized content for deployment on consoles, PC, and mobile.
• Distributing marketplace content and plugin-specific resources.

Strengths

• Optimized for fast loading and memory management during runtime.
• Maintains complex internal relationships and serialized data.
• Ensures consistency across different hardware platforms through the engine's cooking process.

Limitations

• Proprietary format that cannot be opened in standard 3D modeling software.
• Version-sensitive. Assets saved in newer Unreal Engine versions may not open correctly in older versions.

Common Software Support

Natively supported by Unreal Engine, with limited support in some third-party tools.

UNITY File Format Details

Overview

The UNITY file format is the native scene file used by the Unity game engine. It functions as a collection of GameObjects, settings, and references that define a single level, environment, or menu within a project.

What It Stores

It stores scene hierarchy, GameObject and Component data, lighting-related settings, and references to external assets such as meshes and materials. It commonly uses Unity's text-based YAML serialization for human-readable scene files.

Primary Use Cases

• Building and organizing game levels and interactive environments.
• Storing scene layouts, object placement, and component configurations.
• Managing gameplay elements, cameras, lighting, and UI within a scene.

Strengths

• Highly efficient for organizing complex object hierarchies.
• Designed to integrate with Unity's Prefab system and collaborative version control workflows.
• YAML serialization can make scene files easier to merge and manage in version control workflows.

Limitations

• Proprietary format with limited support outside the Unity ecosystem.
• Broken asset GUID references can result in missing scene dependencies and object links.

Common Software Support

Primarily supported by the Unity Editor. Version control tools such as Git and Unity Version Control are commonly used to manage these files.

Additional Notes

Because UNITY files rely heavily on unique identifiers (GUIDs), moving assets outside the editor can break scene references.

UNITYPACKAGE File Format Details

Overview

The UNITYPACKAGE format is a Unity asset package file used by the Unity Editor to bundle and share assets. It facilitates the seamless transfer of complex resources between different projects while maintaining internal references and metadata.

What It Stores

It can contain Unity assets such as 3D models, textures, scripts, shaders, and audio files, along with associated metadata and import settings. It can also preserve Unity-specific assets such as Prefabs and Animator Controllers, along with GUIDs from Unity metadata used to maintain asset references.

Primary Use Cases

• Distributing assets on the Unity Asset Store.
• Porting specific features between internal development projects.
• Sharing collaborative tools or plugins across teams.

Strengths

• Preserves complex component hierarchies and script references.
• Bundles selected assets and folders into a single portable file.
• Allows selective importing of specific items within the package.

Limitations

• Proprietary format designed for the Unity ecosystem.
• Can cause GUID conflicts if identical assets exist in the destination.
• No native preview capability outside of the Unity Editor.

Common Software Support

Primarily supported by the Unity Editor. Limited extraction is possible via third-party utilities, but functional integrity requires the Unity environment.

UPROJECT File Format Details

Overview

A UPROJECT file is a human-readable Unreal Engine project descriptor that contains metadata and configuration used by Unreal Engine to open and manage a project. It acts as the project descriptor that allows the Unreal Editor to identify the engine association, plugins, and associated modules.

What It Stores

It commonly stores the engine association, a list of enabled or disabled plugins, and project modules, including module metadata such as loading phase.

Primary Use Cases

• Initializing the Unreal Editor for a specific game project.
• Managing plugin dependencies across a development team.
• Identifying the specific engine build required to launch the project.
• Declaring project modules used by Unreal Engine build and startup workflows.

Strengths

• Text-based structure makes it relatively easy to inspect and edit manually.
• Lightweight and stores only high-level configuration data.
• Stores engine association information used when opening or switching projects between engine installations.

Limitations

• Does not contain actual assets like meshes or textures.
• Corruption of this file can prevent the project from launching.

Common Software Support

It is used by Unreal Engine project workflows, including Unreal Engine 4 and 5, Unreal Build Tool, and IDE integrations such as Visual Studio's Unreal Engine project support.

USD File Format Details

Overview

The Universal Scene Description (USD) is an extensible, high-performance framework developed by Pixar for authoring, reading, streaming, and interchanging 3D scene description. It is designed to handle massive datasets and complex scene hierarchies across distributed pipelines.

What It Stores

USD can store geometry, animation, shading, lighting, and other scene description data. Its core strength lies in layers and composition arcs, allowing references, variants, payloads, and non-destructive overrides of scene data.

Primary Use Cases

• Feature film and VFX production pipelines.
• Building large-scale digital twins and omniverse environments.
• Interchange between DCC tools like Houdini, Maya, and Katana.

Strengths

• Efficient data reading and streaming through USD's binary .usdc format.
• Non-destructive editing via powerful layering systems.
• Strong support for "instancing" to manage millions of assets efficiently.

Limitations

• High learning curve due to complex composition logic.
• Varying levels of implementation across different software plugins.

Common Software Support

Supported natively or via plugins in Houdini, Maya, Blender, Katana, and NVIDIA Omniverse.

Additional Notes

USD can support a single composed view of shared scene data, helping multiple departments collaborate without overwriting each other's work.

USDA File Format Details

Overview

Universal Scene Description ASCII (USDA) is the human-readable ASCII file encoding of Pixar's USD framework. It is widely used in high-end VFX and animation pipelines to facilitate robust scene assembly and collaborative workflows across different software packages.

What It Stores

USDA files can contain scene hierarchies, geometry, materials, lights, animation, and metadata. They support non-destructive layering, references, variants, and sparse overrides without changing the original assets.

Primary Use Cases

• Large-scale VFX and feature animation scene assembly.
• Inter-studio asset exchange and collaborative pipeline integration.
• Defining complex variants for character outfits or environmental states.
• Widely used interchange for real-time engines and offline renderers.

Strengths

• Human-readable format makes debugging and manual edits straightforward.
• Strong non-destructive editing through layers and references.
• Well suited for reviewing scene data changes in version control.

Limitations

• Larger file sizes compared to the binary USDC equivalent.
• USDA is generally slower to parse than binary USD formats such as USDC.

Common Software Support

Supported natively or through USD plugins and import/export workflows in Maya, Houdini, Blender, Cinema 4D, Unreal Engine, Unity, and NVIDIA Omniverse.

Additional Notes

USDA is one of the OpenUSD file encodings and can be converted to USDC or packaged as USDZ when needed.

USDC File Format Details

Overview

USDC is USD's Crate binary file format, developed by Pixar as part of Universal Scene Description. It is designed for efficient reading, compact storage, and high-performance access to scene description in complex 3D production pipelines and large-scale scene assemblies.

What It Stores

It stores USD scene description data including geometry, materials, lights, cameras, animation, and other authored scene data. It supports layers, references, variants, and sparse overrides, allowing scene data to be composed non-destructively.

Primary Use Cases

• Efficient 3D scene exchange and storage in USD-based pipelines.
• High-speed data caching for complex VFX pipelines.
• Cross-departmental scene assembly in feature film production.

Strengths

• Fast load times due to its Crate binary structure.
• Highly efficient for large datasets and complex scene data.
• Robust support for complex non-destructive layering.

Limitations

• Binary format is not human-readable for manual debugging.
• Full manipulation usually requires USD-compatible tools or libraries.

Common Software Support

Widely supported in Pixar RenderMan, Autodesk Maya, SideFX Houdini, Blender, and NVIDIA Omniverse.

Additional Notes

USDC is losslessly and bidirectionally convertible to the USDA text format, but it is optimized for compact storage and efficient access rather than human readability.

USDZ File Format Details

Overview

USDZ is a zero-compression, unencrypted ZIP archive package format for Universal Scene Description (USD) assets. It is widely used for delivering 3D and augmented reality content on Apple platforms.

What It Stores

The format bundles one or more USD files and their referenced assets into a single package. A USDZ package may contain USD, USDA, USDC, PNG, JPEG, M4A, MP3, and WAV files.

Primary Use Cases

• Delivering web-based AR content via Quick Look on supported Apple platforms.
• Showcasing 3D products in e-commerce and retail environments.
• Sharing animated 3D assets across mobile messaging and mail apps.

Strengths

• Single-file portability eliminates broken texture paths.
• Designed for efficient direct access to packaged assets without decompressing the archive.
• Native, plugin-free integration within the Apple ecosystem.

Limitations

• Read-only format that is difficult to edit directly without unpacking.
• Primarily restricted to Apple platforms for native AR viewing.

Common Software Support

Supported by Apple Quick Look, Reality Composer and Reality Composer Pro workflows, OpenUSD tools, Adobe Substance 3D Painter's USDz export template, and USD-capable DCC or platform workflows with USDZ import/export support.

VDB File Format Details

Overview

OpenVDB (VDB) is an open-source C++ library comprising a hierarchical data structure and tools for the efficient storage and manipulation of sparse volumetric data, with an associated .vdb file format. Originally developed by DreamWorks Animation, it is widely used in high-end visual-effects workflows involving gaseous and volumetric simulations.

What It Stores

The format stores sparse volumetric grids, including density, velocity, temperature, and color data. It uses a hierarchical tree-like data structure optimized for sparse grids such as narrow-band level sets and fog volumes, avoiding explicit storage of empty space.

Primary Use Cases

• Simulating realistic smoke, fire, and explosions.
• Representing complex cloud formations and atmospheric haze.
• Storing liquid surfaces via level-set conversions.
• Facilitating volumetric lighting and rendering in offline engines.

Strengths

• High memory efficiency by storing only active voxels, especially for sparse volumes.
• High-performance access to spatially organized data.
• Robust toolkit for filtering, resampling, and boolean operations.
• Wide adoption across the professional VFX pipeline.

Limitations

• File sizes can grow very large for high-resolution, multi-channel, or time-varying sequences.
• Real-time engine support may require conversion, specialized workflows, or engine-specific volume systems.

Common Software Support

Common Software SupportSupported by Houdini, Blender, and Cinema 4D for OpenVDB volume workflows. Maya and Katana can use OpenVDB through supported renderer or pipeline integrations such as Arnold, RenderMan, Redshift, or other compatible volume workflows. Major renderers such as Arnold, RenderMan, V-Ray, Redshift, and OctaneRender support OpenVDB grids for volumetric rendering. Unreal Engine supports importing VDB files into Sparse Volume Texture workflows.

VOX File Format Details

Overview

The VOX format is the native file format for MagicaVoxel, a lightweight voxel art editor and renderer. It is a RIFF-style binary format designed to store voxel models and scene data.

What It Stores

It stores voxel model data as x, y, z, and color index values, with 1 byte for each component. Extended VOX files can also store multiple models, palette data, scene graph information such as transform, group, and shape nodes, and material properties such as diffuse, metal, glass, and emit.

Primary Use Cases

• Creating stylized 3D pixel art assets for indie games.
• Prototyping environmental layouts and character models.
• Exporting voxel geometry to mesh-based formats for rendering.

Strengths

• Compact file size for complex volumetric structures.
• Preserves the distinct blocky aesthetic without complex topology.
• Simplified workflow for artists transitioning from 2D to 3D.

Limitations

• Uses palette-based color data rather than full material or texture workflows.
• Does not support traditional vertex-based rigging or skeletal animation.

Common Software Support

Natively supported by MagicaVoxel. Blender support is available through the Blender Extensions MagicaVoxel VOX importer, while Unity and Unreal Engine workflows generally require third-party importers or conversion to supported mesh formats.

VRM File Format Details

Overview

VRM is an open-source, platform-independent file format specifically designed for handling humanoid 3D avatar data. Built on the glTF 2.0 framework, it serves as a standardized bridge for using consistent characters across various VR applications, platforms, games, and avatar workflows.

What It Stores

The format encapsulates 3D mesh data, UV maps, textures, and materials. It includes humanoid bone structures, character expressions such as Blend Shape, first-person perspective information, spring bone settings, and metadata such as title, author, and avatar-specific license information.

Primary Use Cases

• VRM-compatible social VR platforms and avatar workflows.
• VTubing and live-streaming performances.
• Interoperable metaverse identities.
• 3D character creation and distribution.

Strengths

• Standardized humanoid bone configuration helps avatars work consistently across supported software.
• Simplifies avatar deployment by packing textures and settings into a single file.
• Features built-in license management for creator protection.

Limitations

• Strictly limited to humanoid skeletons; non-humanoid creatures are unsupported.
• Performance can vary based on the host application's handling of specific shaders such as MToon.

Common Software Support

Supported by Unity through UniVRM, Blender through the VRM Add-on for Blender, VRoid Studio for VRM export, and VRM-compatible avatar applications such as VSeeFace.

VROID File Format Details

Overview

The VROID format is a file format unique to VRoid Studio, used to save, load, and edit 3D model data in VRoid Studio. It acts as a working file for customizable, anime-style 3D humanoid avatars.

What It Stores

It stores editable VRoid model data, including the VRoid base model, hairstyle, costume data, textures, parameters, and related settings used by VRoid Studio.

Primary Use Cases

• Creating base models for VTubing.
• Exporting avatars to VRM for use in VRoid Hub, VR platforms, games, and other compatible applications.

Strengths

• Preserves editable hairstyle data so the model can be further adjusted in VRoid Studio.
• Integrates tightly with the VRoid Studio workflow and VRoid Hub export pipeline.
• Simplifies humanoid avatar creation by keeping editable model settings inside VRoid Studio.
• Well suited for stylized, anime-inspired character aesthetics.

Limitations

• Proprietary format not natively supported by most standard 3D suites.
• Designed for humanoid avatars rather than arbitrary character topologies.

Common Software Support

Primarily supported by VRoid Studio. Models are typically exported to VRM for use in VRoid Hub, VRM-compatible applications, and other tools or game engines, often with additional import or conversion steps.

VRSCENE File Format Details

Overview

The VRSCENE format is a portable ASCII scene file used by V-Ray. It acts as a bridge for sharing scene data across supported V-Ray platforms and host applications.

What It Stores

It can store scene descriptions including geometry, lights, shaders, textures, materials, and animation data.

Primary Use Cases

• Transferring assets between supported V-Ray integrations such as 3ds Max, Maya, Cinema 4D, and other host applications that support V-Ray scene files.
• Moving scenes to render nodes or standalone rendering workflows.
• Real-time visualization and presentation in Chaos Vantage.

Strengths

• Broad interoperability: assets can be transferred across supported V-Ray platforms with consistent scene data.
• In supported workflows, it can let complex scenes be handled externally rather than fully rebuilt in the host application.
• Can be exported with archive or asset-collection workflows to help package related scene assets for transfer.

Limitations

• Requires V-Ray or Chaos software to read or render correctly.
• Difficult to modify geometry once exported; changes usually happen in the source file.

Common Software Support

Commonly supported in V-Ray workflows across host applications such as 3ds Max, Maya, Cinema 4D, SketchUp, Rhino, Revit, Houdini, Blender, and Katana, as well as V-Ray Standalone and Chaos Vantage.

WRL File Format Details

Overview

The WRL file extension is used for Virtual Reality Modeling Language (VRML) files, a legacy text-based scene description format for interactive 3D worlds. It was primarily created for web browsers to render 3D scenes before the advent of modern web graphics standards.

What It Stores

It stores 3D polygonal geometry, vertex positions, normals, surface colors, material properties, textures, lighting, and viewpoint configurations. It can also contain animation and interactive behaviors, including scripted actions, sensors, and event routing.

Primary Use Cases

• Archiving legacy web-based 3D assets.
• Used in some legacy CAD/DCC workflows and some color 3D-printing workflows.
• Importing retro interactive geometry into modern DCC tools.

Strengths

• Human-readable text structure with a UTF-8 VRML header.
• Native support for embedding basic scene illumination and camera viewpoints.
• Early ISO-standardized format for Web-oriented interactive 3D scenes.

Limitations

• Largely legacy in modern workflows and less suited than modern formats for many current web/runtime and production pipelines.
• Lacks robust support for modern character pipelines, advanced materials, or shader workflows.

Common Software Support

3ds Max has documented VRML97/WRL import and export support. Blender's Web3D X3D/VRML2 add-on supports WRL import and X3D export, not WRL export. SolidWorks supports VRML/WRL import and export, while some specialized 3D printing workflows use WRL for color-capable model exchange.

X_B File Format Details

Overview

The X_B format is the binary Parasolid file format associated with the Parasolid geometric modeling kernel. It is widely used in CAD workflows for precise manufacturing and engineering data exchange.

What It Stores

It stores precise Parasolid model geometry, including boundary representation geometry, surfaces, solids, topology, and related model data. Unlike mesh formats, it preserves CAD geometry rather than polygonal approximations, but generally excludes lighting, animation, visual textures, feature history, and parametric constraints.

Primary Use Cases

• High-fidelity data exchange between CAD platforms like SolidWorks and NX.
• Storing precise Parasolid model data in a compact binary format.
• Preparing precise geometric data for CAM and CNC machining.

Strengths

• Binary encoding results in significantly smaller file sizes compared to text-based X_T.
• Preserves precise CAD geometry for industrial manufacturing workflows.
• Faster load and save times due to its non-textual structure.

Limitations

• Not human-readable, making manual inspection or debugging difficult.
• Strictly focused on CAD; lacks support for rigging or polygon-specific features.

Common Software Support

Supported by Parasolid-based CAD/CAM systems such as Siemens NX, Solid Edge, SolidWorks, and Mastercam. Autodesk Fusion supports Parasolid Binary (X_B) in eligible license workflows, while other CAD tools may support Parasolid import/export depending on version and translator availability.

X_T File Format Details

Overview

The X_T format is the Parasolid text file format associated with the Parasolid geometric modeling kernel. It is primarily used for high-fidelity data exchange between engineering and manufacturing software.

What It Stores

It stores precise boundary representation geometry, including solids, surfaces, curves, wireframes, and topological relationships. It can also retain color and component names in assemblies when supported by the exporting and importing systems.

Primary Use Cases

• Interoperability between different CAD systems like SolidWorks and NX.
• Preparation of high-precision models for CNC machining and CAM workflows.
• Archiving high-precision Parasolid geometry and related model data in a widely supported exchange format.

Strengths

• High geometric accuracy for curved surfaces and complex solids.
• Broadly interoperable across CAD systems that support the Parasolid kernel.
• Text-encoded Parasolid format that can be inspected in a text editor and exposes structural/model data, but is not intended for practical hand-editing.

Limitations

• Designed for exact B-rep geometry rather than mesh exchange, and it is not meant for animation or rendering shader data.
• Large files may import more slowly than equivalent X_B files due to their text-based encoding.

Common Software Support

Native to Siemens NX and Solid Edge. Supported by Parasolid-based CAD/CAM systems such as SolidWorks and Mastercam, and by other CAD tools through Parasolid import/export or translation workflows, including Autodesk Fusion in eligible license workflows.

X3D File Format Details

Overview

Extensible 3D (X3D) is a royalty-free ISO standard for representing and communicating 3D scenes and objects. It serves as the successor to Virtual Reality Modeling Language (VRML), providing a framework for web-based 3D graphics, visualization, and interactive 3D applications.

What It Stores

The format stores 3D geometry, appearance properties, lighting, and spatial hierarchy. It also supports keyframe animation, Humanoid Animation (HAnim), shaders, and interactive event-driven scripting.

Primary Use Cases

• Web-based 3D visualization and interactive applications.
• Standardized archival of 3D CAD and engineering models.
• Medical imaging and geospatial data representation.
• Cross-platform asset exchange in open-source pipelines.

Strengths

• ISO/IEC standardized, supporting long-term stability and platform independence.
• Multiple encodings (including XML) enable easy parsing and web integration.
• Highly extensible through a modular profile and component system.

Limitations

• Primary XML encoding is verbose and larger than compact binary formats like glTF.
• Limited native support in modern AAA game engines.

Common Software Support

Supported by Blender through its Web3D X3D/VRML2 import-export add-on, FreeCAD and MeshLab in supported import/export workflows, and Okino PolyTrans for conversion workflows. Web integration is commonly handled through X3DOM or X_ITE.

XPS File Format Details

Overview

The XPS file format is associated with XNALara/XPS character model files used by XNALara and XPS posing software. It gained traction within gaming fan-art communities for posing and rendering game character models.

What It Stores

In the XNALara/XPS ecosystem, XPS model files typically contain mesh data, vertex information, UVs, materials, texture references, and skeletal rigging.

Primary Use Cases

• Custom character posing and fan-art rendering.
• Extracting and archiving video game character models.
• Digital asset sharing across community forums.

Strengths

• Pre-configured rigging allows character models to be posed after import.
• Supported by community tools that help convert and reuse character models across workflows.
• Strong community-driven repository of compatible assets.

Limitations

• Lacks native support for advanced physics, complex animations, or modern PBR materials.
• Limited interoperability without third-party plugins.

Common Software Support

Supported by XNALara and XPS posing software. Blender import and export support is available through community add-ons such as XNALaraMesh, with compatibility depending on Blender version and add-on maintenance.

XSI File Format Details

Overview

The dotXSI (XSI) format is a 3D scene data exchange format developed for Softimage, later acquired by Autodesk. It was used in legacy production pipelines, including game development and film-related workflows, for exchanging scene and asset data.

What It Stores

It stores scene data such as models, characters, animation, hierarchies, materials, and user data; support for additional data types may vary by version and software implementation. It supports character and animation data used in rigged-character workflows, though the exact deformation and animation fields depend on the exporter/importer version.

Primary Use Cases

• Transporting rigged characters and animations between legacy DCC platforms.
• Encoding retro game assets for custom engines utilizing historical formats.
• Interchanging scene and asset data within discontinued Autodesk Softimage production environments.

Strengths

• Strong support for character, hierarchy, material, and animation exchange in legacy Softimage workflows.
• ASCII dotXSI files can be inspected or processed with custom pipeline tools.
• Robust interoperability during its peak era via Autodesk Crosswalk and the Crosswalk SDK.

Limitations

• The format is functionally deprecated, following Softimage's end-of-life status.
• Modern DCC platforms and contemporary game engines generally lack native, out-of-the-box support.

Common Software Support

Historically supported by Autodesk Softimage. Crosswalk-enabled 3ds Max and Maya installations could read dotXSI through the Crosswalk plug-ins. Third-party or legacy tool support should be verified per application version and plugin documentation.

YDD File Format Details

Overview

The YDD file format is a proprietary GTA V asset container known as a Drawable Dictionary, used in Rockstar Advanced Game Engine (RAGE)-based asset workflows. It is commonly used in GTA V character and clothing modding workflows, especially for ped components, ped props, and other drawable collections.

What It Stores

YDD files store collections of GTA V drawable objects, commonly including ped components, ped props, clothing models, LOD models, mesh minimaps, and instanced props, depending on the asset type and workflow.

Primary Use Cases

• Modding custom character clothing and accessories for GTA V.
• Implementing optimized LOD models for game performance.
• Deploying custom drawable assets in GTA V modding and multiplayer server workflows such as FiveM.

Strengths

• Structured for GTA V/RAGE drawable workflows and real-time in-game rendering.
• Efficiently packages multi-tier LOD structures within a single asset.

Limitations

• Proprietary format with no native compatibility in standard 3D DCC tools.
• Complex game-specific structure makes manual editing or merging difficult without dedicated tools.

Common Software Support

Supported by community GTA V modding tools such as OpenIV, CodeWalker, Sollumz, and Durty Cloth Tool. Blender workflows commonly use Sollumz together with CodeWalker XML export/import, while Durty Cloth Tool focuses on GTA V clothing and tattoo pack workflows.

ZPAC File Format Details

Overview

The ZPAC format is a proprietary garment file format used by CLO 3D and Marvelous Designer. It stores garment-related data for digital clothing workflows, including 3D garments, 2D patterns, fabrics, and related garment materials.

What It Stores

A ZPAC file contains garment-related data such as 3D garments, 2D patterns, sewing information, fabrics, and subsidiary materials. It may also save selected garment and trim information, depending on what is included when the garment file is saved.

Primary Use Cases

• Saving and reopening editable digital garment files for fashion production.
• Managing virtual fitting and simulation data for garment visualization.

Strengths

• Keeps garment-related data together in a single editable garment file.
• Retains garment simulation-related data such as fabrics, sewing information, and 2D/3D garment structure.
• Maintains the link between 2D patterns and the simulated 3D garment.

Limitations

• Proprietary format with limited support in general-purpose 3D software.
• Requires export to OBJ or FBX for use in external renderers or game engines.

Common Software Support

Primarily supported by CLO 3D and Marvelous Designer.

ZPR File Format Details

Overview

The ZPR format is the native, proprietary project file used by Pixologic ZBrush. It acts as a comprehensive container that preserves the entire creative environment, including multiple subtools, undo history, and custom settings.

What It Stores

It contains loaded Tools and SubTools, high-resolution sculpting data, layers, polypaint information, canvas document information, assigned materials, lighting and rendering-related project data, timeline animation, and undo history when enabled.

Primary Use Cases

• Saving active high-fidelity sculpting projects for long-term production.
• Archiving complex scenes with multiple sub-objects and layers.
• Transferring full ZBrush sessions between workstations while retaining undo steps when Undo History saving is enabled.
• Preparing high-poly models for 3D printing or retopology.

Strengths

• Stores the entire project state, not just individual models.
• Preserves the Undo History, allowing artists to backtrack through thousands of steps.
• Retains project-level document, material, lighting, rendering, and timeline data for consistency.

Limitations

• Project files can become very large, especially with high-density sculpt data or Undo History saving enabled.
• Proprietary format with virtually no compatibility outside of ZBrush.

Common Software Support

Primarily supported by Maxon ZBrush. It cannot be opened directly in standard DCC tools like Blender or Maya without exporting to an interchange format.

ZPRJ File Format Details

Overview

The ZPRJ format is the proprietary project file type for Marvelous Designer and CLO 3D. It compresses the various files used for garment creation into one project file, integrating garment, avatar, scene, and simulation-related data.

What It Stores

This format contains avatar-related data from an AVT file, garment-related data from a ZPAC file, and animation data if animation is present. This can include avatar data, accessories, arrangement bounding volumes, arrangement points, avatar size, poses, 3D garments, 2D patterns, fabrics, subsidiary materials, 3D environment settings, and user-set simulation options.

Primary Use Cases

• Developing high-fidelity digital clothing for film and AAA games.
• Fashion design prototyping and virtual fitting.
• Creating realistic cloth assets for 3D marketplaces.
• Simulating fabric behavior for visualization.

Strengths

• Maintains non-destructive sewing and pattern relationships.
• Preserves complex physical simulation presets for specific fabrics.
• Bundles all necessary textures and accessories into a single file.

Limitations

• Proprietary format with limited direct compatibility in external DCC tools.
• Project files may become large because they can include avatar-related data, garment-related data, animation data, 3D environment settings, and user-set simulation options.

Common Software Support

Native to Marvelous Designer and CLO 3D. Assets are typically exported to interchange formats such as OBJ, FBX, Alembic, USD, glTF/GLB, or other supported formats for use in external DCC tools, renderers, or game engines.

ZTL File Format Details

Overview

The ZTL format is the proprietary ZBrush Tool file format used by Maxon ZBrush. It is primarily used to save a selected Tool, including its SubTools and sculpting-related model data.

What It Stores

It stores ZBrush Tool data such as high-resolution polygon geometry, SubTools, subdivision levels when present, PolyPaint, masking, layers, UV and texture-related data, and Tool-specific settings such as FiberMesh-related data when used.

Primary Use Cases

• Saving high-fidelity digital sculptures for iterative work.
• Moving detailed assets between different ZBrush projects.
• Storing master sculpts with intact subdivision levels.
• Distributing highly detailed 3D printable models.

Strengths

• Supports ZBrush workflows with high polygon counts and multiple SubTools.
• Preserves Tool and SubTool sculpt data, including subdivision levels when present.
• Often more suitable than OBJ or STL for keeping ZBrush-specific sculpting data editable.

Limitations

• Proprietary format restricted almost exclusively to ZBrush.
• Does not store the full ZBrush project session, canvas document information, timeline animation, or global project settings saved in ZPR files.

Common Software Support

Primarily supported by Maxon ZBrush and ZBrushCore. External workflows typically require exporting to interchange formats or using ZBrush bridge workflows such as GoZ, rather than opening ZTL files directly in standard DCC tools.