New format: M3D #105447

New Issue

cretaceous1 · 2024-08-21T08:07:26+02:00

cretaceous1 commented

2024-08-21 08:07:26 +02:00

Please support Import and Export in the M3D format

Model 3D File Format

https://gitlab.com/bztsrc/model3d
Check out the Model 3D homepage for .m3d file samples. If you find any problem with the
M3D SDK, please use the issue tracker and let me know.

Rationale

In the last 30 years or so many file formats were invented to store 3D models. As a result, nowdays many formats are in use, but
unfortunatelly all of them lack one or more key features, and neither of them can be used to store a single 3D model conveniently.
Either they are too simple (only capable of storing static models, like .OBJ, .PLY, .STL etc.) or highly overcomplicated to store
entire scenes with multiple models and huge pile of unnecessary info (like .BLEND, .DAE, .X3D, .glTF, .FBX etc. Of course those
additional lightning, camera, physics etc. info are only unnecessary if you're just interested in loading a model, like in a game
engine for example). That complexity often leads to problem when interchaning models between software. Also existing scene formats
are often utilize a highly uneffective storage representation which makes them inefficient for model distribution (yes, that
clearly stands for .glTF too, despite the fact they claim otherwise). Also the most useful formats are poorly documented (.STEP,
.B3D, .BLEND etc.) or proprietary (like .FBX, .PBX, .MAX, etc.), so it is questionable if one can use those in their projects at
all and if so, how. Yes there are libraries to come around some of these obsticles, but most importantly they do not solve the
issue of missing capabilities nor distribution compactness in file formats, and they often introduce unnecessarity additional
complexity to the build-environment (like the .FBX SDK for example).

This Model 3D format was designed to address all of the
shortcomings of the existing current formats, so that it can became a truely universal 3D model container and ease all developer's
and model designer's minds, consistently parsed by all software while being easy on network traffic at the same time:

Features

the format is freely usable, MIT licensed (unlike .PBX, .MAX or .C4D)

also has an ASCII representation for exchange and easy debugging (unlike .BLEND or .B3D, similar to .OBJ but with skeletal animation support)

stores exactly one model with all its aspects, but nothing else (unlike .FBX, .X3D, .BLEND; just like .PLY)

has the biggest information density of all the formats (a cube can be stored in as little as 119 bytes)

can store huge number of vertices in magnitude of billions (unlike .3DS)

can store color maps as well as texture maps and materials

can store inlined textures (ideal for model distribution)

can store precise normal vectors, not just smoothing groups (unlike .3DS)

can store voxel images, polygon mesh, procedural surfaces and procedural textures*

can store parameterized mathematical surfaces, like NURBS (and other CAD information)

can store skeleton based animations (unlike .MD3, which uses vertex morph only, or .MD5 which has separate files for anims)

can store actions, several named animation frames within the same file

can store model with absolute scaling factor and face thickness for 3D printing (is there any format that can do these?)

utilizes engine agnostic data structure, focuses on storing what's relevant for the model representation, not for the engines

supports material libraries in separate files if needed (using the same format)

expandable in nature, additional information can be easily added if needed without breaking compatibility with other applications

flexible data types (similar to .PLY, but much simpler, coordinate precision from 8 bits to 64 bits (int8_t to double))

compact file size, damn easy to interpret without third-party libraries** (~80 SLoC see below, unlike .FBX, .X3D, .glTF or .X)

the SDK follows the K.I.S.S. principle, MIT licensed just as the format itself, easy to integrate into any project

(* - you provide a script interpreter callback for the SDK, so you can use any scripting language you like, eg. Lua, Python, whatever)

(** - the model's data may be stream compressed, however a) this is optional, and b) the SDK has a built-in decompressor. You won't
need any third-party libraries to use the SDK, like JSON or XML libraries, libpng, zlib etc. it is dependency-free.)

