Разбираемся с технологией 3D программирования

[ost]

Вы, получается, свою работу автоматизируете в нерабочее время? Ого!

=) Не знаю как Kadet, но так и живем. Сейчас вот отпуск. До конца недели - с интернетом. Успеваю вот тоже. =) Каюсь, оффтоп.

[Kadet]

Вы, получается, свою работу автоматизируете в нерабочее время? Ого!

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

Михаил, напрасно Вы на меня обижаетесь. Я очень ценю помощь каждого и Вашу в частности, но поймите и меня. Я открываю предлагаемый Вами вариант... И что я вижу? То, над чем я трудился почитай месяц, преодолевая дебри инфоголода и каждое новое понимаение чего-либо воспринимая очередным "взятием Берлина"... вы превратили в некоего непонятного "костлявого паучка"... Зачем-то поставили его "на-попа", поменяв Y с Z, и всю свою дальнейшую логику выстроили исходя из этой, "перевёрнутой" и непонятной (для меня) картины мира. Я воспринимаю мир исходя из классической схемы - X - горизонт, Y - высота, Z - глубина. Так меня учили в советской школе и в советском ВУЗе. Возможно сейчас в быту иная картина мира, но для её восприятия мне нужны определённые усилия и трудозатраты.
Я влез в Ваш код, просмотрел его и понял, что для его понимания мне потребуется не меньше недели и отложил это "на потом"...

Так, что уж простите за "несвоевременное" реагирование на вашу попытку помочь.

P.S.: каюсь, функции CALC сразу не заметил. Сразу "побежал" к матрицам, где ничего не понял и отложил (по привычке считая, что всё "дописанное" обычно располагают внизу уже написанного, а не вверху).
За эти функции отдельная Вам благодарность. Буду пользовать.

Только яндекс-транслейт слабоват. Хотя бы гугл.

Оба они "хороши". А чего ожидать от автоматов? Для меня английский как китайская грамота - не в зуб ногой. Даже в школе немецкий учил, который знаю не более английского. Так, что описания на иноязыках для меня вообще, почти неприемлемы. В особенности такие краткие, рассчитанные на первичные глубокие познания вопроса. Ведь для меня Ваша фраза: "специальных функций из адд-инов", тоже абракадабра. Я её вообще не понял.

[eeigor]

add-in то же, что extension – надстройка, расширение с дополнительными возможностями

[mikekaganski]

Виноват, прошу прощения

[Kadet]

mikekaganski, да не стоит. Всё нормально. Рабочие моменты.

Поделюсь с Вами моими потугами внедрить Ваши технологии в свой проект. Сразу оговорюсь - восстанавливаю "картину мира" к классическому виду: X - горизонт, Y - верх, Z - глубина. Мне так понятней, а душе приятней. (Ссылки на вложения)

photo - использовал ваши версии построения моделей. Оставил свой метод создания и позиционирования сцены. Нужно признать, что перетаскивание из макроса в макрос объекта сцены, оказалось более эффективным таскания индекса с последующим поиском этого объекта в каждом новом макросе по индексу. Спасибо за идею!

photo1 - переношу вашу сцену без изменений.

photo2 - обнуляю позицию камеры - (0,0,0).

photo3 - переношу камеру в мою позицию - (41000,11000,0).

В общем, не понятно: почему сцена имеет квадратную форму с равными X и Y, хотя я задаю ей пропорции экрана? Считаю это не правильно. В той задаче, которую я ставлю перед этим проектом в принципе не нужен "правильный" вид сверху/снизу во всех перспективах. Достаточно немного приподнять или приопустить камеру без полного оборота. Поэтому чуть приплюснутая сверху сцена вполне допустима.
Почему при X=0, Y=0, Z=0 мне показывает бок конструкции, хотя по-идее я должен видеть фасад?
Зачем делать обратную нормализацию фокуса камеры (-pt.PositionX и т.д.)? Она-то и устанавливает картинку на "вид-с-боку".

Таки я добалися более-менее удобного для меня изначального положения камеры, НО... остался самый главный вопрос. Ответьте как "художник художнику". 60м - длина каркаса. Расстояние от центра каркаса до смотрящего - 100м. Фасад от смотрящего в 70м, а тыл - в 130м. По всем канонам перспективы - "задница" должна казаться уже "передницы". А у Вас они получаются одинаковыми.

