Как убрать прозрачность в Shape3DPolygonObject

Автор Kadet, 27 марта 2024, 21:37

0 Пользователи и 1 гость просматривают эту тему.

Kadet

Добрый день!
Бьюсь 2-ю неделю, но ничего не получается, а очень нужно.

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

Раньше делал плоско-полигональные объекты, а теперь возникла необходимость создать замкнутую, типа куба. И этот объект всегда получается прозрачной. Видны только контуры-рёбра.

Для примера сделал куб встроенной в LO моделью - com.sun.star.drawing.Shape3DCubeObject. Он получается как надо.
И нарисовал куб полигоналями с помощью - com.sun.star.drawing.Shape3DPolygonObject. Он получается прозрачным.

Прозрачность образуется при появлении "задней стенки", заходящей за "переднюю". Проверял это незамкнутыми формами.

Может кто разбирался с подобными вопросами и сможет помочь с этим.

В тестовом документе нужно надать кнопку "начертить". Появятся два ряда кубов. Слева, залитые, это Cube, а справа, контурные, это PolygonObject.

Cube создаёт макрос DrawCube3D в библиотеке макросов документа.
PolygonObject создаётся макросом - DrowPolygon3D. Матрица полигоналей создаётся в функции setPLPoligon, по Case "КСП".

Если есть желание посмотреть как выглядят не замкнутые полигональные объекты, создаваемые этими же макракросами, в макросе Konstructor нужно установить любой другой sGroup, вместо sGroup = "КСП" (в самом конце макроса).

Kadet

#1
В новом примере (Тест1) я убрал правую и заднюю грани.
Тут явно видно, что прозрачность появляется только там, где грани накладываются друг на друга.

Инет говорит, что якобы нормали граней вывернуты и заливка как бы остаётся внутри. И нужно эти нормали каким-то образом вывернуть обратно, но функция инверсии нормалей (xShape3D.D3DNormalsInvert = True) - не помогает или не работает.

Есть ещё матрица нормалей (xShape3D.D3DNormalsPolygon3D) и матрица текстуры (xShape3D.D3DTexturePolygon3D), но пробы загнать туда какие-нибудь массивы данных нечего не дают.

В общем, не получается.

mikekaganski

У меня нет ответа. Но есть просьба: пожалуйста, для тестов используйте минимальный код - например, на базе приложенного документа. Да, тут нет блекджека, зато нет и кучи ненужных строк, которые только усложняют понимание и затрудняют поиск решения. Спасибо.
С уважением,
Михаил Каганский

Kadet

Зато там есть много хороших рабочих макросов по графике.
Понимаю, что многабукаф, но оставил их, может кому пригодятся.
Макросы отлажены и прекрасно работают. На большинство случаев графики.

mikekaganski

#4
Абсолютно согласен. Макросы хорошие и полезные. Но только если они выложены в теме типа "вот вам хорошие и полезные макросы для X, Y, Z - пользуйтесь!". В такой теме у людей есть хоть какой-то шанс их найти, чтобы воспользоваться. И они в такой теме не мешают людям, которые в теме "помогите решить проблему N" пытаются разобраться в этой проблеме.

Так что разным случаям - разные макросы.
Написал https://ask.libreoffice.org/t/how-to-make-colored-opaque-shape3dpolygonobject/104047.
С уважением,
Михаил Каганский

Kadet

#5
Цитата: mikekaganski от 28 марта 2024, 08:37Так что разным случаям - разные макросы.
Написал https://ask.libreoffice.org/t/how-to-make-colored-opaque-shape3dpolygonobject/104047.
Спасибо!

Там появился ответ, вернее вопросы. Так как там не зарегистрирован и мой английский никакуя, поясню тута. Прошу передать, если будет желание.
ЦитироватьRegina
14ч
Привет, Майк, это интересный проект. Я не знаю готового ответа. Я не использовал макросы для 3D-объектов, но я всегда работал непосредственно в исходном файле. Итак, мне нужно некоторое время, чтобы разобраться в этом и опробовать самому.

