URSS_Sochi-2014, с миру по нитке.

[greben 86]

Можно поподробнее про сглаживание. Если сделать сферу без сглаживания , несмотря на увеличение вершин, она будет для машины меньше весить??? Моя не понимать-вроде учили обратному.

Для начала разберемся с самим сглаживанием.

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

обрабатываться графическим процессором в два приема - от самого светлого, до самого темного и обратно - до 

самого светлого.

В определенный момент градиент может достичь максимума, от нуля до 255.

Если мы разделим 256 на 4, получим 64, то-есть, на каждом полигоне процессору видеокарты

придется делать 64 виртуальных полигона.

 

Тут уж нужно выбирать "золотую середину", либо грузить основной проц, делая цилиндр из множества

полигонов, либо нагрузить видеокарту выполнением этой задачи.

 

В последнее время у нас такое железо, что и то и другое прожует и не подавиться, но во всем

нужно знать меру

[ANRI 854]

В определенный момент градиент может достичь максимума, от нуля до 255.

 

Тут уж нужно выбирать "золотую середину",..

Справедливо в "классическом случае", когда полигон "занимает" на экране более 256 пикселей.

Если на экране он "мелкий", всего единицы пикселей, то градиент маленький.

Выбор "золотой середины" основывается на сценарной картинке и экранным размером сглаженного/несглаженного полигона.

[icebear 604]

При сглаживании все полигоны в сумме будут

обрабатываться графическим процессором в два приема - от самого светлого, до самого темного и обратно - до 

самого светлого.

 

О каких двух проходах речь? И ещё, известно, какой способ заливки/затенения используется в симе?

[greben 86]

Справедливо в "классическом случае", когда полигон "занимает" на экране более 256 пикселей.

Если на экране он "мелкий", всего единицы пикселей, то градиент маленький.

Выбор "золотой середины" основывается на сценарной картинке и экранным размером сглаженного/несглаженного полигона.

Согласен

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

но потребляются. Сам тот факт, что на крышах модели старого терминала оно (сглаживание) присутствует,

говорит о том, что мы не ведаем самых элементарных вещей, от которых один вред, иногда его масштабы

достигают запредельного маразма

[kit862008 0]

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

terminal_URSS.zip

[greben 86]

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

А почему же сглаживание на крышах осталось??? Да и на башне ее, по моему, тоже не должно быть.

[kit862008 0]

А почему же сглаживание на крышах осталось??? Да и на башне ее, по моему, тоже не должно быть.

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

[greben 86]

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

Извиняюсь, но я не нашел ни одной детали без сглаживания в этом творении

Забросил два скрина:

1 - Ваш исходник.

2 - После моей ревизии.

 

Извиняюсь,  но есть в моделировании банальные правила, которые нужно соблюдать,

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

Это примерно, как сесть за стол и начать кушать, не имея приборов

 

Г-Макс изначально (по-умолчанию) всю геометрию (детали - боксы, сферы, цилиндры) делает

сглаженными. Есть правило - поставил детальку, сразу же нужно выделить на ней все полигоны

и прибить на них сглаживание, за тем нужно прибить все ненужные полигоны, которые у нас

будут невидимы в процессе пользования в симе, так-называемые - "донышки" и прочие скрытые

полигоны.

[tangeregvip 1948]

Раз пошел разговор об оптимизации , то будьте столь любезны -обьясните ,чем вызвано размещение обьектов в сцене (вроде приводов с двух сторон) под один рефпойнт с большим расстоянием между обьектами. Как следствие в таких сценах лодирование отсутствует.Неужели лучше собрать под один рефпойнт чем разбить на зоны и пролодировать.И хотелось бы уточнить (в попугаях)))тяжесть рефпойнта , текстурного листа(1024), в тект.вершинах- т.е. некое уравнение для того чтобы представлять где использовать (к примеру) , еще один лист или усложнить модель.А то вроде как уменьшают количество рефпойнтов , несмотря на то что вся тяжесть количества вершин постоянно присутствует-хотя многие обьекты вообще могут быть не видны.Надеюсь внятно задал вопрос.)

[greben 86]

Вопрос более чем понятен, спасибо!

Начнем с лодирования.

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

,ой, как ФПС-ы любит

Иногда от лодирования вреда бывает больше, чем пользы. Моя практика показала, что оно имело

смысл только в мсфс-2000 и мсфс-2002, там, где всё было создано на основе СКАЗМ-а, в 9-ке, а уж

тем более в 10-ке я от него напрочь отказался. Но это мои личные убеждения и не есть утверждение

к действиям

 

Рефпоинт...

Это не просто какая-то точка, от которой пляшет "отрисовщик" геометрии 3Д-модельки, это в сотни

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

У рефпоинта не один десяток задач и, по моему, если не ошибаюсь, что-то в районе 160 свойств,

которые движок сима крутит в своей голове с разной периодичностью по времени, они называются

ПЕРЕМЕННЫЕ - время, время суток, положение солнца, расстояние до пилота, времена года, погода,

ну и так далее...

 

Теперь только жестокие факты, от которых я сам был в шоке:

