Перейти к содержанию
Fire Monkey от А до Я
  • 0

Рендеринг "невидимых" плоскостей или как обуздать отсечение


HoShiMin

Вопрос

Уже создавал тему по этому вопросу, надеялся, что в ХЕ8 рендеринг исправят, но нет. Кроме того, проблема обросла подробностями. 

Итак, та же моделька того же человечка в шлеме, собрана на TPlane'ах, код текстурирования тот же, всё так же не рендерится голова внутри. В тот раз проблема решилась случайно и я сам не понял, что же именно привело к решению. С тех пор форму старался не трогать, но рано или поздно дошёл и до неё черёд. И как результат, та же проблема - уже в ХЕ8.

 

Подробнее о том, как организована модель:

Viewport3D, внутри него лежит TDummy, в котором собрана TPlane'ами модель, а также камера, которая на это безобразие смотрит:

post-855-0-59539600-1431295614_thumb.png

 

 

Теперь непосредственно к проблеме:

Смотрим на скрин:

post-855-0-78153300-1431293719_thumb.png

 

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

Интересно, а что "внутри" шлема? Чтобы узнать, сделал возможность в рантайме, не закрывая программу, "снять" шлем (Visible для всех граней в False).

Смотрим:

post-855-0-21874700-1431293721_thumb.png

 

Оп! Все грани на месте, всё отлично прорендерилось! А если снова "надеть" шлем?

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

 

Следующим шагом попробуем уменьшить прозрачность одной из плоскостей шлема и посмотреть сквозь неё на отсечённую плоскость головы:

 post-855-0-70137400-1431293723_thumb.png

 

Так точно, и полупрозрачность не заставляет включаться рендеринг "внутренних" граней.

 

А что будет, если поменять разрядность платформы? Выставим Win64/Debug и - о чудо! - рендеринг внезапно заработал!

post-855-0-48411900-1431293722_thumb.png

 

 

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

post-855-0-92756600-1431293724_thumb.png

 

 

Итак, что же мы узнали из этих исследований? Ровным счётом ничего. Рендеринг или, наоборот, нерендеринг не имеют никаких закономерностей.

 

Какими способами удалось повлиять на прорисовку этих поверхностей:

1) Изменение целевой платформы (Win32/Win64/Debug/Release) дают разный результат - практически всегда из четырёх комбинаций есть удачная, где всё рендерится

2) Изменение формы - добавление новых элементов или удаление существующих, помогает не всегда. На рабочей конфигурации может наоборот привести к отсечению граней

3) Изменение кода. ЛЮБОЕ. Даже никак не связанное с рендерингом. Достаточно воткнуть в произвольное место что-то типа Inc(Variable), чтобы рендеринг починился. Этого же, впрочем, достаточно и для того, чтобы рендеринг сломался.

 

Что НИКАК не влияет на рендеринг:

А не влияет всё то, что должно было бы повлиять, а именно:

1) Расстановка в любых мыслимых и немыслимых местах BeginUpdate'ов и EndUpdate'ов

2) Repaint'ы и Invalidate'ы всего и вся

3) Обновление текстур (грубо говоря, заливка модели новой текстурой)

4) Использование StyleBook'a

 

Исходя из вайрфреймов, нарисованных на каждой плоскости, мы видим, что не прорисовываются сами TPlane'ы. Могу предположить, что движок считает их невидимыми и отсекает как ненужные для оптимизации, но почему, в таком случае, рендерятся передняя и задняя плоскости головы?

 

Итак, вопрос - классика: кто виноват и что делать. Баг ли это в движке FMX, или же всё учтено и достаточно задать волшебную опцию, которая разом всё починит - я так и не узнал. Приветствуется любая помощь, а также хотелось бы раз и навсегда закрыть вопрос: в каких случаях нужно делать BeginUpdate/EndUpdate и влияет ли он на обработку отрисовки унаследованных объектов.

Изменено пользователем HoShiMin
Ссылка на комментарий

