Существует как минимум три варианта хранения 3D объектов в файлах разных форматов:
1. Constructive Solid Geometry (CSG) - Этот вариант предполагает 3D тело, созданное из примитивов, таких как сфера, куб, цилиндр, конус, тор и пр. путём комбинирования и преобразования их с помощью булевых операций (сложение, вычитание, пересечение), и других операций преобразования. Такой вариант требует минимума для описания самих объектов. В некоем псевдо формате хранения 3D тел CSG будет выглядеть примерно так:
#1=SPHERE(10., (10., 10., 10.)); // Сфера задаётся радиусом и координатами её центра
#2=CYLINDER(10., 5., (11., 10., 10.)); // Цилиндр задаётся радиусом основания, высотой и координатами центра базовой окружности
#3=CSG_BODY(#1, #2, .ADD.); // Тело, полученное путём сложения ранее заданных сферы и цилиндра
В таком варианте мы ничего не знаем о детализации объектов, описанных в файле. Информация действительно требует мало места для хранения, но приложение, работающее с данными такого формата, должно уметь генерировать сферы и цилиндры с помощью библиотеки (твердотельного) 3D моделирования, и, более того, уметь совершать булевы операции с такими объектами в качестве операндов. Достаточно серьёзная наукоёмкая функциональность, которой наделены серьёзные CAD приложения (Компас 3D, Solidworks, Inventor...), благодаря использованию в них собственных или сторонних библиотек твердотельного моделирования. Впрочем, возможности данного подхода могут быть ограниченны (просто создать сферу или цилиндр, но гораздо сложнее смоделировать что-то из NURBS-поверхностей), поэтому никто не запрещает в качестве операндов использовать тела, хранящиеся в т.н. граничном представлении (Boundary Representation), описанном в пункте 2.
2. Boundary Representation (Граничное представление) - при таком подходе теряется информация о том, каким образом 3D представление было получено (не будем вдаваться в подробности, т.к., конечно, эту информацию можно сохранить при надобности), но такое представление достаточно для того чтобы описать 3D тело любой сложности, и при этом решение о детализации конечного варианта будет приниматься на стороне приложения, работающего с загруженной моделью, т.к. поверхности граней и геометрия рёбер заданы математическими уравнениями (уравнение плоскости, сферической поверхности, конической поверхности, NURBS-поверхности и пр., а в качестве геометрии рёбер используются параметрические уравнения кривых, таких как окружность, прямая (отрезок), NURBS-кривая и пр.). В отображающем приложении достаточно просто указать уровень детализации (разбиение) поверхностей на плоские фасеты, но несколько сложнее визуализировать целое 3D тело, т.к., например, нужно контролировать совпадение разбиения сопряженных поверхностей, ограниченных одним и тем же COEDGE.
#1=EDGE_CIRCULAR(...); // Геометрическая кривая и два вертекса, ограничивающие дугу в качестве параметров
#2=EDGE_LINEAR(...); // Геометрическая кривая и два вертекса в качестве параметров
#3=EDGE_CIRCULAR();
#4=EDGE_LINEAR();
#5=SURFACE_CYLINDRICAL(...);
#6=FACE(#1);
#7=LOOP(#2, (#1, #2, #3, #4));
...
#50=CLOSED_SHELL((#7, #8...)); // Несколько соединённых поверхностей, ограничивающих пространство
#100=MANIFOLD_SOLID_BREP((#50,)); // Внешняя оболочка обычно идёт первой, далее - пустые (void) пространства внутри неё
По понятным причинам, задавать таким образом топологию для фасетированных объектов (о ней в следующем пункте) избыточно, но для тел с поверхностями и кривыми, заданными математическими уравнениями - самый подходящий вариант. Открывающее приложение для просмотра файлов в случае отрисовки таких объектов может вообще не иметь библиотеки твердотельного моделирования, а просто заниматься отрисовкой разбиения таких поверхностей, но наличие же библиотеки моделирования позволит такому объекту участвовать в различных операциях моделирования в качестве операнда (сложение, вычитание, пересечение, снять фаску и пр.). Функциональность не самая простая, но не настолько ресурсоёмкая, как восстановление объектов по их параметрическому описанию и последовательности операций моделирования. Детализация поверхностей остаётся на уровне приложения, которое отображает такое 3D тело.
3. Faceted (Boundary) Representation - Данное представление тоже может быть охарактеризовано как граничное, но отличается от предыдущего тем, что поверхности граней разбиваются на плоские (планарные) части, треугольники или плоские многоугольники, поэтому и структуры для хранения таких представлений используются другие. Для того, чтобы сократить расход памяти.
Вариантом хранения данных в таком представлении может быть следующая последовательность объектов:
#1=CARTESIAN_POINT(0., 0., 0.);
#2=CARTESIAN_POINT(1., 0., 0.);
#3=CARTESIAN_POINT(1., 1., 0.);
#4=CARTESIAN_POINT(0., 1., 0.);
#5=PLANAR_FACE((#1, #2, #3)); // Фасет задаётся тремя точками, приходит в первую (1-2-3-1)
#6=PLANAR_FACE_((#1, #3, #4)); // 1-3-4-1
#7=SHELL((#5, #6)); // Фасетированная поверхность состоит из двух треугольников
#8=FACETED_BODY((#7));
Или подобная. При таком подходе детализация сохранённого 3D объекта определяется в момент сохранения геометрии в файл. Понятно, что далее поменять детализацию и восстановить из фасетированного представления классическое граничное представление с математически заданными поверхностями достаточно проблематично, не говоря уже о восстановлении истории создания исходного объекта. Но этот вариант наиболее прост для отображения, например, в браузере, или в несложном приложении для просмотра 3D файлов, т.к. наиболее близок к тому, что уходит в Open GL. Для упрощения (уменьшения детализации, уменьшения количества треугольников/фасетов) таких объектов в таком представлении используются специальные алгоритмы, они часто реализованы в программах, умеющих работать с таким представлением. Обратная задача повышения детализации (например, превращение наборов вершин в аналитические поверхности) возможно, но является достаточно ресурсозатратной задачей и как правило сопровождается правом на ошибку.
Теперь вернёмся к упомянутым в заголовке статьи форматам.
STL (StereoLithography) формат оперирует исключительно третьим вариантом представления трёхмерного объекта, т.е. в распоряжении программы, которая откроет такой файл, будет только набор фасетов (треугольников). В файле просто указываются последовательности координат вершин треугольников и связи между ними, за счёт чего сокращается размер файла по сравнению, например, с примером, показанным в пункте 3. Данный формат хорошо подходит для использования в конечных задачах типа печати модели на 3D принтере (собственно, для этого формат и существует). Исходное приложение сохраняет объект с указанной детализацией, приложение подготовки модели к печати исследует модель на ошибки, ищет, например, вырожденные (схлопнутые) фасеты, и отправляет модель на печать (в реальности, конечно, подготовка модели к печати гораздо сложнее).
STEP (STandard for Exchange of Product Data) - обменный формат, который кроме возможности описания 3D тел во всех трех вариантах (в т.ч. и одновременно в рамках одного файла), имеет возможность применения стилей к поверхностям (цвета, прозрачность), хранения сопутствующей информации для изготовления продукта (PMI - размеры, датумы с ассоциативностью к геометрии и пр.), хранения дополнительных атрибутов пользователя для элементов топологии и геометрии и т.д. и .т.д. Этот, гораздо более сложный формат в сравнении с STL, конечно, требует бОльших ресурсов от разработчиков приложения, его поддерживающих, но является самодостаточным в том плане, что из правильно оформленного STEP файла можно получить всю информацию о модели, имея относительно дешёвое приложение для просмотра файлов, а не дорогой CAD/PLM. При обратном импортировании STEP файла в CAD приложение существует возможность восстановления истории создания объекта, ассоциативности его частей с размерами и пр. Речь здесь идёт о STEP современной версии AP242 (предыдущие ревизии формата AP203 и AP214 являются устаревшими и, конечно, имеют некоторые ограничения по своим возможностям).