Статья 3

[Dronas]

Точно! Надо все боксами, но тогда мы можем потерять уважаемого Vadifona. По поводу примера Койота - неужели не видно разницы, и не хочется ли, все же, положить взгляд на более приятный вариант со скруглением? И не в этом бортике 640 поликов, а благодаря экономии, которая не меняет вид объекта, мы имеем право его сделать. И не кнопку прошу всех делать - я продемонстрировал принцип, который можно применить при моделировании вообще, что-ж вы к ней пристали, бедной.

 

Тут такое дело, если оптимизация не то что огрубляет форму, а искажает её (сведение нижней части на нет), Вадифону тоже может не понравиться ;)

[Coyote]

Тут такое дело, если оптимизация не то что огрубляет форму, а искажает её (сведение нижней части на нет), Вадифону тоже может не понравиться ;)

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

[Dronas]

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

 

Да понимаю я, но коль уж придираться, так придираться :)

[GK]

Чего-то я уже не доганяю ... Так этот смысл урока был понятен сразу.

[Vadifon]

Точно! Надо все боксами, но тогда мы можем потерять уважаемого Vadifona.

:thumbup: от меня так просто не избавиться...

Музчины(разработчики) - ну давайте тренироваться на кошках, а имя котику пусть будет ИЛС. Заодно и над материалами со странными оптическими свойствами поизмываетесь :P

[Coyote]

Чего-то я уже не доганяю ... Так этот смысл урока был понятен сразу.

Я лишь дискутировал на тему, нужна ли на торце именно кнопки, средняя грань. А урок был понятен сразу.

[ZloySkin]

Ребята, этот труд никого ни к чему не обязывает, там во второй строчке с выравниванием по правому краю все написано. А если я пишу, что разница будет, значит она будет, так как я знаю, что она есть в условиях нашего движка, при настройках материалов для такой кнопки в фулл трехмерной кабине. Что вообще за мода пошла подвергать сомнению слова столпов?:smilewink:

 

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

Знаешь самую знаменитую фразу Константина Сергеевича Станиславского?

Ну НЕ ВЕРЮ я в это, просто НЕ ВЕРЮ. Не может энтрапия убывать. Всё что ты сделал с бедной кнопкой, это элементарно изуродовал, при этом существенно напряг руки, которые в данном конкретном случае можно легко подставить в известную русскую поговорку про дурную голову вместо ног.

Проявление в тебе атавистического мышления конца 90-х, я могу оправдать только в двух случаях:

1. Кнопок действительно несколько тысяч, но при этом они являются единым монолитом и если нажимаются то, только все вместе.

2. Кнопки не являются монолитом, но они абсолютно однинаковы во всём, включая абсолютно все атрибуты, то есть являются инстансами.

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

 

Стас, то что ты написал - ересь, причём твоей фразой о столпах, возведённая в догму. Не слишком много берёшь на себя? :)

 

Граждане, в уменьшение ФПС я не верю, всё, к чему призывает Стас своими манипуляциями с кнопкой, есть не что иное, как "бесполезное дёргание шаловливыми ручонками", основанное на атавистическом мышлении конца 90-х, то есть попросту Сизифов труд и типичный пример ещё одной поговорки: "Лучшее - враг хорошего". Запомните, в истинной вере есть только такие постулаты:

1. Один меш - одна текстура - одни атрибуты - один дрокол.

2. Если внутри дрокола количество треугольников меньше 3-5 тысяч, то их количество не имеет значения, даже если будет отличаться в разы, а не то чтобы даже на десятки процентов. Это означает, что объект, независимо от рендера (НЕЗАВИСИМО от рендера, надеюсь все понимают, что это значит и Стас тоже :)) состоящий из одного треугольника будет отрисовываться столько же времени, сколько объект с теми же атрибутами из 1000 треугольников. ФПС НЕ БУДЕТ ОТЛИЧАТЬСЯ!!! Это также верно, как и то, что энтрапия не может убывать. Почему я не написал 3-5 тысяч? Потому что атрибуты материалов бывают разными и могут не влезать в один проход рендера.

3. Перефразируя известную поговорку, напишу: Лучшее - враг хорошего, ВСЕГДА.

 

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

 

