RailUnion.net

AlexanderG писал(а):Я думаю, имелось в виду совсем иное — появившаяся в каком-то из новых ТРС возможность хранить текстуры и меши в другом ассете и ссылаться на них из самого сценери-объекта.

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

CFM писал(а):Вот было бы хорошо поподробнее о такой технологии узнать.

Это очень просто. Создается дополнение под отдельным куидом, куда сваливаются все меши со своими текстурами, которые мы хотим поместить в библиотеку. Это дополнение имеет kind "mesh". Меш-тейбл в нем можно не делать - он в данном случае не обязателен.
Теперь возьмем объект, в котором нужно вызвать меш из библиотеки. Вглядит это так:

Код: Выделить всё

mesh-table {
    default {                  //название меша
       mesh-asset           <kuid:xxxxx:yyyyy>            //куид библиотеки мешей
       mesh                    "xxxxxx.im"                       //имя необходимого файла в библиотеке
       auto-create           1
     }
}


Офф:
Ничего себе... А я думал, что в kind "mesh" можно хранить одну меш...

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

Вот только не помню - можно ли там LM-файлы хранить.

Посмотрел знаки нейтральной вставки. Здорово придумано. Теперь осталось выяснить, можно ли там использовать LM файлы.

Тут 2 варианта:

а) делаешь библиотеки кронштейнов и подвесов (использующих одну и ту же текстуру), делаешь библиотеку столбов (также для каждой текстуры свою), и делаешь мешь из одного треугольника (с полностью прозрачной текстурой) с 4мя точками привязки (по одной на крепление мешей подвеса и столба + 2 точки под крепление провода ).

т.е. что-то такое

mesh-table {
default {
mesh "tochki_privazki.im"
auto-create 1
effects
{
эффекты креплений проводов тут

}
}

podves { //мешь подвеса
mesh-asset <kuid:xxxxx:yyyyy> //куид библиотеки мешей
mesh "xxxxxx.im" //имя необходимого файла в библиотеке
auto-create 1
att-parent default
att a.podves
}
stolb { //название меша
mesh-asset <kuid:xxxxx:zzzz> //куид библиотеки мешей
mesh "yyyy.im" //имя необходимого файла в библиотеке
auto-create 1
att-parent default
att a.stolb
}
}


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

б) - сделать ссылки из той библиотеки, т.е. когда набор опор использует одну и ту же текстуру, то можно меши всех лодов и lm-файлы скинуть в такую бибилотеку, а в куидах опор делать "пустышки" - т.е. просто ссылки на lm-файлы библиотеки. Именно то, что ты имеешь в виду словами

Теперь осталось выяснить, можно ли там использовать LM файлы.

В обоих случаях мы получаем экономию видеопамяти (надо грузить только одну текстуру на всю группу опор). А вот выбрать что лучше - копирование обработанных мешей во время визуализации или ЛОДы - честно не знаю... В первом случае мы также получаем возможность делать "конструктор". (но для картостроителя оба варианта при расстановке ничем отличаться не будут - на каждый тип опор нужен отдельный куид)

TRam_ писал(а):Тут 2 варианта:
(т.к. идея заключается в копировании одной и той же меши, поэтому на менее загруженных местах будет использоваться только LOD0 по всей карте, на более загруженных - только LOD1, и т.п.).

То есть это значит, что, скажем, в лучшем случае будет ЛОД0, а в худшем, скажем, ЛОД4, и зависеть это будет не от расстояния до модели, а от количества моделей в поле видимости? И если у меня перед камерой будет станция с парой сотен видимых опор, то я буду на любом расстоянии от камеры видеть ЛОД4?

На счет второго метода. Я понял, что тут тоже можно делать "конструктор", ссылаясь на несколько lm-файлов в одном контейнере mesh-table?

и зависеть это будет не от расстояния до модели, а от количества моделей в поле видимости? И если у меня перед камерой будет станция с парой сотен видимых опор, то я буду на любом расстоянии от камеры видеть ЛОД4?

скорее не только опор,а от общего fps . Т.е. в густом 8битном лесу будет ЛОД4, на поле - ЛОД0. По крайней мере я это так понимаю.

Я понял, что тут тоже можно делать "конструктор", ссылаясь на несколько lm-файлов в одном контейнере mesh-table?

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

TRam_ писал(а):

и зависеть это будет не от расстояния до модели, а от количества моделей в поле видимости? И если у меня перед камерой будет станция с парой сотен видимых опор, то я буду на любом расстоянии от камеры видеть ЛОД4?