(Это не стёб, мне действительно хочется разобраться).

[Kadet]

photo_my - то, что я получаю только своими методами.

photo_my+mk - а это совместными, т.е. то, чего я смог добиться внедряя макросы. И всё бы ничего. И угол обзора настрою, и косяк с крышей поправлю. Вопросы решаемы. Но мне не понятно, почему тыльная (дальняя) сторона конструкции равна или даже шире фасадной (ближней). Почему-то кажется, что должно быть наоборот.

[mikekaganski]

В общем, не понятно: почему сцена имеет квадратную форму с равными X и Y, хотя я задаю ей пропорции экрана? Считаю это не правильно. В той задаче, которую я ставлю перед этим проектом в принципе не нужен "правильный" вид сверху/снизу во всех перспективах. Достаточно немного приподнять или приопустить камеру без полного оборота. Поэтому чуть приплюснутая сверху сцена вполне допустима.

Ничего тут не "должно". Я так же, как и Вы, экспериментировал, и причём тоже не заглядывая в код (времени не было), поэтому эмпирика и догадки. Я видел искажения при прямоугольной сцене, и предположил, что результирующее изображение в своих границах в конце концов вписывается в габариты элемента сцены на странице. Из этого было следствие: для предотвращения искажений результирующее трассированной изображение должно иметь те же соотношения длины и высоты, что и объект сцены. Но моё предположение не доказано (как, впрочем, и не опровергнуто) - просто я пытался определить это самым простым способом - заставив и результат трассировки, и сцену иметь одинаковые размеры по всем направлениям. Для трассировки я поэтому добавил описывающий шар, который, как я надеялся, сделает изображение шара одинаковым со всех точек, а для сцены - понятно.

Но тут возникает момент - перспектива, которая деформирует трассировку. Я отключил перспективу для тестов.

Что касается "Зачем делать обратную нормализацию фокуса камеры (-pt.PositionX и т.д.)? Она-то и устанавливает картинку на "вид-с-боку"" - на самом деле это этап определения правильного задания камеры. С учётом того, что я поместил группу объектов сцены в 0,0,0, направление нормали к плоскости получается тривиальным - оно просто совпадает с значениями координат. И тем не менее, всё плохо - деформации остаются. Я проверял, что будет при развороте в противоположном направлении - отсюда и минусы. При этом, несмотря на то что по логике мы должны смотреть совсем не туда, объекты сцены всё равно видны в центре - просто развёрнуты иначе. Я пока не могу это объяснить. Возможно, я просто не до конца разобрался с правильными значениями фокусного расстояния и глубины...

[Kadet]

Я видел искажения при прямоугольной сцене

Возможно искажения могут уйти если применить другие методы позиционирования камеры, чем применил я в первичном варианте, кстати и Вы тоже, позиционируя камеру по X, Y, Z = 100000.
Заметил, что если изменять позицию камеры изменяя её положение по X, Y и Z то модель вместо простого разворота ещё и деформируется. При попытке вращения плоскости X-Z методом изменения этих координат по окружности, вместо простого разворота модель почему-то растягивало, инвертировало и выдавало прочие безобразия.
Однако, если применить к сцене методы матричных преобразований, воздействую на её матрицу, а не на координаты камеры, мне показалось, что деформации уходят.

[mikekaganski]

Совершенно верно. Просто интересно, что это за камера такая. Мне казалось, что логично двигать камеру, чтобы непосредственно выразить идею взгляда на объект с разных сторон, но видимо, проще модифицировать сцену. Либо это баг, либо я не понимаю логику позиционирования камеры от слова совсем.

[Kadet]

Мне казалось, что логично двигать камеру, чтобы непосредственно выразить идею взгляда на объект с разных сторон, но видимо, проще модифицировать сцену.

Мне тоже так казалось, именно поэтому изначально я пошёл именно поэтому пути. И именно по-этому написал в багзилу, где меня не поняли и предложили использовать мартицу.