Плюс, многое зависит ещё и от того какую площадь занимают на экране треугольники и каким образом они растеризуются.

[Dronas]

Согласен во многом с злым товарищем, кроме того, что инстансинг доступен только на восьмых жифорсах (минимум на том, что тянет ДХ9 доступен, не в том конечно виде, что в ДХ10, хотя суть та же :)), про количество треугольников в DP тоже согласен, правда чем больше кнопок, тем больше экономится драгоценной памяти, а вот то. Ну и "увеличеная" кнопка требует больше времени на себя при отрисовке...

А вообще как там чё отрисовывается мы не знаем, Гриша занят и пишет неохотно :)

[Acgaen]

МЕНЯ ПОСТИГ СТРАШНЫЙ КОШМАР - я не о кнопке писал как таковой. Столп - это ирония, там даже смайлик нарисован. Очевидно, нужно было изобразить какой-либо танк и уменьшить в нем на 40-ка страницах с картинками количество полигонов на четверть. Откуда такой резонанс у этой кнопки взялся? И я уже много раз просил не растекаться по древу в областях, о которых представление очень своебразное - не вижу смысла в этих длинных постах, не вижу смысла что-то доказывать, как известно флуд это искусство, а я им, к сожалению, не обладаю.

Цитирую:

"Бесполезное пособие, могущее помочь кому-то где-то как-то убить ненужные треугольники"

[Coyote]

МЕНЯ ПОСТИГ СТРАШНЫЙ КОШМАР - я не о кнопке писал как таковой. Столп - это ирония, там даже смайлик нарисован. Очевидно, нужно было изобразить какой-либо танк и уменьшить в нем на 40-ка страницах с картинками количество полигонов на четверть. Откуда такой резонанс у этой кнопки взялся? И я уже много раз просил не растекаться по древу в областях, о которых представление очень своебразное - не вижу смысла в этих длинных постах, не вижу смысла что-то доказывать, как известно флуд это искусство, а я им, к сожалению, не обладаю.

Цитирую:

"Бесполезное пособие, могущее помочь кому-то где-то как-то убить ненужные треугольники"

Опять столкнулись два СТОЛПА!:)

[Dronas]

МЕНЯ ПОСТИГ СТРАШНЫЙ КОШМАР - я не о кнопке писал как таковой. Столп - это ирония, там даже смайлик нарисован. Очевидно, нужно было изобразить какой-либо танк и уменьшить в нем на 40-ка страницах с картинками количество полигонов на четверть. Откуда такой резонанс у этой кнопки взялся? И я уже много раз просил не растекаться по древу в областях, о которых представление очень своебразное - не вижу смысла в этих длинных постах, не вижу смысла что-то доказывать, как известно флуд это искусство, а я им, к сожалению, не обладаю.

Цитирую:

"Бесполезное пособие, могущее помочь кому-то где-то как-то убить ненужные треугольники"

 

Хм, а дело в том, что кабина в ЛО и сейчас жрёт не мало...

[Andrew Tikhonovsky]

А меня вот, как инженера-физика :), всегда смущают фразы о том, что "количество чего-то" не влияеет на "что-то", если основной характеристикой "что-то" является именно обработка "количества чего-то", причем этот параметр конечен в абсолютном значении. :) О как загнул!

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

То есть, если есть толстая труба, и в нее всунуть трубу по-меньше, то вроде как большая труба и не заметит маленькую трубу, и вода будет течь замечательно, но вот если в большую трубу всунуть 1000 маленьких, 1001 может места и нехватить.

[Dmut]

поясню мысль уважаемого Стаса - смысл не в том что вообще не нужно оптимизировать треугольники, а в том, нужно правильно распределять собственные ресурсы (человеко-часы) на оптимизацию. дизайнеры, как и программисты, без дела не сидят и им очень важно правильно разделить своё время - бессмысленно тратить день оптимизации там где получится выигрыш 1 fps, если можно в другом месте за день работы выиграть 5fps. нужно все модели доводить до некого среднего результата по параметру "необходимое время \ получаемый прирост". в данном примере Стас показал как без больших потерь времени можно стандартными приёмами съэкономить полигоны.

[Dronas]

