Александр Петров

1. Изучать ТыТрубу и статьи на предмет топологии/ретопологии и отверстий. Там целый вагон методов как именно ровнять сетку, как корректно организовать переходы кромок в зависимости от формы модели и отверстия. Очень много полезных приёмов и методик есть в теме hard surface modeling - там это первоочередная задача и поэтому..
2. Ставить специально обученные аддоны для этого самого hard surface: Hard Ops + Box Cutter в обязательном порядке, на подхвате: Advanced Boolean Tools или Bool Tool, для паттернов отверстий - Kitops. Можно ещё накинуть парочку аддонов для работы с сеткой (типа Mesh Machine).
Они отлично умеют резать разные дырки и по функционалу даже близки к САПР-овским операциям вырезания и экструдирования.

Оптимальное решение: встроенный Python. На нём в Blender можно написать практически всё сразу с привязкой к особенностям моделирования.
Весьма посредственно знаком с Python, но даже моих куцых знаний хватило чтобы оперативно написать небольшой генератор, для начала, базовых тел:

Остальное дописывается поверх по мере необходимости модулями.

Разместить где? Если в сети, на сайте отеля, то Blend4Web. Можете посмотреть функционал на официальной страничке проекта. Там приличное количество красивых интерактивных вещей. Уровень качества и проработки зависит только от вас.. как и оптимизация. Другого способа достаточно просто вести такой проект я не знаю, пожалуй. Тут при наличии исходника в Blender или Max можно перезаливать файл презентации при необходимости.

Ну..второй вариант - создать фактически браузерную игру..да хоть бы и том же Unity. Но это на порядки дороже.

1. А это как вам лично удобнее, куда вы собрались это деть и есть ли требования к скрытой геометрии (её отсутствии). Я - адепт культа твердотельного моделирования, в частности CAD и данный вопрос решен однозначно: Деталь - отдельный элемент, он входит в сборку как отдельный компонент. Интерференция при этом недопустима, кроме случаев когда оправдана. Исполнение деталей одним телом допустимо только с целью упрощения. Но это инженерный подход и особенность твердотела, в каркасном же это правило не работает - оно там не нужно.
При любом подходе результат будет сходным на самом деле, потому что в любом редакторе есть возможность усечь лишние поверхности до пересечения с другой поверхность, а затем сшить обе по границе в один меш. А можно не сшивать, например, для отработки текстур отдельно по каждому элементу. Причём добиться этого можно несколькими путями - Boolean просто самый простой.
Избегать (а значит следить) надо за наложением полигонов друг на друга. Вот это реально беда. Если у вас два цилиндра одинакового диаметра и вы "вставляете" один в другой, то не делайте так. А пересечение под углом - можно, а иногда позарез надо.
По вопросу совсем мелких деталей вроде крепления прицела.. опять вопрос не к нам. Зависит от задачи. Если вы хотите даже резьбу прорисовывать в отверстиях и думаете что это оправданно, то это ваше право. С другой стороны Bump mapping ещё живой и некоторые вещи вообще в каркасном моделировании рисовать не надо. Как раз всяких рельефных выступов на оружии касается в первую очередь.

2. Честно говоря, я уже даже забыл обоснование, почему их не рекомендуют использовать. Где-то когда слышал в самом начале, когда пользовал Blender, но идея не прижилась.. потому что, как сейчас помню, тут же после этого утверждения было сказано, что без этого обойтись будет нельзя и, мол, стремитесь, но не увлекайтесь. Это в конечном счете решается и по ходу дела последующей правкой конкретного куска. Не заморачивайтесь, вообщем. В конечном счете там всё равно всё треугольники - для однозначного определения положения плоскости в пространстве необходимо и достаточно три точки. =)

Я сейчас вам открою тайну. Компас (и не только) - не только для деталей. Компас - фактически среда и он имеет минимум 3 конфигурации: MCAD - машиностроение, ECAD - приборостроение(электроника) и...AEC - строительство. Интерфейс только условно общий, потому что переключается прямо внутри базового Компас (если установлены конфигурации), подключаются библиотеки компонентов и получается три разных софтины. Условно, конечно, потому что есть ещё и Компас-Строитель, который сделан отдельной САПР именно под вот такие вот вещи, как у вас на картинке. И вот он уже специфичен только в одну сторону.