Однако у позиционирования матрицей тоже есть свои косяки. После первичного смещения матрицей начинаются проблемы с позиционированием, наклонами и т.п. у  моделей, встраиваемых после преобразования матрицы сцены. Особенно ярко выражаются косяки в RotateAlign.
Именно из-за этого, попробовав матрицу, я и вернулся к простому позиционированию камеры. Пусть даже с небольшими деформациями, но всё же с правильным позицинированием моделей.
А матрицей удобно вращять уже после того, как все модели встроены. Тогда искажения минимальны.

[Kadet]

Странности продолжаются.
Фокус камеры по Z не должен иметь нулевое значение. По умолчанию он равен 288,456

Код Выделить Развернуть

D3DCamera.vpn.DirectionZ = 2884
При нуле модели перестают отображаться в сцене.
Возможно это мой личный частный случай, но это происходит.

[Kadet]

Наконец-то добился от преобразований Михаила удовлетворяющей проект работы. Y-Z привёл к привычному мне миропониманию.
Все манипуляции с камерой произвожу матричными преобразованиями.  Однако, при первичном выставлении положения камеры всё равно приходится загонять некоторые "загадочные" цифры, без которых получается либо "Пикасо", либо "белый квадрат".

Код Выделить Развернуть

D3DCamera.vrp.PositionZ = 102885.714285714
D3DCamera.vpn.DirectionZ = 2885.714285714

Первая - дистанция до фокуса. Вторая смещение фокуса по Z. Цифры изменяют порядок в зависимости от удаления до фокуса объекта. Что это за магические цифры и почему без них не работает остаётся загадкой.

Не нравятся какие-то искажения форм стоек и их непонятно-полосатая заливка (возможно это приколы лишь моего компа).
Так же не нравится неизменность наклона положения модели по высоте при вращении (первичный наклон по оси X). Гораздо лучше было, когда вертикаль камеры была фиксированной, а плоскость вращения как бы крутилась под ней.
xDoc.lockControllers при восстановлении первоначального положения после вращения почему-то не работает.

Есть ли искажения, как раньше?

[kompilainenn]

У меня ощущение, что вам нужен параметрический CAD, а вы мучаете бедный офисный пакет

[mikekaganski]

И именно по-этому написал в багзилу, где меня не поняли и предложили использовать мартицу.

Почему Вы решили, что Вас не поняли в баге 143465? Регина ответила Вам, посоветовала, и более того, уточнила, что Вы говорите не о баге, а о новом функционале. Кроме того, Ваш запрос совсем не относится к камере (которая всего лишь набор параметров сцены, а не отдельный объект), поэтому непонятно, почему Вы о нём написали в контексте ответа #83.

[mikekaganski]

Однако, при первичном выставлении положения камеры всё равно приходится загонять некоторые "загадочные" цифры, без которых получается либо "Пикасо", либо "белый квадрат".

Код Выделить Развернуть

D3DCamera.vrp.PositionZ = 102885.714285714
D3DCamera.vpn.DirectionZ = 2885.714285714

Первая - дистанция до фокуса. Вторая смещение фокуса по Z.

Нет.

vrp - это View Reference Point - трёхмерная точка, в которой расположена камера. Точка, в которой находится "зритель" в трёхмерном пространстве сцены. PositionZ - это просто координата Z (высота в норме, у Вас - одна из горизонтальных осей).

vpn - это View Plane Normal - нормаль (вектор, перпендикулярный) к плоскости взгляда (то есть к плоскости, которая будет отрисована). Так неочевидно назван фактически вектор, совместно с vrp определяющий ось, по которой направлена камера. По стандартному соглашению, этот вектор направлен от объекта к камере (я не проверял в коде, следуем ли мы этому соглашению, но по идее должны). Этот вектор в общем случае определяется как разность точек камеры и объекта. Вектор можно нормализовать - на самом деле его величина не имеет значения, поскольку единственное его назначение - определить ось взгляда. Его DirectionZ - это, конечно, просто проекция вектора на ось Z.

До кучи ещё vup - это View-UP вектор, определяющий направление верха относительно камеры (то есть, где будет "верх" у результирующего изображения). Этот вектор при перемножении с vpn должен давать вектор "горизонтали, перпендикулярной взгляду". Изменение этого вектора фактически аналогично вращению камеры вокруг оси взгляда (камера делает фигуру высшего пилотажа "бочка").