Сцена имела более 6000 объектов разной сложности, собраны они были в несколько групп, что-то

в районе 25-30 групп, ФПС было всего 15.

После того, как я собрал эти же объекты в ОДУ модель с одним рефпоинтом, то получил аж 118 ФПС-ов.

 

Думаю, дальше говорить не стоит

 

ПРЕДУПРЕЖДАЮ!

Не нужно бежать сломя голову и лепить всё в одну кучу, ибо у каждого объекта должны быть свои

свойства, к примеру: здания могут быть простыми, без смены сезонов, а вот деревья должны это

всё иметь, значит их нужно разбить на две группы - сезонные и примитивные, так-же и с кастомными

огнями - они должны гореть ночью и не гореть днем, должны иметь возможность включения по 

запросу пилота, ну и т.д....

 

УДАЧИ!!!

[tangeregvip 1948]

В сцене Дубай присутствует лодирование почти на все мелкие группы обектов-видимо не все так однозначно. Хотелось бы услышать мнение "начальника транспортного цеха" (ANRI) по данному вопросу))).

[kit862008 0]

Извиняюсь, но я не нашел ни одной детали без сглаживания в этом творении

Забросил два скрина:

1 - Ваш исходник.

2 - После моей ревизии.

 

Извиняюсь,  но есть в моделировании банальные правила, которые нужно соблюдать,

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

Это примерно, как сесть за стол и начать кушать, не имея приборов

 

Г-Макс изначально (по-умолчанию) всю геометрию (детали - боксы, сферы, цилиндры) делает

сглаженными. Есть правило - поставил детальку, сразу же нужно выделить на ней все полигоны

и прибить на них сглаживание, за тем нужно прибить все ненужные полигоны, которые у нас

будут невидимы в процессе пользования в симе, так-называемые - "донышки" и прочие скрытые

полигоны.

Я не волшебник.. я только учусь))) А про донышки и лишние полигоны я в курсе... Если обратили внимание таковых и нет в исходнике. 

[ANRI 854]

Хотелось бы услышать мнение "начальника транспортного цеха" (ANRI) по данному вопросу))).

http://www.avsim.su/forum/topic/116371-вопросы-к-anri/?p=2392168

[tangeregvip 1948]

Спасибо за ответ.

[tangeregvip 1948]

Переделал здание из сценария-жду критики)).

SOCHI.zip

[tangeregvip 1948]

Забыл OMI-тоже жду разборов.)

omi1.zip

[Jazz 223]

Раз пошел разговор об оптимизации , то будьте столь любезны -обьясните ,чем вызвано размещение обьектов в сцене (вроде приводов с двух сторон) под один рефпойнт с большим расстоянием между обьектами. Как следствие в таких сценах лодирование отсутствует.Неужели лучше собрать под один рефпойнт чем разбить на зоны и пролодировать.И хотелось бы уточнить (в попугаях)))тяжесть рефпойнта , текстурного листа(1024), в тект.вершинах- т.е. некое уравнение для того чтобы представлять где использовать (к примеру) , еще один лист или усложнить модель.А то вроде как уменьшают количество рефпойнтов , несмотря на то что вся тяжесть количества вершин постоянно присутствует-хотя многие обьекты вообще могут быть не видны.Надеюсь внятно задал вопрос.)

Сам по себе рефпоинт (бррр... как указание scale-superscale) это вроде как всего лишь две функи преобразований - перенос и масштаб, т.е. сложение и умножение. Сколько там тактов надо - 4? 6? Кошмары начинаются тогда, когда необходимо менять состояние графического каскада - в этом случае дровам и железу надо установить огромную кучу всяких настроек и значений регистров. Состояние каскада, как нам известно, меняется только в тот момент, когда мы отправляем указание на отрисовку загруженной в буфер геометрии и только при условии, что изменение состояния каскада необходимо (т.е. мы указали какие-то новые параметры каскада - например новые свойства материала). Таким образом, если указание на отрисовку без изменения состояния "весит" 900 попугаев, то с изменением уже 900000 пернатых друзей. Цифры центрально-процессорные ))) примерные, но близкие к правде. Т.е. получается, что модель с одним "рефпоинтом" и двумя используемыми текстурами будет "стоить" в 500 раз дороже, чем аналогичная по геометрии модель с одной текстурой, но двумя "рефпоинтами". Но если мне не изменяет память, то преобразования возможны и в самом вершинном буфере, а значит вторая модель может быть и в 1000 раз легче. Именно поэтому количество этих самых "рефпоинтов" (опять брр брр) ну никак не может является прямым показателем тяжести модели. 

 

Вопрос же о тяжести геометрии... как вы понимаете, это сильно зависит от железа, скорости и размеров памяти, шин и т.д. Т.е. насколько шустро каскад может переправить содержимое вершинного буфера в железку и как шустро сама железяка способна "заливать пиксели" вне области проекции. Но в любом случае, количество вершин станет определяющим фактором только в том случае, если время, затраченное на их "доставку" превысит время для 900 * 2 тактов ЦПУ.

 

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

 

