hard, вопрос для всех программ  (Прочитано 10238 раз)

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

Разность тангенспространства с каким тангенспространством ты имеешь в виду?

( для  ghostdom - программа -http://www.handplane3d.com/ - конвертер нормалок под софт)

Об этой утлитке давно в курсе, вот только не юзаю, по причине ненадобности. По крайней мере пока. Мои нормалки пока работают нормально как в юньке так и в анриале и крае, хотя последними двумя давненько не занимался.
И сразу же вопрос. Эта утилитка появилась на свете всего то года 3 как. А что же тогда люди делали раньше, когда ее еще не было? Только давай не будем говорить о кривизне чьихто рук.

 

немного  - 5 год пошел. плотно? каждый день.

Отлично) А можно посмотреть твои работы?

т.е он предлагает ВСЕ островки делать с жесткими гранями?!

Не все, но можно и так сказать. Прежде всего - хард стараются ставить там где угол между 2-мя поверхностями 90 градусов или больше. Если меньше, надо смотреть по месту.

Отлично) А можно посмотреть твои работы?

Да, ты знаешь - работы твои отлично смотрятся

 за шинкование -
http://polycount.com/discussion/81154/understanding-averaged-normals-and-ray-projection-who-put-waviness-in-my-normal-map
вся темка занимательная
не могу ссылку дать на пост с занимательной картинкой - 6 страница
 сами картиники. речь вообще о кейдже, но насчет того что там по вашей теории должны быть харды -



на gif-е разница с кейджом и без, чтоб не было скоропалительных выводов.

Как понять - неправильный? Почему он неправильный? Вполне так себе может быть и правильным. Смотря как и где использовать

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

рука -лицо...

А что же тогда люди делали раньше, когда ее еще не было?

пайплайн завязаный на какой то определенный пакет с своими самописными экспортерами прояснит ситуацию?

Отлично) А можно посмотреть твои работы?

Это изменит твое мировосприятие и отношение к тому что я написал?
https://www.artstation.com/artist/legionaire

пайплайн завязаный на какой то определенный пакет с своими самописными экспортерами прояснит ситуацию?

Это не тот ответ. Я спросил - что люди делали пока ее не было.

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

Нет, не изменит. Делаешь ты все правильно и в точности как и остальные. Вот только описываешь и рассказываешь все как-то ну очень вычурно, сумбурно.

за шинкование -
http://polycount.com/discussion/81154/understanding-averaged-normals-and-ray-projection-who-put-waviness-in-my-normal-map
вся темка занимательная
не могу ссылку дать на пост с занимательной картинкой - 6 страница
 сами картиники. речь вообще о кейдже, но насчет того что там по вашей теории должны быть харды -

Да да, знаем мы такую статейку и не только ее. Кстати - года три как здесь на форуме была попытка сделать перевод похожей статейки с того же поликаунта. Не менее интересной. И заметь - этой статье уже 6-ть лет. Так что это уже давно не новость.

Мне работы дядьки понравились!  (yes) (pcn)

на пальцах -
программка( хотя и результат в ней не ахти из за того что она не делает компенсацию жестких ребер) всего лишь упростила перебрасывание нормалки из софта в софт.
для макса пекли в максе. для майки пекли в майе. для движков писали экспортеры в двиг с переносом бинормалей и нормалей из майки (к примеру) для ЮДК под майку был свой экспортер. уже не помню как обзывается формат, вроде ASe , потом перешли на FBX.

Вот только описываешь и рассказываешь все как-то ну очень вычурно, сумбурно.

возможно. страдаю косноязычием в попытке объяснить сложные вещи простыми словами, а картинки чтоб понятней сделать ленюсь.

Так что это уже давно не новость.

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

Отличные работы!

на пальцах -
программка( хотя и результат в ней не ахти из за того что она не делает компенсацию жестких ребер) всего лишь упростила перебрасывание нормалки из софта в софт.
для макса пекли в максе. для майки пекли в майе. для движков писали экспортеры в двиг с переносом бинормалей и нормалей из майки (к примеру) для ЮДК под майку был свой экспортер. уже не помню как обзывается формат, вроде ASe , потом перешли на FBX.

Цитировать

Вот только описываешь и рассказываешь все как-то ну очень вычурно, сумбурно.

возможно. страдаю косноязычием в попытке объяснить сложные вещи простыми словами, а картинки чтоб понятней сделать ленюсь.

Цитировать

Так что это уже давно не новость.

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

лично я стремлюсь к оптимальному соотношению цена/качество, тобишь скорость/результат.  и чем больше продвинутые пользователи напишут типов и триков, тем быстрее мы эту формулу выведем ))

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

Хоть убей не понимаю как програмка, результат работы какой - не ахти, может упростить работу.