AutoCAD - абсолютно та же история, но они пошли теперь другим путем. Раньше он был просто очень гибким и его просто надо было настроить. В обычном "голом" AutoCAD и сейчас дефолтно в состоянии боевой готовности находиться тьма инструментов из которых вам лично надо, как правило, не более 50%, а то и меньше. Отсюда кажущаяся туповатость и сложность интерфейса - там просто половину надо выключить...но только пользователь может определить для себя что именно выключить.
В остальном у них то же самое примерно: AutoCAD Architecture, AutoCAD Electrical, AutoCAD Mechanical, важное уточнение: AutoCAD Map 3D и ещё ряд более специфичных вариантов. Но всё то же самое - в рамка одного и того же ядра.

А вот дальнейшее производство это CAM.. который вообще к CAD отношения не имеет и всегда идёт просто рядом, но не в составе непосредственно самой CAD. Их на самом деле не меньше, чем первых и подбирать их надо по довольно не очевидному параметру - модели станка. G-код не един для всех, а в CAM есть такое понятие как постпроцессор. Поэтому код формируется под конкретную стойку и станок (с учетом понимания системы координат станка как минимум). Списки со станками и стойками есть на сайтах разработчиков, собственно систем. Могу сразу вам назвать MasterCAM и SprutCAM, как весьма распространённые. А вот домашние станки-самоделки или китайский NoName, которые под стойкой понимают непосредственно ПК это шаг в сторону - им нужен CNC Software. Здесь можно долго не рыться - Mach3 вполне достойный вариант.

На ArchiCAD зря ругаетесь. Это как раз тот самый инструмент, который позволяет не гонять модели лишний раз во всякие там блендеры, ломая структуру проекта в полигональную каркасную модель для передачи на рендер. ArchiCAD это спроектировал, отдал своему рендеру и готово. Быстро, просто, всего две педали вместо трёх и рукой лишний раз ничего не надо дергать.

>> PSКрыльчатка турбины - это сразу определённый класс станка. Как минимум 4-х осевой, лучше 4.5 или 5. и это действительно запарно технологически для частника. Слишком запарно.

Для этой задачи есть CAM-системы. Это такой зверь в который загоняется 3D-модель, настраивается система координат и строится технологический процесс. С допусками на обработку,, оптимизацией траектории инструмента, корректировками, указанием смены инструмента и т.д.
Но есть нюанс. Нюанс называется связка "станок+стойка", в рамках CAM имеющая вид конкретного препроцессора под конкретную стойку и типа станка - 4 оси бывают разные. Есть т.н. 3.5, которые тоже 4, да не очень. В частности поворотный стол на некоторых умеет крутиться только на 180, а не на 360, в итоге команда на поворот более 180 выдаст ошибку на железе, хотя симуляция отработала. Иными словами G-код для одной стойки может быть весьма непохож на код для другой стойки, особенно по части понятий стойки относительно положения осей. В своё время я плотно работал со SprutCAM, поскольку там были мои стойки и типы станков и модельки любой сложности корректно перелопачивались в код, который успешно отрабатывался стойкой.
Но систем гораздо больше. Можете ознакомиться с рынком, обычно в доках есть модели стоек и станков.

А вот по вопросу исходной модели.. ну CAD-файлы тот же Sprut ест любые. Кормил его sldprt, iges, step, m3d.. чем только не кормил, но насчет C4D ничего не скажу. "Не по феншую" оно точно, но экспорт в iges и stl там есть.

Так же многие CAM-системы, вроде MasterCAM или SurfCAM любят (во всяком случае могут) работать с облаком точек и даже парочка плотно связана с Rhino. Соответственно перегнать что-то из C4D в нужный формат не проблема. Вопрос требований точности. Импорт-Экспортные операции им явно не на пользу. Именно поэтому расчётный софт по гребным винтам часто даёт набор координат по которой CAM уже сама строит поверхность. Так нет проблем с кривизной поверхностей, переброшенных 10 раз из формата в формат.