PS: хыыы хороший реферат получился )))))

[icebear 604]

Насколько известно, MSFS не использует возможности граф. ускорителей и т.п., откуда тогда выкладки про вершинные буферы и т.п.? И ещё, откуда известна организация графического движка сима (в смысле построения иерархии объектов, способ отрисовки, последовательность и т.д.)? Мне просто интересно.

[Jazz 223]

Ну как же... по родным майкрософтовским АПИ именуемыми DirectX сколько всякой документации от статеек до сдк за 20 лет написано и прочитано было, будет логично предположить, что создатели АПИ при его использовании будут следовать своим же рекомендациям и примерам по организации программной части графического каскада. Да и в сдк-98 к симу ну очень много информации о работе его интерпретатора.

 

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

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

 

UPD: про выкладки с буфером вершин тоже не понял вопрос, я приводил тайминги CPU при выполнении указания D3D на отрисовку (ака draw call -  DrawIndexedPrimitive() типа). Т.е. это общее время в шагах процессора, затрачиваемое с момента передачи указания через АПИ и до момента возврата результата от АПИ.

[icebear 604]

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

[Jazz 223]

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

 

 

По поводу ЦПУ vs ГПУ vs FS vs DX. Вот смотрите, я немного упрощу: имели мы когда-то году так в 1998 интерфейсы ДХ6 и железо с дровами, для работы с которыми ДХ6 использовал определенный набор доступных на тот момент функций и операций. Элементарщина вроде передачи буфера в виде куска данных из ОЗУ компа далее по конвейеру и всякие команды по настройке каскадов. Куда и как там эти данные шли, через какую шину - уже не так важно. Важно то, что кроме определенного набора операций по установке состояния каскада, заливке, расчета освещенности и тд для работы с железом ничего более не существовало. Допустим, это были карты семейства 3dfx типа вуду2. На следующий год выпускается новоая линейка видеокарт вуду3, с более широкой шиной и большим объемом памяти для рисования на борту, соответственно новыми функами и операциями. Но дх6-то о них не в курсе и софт тоже не в курсе. Поэтому мс выпускает дх7 с новым интерфейсом и новыми функциями, допустим, переключение контекста уже не нужно или появилась возможность хранить данные буферов в памяти карты. Вроде все круто, но софт-то до сих пор пользуется интерфейсом дх6, а следовательно все эти нововведения не будут задействованы и выигрыш в производительности если и будет, то только за счет увеличения пропускной способности шин, размера оперативки, увеличения частоты ЦПУ и какой-то оптимизации алгоритмов работы каскадов конвейера на уровне дров. Т.о. в нашем случае, если мы говорим о фс9 и дх9, то какое бы новое железо не выпускалось и сколько бы не был крут дх12 со всеми своими суперскоростными и суперкрасивыми шейдерными операциями, фс9 так и будет работать через интерфейс дх9, пользуясь все теми же стандартами, функами, операциями, которые были придуманы и реализованы в 2002г или в каком там дх9 вышел. Если, к примеру, фс9 через дх9 организовывал вершинный буфер (чиорд! опять он!) в оперативке, то он так и будет там его организовывать, независимо ни от чего. 

 

Теперь пару слов о симе и его требовательности к процу. У меня не такой большой опыт написания платформ для отображения окружающего мира, но я вам могу сказать, что до того, как собрать и отправить на отрисовку содержание буфера 3д сцены требуется огромное количество арифметических и логических операций - от чтения данных из файлов, загрузок, выборок, индексирований, фильтраций, сортировок до создания объектов AI и их операций. Прибавьте сюда обсчет флайт-модели, математику и графику приборов и систем самолета и получим очень громоздкое и требовательное к скорости ЦПУ чудище. Т.е. имеем две составляющие плюс работа конвейера - три. Вот и выходит, что сколько бы мы не ускоряли графический конвейер, рано или поздно мы упремся в то, что ЦПУ просто ниасилит дальше ускорять две другие части комплекса и все это хозяйство застрянет на 30фпс. Как вариант )))) 

[icebear 604]

Jazz, спасибо. Я как-то упустил смену интерфейсов от версии к версии, так что мог бы и сам на свой вопрос ответить. А что, в железках старые интерфейсы на аппаратном уровне не поддерживают?

[Jazz 223]

Да без проблем )))

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

[icebear 604]

Не, я имел в виду другое (потому что здесь я абсолютно не в теме): выпускают допустим карту, пишут на ней full dx9 support или там как-то ещё. Это означает, что она "умеет" DX9 от А до Я, или все предыдущие версии тоже (хотя бы в рамках тех возможностей, которые были в предыдущих моделях карты, но соотвественно с оптимизацией в данном случае на современное железо). Эту тему уже надо бы выселить хотя-бы в "панели", с Сочи тут уже вообще ничего общего нету

[tangeregvip 1948]

Так-Мнения разделились-конценсунс не найден по поводу рефпойнта.))Разговор родился в теме потому , что нет жалоб на торможение даже на слабом железе.А обьекты здесь расставлены по разному-поэтому хочется понять в чем отгадка.