для движков писали экспортеры в двиг с переносом бинормалей и нормалей из майки (к примеру) для ЮДК под майку был свой экспортер. уже не помню как обзывается формат, вроде ASe , потом перешли на FBX.

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

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

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

возможно. страдаю косноязычием в попытке объяснить сложные вещи простыми словами, а картинки чтоб понятней сделать ленюсь.

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

И таки да, я прошу извинения за резкость в своих высказываниях, но с учетом всего вышесказанного.

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

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

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

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

ОК. на трезвую голову без эмоций и преодолев нелюбовь к длинным текстам
1 по поводу hard edge \ soft edge

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

видеокарте похрен, она ничего никуда не добавляет. она отрисовывает, то что ей передает через инструкции или DirectX или OpenGL, а по существу, на порядок ниже инструкции из шейдера. все это дело записано в виде векторов, в каком направлении отражать свет по отношению к вертексу.
Дальше - технология hard edge \ soft edge реализована в maya и softimage.  в 3dsMax, Cinema4d это группы сглаживания. в Modo  своя система . в Blender  раньше было как и в игровых движках, сейчас вроде как Maya (но это по словам блендеристов, я им мало доверяю).
По сути технологии призваны к одному - указать видеокарте нужный вектор отражения света. как это в майе -
На первом скрине выделены 2 вертекса, ребро между ними Soft edge

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

Теперь про игровые движки. 
3 скрин -

 Здесь я отдетачил ( разрезал по ребру . команда Detach Component) ребра. визуально я получил тоже самое что и назначив Hard Edge . с единственной разницей - теперь у меня 2 вертекса и соответственно 2 ребра.

Так же само происходит в игровых движках. НО. возвращаясь к тому что я писал в первом посте . В 3Д софте (Макс, Майя итд) в месте юви шва, никаких транcформаций относительно 3д модели не происходит. на месте шва все также 2 вершины и одно ребро. Скрин

мы видим что ничего не поменялось, у нас по прежнему SoftEdge, 2 вертекса,
И вот попадая в движок , в месте юви шва у нас получается картина как на 3 скрине. Но, как я сказал технологии не стоят на месте ( момент я как то пропустил, но в directX9 этого еще  в широком применении не было. возможно кто то программно и исправлял в шейдерах эти штуки) - нормали, которые разведены как на скрине 3 , в месте где из 3Дсофта выходит мягкое ребро, просто проварачиваются, чтоб перпендикулярные векторы относительно плоскости,  смотрели в одном направлении.
примерно так -

Но там по прежнему 4 вершины и 2 ребра. и если мы это не учитываем, и не назначим место шва HardEdge -м,  то визуально получим результат как на этом скрине

Если посмотреть, то ерунда вроде. но ерунда на этом примере. а вот что может быть если не следовать этому правилу -
известная студия, известная игра. Но деньги отбиты, пипл схавал и побоку что и как. А вдруг это гениальный дизайнерский ход?

2 теперь по поводу что раньше курица или яйцо.  ( hard edge or UV seam). оба метода дают финальный результат. с единственной разницей -
1 меньше швов, это оптимизация, путем уменьшения количества вертексов у модели.
2 меньше швов на углах, визуально лучше смотрится модель.
А поскольку вопрос задан в теме за Хnormal, который отлично справляется с компенсацией "неправильного шейдинга" ( вот често, тут с человеком разговаривали, какой термин применим к этому явлению, но так и не пришли к вразумительному  совместному понятию. пусть будет он. если кто в курсе как это правилней обозвать скажу спасибо. ниже  на картинке), то почему не использовать этот способ?


Естественно, все выше сказанное за достижение результата, применимо к понятию, время\качество\куда нужно. поскольку я работаю для ПК и  с пушками, которые занимают 3\4 экрана в игре и в близком расстоянии от камеры, то нужно, чтобы все было идеально.  а ежели это моделька для игры на мобильных устройствах, то и требования к качеству намного ниже и на многие вещи можно просто забить болт. это же относится к  моим словам о программке handplane3d.

теперь за бинормали, тангенс пространство . вот 2 скрина с моделькой из юнити. бейк в xNormal,  с плагином UnityTspace.
в первом варианте бинормали из майки,


 во втором все пересчитано.


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

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





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



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

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

я не писал, что это проблема. но танцы с бубном в некоторых случаях были гарантированы.

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

вопрос задан на этом форуме, тоже в темке за хНормал. ну это так, вдруг ты не заметил.

таки да, я прошу извинения за резкость в своих высказываниях, но с учетом всего вышесказанного.

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


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------


SiG Antialising 4 стоит?

кстати выставление жестких граней никак на запекание не влияет и нужно только для визуализации

это пример с компенсацией шва ( если ХардЭйдж) и без ( Если СофтЕйдж)


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