Маяк (Low Poly)
- Автор темы Black Helix
- Дата создания
Почему сразу забыть, надо не забыть, а принять к сведению)))
1)Совершенно согласен со всем написанным, я этого и не отрицал. И, все таки, понятие "ооочень большой поликаунт" есть, только для каждого движка свой...
2)Nvidia был приведен в пример, есть много всего. Есть игры, где плавный угол на стыке досок показывать совершенно не нужно, там и этот плагин хорошо подходит. На сложных объектах выглядит нормально, проверенно и не только мной.
3)Мы, как-то тут подсчитывали сколько пикселей надо оставлять, для того, чтобы объекты при уменьшении текстуры в 4 раза, не заходили друг на друга на маппинге, проверяли, косяков не нашли (5 пикселей подходят). А уменьшать текстуру более,чем в 4 раза, ну не знаю, мне кажется, не рационально.
4)Ну здесь, тоже, все зависит от предъявляемых требований, я привел пример, у меня требования такие, поэтому так и написал. Представь, что помимо маяка, в сцене, где поддерживается до ляма поликов, присутсвуют объекты, которые съедают большинство ресурсов, тут и триугольные перила смотрятся норм. 90-е здесь не причем, сейчас такие требования встречаются в популярных играх.
Я пишу только о том, с чем сталкивался, поэтому колкая фраза: "Тут господин Скиф, как мне кажется, даже не понимает о чем пишет" не катит.
У каждого свой подход и свои требования...
1)Совершенно согласен со всем написанным, я этого и не отрицал. И, все таки, понятие "ооочень большой поликаунт" есть, только для каждого движка свой...
2)Nvidia был приведен в пример, есть много всего. Есть игры, где плавный угол на стыке досок показывать совершенно не нужно, там и этот плагин хорошо подходит. На сложных объектах выглядит нормально, проверенно и не только мной.
3)Мы, как-то тут подсчитывали сколько пикселей надо оставлять, для того, чтобы объекты при уменьшении текстуры в 4 раза, не заходили друг на друга на маппинге, проверяли, косяков не нашли (5 пикселей подходят). А уменьшать текстуру более,чем в 4 раза, ну не знаю, мне кажется, не рационально.
4)Ну здесь, тоже, все зависит от предъявляемых требований, я привел пример, у меня требования такие, поэтому так и написал. Представь, что помимо маяка, в сцене, где поддерживается до ляма поликов, присутсвуют объекты, которые съедают большинство ресурсов, тут и триугольные перила смотрятся норм. 90-е здесь не причем, сейчас такие требования встречаются в популярных играх.
Я пишу только о том, с чем сталкивался, поэтому колкая фраза: "Тут господин Скиф, как мне кажется, даже не понимает о чем пишет" не катит.
У каждого свой подход и свои требования...
- Рейтинг
- 218
Я ж говорю - не совсем понимаешь для чего этот паддинг делается) Речь идет не том уменьшении текстуры, когда это делает художник руками, а про мипмэппинг - это когда движков это делает, используя вшитые в текстуру мипмэпы. Это происходит ВСЕГДА, и это ВСЕГДА рационально, при чем уменьшение происходит куда большее, чем в 4 раза, хоть в 8 или 16. Если бы этого не было, если бы в текстуру был бы зашит только нулевой мипмэп, то по отдалении от объекта, на котором эта текстура лежит, движок просто не знал бы какой пиксель текстуры отрисовывать и начинался бы файтинг, т.е. мерзкое дребезжание текстуры. Вот для этого мипмэппинг и изобрели. И вот пример рамеров паддинга:
128 = 2px
256 = 2px
512 = 4px
1024 = 8px
2048 = 16px
Паддинг всегда такой, как написано выше, и не надо рассказывать про 5 пикселей, т.к. для текстур больше чем 512х512 - этого уже мало. Советую почитать статьи, ссылки на которые я кидал в прошлом посте)
Речь идет не о миллионе поликов в сцене, а о миллионе поликов в кадре - это разные вещи. Для нормального фпс, на текущем поколении РС, в среднем это около 1-1,5млн. А вся сцена может быть хоть 10 хоть 30 млн. поликов, и ниче в этом страшного нет. Если сделать перила 3х-гранными, то прирост к производительности будет до смешного мал, т.к. даже лишние пара десятков тыщ поликов погоды не сделают. Куда больше ресурсов жрут шейдеры, партиклы, физика, свет, а уже потом поликаунт. Так что задрачивать оптимизацию до уровня 3х-гранных перил - это лишняя трата времени и минус к качеству видеоряда) Более того, если сделать этот сегмент (с перилом) отдельным и размножить его уже в самом движке, то это вообще особо на производительность не повлияет, даже если этих перил будет тыща, а все благодаря хардварному инстансингу) Короче я к тому, что есть куча способов сделать куда более высокополигональные модели, а не мучаться с 3х-гранным ужасом, и при этом не потерять в производительности)
128 = 2px
256 = 2px
512 = 4px
1024 = 8px
2048 = 16px
Паддинг всегда такой, как написано выше, и не надо рассказывать про 5 пикселей, т.к. для текстур больше чем 512х512 - этого уже мало. Советую почитать статьи, ссылки на которые я кидал в прошлом посте)
Речь идет не о миллионе поликов в сцене, а о миллионе поликов в кадре - это разные вещи. Для нормального фпс, на текущем поколении РС, в среднем это около 1-1,5млн. А вся сцена может быть хоть 10 хоть 30 млн. поликов, и ниче в этом страшного нет. Если сделать перила 3х-гранными, то прирост к производительности будет до смешного мал, т.к. даже лишние пара десятков тыщ поликов погоды не сделают. Куда больше ресурсов жрут шейдеры, партиклы, физика, свет, а уже потом поликаунт. Так что задрачивать оптимизацию до уровня 3х-гранных перил - это лишняя трата времени и минус к качеству видеоряда) Более того, если сделать этот сегмент (с перилом) отдельным и размножить его уже в самом движке, то это вообще особо на производительность не повлияет, даже если этих перил будет тыща, а все благодаря хардварному инстансингу) Короче я к тому, что есть куча способов сделать куда более высокополигональные модели, а не мучаться с 3х-гранным ужасом, и при этом не потерять в производительности)
Я поделился советами и высказал свою точку зрения, основываясь на том, как это делают в одной мировой игровой компании. Там пара тысяч поликов несет огромное значение и текстуры, зачастую, уменьшаются вручную моделлерами, почему это так, без понятия, так как в движковые подробности не вдавался. Думаю, Г.Н. почерпнул, что ему надо из двух совершенно разных взглядов на проблему...