Дополненная или виртуальная? (дополненная это GoogleGlass и аналоги, покемоны эти несчастные, а VR - виртуальная (Virtual Reality). Не так чтобы было много отличий, но они есть. Хотя бы потому, что с проекциями поверх зрения у человечества пока технологии ещё детскими болезнями тяготятся.

А по функционалу.. Да просто всё, в целом. На валенок похоже. Нужно два экрана маленького размера и большого разрешения, трёхосный акселерометр (в идеале дополненный гироскопом), простенький контроллер и драйвер, который переведет смещения акселерометра в смещение поля зрения в виртуальном мире. А реакция на смещения вопрос уже к ПО.

Сложность опциональная. Есть картонные держатели, позволяющие сделать из смартфона очки виртуальной реальности. Т.е. сложность равна сложности смартфона в таком случае (там есть экран, акселерометр, процессор и драйвер). При желании можно паять своё, благо на рынке хватает готовых модулей с трехосными датчиками навигации (можно ведь туда и компас настоящий воткнуть).
Почему тогда есть Oculus, Vive и Ко? Ну во-первых ради денег, конечно. Простая и понятная аппаратная база, максимум ПО, стоимость разработки которого оценить очень сложно. Но, несмотря на это, ряд важных вопросов они всё же решают. Ну первое что приходит на ум - экран. Он обязан иметь максимально маленький размер пикселя, потому что глаз находится очень близко и зерно видно прекрасно. У Vive экран для одного глаза имеет разрешение 1080x1200.. и это в таком то размере! Производство таких вещей ещё надо организовать, а потом поставить так, чтобы глаза не разбегались.
Если проще, то вся сложность чисто инженерная - правильно и компактно скомпоновать это всё в шлем, чтобы он весил мало и не мешался. Ну и кусочек, связанный с опытными испытаниями, чтобы девайс корректно считывал своё положение, перемещение и понимал входящий сигнал. Это всё уже ПО-шные вопросы, но требующие решения.

Российского производства.. а зачем? Кому оно надо? Кто это купит? Аппаратная простота это она в мире простота, а у нас ничего из перечисленного нет. Тот кто возьмется за разработку будет вынужден покупать экраны, покупать контроллеры, покупать датчики..и покупать ПО для написания ПО. А потом ещё всё это как-то собирать. Получится золотое устройство в два, а то и в три раза дороже самого последнего Oculus Rift с уже готовым SDK и серьёзно развернутой компанией, которая не прекратит работу вот уже завтра, потому что деньги кончились.. И это при условии, что можно взять китайский смартфон за 15к, поставить его в картонный держатель, вырезанный из старой коробки от телевизора и сидеть смотреть порнографию котиков в виртуальном мире.
Теперь уже и зарубежных особо не появится. Вся фишка Oculus Rift была в том, что они были первые, кто выпустил массовый прототип. А потом подтянулись остальные. Gear неплохо ломанулся в игровую зону с расчетом на SteamVR. Производителей этих шлемов так мало, не потому что сложно, а потому что никому не надо, особенно за такие деньги. После появления вышеописанных картонных коробочек, выход на рынок с самостоятельным девайсом почти нереален, если вы не гигант типа Valve, которая знает куда эти очки прикрутить.

Читать всё про инерциальную навигацию в пространстве, контроллеры и видеотракты. Дополнительно стоит почитать биологию и анатомию по части зрения и восприятия, чтобы определиться с оптимальными параметрами. Ну и по эргономике хоть что-нибудь минимально, чтобы не получился кирпич на веревочках. Естественно, всё это повязано через ПО, поэтому параллельно читайте программирование всего это (инерциальная навигация требует не только понимания её самой, но и методов обработки в цифре)

Спрашивать форумы, статьи, тот же хабр. Не привязывайтесь жестко что это именно VR. Любой квадрокоптер использует абсолютно то же самое, только иначе. Даже где-то была статья, где мужик себе акселерометр прицепил на резинке к голове и управлял камерой в игре. Сделано на коленке, но полностью показывает сложность системы.

Вы уж извините, но специалисты этим не занимаются. Это хобби для гика. Любой вменяемый инженер-"мехатронщик" сделает такое не выходя из дома. Разве что экраны забрать у доставки, если на полке с хламом нет подходящих. Просто ставиться вопрос контента и идея собрать такое сразу пропадает. Контента нет. Т.е. есть демонстрационные ролики, какие-то небольшие софтинки. Всё очень скудно и не интересно, поиграться, разобрать на части и сделать что-то полезнее. Оказалось, что просто так взять готовую игру, например, созданную под плоский экран и просто показать на два глаза не катит. Надо смещать изображение на угол обзора, обеспечивающий бинокулярное зрение, а это не так просто сделать с готовым продуктом - получается похабно.
Поэтому сейчас все наборы этих шлемов идут фактически как "набор для разработчика"... разработчика приложений, разумеется. Потому что нужен рынок приложений, а их нет и писать хотят далеко не все. Вот тут сложности появились. Сложности с платформами, сложности с графикой, движками и ещё вагоном непоняток, которые никто пока не отрабатывал серьёзно.

А касательно всё таки дополненной, то всё то же самое, только проецировать сложно..а точнее некуда. Конечно, буквально неделю назад появилась статейка на GT, где из советского калькулятора сделали "аналог" GoogleGlass, но до серии там далеко, хоть и интересно. =)