В общем, существуют такие проблемы:

Многоугольник должен быть замкнутым, чтобы его можно было заполнить.
Я думаю, у многоугольника должны быть все точки на плоскости.
У многоугольника есть "inside" и "outside". Что такое "inside" и "outside", зависит от порядка расположения точек. "Inside" многоугольника обычно не рисуется. Тогда полигон будет выглядеть прозрачным.
Я не уверен, сработает ли использование полигона непосредственно в сцене вообще. Если вы сохраните файл, в результате получится пустая сцена. В настоящее время сцена в ODF может содержать только дочерние элементы cube, sphere, extrusion, rotate и scene.
Возможно, вам следует начать с гораздо меньшего размера, с одного плоского многоугольника и без преобразований.

И я бы не стал работать в Calc, потому что в нем нет пользовательского интерфейса для 3D. Из-за этого make невозможно экспериментировать с настройками рендеринга.


Многоугольник замкнутый. Все точки одной грани лежат в одной плоскости. Это определённо.

Что такое "inside" и "outside" не понимаю, но с порядком расстановки точек экспериментировал. Не помогло.
На счёт сохранения не знаю, да, честно-говоря, для моего проекта это не обязательно. Фигуры каждый раз формируются заново на основании данных из БД.

Calc в основе выбран не случайно. Основа проекта - БД и табличные документы. Графика - побочный продукт и украшение, но однако вещь очень важная. Посему и Calc.

Однако Регина подала хорошую идею - скопировать созданный макросом объект в Drow и поэкспериментировать.

Кстати, сравнивал все методы и значения объектов Cube и Polygon. Все перехлёстывающиеся методы (которые есть и там и там) устанавливаю одинаковыми. Однако, в Polygon есть ряд методов, которых нет в Cube. Это (xShape3D.D3DNormalsPolygon3D) и (xShape3D.D3DTexturePolygon3D), и они пусты. Т.е. - это массивы типа - PolyPolygonShape3D, но они пусты. В такие же массивы загоняются координаты точек фигуры. Но в этих массивах ничего нет. Может в них всё дело?! Хотя я пытался загнать туда  какие-нибудь цифры, даже полностью координатный массив загонял. Не помогало.

Kadet

В догонку. Плоскими полигонами занимался, и описывал выше. С ними всё  в порядке. Проблема возникает только тогда, когда полигоны налегают друг на друга. Получается прозрачность.

В инете пишут, что подобный эффект иногда возникает, когда параметр
xShape3D.FillColorTheme = -1(А так оно и есть). Тогда цвета при наложении перемножается и при Theme=-1 выходят за рамки дозволенности (видимо становятся отрицательными). И получается эффект прозрачности. Т.е. - заливка исчезает.
Но, эксперименты по изменению этого параметра не приводят к решению этой проблемы.

Kadet

mikekaganski, спасибо. Увидел ваш перепост на сайте LO.

Покажу таки, что зачем всё это нужно и насколько это серьёзно.

Я строю проект здания с расчётом его сметы, эскизами и т.п. К эскизам и расчётам должны прилагаться 3D-модели рассчитываемых объектов.

Вот экспорт 3D-моделей в PDF.

Пример-1 - здание обшито пронастилом. Профнастил тоже делается с помощью того же полигонального макроса. НО, профлист хоть и фигурная модель, но односторонняя. Он плоский. У него нет обратной стороны. Всё получается как надо.

Пример_2 - та же конструкция, но обшивка делается сэндвич-панелями. В отличает от профлиста сэндвич-панели это объёмная модель. Она обязательно должна иметь толщину.
В итоге получается - поликарбонат.

Kadet

#8
По идее, за направление (стороны) заливки в модели отвечают два параметра
Они же, по-идее, отвечают за направление "inside" и "outside" ("внутрь" и "наружу")
    xShape3D.D3DDoubleSided = True    ' Двусторонняя заливка
    xShape3D.D3DNormalsInvert = True    ' Инверсия нормалей