А меня вот, как инженера-физика :), всегда смущают фразы о том, что "количество чего-то" не влияеет на "что-то", если основной характеристикой "что-то" является именно обработка "количества чего-то", причем этот параметр конечен в абсолютном значении. :) О как загнул!

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

То есть, если есть толстая труба, и в нее всунуть трубу по-меньше, то вроде как большая труба и не заметит маленькую трубу, и вода будет течь замечательно, но вот если в большую трубу всунуть 1000 маленьких, 1001 может места и нехватить.

 

Современные видюхи довольно шестро работают с поликами, в результате чего иногда отрисовать 1 треугольник или скажем 500 по скорости одинаково :)

[Dronas]

поясню мысль уважаемого Стаса - смысл не в том что вообще не нужно оптимизировать треугольники, а в том, нужно правильно распределять собственные ресурсы (человеко-часы) на оптимизацию. дизайнеры, как и программисты, без дела не сидят и им очень важно правильно разделить своё время - бессмысленно тратить день оптимизации там где получится выигрыш 1 fps, если можно в другом месте за день работы выиграть 5fps. нужно все модели доводить до некого среднего результата по параметру "необходимое время \ получаемый прирост". в данном примере Стас показал как без больших потерь времени можно стандартными приёмами съэкономить полигоны.

 

Так, отличненько, т.е. ищем что, где и сколько жрёт и начинаем борьбу с максимально жрущего? С водой-то чего? В акуле всё так же останется?

[grisha]

Весело у вас тут

 

Отписал один пост в эту ветку - теперь обновления приходят :)

 

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

 

При работе симулятора идут несколько условно параллельных процессов: моделирование игрового мира, подготовка кадра и отправка на отрисовку, обработка полигонов на GPU, потом обработка пикселов на GPU.

 

Производительность симулятора в целом ограничивается самым узким звеном в этом конвейере. Если моделирование систем вертолета выдает 2fps, то что у него 3D модель будет из двух полигонов что из двухсот тысяч - все равно будет 2fps. Наша задача загрузить все этапы конвейера максимально равномерно, чтобы ни один не простаивал и не ждал остальных.

 

Полноценно это можно протестировать только летая реальные миссии на симуляторе с разной детализацией моделей и текстур. Альтернативный метод - чувства пятой точки разработчиков (например меня лично), которые и являются источником текущих бюджетов на модели и текстуры.

 

Таким образом до тех пор пока количество полигонов не становится узким местом, наращивание их количества вообще никак не сказывается на fps. Но как только общее количество в кадре переваливает некий рубеж - именно они и становятся узким местом. Поэтому желательно вкладываться близко к бюджету: делать сильно меньше полигонов не прибавит ощутимой производительности, но даже незначительное превышение может стоить fps. Причем стоить fps оно будет не в ModelViewer, а в реальном полете когда вокруг полно других сложных моделей со своими заморочками.

 

Теперь о кнопках. Важность кокпита в том что он (как и свой вертолет) всегда в кадре, с ним не отмажешься близким переключением лодов или тем что объект встречается редко. Поэтому превышение бюджетов полигонов/текстур/элементов на нем особенно неприятно.

 

Получилось длинно, но надеюсь по делу. С уважением,

Гриша

 

Edit: инстансинг движком не поддерживается, что одинаковые кнопки что разные нам по барабану. Имеют значение полное количество элементов (объекты в 3D Max), полное количество полигонов и полный объем текстур.

[USSR_Gys71]

Интересно. С полигонами и текстурами понятно. А какие ограничения на количество объектов в модели существуют на данный момент?

[grisha]

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

[sv-rus]

С водой все будет как в Локоне, не меняли. Как и подавляющее большинство остальных эффектов.

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

[Dronas]

По просьбам трудящихся

часть 1:

 

Привет!

А всё равно не ясно, насколько реально будут тормозить работу кнопочки, как организована их отрисовка и прочее, ведь как мало не занимала бы кнопочка, при количестве этих кнопочек в 100 штук и их отрисовке отдельным ДИПом теряется куча времени.

 

Не могу дать ответ конкретно по кнопочкам. Если, к примеру, вся остальная панель в кокпите будет из одного треугольника то 100 кнопочек * 100 полигонов = 10К полигонов, что укладывается в бюджет. Но в нашем кокпите много других элементов добавляющих полигоны.

 