скорее не только опор,а от общего fps . Т.е. в густом 8битном лесу будет ЛОД4, на поле - ЛОД0. По крайней мере я это так понимаю.

Я понял, что тут тоже можно делать "конструктор", ссылаясь на несколько lm-файлов в одном контейнере mesh-table?

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

Но если на при низком ФПС, а на станциях он низкий как правило, будет ЛОД4 - то несколько теряется смысл. Неприятно же видеть треугольные изоляторы и тд.

И еще хотелось бы поточнее про преимущества второго метода. Если там модели так же находятся в библиотеке, а ассеты только на них ссылаются, значит ЛОДы должны вести себя так же, как и в первом методе со ститчед-мешами?

Я просто что-то не очень теперь понимаю механику второго метода. В первом случае, я понимаю, происходит примерно следующее: делается обходит config'ов, составляется массив ссылок attachment'ов на "пришиваемые" модели, потом эти модели передаются на видеокарту, рассчитываются и хранятся в ОЗУ видюхи в единственном экземпляре, а далее просто копируется куда нужно, то есть экономится время для расчетов на ГПУ. А во втором что? Там же не сшиваются уже рассчитанные меши, а стоит ссылка на мешь из библиотеки, то есть в оперативу видюхи всё равно будет передано столько копий модели, сколько ассетов её используют.

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

На меши второй метод вроде не должен никак влиять.

Возможно, первый метод позволит или отказаться от ЛОДов или хотя бы уменьшить их число? Ведь копирование - куда меньшая по затратам процедура чем рассчет меши.

Второй метод, по идее, должен дать существенный выигрыш, так как у меня почти все объекты КС использует 2 основные текстуры. А можно в библиотеке хранить только текстуры?

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

Посмотри библиотеку стрелочных приводов отсюда http://www.relsomania.ucoz.ru/load/stre ... /16-1-0-92

Там показано, как прописывать в texture.txt файлах где лежат текстуры

В общем, область для экспериментов указали, дальше уже начинается неисследованная область сравнения безЛОДовых и ЛОДовых объектов...

На счет второго метода ясно.

А вот на счет того, что "чем меньше lm-файлов визуализируется, тем лучше". В каком смысле? trainz тратит много ресурсов на их обработку? Или обработка происходит со сбоями при большом их количестве? Тогда может быть можно использовать первый метод без ЛОДов или делать меньше ЛОДов и делать их через конфиг? В принципе AC3V4 работает без ЛОДов на приемлемом уровне производительности, возможно использование ститчед-мешей без ЛОДов позволит поднять её производительность существенно? При этом полигональность объектов AC3 варьируется от 300 до 1800 полигонов

Имел в виду чем меньше одновременно показываемых мешей, тем лучше. Вне зависимости от того, lm или напрямую im. Дело в необходимости создавать буффер вершин, буффер материалов и т.п. (иначе говоря "лес" деревьев единой мешью обработать проще, чем лес из отдельных мешей деревьев)

возможно использование ститчед-мешей без ЛОДов позволит поднять её производительность существенно?

попробуй. Я честно не видел отзывов "тут одно работает быстрее, а другое - медленее". Учитывая что трс 2010 отвечает на загруженность скорее не снижением fps, а снижением дальности прорисовки.

TRam_ писал(а):Имел в виду чем меньше одновременно показываемых мешей, тем лучше. Вне зависимости от того, lm или напрямую im. Дело в необходимости создавать буффер вершин, буффер материалов и т.п. (иначе говоря "лес" деревьев единой мешью обработать проще, чем лес из отдельных мешей деревьев)

возможно использование ститчед-мешей без ЛОДов позволит поднять её производительность существенно?

попробуй. Я честно не видел отзывов "тут одно работает быстрее, а другое - медленее". Учитывая что трс 2010 отвечает на загруженность скорее не снижением fps, а снижением дальности прорисовки.

Да, я пожалуй, поэкспериментирую с неLODированными объектами по первому методу. Очень подкупает возможность "сшивать" опоры из отдельных консолей, стоек и прочих поддерживающих конструкций уже в ТРС. Опять же, возможно, использование ститчед-мешей даст выигрыш в производительности и без использования ЛОДов. Всё же у меня объекты с не очень большим количеством полигонов (подвес под поперечину занимает около 300-500 полигонов, промежуточная опора занимает около 800 полигонов, переходная - до 1800, больше 2000 полигонов только тяговая подстанция).

Итак. Выбор ЛОД от ФПС не зависит, только от его фактического размера на дисплее. MeshStitching ЛОДы учитывает.