Но, изменение их значений не решают проблему.

economist

Kadet, очень круто, особенно в части сбора всех методов процедурного рисования. Раньше видел подобное но в ограниченных применениях (окна, кровля, фундаменты). Отделка наружная вроде тоже частный случай, но непростой.

Все равно не покидает мысль что выбран не просто трудный, а самый трудный путь из возможных в свободном и free-ПО.

На мой взгляд архитектурно правильнее было бы сделать все в истинном CAD или удобном рисовально-чертежном ПО, имеющем готовые механизмы или расширения для табличного экспорта Смет с объемами, расценками, коэффициентами, суммами (ну почти Гранд-смета). Это решено или почти решено в:
- Sketchup - это Free, но слишком хорошее, аналогов в СПО пока нет
- FreeCAD (+Python) - это СПО
- InkScape  (+Python)  - это СПО

Помимо готовых разных проекций и срезов (для сложных объектов это неизбежно), CAD/CAE очень часто позволяют использовать готовые чертежи зданий (DXF/DWG) или 3D-модели из фото/облетов коптером, посаженные "в размер". Импорт DXF в Draw все-таки односторонний и очень ограниченный. 

Например, в SketchUp для создания 3D-модели из JPG-чережа (план, вид сверху, +высота потолков и +размеры всех окон) - уходит около 8 минут. При этом вы получаете готовые обмеры внутри/снаружи, все строительные объемы, смету. А еще - очень круто выглядящие эскизы с освещением из разных точек. Понятно что в договоре это лишнее, но мы то знаем что до договора идет важнейшая стадия принятия сделки и визуализация имеет огромное значение. Даже интерактивный подбор цвета может стать фактором выбора данного поставщика, а не другого, где только караксный, упрощенный, изометрический чертеж итд.   

   

       
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

Kadet

economist, метод не лёгкий, бесспорно, но уже откатанный. В принципе уже разработаны расчёты 2-х видов промышленных строений. И всё в порядке. На подходе ещё два вида. Уже частично сделанные. А в намётках ещё один вид.
В общем - проект пользуется определённым спросом.

Это я к чему. Всё уже фактически пройдено, и неплохо работает. И делается легко. И менять коней на финишной прямой, не самая лучшая идея.

К тому же, кады и т.п. конечно есть, и я даже пробовал их внедрить, но... Главная проблема кадов в том, что для работы в них требуются специальные навыки. Например для работы в популярной в этой среде "Компасе" нужна как минимум полугодичная спец-подготовка специалиста. Да и программировать кады не просто. А уж снимать и хранить данные в БД ещё сложней.

Главная фишка моих программ в том, что они не требуют каких-либо специальных знаний и навыков. Любой прораб средней руки сядет, выберет нужные ему параметры и в итоге получит расчёты с эскизами конструкции. Занимает это обычно не более получаса. А в кадах рисунки делают иной раз неделями.
В БД хранятся только цифры и названия элементов. И на основании этих данных программа каждый раз заново стоит конструкцию.

Просто работать, легко вносить изменения, легко хранить. Ещё в ЛО легко всё экспортируется и в отдельный Calc-документ и в PDF, и во Write.

Да, минусов не мало. Бесспорно. Это и тяжёлая графика, и медленная прорисовка, и сложности со вращением 3D-видов (мышкой они не поворачиваются) и т.п. но, всё-таки это не сильно портит картину.

Kadet

Цитата: economist от 30 марта 2024, 10:34Kadet, очень круто, особенно в части сбора всех методов процедурного рисования. Раньше видел подобное но в ограниченных применениях (окна, кровля, фундаменты). Отделка наружная вроде тоже частный случай, но непростой.
Тут ещё фигуры Базье не представлены. А они есть и используются.
 :roll:

Kadet