Дóжили. Недавно была обнаружена проблема синхронизации игрового процесса с реальным временем не где-нибудь, а в игре "Quake Champions". Название игры "Quake" раньше было синонимом чего-то крутого, высокотехнологичного и идеального. И в голову не могло придти, что через какую-то пару десятков лет и камня на камне не останется от былого превосходства, а в новой игре с именем "Quake" появятся грубые ошибки, приводящие к тому, что один из игроков может получить преимущество только потому, что у него лучше "железо". Дело в том, что скорость стрельбы в новом шутере зависит от fps, то есть, количество пуль, выпущенных игроками с разным значением fps за один и тот же промежуток времени будет разным, а значит один из них может получить преимущество.

Данная статья рекомендуется к прочтению всем разработчикам игр, а в особенности разработчикам программ для движущихся механизмов. Да, подобные проблемы были и в коде библиотеки для работы с шаговыми двигателями для Arduino. Но если вы создаете программы для управления полетом ракет, или для атомных реакторов, то, ребята, вам эта статья не поможет. Вам нужны другие уровни синхронности, и специальное железо, работающее под управлением RTOS.

На первый взгляд, задача применения размерных ограничений к чертежу кажется не сложнее упражнения из школьного учебника. Точно так же показалось и мне, когда я впервые узнал о ней. В то время я работал в компании, которая занималась разработкой программного комплекса для проектирования индивидуальных жилых домов с подготовкой проектной документации "под ключ". В этом проекте я занимался разработкой алгоритма генерации многоскатных крыш, а впоследствии и всего геометрического ядра на основе Булевых операций, поэтому за дальнейшей историей я следил издалека. В какой-то определенный момент, заказчику захотелось, чтобы проектировщики могли просто указать размеры комнат, углы эркеров и ширину дверных проемов, а программа автоматически рассчитала бы все остальные параметры внешнего и внутреннего устройства дома. Эта мысль возникла у заказчика спонтанно, и поэтому срочно нужно было сделать “точно так же, как в CATIA”. Наш тимлид подошел к решению задачи с энтузиазмом и начал разрабатывать прототип. Он решал сотни уравнений в MathCAD, весь кабинет был завален графиками частных решений для двух, трех, четырех точек… Его изначальное предположение о том, что задачу можно решить аналитически, потерпело фиаско: на дворе был 2005, а это значило, что в интернете невозможно было найти хоть какую-то информацию по данной теме. В результате, после двух месяцев напряженных исследований, данную функциональность пришлось исключить.
Часть 1: Введение
Часть 2: Эскиз
Часть 3: Степени свободы и уравнения ограничений
Часть 4: «Неисповедимы пути Решателя» или «Червоточины Ньютона»

Важным условием корректности построенного эскиза является непротиворечивость наложенных ограничений. Если наложено меньше ограничений, чем требуется, некоторые параметры не могут быть однозначно определены, поэтому могут изменяться в некотором диапазоне значений. В таких случаях говорят, что чертеж имеет степени свободы (Degrees Of Freedom; DOF). Анализ степеней свободы позволяет инженеру-конструктору накладывать только необходимое и достаточное количество ограничений, не позволяя системе уравнений быть переопределенной (overconstrained), и не позволяя оставить какую-либо степень свободы без наложенных ограничений.
Часть 1: Введение
Часть 2: Эскиз
Часть 3: Степени свободы и уравнения ограничений
Часть 4: «Неисповедимы пути Решателя» или «Червоточины Ньютона»

Построение геометрии любой детали в SolveSpace начинается с проектирования эскиза (sketch). Эскиз представляет собой набор замкнутых контуров (циклов, loop), каждый из которых не должен иметь самопересечений и пересечений с другими контурами. Контуры состоят из примитивов (entity). Примитивы объединяются в контуры с помощью ограничения "точка-к-точке" (points coincident).
Часть 1: Введение
Часть 2: Эскиз
Часть 3: Степени свободы и уравнения ограничений
Часть 4: «Неисповедимы пути Решателя» или «Червоточины Ньютона»

Многие из нас в школе или университете посещали уроки черчения, но не многим из нас это нравилось. Часами возиться с линейкой, циркулем и плохо заточенным карандашом, пытаясь ровно и без помарок выводить размерные линии, бесконечные штриховки и странные формы, мало кому могло показаться интересным. Тем более, что к тому времени уже существовали компьютерные программы, способные автоматизировать это скучное, бессмысленное и беспощадное занятие. А настоящий прорыв в области проектирования деталей и подготовки конструкторской документации произошел в 1989 вместе с дебютом параметрического моделирования в Системе Автоматизированного Проектирования (САПР) Pro/Engineer.

Это — вводная статья к циклу статей "Параметрическое моделирование". Из этого цикла вы узнаете о внутреннем устройстве настоящего решателя геометрических ограничений, проблемах и их решениях на примере open-source САПР "SolveSpace". Кому не чужд мир трехмерного моделирования, добро пожаловать под кат!

Модель ударно-спускового механизма РПГ-7, созданная в САПР SolveSpace