Рекомендуемые сообщения

  • 0

Впечатляет. Обидно, что много багов. По себе знаю, как это выбивает из процесса и сколько "съедает" времени.

 

Напишу только про BeginUpdate/EndUpdate. Не буду утверждать, что это верный подход, но в процессе экспериментов сложилось следующие мнение и подход к этому вопросу.

BeginUpdate ускоряет "обновление" элементов, за счет того, что отключает срабатывание у объектов процедур, подвешенных на события on... Т.е. к примеру если не нужно, чтобы сработала обработка на events onCange, или если не важно, я включают BeginUpdate. И наоборот...

Ссылка на комментарий
  • 0

Впечатляет. Обидно, что много багов. По себе знаю, как это выбивает из процесса и сколько "съедает" времени.

 

Напишу только про BeginUpdate/EndUpdate. Не буду утверждать, что это верный подход, но в процессе экспериментов сложилось следующие мнение и подход к этому вопросу.

BeginUpdate ускоряет "обновление" элементов, за счет того, что отключает срабатывание у объектов процедур, подвешенных на события on... Т.е. к примеру если не нужно, чтобы сработала обработка на events onCange, или если не важно, я включают BeginUpdate. И наоборот...

Это-то как раз понятно, вопрос немного в другом: необходимо ли предотвращать перерисовку на время, скажем, загрузки битмапа или в похожих случаях. Именно чтобы избежать артефактов. И если я выставлю BeginUpdate для TImage, внутри которого лежит ещё куча объектов, они тоже не будут перерисовываться, пока к компоненту-родителю не будет применён EndUpdate, или нужно их блокировать отдельно? И какой вообще принцип работы с ними? Например, будет ли назначена объекту принудительная перерисовка после EndUpdate, или нужно вызывать Repaint.

 

Ну а в плане багов, кроме этого (и невозможности комбинировать эффекты, типа размытия, с другими) пока что всё идёт хорошо, верстать формы - одно удовольствие, от обилия эффектов радуется душа, хочется попробовать всё и сразу, да и с производительностью всё обстоит в целом неплохо. Попробовал всю свою форму закинуть в ещё один Viewport3D, чтобы сделать эффект изменения перспективы, как в главном меню Crysis 2, когда двигаешь мышью и немного поворачивается перспектива, но для таких нагрузок, видимо, FMX не предназначен - крутиться моделька стала с подтормаживаниями (возможно, полноценный перенос в 3D решит проблему, но в HD приложении так, от эффекта этакого "параллакса" пока пришлось отказаться).

Изменено пользователем HoShiMin
Ссылка на комментарий
  • 0

 

Впечатляет. Обидно, что много багов. По себе знаю, как это выбивает из процесса и сколько "съедает" времени.

 

Напишу только про BeginUpdate/EndUpdate. Не буду утверждать, что это верный подход, но в процессе экспериментов сложилось следующие мнение и подход к этому вопросу.

BeginUpdate ускоряет "обновление" элементов, за счет того, что отключает срабатывание у объектов процедур, подвешенных на события on... Т.е. к примеру если не нужно, чтобы сработала обработка на events onCange, или если не важно, я включают BeginUpdate. И наоборот...

Это-то как раз понятно, вопрос немного в другом: необходимо ли предотвращать перерисовку на время, скажем, загрузки битмапа или в похожих случаях. Именно чтобы избежать артефактов. И если я выставлю BeginUpdate для TImage, внутри которого лежит ещё куча объектов, они тоже не будут перерисовываться, пока к компоненту-родителю не будет применён EndUpdate, или нужно их блокировать отдельно? И какой вообще принцип работы с ними? Например, будет ли назначена объекту принудительная перерисовка после EndUpdate, или нужно вызывать Repaint.

 