Please support Import and Export in the M3D format Model 3D File Format ==================== > https://gitlab.com/bztsrc/model3d > Check out the [Model 3D homepage](https://bztsrc.gitlab.io/model3d/) for .m3d file samples. If you find any problem with the M3D SDK, please use the [issue tracker](https://gitlab.com/bztsrc/model3d/issues) and let me know. > ## Rationale > In the last 30 years or so many file formats were invented to store 3D models. As a result, nowdays many formats are in use, but unfortunatelly all of them lack one or more key features, and neither of them can be used to store a single 3D model conveniently. Either they are too simple (only capable of storing static models, like .OBJ, .PLY, .STL etc.) or highly overcomplicated to store entire scenes with multiple models and huge pile of unnecessary info (like .BLEND, .DAE, .X3D, .glTF, .FBX etc. Of course those additional lightning, camera, physics etc. info are only unnecessary if you're just interested in loading a model, like in a game engine for example). That complexity often leads to problem when interchaning models between software. Also existing scene formats are often utilize a highly uneffective storage representation which makes them inefficient for model distribution (yes, that clearly stands for .glTF too, despite the fact they claim otherwise). Also the most useful formats are poorly documented (.STEP, .B3D, .BLEND etc.) or proprietary (like .FBX, .PBX, .MAX, etc.), so it is questionable if one can use those in their projects at all and if so, how. Yes there are libraries to come around some of these obsticles, but most importantly they do not solve the issue of missing capabilities nor distribution compactness in file formats, and they often introduce unnecessarity additional complexity to the build-environment (like the .FBX SDK for example). > [This Model 3D format](https://gitlab.com/bztsrc/model3d/blob/master/docs/m3d_format.md) was designed to address all of the shortcomings of the existing current formats, so that it can became a truely universal 3D model container and ease all developer's and model designer's minds, consistently parsed by all software while being easy on network traffic at the same time: > ### Features > - the format is freely usable, MIT licensed (unlike .PBX, .MAX or .C4D) > - also has an [ASCII](https://gitlab.com/bztsrc/model3d/blob/master/docs/a3d_format.md) representation for exchange and easy debugging (unlike .BLEND or .B3D, similar to .OBJ but with skeletal animation support) > - stores exactly one model with all its aspects, but nothing else (unlike .FBX, .X3D, .BLEND; just like .PLY) > - has the biggest information density of all the formats (a cube can be stored in as little as 119 bytes) > - can store huge number of vertices in magnitude of billions (unlike .3DS) > - can store color maps as well as texture maps and materials > - can store inlined textures (ideal for model distribution) > - can store precise normal vectors, not just smoothing groups (unlike .3DS) > - can store [voxel](https://gitlab.com/bztsrc/model3d/blob/master/docs/voxel_format.md) images, polygon mesh, procedural surfaces and procedural textures* > - can store parameterized mathematical surfaces, like [NURBS](https://gitlab.com/bztsrc/model3d/blob/master/docs/shape.md) (and other [CAD](https://gitlab.com/bztsrc/model3d/blob/master/docs/CAD.md) information) > - can store skeleton based animations (unlike .MD3, which uses vertex morph only, or .MD5 which has separate files for anims) > - can store actions, several named animation frames within the same file > - can store model with absolute scaling factor and face thickness for 3D printing (is there any format that can do these?) > - utilizes engine agnostic data structure, focuses on storing what's relevant for the model representation, not for the engines > - supports material libraries in separate files if needed (using the same format) > - expandable in nature, additional information can be easily added if needed without breaking compatibility with other applications > - flexible data types (similar to .PLY, but much simpler, coordinate precision from 8 bits to 64 bits (*int8_t* to *double*)) > - compact file size, damn easy to interpret without third-party libraries** (~80 SLoC see below, unlike .FBX, .X3D, .glTF or .X) > - the SDK follows the K.I.S.S. principle, MIT licensed just as the format itself, easy to integrate into any project > (* - you provide a script interpreter callback for the SDK, so you can [use any scripting language](https://gitlab.com/bztsrc/model3d/blob/master/docs/procedural.md) you like, eg. Lua, Python, whatever) > (** - the model's data may be stream compressed, however a) this is optional, and b) the SDK has a built-in decompressor. You won't need any third-party libraries to use the SDK, like JSON or XML libraries, libpng, zlib etc. it is dependency-free.)

Campbell Barton commented

2024-08-21 08:47:02 +02:00

Feature requests are out of scope for Blender's issue tracker.

Campbell Barton closed this issue

2024-08-21 08:47:03 +02:00

Blender Bot added the

Status

Archived

label 2024-08-21 08:47:04 +02:00

cretaceous1 commented

2024-08-23 07:20:25 +02:00

@ideasman42 The author of .M3D has written a blender plugin. Please add it to blender/blender-addons. https://gitlab.com/bztsrc/model3d/tree/master/blender