Я доверяю дизайнерам выбирать более и менее важные участки внутри моделей. По мне - так кубика было бы вполне достаточно, но я знаю людей которые будут под лупой рассматривать этот кокпит и тащиться от его проработки. Для меня, как для человека отвечающего за графику, важно чтобы модели вкладывались в свои бюджеты. Как распорядиться треугольниками в пределах бюджета чтобы получить картинку получше - дело дизайнера.

 

Эх, я не об этом немного. Что отрисуется быстрее 100 кнопок по 100 треугольников за раз или 100 кнопок по 50 треугольников поотдельности? :(

 

К стати правда, поделись инфой, как организовывается в ЛО отрисовка кабины? Имеет ли каждый объект свой вершинный буфер или всё хранится вместе, касательно акулы - прорисовывается ли каждый тумблер, кнопка, крутилка, отдельно?

 

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

 

Вертексные/индексные буферы отводятся динамически, и заранее сказать во сколько буферов попадет кабина при загрузке в движок невозможно, да и не важно. Как я уже говорил: важно количество вызовов отрисовки которое пропорционально количеству элементов (этот оверхед приходится на второй этап конвейера), общее количество полигонов (третий этап) и размер текстур (четвертый этап).

 

Учитывая отсутствие инстансинга невозможно отрисовать 100 кнопок за раз, т.к. они все анимируются поотдельности. Поэтому так вопрос вообще не стоит. Все кнопки являются отдельными элементами и уходят на отрисовку по отдельности, соптимизировать это не отказываясь от их анимации в текущем движке невозможно.

 

По полигонам: опять же важно их общее количество. Например если у нас есть 100 кнопок и больше ничего то скорее всего неважно будут они состоять из 2 полигонов или из 100 т.к. узкое место придется на сбор элементов. Но если к ним прибавить еще панель (1 элемент) состоящую из 10000 полигонов, то разница может появиться т.к. суммарное количество полигонов может передвинуть узкое место на вершинный шейдер.

 

Я понимаю что это немного сложно, возможно презентации вроде ftp://download.nvidia.com/developer/...sh_GPUPerf.pdf будут интересны если уж хочется понять процесс досконально.

 

Была инфа, что движок переехал с DX8 на DX9, а там вроде хардварный инстансинг доступен, да у кнопок разные текстурные координаты, но ведь тоже наверное решаемо.

 

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

 

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

 

Делать два состояния или выставлять трансформацию по производительности не важно.

 

Не согласен! В первом случае кнопки перемещаются из одного "списка отображения" в другой при изменении состояния кнопки, во втором каждый кадр, для каждой кнопки выставляются свои матрицы.

 

А вот память у нас конечно жрётся, но опять же можно делать не дубли кнопок в разных положениях а физически пересчитывать вершины изменяемой кнопки и переписывать их в буфере нахождения кнопки, причём отрисовку вызывать надо будет только по количеству тукстур :)

 

Так, сорри, но в дискуссию на эту тему втягиваться не хочу. Моя задача на этом форуме - прояснить как работает движок. Для пожеланий по поводу того как он должен работать есть соответствующая ветка.

 

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

 

часть 2 (как-то распараллелилось):

Пусть есть гипотетическая система со следующей производительностью:

1 элемент уходит на отрисовку за 0.01ms (CPU)

1 полигон отрисовывается за 0.0001ms (GPU)

 

Пусть есть 100 кнопочек по 2 полигона:

CPU: 100 * 0.01ms = 1ms

GPU: 100 * 2 * 0.0001 = 0.02ms

Полное время кадра: 1ms (98% времени видеокарта будет простаивать)

 

Пусть есть 100 кнопочек по 100 полигонов:

CPU: 100 * 0.01ms = 1ms

GPU: 100 * 100 * 0.0001 = 1ms

Полное время кадра: 1ms (процессор и видеокарта полностью загружены)

 

Пусть теперь есть 100 кнопочек по 2 полигона, плюс панель на 10000 полигонов:

CPU: (100 + 1) * 0.01ms = 1.01ms

GPU: (100 * 2 + 10000) * 0.0001 = 1.02ms

Полное время кадра: 1.02ms (процессор и видеокарта полностью загружены)

 

Наконец пусть есть 100 кнопочек по 100 полигонов, плюс панель на 10000 полигонов:

