Иван

1. Реальный hard surface с претензией на инженерную достоверность - это полноценно твердотельные модели в САПР(CAD). Без вариантов. Именно там геометрия первична и только там механизмы будут геометрически и топологически достоверны, а процесс будет похож на сборку конструктора. Solidworks, Inventor и другие САПР среднего класса вполне подойдут. Уроки на ТыТрубе в избытке.
2. Любой "каркасник" - это имитация с целью визуализации. Ни один из них (вкл. Blender) не умеет в твердотельное моделирование в силу своего назначения и самой сути. Ему это не надо. Это всё фикция и костыли, которые позволяют добиться лишь эффекта твердых тел, не более. Любые симуляции работы механизмов в каркасных редакторах - имитация взаимодействия, проработанная автором до той степени, чтобы условность изнанки была не заметна. Универсального конструктора с детальками, которые взаимодействуют как бы сами по себе на основании собственной геометрии вы тут не найдёте - всё ручками.
И поэтому все "крутые работы с ArtStation" делают именно так: имитацией. Потому что никому там высочайшая точность (а тем более техническая обоснованность) самой геометрии не нужна, а обеспечить её параметрическую природу в "каркаснике" практически невозможно. Текстурами и хитростями намного проще и быстрее добиться необходимого визуального эффекта, чем проработать настоящую конструкцию.
А в анимации механизмов работают Empty, системы костей, драйверы и IK, а меш/объект просто их "пассажир" (потомок, если быть точным). Его форма имеет лишь визуальное значение и на поведение конструкции не влияет.

Относительно Blender и HS всё предельно просто: "голый" Blender - профнепригоден ни в одном из направлений. Его функционал заключается в аддонах. И для hard surface есть обязательные (платные) аддоны HardOps и BoxCutter, упрощающие построение железок. К ним дополнительно на подхвате идут MACHIN3tools, Kit Ops, Cablerator.. и, в целом, можно гуглом поискать пул аддонов для hard surface моделинга и библиотеки ассетов. С этими инструментами попытка моделировать механизмы будет хоть немного продуктивной.
Начать ознакомление можно, например, с курса The Ultimate Guide to Hard Ops and Boxcutter.

Суть в том что есть годами сложившаяся традиция решения определенных задач в Excel.

С годами версии экселя меняются. Когда-то давно был предел в 65 тысяч строк. Когда-то давно был предел в 1-5 мегабайт на файл.

Если брать просто данные, то эксель довольно неплохо справляется с большими объемами, там скорее упирается в оперативку на конкретном компе.
Но если начинаете оформлять, то я видел как довольно небольшой файл, но с оформлением в каждой ячейке вынуждают эксель зависать.

Много связей с внешними файлами - плохо. Эксель все-таки не база данных, и обновление из разных файлов будет подтормаживать.

Если у вас много функционала, возможно имеет смысл подумать о каком-то приложении, может быть с базой, но можно и напополам.
Тем более что с Экселем напрямую могут работать многие библиотеки.

я на практике сталкивался с таким-была выгрузка из двух баз данных.нужно было сделать нечеткий текстовый поиск и объеденить по ключевому столбцу в одну таблицу.использовал fuzzy lookup.ексель сравнивал 90тыс строк из одной таблицы с 300 строк из другой.на больших объемах крашился.это занимало по 40 минут на core i7 при учете того,что ексель нагружает каждое ядро только на 25%.результаты многократно повторял и склеивал в итоговую таблицу.сейчас я уже знаю,что такое pover pivot и решил бы эту задачу правильно и быстрее.но тогда вариантов не было.сроки поджимали.на питоне это можно было идеально реализовать,но человек,который взялся за решение задачи-провалил все сроки и так ничего и не сделал.пока искал решение ускорения расчетов в екселе,чего только не находил.даже cuda ядра с видеокарты люди подключают(но дальше прототипа дело не пошло).вообще работая с olap кубами и pover pivot+ pover query+pover bi- могу сказать,что до ограничений я так и не дошел.ютуб творит чудеса в плане обучения.посмотрите каналы станислава салостея и николая павлова.там информаци более чем достаточно.а если дальше копать,то я например питон и node red использую.
и как сказали выше-нужно быть внимательным с условным форматированием.по этому вопросу вот отличное решение https://www.youtube.com/watch?v=sc9xyMl1uu8&list=P...

Я обычно смотрю инструкцию
1.
https://support.office.com/ru-ru/article/%D1%82%D0...

2. гугл excel profiler
3. У вас видимо уже.

Если я правильно вас понял. То возможно данное видео поможет вам.

"В свойствах ярлыка запуска бобра нужно было дописать такую строчку в конец команды:
-vmargs -Dfile.encoding=UTF8" (с) IXBT

Свойство модуля определить как переменную внутри модуля -- будет можно обращаться из любого места модуля.
Соотнести свойство с переменной.

https://msdn.microsoft.com/en-us/library/ms173212.aspx

Нормальное поведение, что пространства имен из разных сборок объединяются в одно, по ссылке выше, это для того, если у вас есть совпадающие имена в одном пространстве, но разных сборках. Все равно подключаются обе, без system.dll очень тяжело чего то написать. Просто в mscorlib.dll нет управляемого кода, это фактически и есть CLR, в system просто вынесли более высокоуровневые вещи.

Пространства имен это по сути просто синтаксический сахар (ну и немного метаданных вроде), для .net это просто префиксы имен типов. Т.е. то, что выглядит как MyClass, находящийся в пространстве имен MyNamespace, для CLR является типом с именем MyNamespace.MyClass, поэтому MyNamespace.MyClass может быть в одной сборке, а MyNamespace.AnotherClass в другой.