Ну а в плане багов, кроме этого (и невозможности комбинировать эффекты, типа размытия, с другими) пока что всё идёт хорошо, верстать формы - одно удовольствие, от обилия эффектов радуется душа, хочется попробовать всё и сразу, да и с производительностью всё обстоит в целом неплохо. Попробовал всю свою форму закинуть в ещё один Viewport3D, чтобы сделать эффект изменения перспективы, как в главном меню Crysis 2, когда двигаешь мышью и немного поворачивается перспектива, но для таких нагрузок, видимо, FMX не предназначен - крутиться моделька стала с подтормаживаниями (возможно, полноценный перенос в 3D решит проблему, но в HD приложении так, от эффекта этакого "параллакса" пока пришлось отказаться).

 

а что вы такое делаете? игру?

Ссылка на комментарий
  • 0

а что вы такое делаете? игру?

Лаунчер для одной очень известной игры. Это такая функциональная запускалка с проверкой игрового клиента, выбором сервера, настройкой внешнего вида игрока (для визуализации и нужна моделька) и мощной низкоуровневой антиотладочной защитой и защитой от редакторов памяти. Подробнее здесь. И всё было бы здорово, если бы не досадное отсечение плоскостей у головы, которое я никак не могу победить. Здесь уже нужна помощь разработчиков FMX...

Ссылка на комментарий
  • 0

я вот не пойму, если ты делаешь программу с

мощной низкоуровневой антиотладочной защитой и защитой от редакторов памяти

 

 

неужели так трудно прогнать в отладчике программу и пошагово выяснить почему не прорисовываются определенные плоскости? исходники FMX есть. 

Ссылка на комментарий
  • 0

я вот не пойму, если ты делаешь программу с

мощной низкоуровневой антиотладочной защитой и защитой от редакторов памяти

 

 

неужели так трудно прогнать в отладчике программу и пошагово выяснить почему не прорисовываются определенные плоскости? исходники FMX есть. 

Действительно, пошагово пробежаться по тысячам строчек с неизвестным принципом работы и исправить рендеринг - это же так просто.

Ссылка на комментарий
  • 0

главное найти от куда плясать и все. а что ты хотел то? fmx это такой зверь которые надо пилить и пилить, не зря наши делали. это как и наши машины, купил а потом напильником подгоняй что бы работало  :D

Ссылка на комментарий
  • 0

главное найти от куда плясать и все. а что ты хотел то? fmx это такой зверь которые надо пилить и пилить, не зря наши делали. это как и наши машины, купил а потом напильником подгоняй что бы работало  :D

Так и есть) Пробовал уже пробежаться по коду FMX, но ничего это не дало, что, в общем-то, неудивительно) Но вот что интересно - для каждого TPlane'a в OnRender добавил Application.ProcessMessages (ни из каких соображений это не следовало, просто на авось) и отчасти помогло. Плоскости уже не отсекаются, но и текстурки под шлемом не прорисовываются, а заливаются почему-то чёрным до первого взаимодействия с моделью (стоит её ухватить мышью и чуть-чуть подвинуть - всё прорисовывается). Но надолго ли? Я даже не знаю, почему обработка очереди сообщений помогла, а Repaint'ы и Invalidate'ы - нет. Может, это иллюзия починки, ведь в первом посте я выяснил, что рендеринг может починить совершенно любой код, вставленный в совершенно произвольное место (и он же может его сломать).

post-855-0-96473400-1431547214.png

Изменено пользователем HoShiMin
Ссылка на комментарий
  • 0

Может, это иллюзия починки, ведь в первом посте я выяснил, что рендеринг может починить совершенно любой код, вставленный в совершенно произвольное место (и он же может его сломать).

Так и есть, ничего это не решило. Теперь отсекается задняя поверхность. Вот где здесь найти логику?

Ссылка на комментарий
  • 0

У меня была похожая проблема. За Tplane с альфа каналом ничего не рисовалось (Сразу фон). Помогла смена материала с TLightMaterial на TTextureMaterial.

Ссылка на комментарий

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить на вопрос...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...