Ekins_Inventor_API
.pdf
Аппроксимация кривых и поверхностей
API предоставляет средства для аппроксимации кривых и поверхностей. Для кривых применяется кусочно-линейная аппроксимация, для поверхностей — полигональная аппроксимация треугольниками (фасетами). Способы аппроксимации становятся важными, когда вам требуется взаимодействовать с другим программным обеспечением, которое не может использовать гладкие кривые и/или поверхности. Инвентор вычисляет и использует линейные сегменты и фасеты в процессе формирования данных, посылаемых в видеокарту компьютера для отображения на мониторе. Изображения, которые в результате рендеринга кажутся нам гладкими, в действительности сформированы из крошечных треугольников. Сама же модель всегда состоит из гладких и точных поверхностей, именно они используются для всех связанных с моделью вычислений, однако для отображения поверхностей на экране используется аппроксимация треугольниками.
API предоставляет доступ к наборам треугольников и линейных сегментов, которые уже вычислены Инвентором для задачи визуализации. Вы также можете использовать Инвентор для выполнения процедур аппроксимации с некоторой наперёд заданной точностью. Эти аспекты не будут здесь обсуждаться подробно, поскольку используются не слишком широко и проиллюстрированы рядом примеров в API.
Твердые тела (Solids)
Типичные детали представлены в Инвенторе твердыми телами. Твердое тело лежит в основе интуитивно понятного и естественного способа работы с геометрией, поскольку является аналогом доступного для манипуляций объекта реального мира. В Инвенторе твердое тело создается и изменяется посредством конструктивных элементов, которые удаляют либо добавляют в тело материал. Поскольку Инвентор является параметрическим ассоциативным моделлером, вы можете редактировать модель, изменяя те или иные независимые параметры конструктивных элементов с последующим перевычислением модели.
С точки зрения Инвентора конструктивные элементы представляют собой наборы команд. В результате выполнения предписанной последовательности команд Инвентор создает или изменяет модель твердого тела. Данная статья фокусируется не на внутренних процессах, приводящих к созданию модели, а на твердотельной модели как конечном результате этих операций и инструментарии API для работы с ней.
Твердое тело в Инвенторе представлено описанием границ этого тела (Boundary Representation, B-Rep). Структура данных B-Rep
является описанием совокупности связанных поверхностей, формирующих внешнюю границу объема тела. И хотя модель представляется нам твердотельной (мы можем что-нибудь из нее вырезать, определить весовые характеристики, проводить расчеты и иные характерные для твердых тел операции), в действительности это лишь набор поверхностей. Связность поверхностей относится к области топологии, и в модели B-Rep для этих задач предусмотрены необходимые инструменты. На рисунке справа приведена простая модель твердого тела, которая будет использована для иллюстрации этих концепций.
Твердое тело в API представлено объектом SurfaceBody. Несмотря на то, что в его имени присутствует слово «поверхность» (“Surface”), объект SurfaceBody является обобщенным объектом, представляющим любой высокоуровневый объект B-Rep, включая и твердые, и поверхностные тела. Основное отличие твердотельной модели заключается в том, что она формируется замкнутой совокупностью поверхностей. Каждая ограничивающая тело
11
поверхность в объекте SurfaceBody представлена объектом Face (грань). Как видно из рисунка справа, в нашем примере границы тела сформированы восемью гранями. Объект Face поддерживает грани произвольной геометрии, независимо от их формы. Предыдущее обсуждение поверхностей касалось вопросов доступа к информации о геометрии грани.
Для формирования твердотельной модели недостаточно иметь ограничивающие тело поверхности. Важно, чтобы они были связанными между собой. Контакт между гранями описывается объектом Edge (ребро) и геометрически представлен некоторой кривой. Каждая грань «знает» ограничивающие ее ребра, и каждое ребро «знает», какие две грани оно соединяет. Другим полезным для программиста элементом топологии являются замкнутые контуры (loop). В объектной модели API они представлены объектом EdgeLoop. В общем случае замкнутый контур формируется группой последовательно соединенных ребер. На рисунке ниже одна грань имеет границы в виде двух замкнутых контуров. Внутренний контур в центре грани сформирован из одного круглого ребра. Внешний контур состоит из четырех прямолинейных рёбер. Замкнутые контуры образуют границы граней.
Другим распространенным объектом B-Rep является объект Vertex (вершина). Вершины существуют на концах любого ребра и описывают точки контакта между ребрами. Всякое ребро «знает» вершины на своих концах, и всякая вершина «знает», какие ребра в этой вершине соединены.
Еще одним, хотя и не слишком часто применяемым объектом B-Rep, является FaceShell. В Инвенторе вполне возможна ситуация, когда тело (solid) оказывается состоящим более, чем из одной части. Пример такого тела приведен на рисунке ниже. Тело слева состоит из
одной части. Справа то же тело разделилось на две части в результате увеличения диаметра центрального отверстия. Несмотря на то, что визуально модель оказалась разделенной надвое, с точки зрения API она по-прежнему остается моделью одного тела и представлена одним объектом SurfaceBody. Однако каждый «осколок» представлен своим собственным объектом FaceShell. Большинство деталей имеют лишь один объект FaceShell, но, как видим, их может быть и больше. Другим примером может служить полый шар, сформированный двумя концентрическими сферическими поверхностями. В целом шар является одним телом и представлен одним объектом SurfaceBody, но внешняя и внутренняя сферические поверхности имеют свои собственные объекты FaceShell. Если в таком шаре просверлить отверстие, которое соединит внешнюю и внутреннюю сферы, то грани объединятся, и останется только один объект FaceShell.
12
СБОРКИ (Assemblies)
Далее мы рассмотрим, каким образом в Инвенторе представляется геометрия деталей. Документ детали содержит описание геометрии детали, а сборки позволяют вам собирать детали в конструкцию. Распространенной задачей является получение доступа к геометрии детали в контексте сборки. Любая деталь в сборке выступает как компонент сборки (occurrence). В API для этой цели предусмотрен объект ComponentOccurrence (экземпляр компонента, вхождение компонента). Компонент сборки может представлять собой как деталь, так и подсборку. Всякий раз при выполнении команды «Вставить компонент» («Place Component») вы создаете в сборке новый компонент ComponentOccurrence. Объект ComponentOccurrence поддерживает свойство SurfaceBodies, и если компонентом является экземпляр детали, то именно SurfaceBodies обеспечивает доступ к ее геометрии.
Заслуживает внимания тот факт, что сборка не содержит данных о геометрии компонентов, а хранит лишь ссылки на документы деталей с описанием их геометрии. Если в сборке нет геометрии, то каким же образом пользовательский интерфейс позволяет вам работать с геометрией компонентов сборки? Эта проблема решается с помощью прокси-объектов.
Прокси-объекты (Proxies)
Как уже было сказано, в сборках хранятся лишь ссылки на файлы компонентов, но не их геометрия. На первый взгляд, это противоречит повседневному опыту конечного пользователя Инвентора. Ведь среда проектирования создает полное впечатление, что геометрия деталей «живет» в сборке. Так, при наложении сборочной зависимости совмещения (mate constraint) двух деталей вы вольны выбрать любую грань детали, совершенно не задумываясь, а где на самом деле хранится описание ее геометрии. Нечто похожее получается и при работе через API. Вы так же можете перебирать компоненты в сборке и получать доступ к их геометрии, как если бы она реально присутствовала на верхнем уровне сборки.
Рассмотрим, как это работает, на примере простой сборки (см. следующий рисунок). В этой сборке имеются два экземпляра детали колеса. Каждый экземпляр представлен своим объектом ComponentOccurrence. Предположим, что нам требуется выделить цилиндрическую грань отверстия в колесе. Первый вопрос: как пользователь может выделить цилиндр, если его геометрия в сборке отсутствует? И второй вопрос: положим, что можно как-то выделить цилиндрическую грань, но каким образом Инвентор будет различать грани отверстий в разных экземплярах колеса, если в действительности существует всего лишь одно отверстие, описание которого хранится в единственном файле детали колеса?
13
Обе поставленных проблемы решаются с помощью прокси-объектов. Они представляют в сборке объекты так, как если бы те действительно существовали в сборке. Если вернуться к задаче выделения цилиндрической грани в колесе, то когда пользователь выделяет грань в сборке, в действительности выделенным оказывается объект FaceProxy. FaceProxy как наследник объекта Face поддерживает все его методы и свойства плюс еще несколько дополнительных, которые специфичны для прокси-объектов. Поскольку FaceProxy является наследником объекта Face, в большинстве случаев вы можете работать с ним как с обычным объектом Face, нисколько не беспокоясь о его прокси-природе. И хотя в случае проксиобъекта вы используете те же методы и свойства, что и у объекта-родителя, но возвращаемая ими информация отражает положение объекта в системе координат сборки.
При выделении в сборке цилиндрических граней двух колес возвращаются ссылки на разные объекты FaceProxy, у каждой из граней он будет свой, несмотря на то, что они представляют одну и ту же грань детали. Возвращаемая объектами FaceProxy информация будет разной изза отличающегося положения компонентов в системе координат сборки.
Прокси-объекты поддерживаются для широкого круга объектов. Фактически, они необходимы для любых объектов, которые доступны к выделению в контексте сборки. Когда вы получаете ссылку на прокси-объект при переборе компонентов сборки или как результат выделения объекта пользователем, вам, как правило, не следует беспокоиться о том, что вы имеете дело не с самим объектом, а с его прокси-представителем.
Концепция прокси-объектов настолько упрощает работу с объектами из разных файлов, что создается впечатление, будто компоненты и в самом деле существуют в сборке, как это и представляется конечному пользователю Инвентора.
Существуют ситуации, когда вам потребуется самим создавать прокси-объекты, чтобы передать их в качестве входных аргументов другим методам. Самый распространенный случай этого рода — программное формирование сборки с наложением на ее компоненты сборочных зависимостей. Рассмотрим задачу вставки в сборку болта. Круглое ребро, указанное на рисунке справа, будет использоваться как аргумент при наложении зависимости. Предположим также, что для быстрого поиска нужного ребра при
работе с болтом в контексте сборки с этим ребром ассоциирован некий известный нам атрибут.
Приведенная сборка состоит из двух деталей, между которыми мы намереваемся установить зависимость вставки. Допустим, мы уже получили ссылку на компонент-кубик и, применив APIфункционал B-Rep, нашли в нем круглое ребро отверстия. Поскольку мы добрались до ребра через компонент и его объект SurfaceBody, ссылка будет указывать на прокси-объект EdgeProxy, что означает, что он ведет себя так, как если бы это ребро действительно существовало в сборке. Теперь нам следует получить объект EdgeProxy для соответствующего ребра в болте. Для поиска ребра к нему был добавлен атрибут, однако этот атрибут существует в детали Болт, а не в сборке. Поиск атрибута
в сборке результата не даст, его там просто нет. Искать его следует в контексте документа детали Болт. Поскольку. мы проводим поиск в документе Болт, возвращаемый объект будет действительным ребром, а не прокси-объектом. API предоставляет нам инструменты для создания прокси-объекта. Программный пример иллюстрирует доступ к документу детали, процедуру поиска ребра, создание прокси-объекта и, наконец, наложение сборочной зависимости. Предполагается, что у мы уже имеем ссылку на объект EdgeProxy для ребра на кубике и ссылку на компонент Болт.
' Доступ к определению компонента Болт из самого компонента Болт. Dim oBoltCompDef As ComponentDefinition
Set oBoltCompDef = oBoltOccurrence.Definition
‘ поиск ребра с помощью менеджера атрибутов документа Болт
Dim oAttribManager As AttributeManager
Set oAttribManager = oBoltCompDef.Document.AttributeManager Dim oObjects As ObjectCollection
14
Set oObjects = oAttribManager.FindObjects("AutoBolts")
Dim oBoltEdge As Edge
Set oBoltEdge = oObjects.Item(1)
'Создание для ребра прокси-объекта. Dim oAsmBoltEdge As EdgeProxy
Call oBoltOccurrence.CreateGeometryProxy(oBoltEdge, oAsmBoltEdge)
'Наложение сборочной зависимости.
Call oDoc.ComponentDefinition.Constraints. _
AddInsertConstraint(oBlockEdge, oAsmBoltEdge, True, 0)
Приведенный пример иллюстрирует ряд важных моментов. В свойстве Definition
компонент ComponentOccurrence возвращает объект ComponentDefinition (определение компонента) документа, на который компонент ссылается. В нашем случае результатом будет объект PartComponentDefinition детали Болт. Это тот же самый объект PartComponentDefinition, который мы получаем как свойство
PartDocument.ComponentDefinition. Всякий раз, когда вы используете свойство Definition
компонента, любое обращение к ComponentDefinition будет выполняться в контексте детали, а не сборки. А имея доступ к документу детали, вы получаете в свое распоряжение весь предназначенный для этих объектов инструментарий API. В частности, вам доступны для изменения значения параметров, и можно даже добавлять новые конструктивные элементы.
Как только ребро в детали найдено, следует создать прокси-объект, который будет представлять это ребро в сборке. Делается это с помощью метода CreateGeometryProxy объекта ComponentOccurrence. Входным аргументом метода является объект, для которого требуется сформировать прокси-представителя, результатом работы метода является прокси-объект соответствующего типа. Теперь мы имеем объект, который представляет ребро в контексте сборки. Последняя строка фрагмента использует прокси-объект ребра болта и прокси-объект ребра на кубике для наложения сборочной зависимости вставки.
Как уже отмечалось, прокси-объекты наследуются из соответствующих «реальных» объектов. По этой причине они поддерживают все методы и свойства объектов-родителей. Но есть у них два дополнительных свойства, которых у родителей нет —
ContainingOccurrence и NativeObject. Свойство ContainingOccurrence возвращает компонент ComponentOccurrence, через который данный прокси-объект виден в сборке. В предыдущем примере свойство ContainingOccurrence прокси-объекта ребра в болте вернет компонент Болт. Свойство NativeObject возвращает настоящий объект, представляемый прокси-объектом. В нашем примере, свойство NativeObject объекта EdgeProxy вернет действительный объект Edge детали.
Одним из общих свойств объектов и их прокси-представителей является свойство Parent (родитель). Но хотя свойство общее, возвращаемые ссылки будут указывать на разных родителей. В нашем примере, свойство Parent настоящей грани вернет объект SurfaceBody детали, тогда как Parent прокси-объекта EdgeProxy вернет объект SurfaceBodyProxy, представляющий тело в контексте сборки.
15
Обход дерева сборки (Assembly Traversal)
Обход иерархического дерева сложных сборок является необходимым этапом в решении многих задач. Рассмотрим пример многоуровневой сборки. И пусть она имеет всего два уровня, но рассматриваемый подход будет работать при любом количестве уровней. В данном примере сборка верхнего уровня Car.iam состоит из двух экземпляров колесной сборки и детали кузова.
Рассмотрим фрагмент объектной модели API, который обеспечивает просмотр не только одного, но и всех других уровней сборки. Для обхода дерева сборки нам сначала необходимо у объекта AssemblyComponentDefinition получить ссылку на коллекцию ComponentOccurrences
компонентов данной сборки. Итеративный перебор элементов этой коллекции возвращает объекты типа ComponentOccurrence. Если компонент представляет деталь, вы можете исследовать ее геометрию, опираясь на возвращаемую компонентом информацию о поверхностях. Если же компонент оказался подсборкой, свойство SubOccurrences объекта ComponentOccurrence предоставит возможность перебора составляющих ее компонентов. При обходе дерева сборки вы просто опускаетесь на уровень ниже, если объект ComponentOccurrence оказывается подсборкой.
Описанные процедуры иллюстрируются следующим примером.
Public Sub AssemblyTraversal()
'Ссылка на активный документ. Полагаем, что это сборка. Dim oAsmDoc As AssemblyDocument
Set oAsmDoc = ThisApplication.ActiveDocument
'Начинаем обход сборки
Call TraverseAsm(oAsmDoc.ComponentDefinition.Occurrences, 1)
End Sub
16
' Аргумент Level необходим для вычисления левого отступа при печати.
Private Sub TraverseAsm(oOccurrences As ComponentOccurrences, Level As Integer)
' перебор компонентов на текущем уровне иерархии. Dim oOcc As ComponentOccurrence
For Each oOcc In oOccurrences
'вывод на печать имени текущего компонента
Debug.Print Space(Level * 3) & oOcc.Name
'Если текущий компонент – подсборка, то снова вызываем
'эту процедуру с текущим компонентом в качестве аргумента. If oOcc.DefinitionDocumentType = kAssemblyDocumentObject Then
Call TraverseAsm(oOcc.SubOccurrences, Level + 1) End If
Next
End Sub
Первое, что бросается в глаза — задача решается не одной процедурой, а двумя. Для просмотра сборочной иерархии произвольной вложенности мы вынуждены воспользоваться рекурсивной процедурой. Рекурсия — вызов функции или процедуры из неё же самой. Процедура TraverseAsm выполняет всю работу по перебору компонентов на уровне текущей сборки и, если наткнется на подсборку, вызывает сама себя для ее просмотра. Так продолжается до тех пор, пока не будут пройдены все подсборки. Процедура же AssemblyTraversal лишь дает старт этому процессу.
Результат данного примера очень прост — будут напечатаны имена всех компонентов сборки по мере их обнаружения. Однако с каждым компонентом может быть выполнена гораздо более сложная операция. Например, возможно сформировать пользовательскую спецификацию, для которой из всех документов, на которые ссылаются компоненты, будет извлечена информация о свойствах.
МАТЕМАТИЧЕСКИЕ ОБЪЕКТЫ
Объект TransientGeometry (Вспомогательная геометрия)
Выше мы рассмотрели способы получения геометрической информации об объектах. С использованием функционала объекта TransientGeometry (вспомогательная геометрия) возможно и непосредственное создание множества геометрических объектов. Ссылку на объект TransientGeometry предоставляет объект Application. В арсенале TransientGeometry имеется ряд методов Add для создания различных геометрических объектов. Все без исключения объекты, вспомогательной геометрии «живут» только в текущем сеансе работы приложения и в файлах не сохраняются. В дополнение к геометрическим объектам TransientGeometry позволяет создавать и некоторые математические виды объектов, предназначенные в API для выполнения вспомогательных функций. Двумя такими объектами являются объекты Vector и Matrix. Поскольку они не визуализируются в Инвенторе, то вызывают немало вопросов при применении. Ниже мы обсудим каждый из них.
Объект Vector
Вектор предоставляет удобный способ задания направления и величины. 3D-вектор имеет три компоненты x,y,z, а 2D-вектор — только две, x и y. Несмотря на простоту, объект Vector
17
поддерживает богатый набор методов и свойств, которые облегчают векторные операции. Рассмотрим пару примеров с векторами. Весьма распространенным применением векторов является задание направления и величины перемещения объектов. Операция перемещения (трансляция) объекта в пространстве не предполагает вращения объекта. Например, вектор (3,1,0) определяет перемещение объекта на 3 единицы вдоль оси X, на 1 единицу вдоль оси Y и 0 единиц вдоль оси Z, что приводит к смещению объекта на расстояние 3.162 единиц, как показано ниже.
Другой распространенной задачей векторов является задание направлений. В предыдущем примере вектор использовался для задания и направления и величины перемещения детали. В случаях, когда требуется задать лишь направление, обычно используются единичные векторы в виде объектов типа UnitVector. Длина вектора UnitVector всегда равна единице. Примером, когда векторы используются для задания направлений, является получение от некоторых объектов вспомогательной геометрии данных об ориентации. Например, объект Cylinder (Цилиндр) поддерживает свойство AxisVector (вектор оси), которое возвращает единичный вектор типа UnitVector. Он описывает направление в пространстве оси цилиндра.
Мощность функционала объекта Vector определяется набором его методов и свойств. Рассмотрим наиболее употребительные из них. При определении прямоугольной системы координат вы обычно имеете точку, которая станет началом системы координат (Origin), и три вектора, которые задают направления осей x, y и z. Ими могут быть и единичные векторы, поскольку их длины значения не имеют. Чтобы система координат была действительно прямоугольной, векторы должны удовлетворять следующим условиям:
1.Направление оси y должно быть перпендикулярно направлению оси x.
2.Направление оси z должно быть перпендикулярно направлениям осей x и y, а также удовлетворять правилу правой руки, т.к. в Инвенторе используются только правые системы координат.
Рассмотрим на конкретном примере простой метод создания трех векторов, одновременно удовлетворяющих перечисленным условиям. Предположим, требуется задать координатную систему, в которой ось x направлена вдоль направления (3, 7, 6), ось y должна быть направлена вверх, это будет её положительное направление. И наконец, ось z должна быть корректно сориентирована относительно осей x и y.
Для векторов определена операция, называемая векторным произведением, которая по двум неколлинеарным векторам позволяет вычислить третий вектор. Любые два непараллельных вектора позволяют задать плоскость. Если вы совместите начала двух таких векторов, они будут лежать в одной плоскости. Результатом векторного произведения этих векторов является третий вектор, перпендикулярный этой плоскости (см. рисунок справа). Направление вектора z зависит от последовательности, в которой векторы x и y участвуют в операции векторного произведения. Вектор z, показанный на рисунке, является
результатом векторного произведения вектора x на вектор y и удовлетворяет правилу правой руки. Направьте указательный палец правой руки вдоль оси x, а средний палец влево вдоль оси y, тогда направленный вверх большой палец правой руки укажет положительное направление вектора z. Если в векторном произведении векторы x и y поменять местами, то направление результирующего вектора z изменится на противоположное.
Посмотрим, как с помощью векторного произведения можно построить описанную в задаче систему координат. Сначала пошагово опишем алгоритм, а затем рассмотрим его программную реализацию.
1. Создать вектор в известном направлении оси x, (3,7,6).
18
2.Создать вектор который определяет ось y, направление (0,1,0). (Понятно, что это не точное направление оси y, а лишь его грубое приближение.)
3.Вычислить вектор z как векторное произведение вектора x на вектор y. Полученное направление является точным (это направление нормали к плоскости, в которой лежат векторы x и y).
4.Вычислить вектор y как векторное произведение вектора z на вектор x. Полученное направление вектора y является точным.
Public Sub CreateCoordSystem()
' Ссылка на вспомогательную геометрию. Dim oTG As TransientGeometry
Set oTG = ThisApplication.TransientGeometry
'создание вектора для оси x. Dim oXAxis As UnitVector
Set oXAxis = oTG.CreateUnitVector(3, 7, 6)
'создание первого приближения для вектора в направлении оси y. Dim oYAxis As UnitVector
Set oYAxis = oTG.CreateUnitVector(0, 1, 0)
'Вычисление вектора z как векторного произведения x на y.
Dim oZAxis As UnitVector
Set oZAxis = oXAxis.CrossProduct(oYAxis)
'Создание вектора y как векторного произведения z на x. Set oYAxis = oZAxis.CrossProduct(oXAxis)
'Вывод результатов
Debug.Print "Ось x: " & oXAxis.X & ", " & oXAxis.Y & ", " & oXAxis.Z Debug.Print "Ось y: " & oYAxis.X & ", " & oYAxis.Y & ", " & oYAxis.Z Debug.Print "Ось z: " & oZAxis.X & ", " & oZAxis.Y & ", " & oZAxis.Z
End Sub
Пару слов стоит сказать и о других функциях, поддерживаемых объектом Vector. Методы
AngleTo, IsEqualTo, IsParallelTo и IsPerpendicularTo позволяют различными способами сравнивать два вектора. Методы AddVector, SubtractVector, CrossProduct, и DotProduct
реализуют основные векторные операции — сложение и вычитание, векторное и скалярное произведения векторов. Объект Vector (в отличие от единичного вектора UnitVector) поддерживает ряд методов и свойств, связанных с его длиной. Это Length, Normalize (приведение вектора к единичной длине или нормализация) и ScaleBy (умножение вектора на скаляр). Наконец, поддерживаются операции преобразования типа векторов. Из объекта Vector с помощью метода AsUnitVector можно получить объект UnitVector, тогда как метод AsVector наоборот приводит тип UnitVector к типу Vector.
Объект Matrix
Матрица представляет собой двумерный массив чисел. Для трехмерного пространства Инвентор поддерживает объект Matrix, для двумерных пространств предусмотрен объект Matrix2d. Объект Matrix представляет собой матрицу размерностью 4x4 (4 строки и 4 столбца). Объект Matrix2d представляет собой матрицу размерностью 3x3. Типичная 3D-матрица 4x4 показана на рисунке справа. Объект Matrix инкапсулирует в себе 16 значений. Выглядят матрицы довольно просто, однако вовсе не так просто научиться их корректно
19
применять на практике. Из всей вспомогательной геометрии матрицы являются наименее очевидными объектами и вызывают наибольшие трудности у программистов.
Дальнейшее изложение сфокусировано на практическом подходе к матрицам, который в свое время помог автору. Надеюсь, что этот подход окажется полезным и для читателя. В зависимости от решаемой задачи, я рассматриваю матрицы с двух точек зрения. В первом случае матрица служит инструментом для задания системы координат. Во втором случае матрица описывает некоторое геометрическое преобразование. Первый подход является самым простым и наиболее полезным.
Рассмотрим, из чего состоит система координат, и увидим, каким образом матрица обеспечивает требуемую информацию. Координатная система описывает положение и ориентацию в пространстве. В трехмерном пространстве начало координат есть трехмерная координатная точка (x.y.z), заданная в пространстве модели. Она задает положение системы координат. Ориентация системы координат описывается направлениями главных осей x, y и z.
В ортогональных системах координат, которые всегда используются Инвентором, действует ряд жёстких правил, уже обсуждавшихся выше, а именно, оси x,y и z являются взаимно перпендикулярными, а направление оси z удовлетворяет правилу правой руки. Все три вектора направлений являются единичными.
Рисунок справа показывает, каким образом матрица хранит геометрическую информацию о системе координат. Во-первых, при использовании матрицы вы можете игнорировать нижнюю строку. В ней всегда хранятся одни и те же значения 0, 0, 0, 1. Остальные 12 значений определяют координатную систему. Первый столбец описывает компоненты направления оси x (1,0,0). Второй столбец задает направление оси y (0,1,0), третий — оси z (0,0,1). Последний столбец определяет положение начала системы координат (0,0,0). Показанная справа матрица называется единичной. Начало координат и направления единичных векторов совпадают с базовой системой координат. Такая матрица не описывает ни перемещения, ни вращения.
Рассмотрим, как применить эту информацию для описания конкретной системы координат Как будет выглядеть матрица для задания системы координат с началом в точке (10,5,0) и повёрнутой на 45° вокруг оси z?
Рассмотрим сначала ось x. Если новая система координат повернута на 45° вокруг оси z, значит и ось x повернута относительно базовой оси x на 45° в положительном направлении отсчета углов. Таким образом, ось x направлена в направлении вектора (1, 1, 0), но поскольку вектор системы координат должен быть единичным, то результат должен выглядеть так (0.707, 0.707, 0). Соответственно, ось y имеет отрицательную компоненту по x и положительную по y и будет выглядеть следующим образом (-0.707, 0.707, 0). Ось z направления не меняет (0, 0, 1). Наконец, в четверном столбце вписываются координаты точки начала системы координат (10, 5, 0).
20