CPU: (100 + 1) * 0.01ms = 1.01ms

GPU: (100 * 100 + 10000) * 0.0001 = 2ms

Полное время кадра: 2ms (50% времени процессор простаивает)

 

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

 

Поэтому невозможно рассматривать кнопочки в отрыве от всей остальной сцены. Имеет значение баланс полного количества элементов/полигонов/текстур обрабатываемый в течение кадра.

 

Только вот я не говорю, что надо рисовать кнопки по 1000 треугольников, я говорю о том, что все кнопки в кабине можно отрисовать по формуле:

 

roundUp(TriCount / MaxTriCount) * TexCount * 2

 

где:

TriCount - количество примитивов в отрисовываемых кнопках;

MaxTriCount - максимальное количество примитивов за ДИП;

TexCount - количество текстур;

2 - возможные положения кнопок;

 

отсечения же невидимых панелей наверное в DCS нет.

 

Во-первых, что такое ДИП? Во вторых я не понимаю что значит "отрисовать кнопки по формуле". Отсечение конечно есть, я говорю о полигонах в кадре.

 

ДИП - DrawIndexedPrimitive или DIP

отрисовать кнопки по формуле - количество вызовов DIP(ДИП) :cry:

 

Кажется я понял что имеется ввиду... Надеюсь что понял. Предлагается отрисовать много кнопок одним вызовом. Как я уже сказал в ЧА это невозможно, т.к. кнопки имеют индивидуальную анимацию задаваемую моделированием. Неподвижные кнопки конечно можно объединять в один элемент.

 

К примеру, имеем 4 кнопки. Каждая может быть нажата/отжата. Как один объект они имеют 2^4 = 16 возможных состояний, и это число будет удваиваться с каждой добавляемой в этот объект кнопкой.

 

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

 

Т.ч. на кнопках можно сильно не экономить, да и мелкие детали на самолётах лучше уж геометрией чем текстурой :)

[Acgaen]

Хорошо, что кнопка породила такую полезную ветку, душа греется.

[Andrew Tikhonovsky]

Я так понял, что скоро мы будем моделировать объект во всех возможных его "измененных" состояниях, и при отрисовке каждого кадра будет подставляться соответствующая модель (только вот интересно сколько памяти нужно будет, чтобы все это хранить?). :)

[ZloySkin]

Современные видюхи довольно шестро работают с поликами, в результате чего иногда отрисовать 1 треугольник или скажем 500 по скорости одинаково :)

 

В предыдущем посте я всколзь упомянул об одном из важнейших условий, но развивать тему не стал, хотя надо было. Речь шла о площадях и методах растеризации треугольников. Тут Гриша уже упоминал о том, что отрисовка внутренней части кабины есть величина константная, поскольку она не удаляется и не приближается настолько, чтобы количество треугольников передаваемых на рендер существенно изменялось. При этом он забыл упомянуть о том, что один треугольник, занимающий на экране площадь в 3 пиксела и другой, занимающий полэкрана будут отрисовываться разное количество времени. И в связи с этим объект в 1000 треугольников, может совершенно свободно рисоваться быстрее объекта, состоящего из всего одного треугольника.

В своём спиче, Гриша имел в виду СУММАРНОЕ количество треугольников в кадре. Когда оно перешкаливает за некоторое количество, то видеокарточке становится плохо.

То, о чём говорил я можно сравнить с сельским толчком.

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

Так вот суть гришиной речи сводилась к тому, что НЕ НАДО МНОГО КАКАТЬ!

А суть моей речи сводилась к тому, что на ОДНО ОЧКО НЕЛЬЗЯ СЕСТЬ ВДВОЁМ!

По другому мне не объяснить, надеюсь вы уловили суть.

[Andrew Tikhonovsky]

А у меня элегантнее сравнение было! ;)

[SuperVasia]

Я так понял, что скоро мы будем моделировать объект во всех возможных его "измененных" состояниях, и при отрисовке каждого кадра будет подставляться соответствующая модель (только вот интересно сколько памяти нужно будет, чтобы все это хранить?). :)

Подобный опыт уже был (десантники анимировались именно моделью под кажый кадр)

особых проблем не вызвало кроме работы по получению модели на каждый кадр