где в мторе бамп?
- Автор темы mickey 1373
- Дата создания
Странный вопрос. Бамп это ухудшеная весия дмсплейса. Рендерман
и бамп и дисплейс делает за одно и то же время, т.ч. пользоваться бампом почти нет смысла, а за счет дисплейса можно творить чудеса с моделями.
Можно комбинировать дисплейсы с положительным и отрицательным воздействием и получать суперштуки.
и бамп и дисплейс делает за одно и то же время, т.ч. пользоваться бампом почти нет смысла, а за счет дисплейса можно творить чудеса с моделями.
Можно комбинировать дисплейсы с положительным и отрицательным воздействием и получать суперштуки.
> А что значит
> "не включать дисплейс будет бамп".
Теория. Очень грубо, но для новичка, не читавшего доку (что видно, к сожалению, сразу) вполне сойдёт.
У displacement shaders есть доступ на запись к двум переменным (если упростить, конечно) - P и N.
P - точка в пространстве, которая на данный момент шейдится
N - нормаль поверхности в этой точке
Ну так вот, можно поменять в шейдере только N, и тогда это будет бамп. Смысл в том, что поверхность будет выглядеть, как будто она покорёжена, но геометрия её не меняется.
Можно поменять и N, и P. Поскольку мы поменяли P, то меняется геометрия объекта и мы имеем честный displacement. Тот самый, который так качественно делает prman.
Как это выглядит в тексте шейдера (кусок шейдера взят из стандартной поставки ShaderMan; использован код из BMRT с разрешения Larry Gritz):
normal Displace (vector dir; string space;
float amp; float truedisp
{
extern point P;
float spacescale = length(vtransform(space, dir));
vector Ndisp = dir * (amp / max(spacescale,1e-6));
P += truedisp * Ndisp;
return normalize (calculatenormal (P + (1-truedisp)*Ndisp));
}
Внимание! Это - не готовый шейдер, а всего-лишь функция. Её использование в готовом шейдере:
N = Displace (normalize(N), "shader", disp, 1);
Это была теория. Теперь пошла практика. SLIM. В Simple Displacement apperance включаем пимпочку "Do displacement". В Combine - то же самое.
MayaMan, по идее, наследует этот параметр от Майки, то есть если в ней поставить true displacement, то и в шейдерах, генерируемых MayaMan, тоже будет нормальный displacement. На всякий случай есть у них тоже пимпа, находится в Raytracing Options, работает точно так-же, как и у Слима, но относится только к рейтрейсерам типа Entropy или BMRT. Подробнее - \html\globals\raytracing.html.
> "не включать дисплейс будет бамп".
Теория. Очень грубо, но для новичка, не читавшего доку (что видно, к сожалению, сразу) вполне сойдёт.
У displacement shaders есть доступ на запись к двум переменным (если упростить, конечно) - P и N.
P - точка в пространстве, которая на данный момент шейдится
N - нормаль поверхности в этой точке
Ну так вот, можно поменять в шейдере только N, и тогда это будет бамп. Смысл в том, что поверхность будет выглядеть, как будто она покорёжена, но геометрия её не меняется.
Можно поменять и N, и P. Поскольку мы поменяли P, то меняется геометрия объекта и мы имеем честный displacement. Тот самый, который так качественно делает prman.
Как это выглядит в тексте шейдера (кусок шейдера взят из стандартной поставки ShaderMan; использован код из BMRT с разрешения Larry Gritz):
normal Displace (vector dir; string space;
float amp; float truedisp
{
extern point P;
float spacescale = length(vtransform(space, dir));
vector Ndisp = dir * (amp / max(spacescale,1e-6));
P += truedisp * Ndisp;
return normalize (calculatenormal (P + (1-truedisp)*Ndisp));
}
Внимание! Это - не готовый шейдер, а всего-лишь функция. Её использование в готовом шейдере:
N = Displace (normalize(N), "shader", disp, 1);
Это была теория. Теперь пошла практика. SLIM. В Simple Displacement apperance включаем пимпочку "Do displacement". В Combine - то же самое.
MayaMan, по идее, наследует этот параметр от Майки, то есть если в ней поставить true displacement, то и в шейдерах, генерируемых MayaMan, тоже будет нормальный displacement. На всякий случай есть у них тоже пимпа, находится в Raytracing Options, работает точно так-же, как и у Слима, но относится только к рейтрейсерам типа Entropy или BMRT. Подробнее - \html\globals\raytracing.html.
Раз заговорили о Displacement, то тогда хотелось бы вот что спросить:
Насколько я понял для расчета Дисплесемент PRMan использует нормали вершин. Так? А что буде т с объектами, у которых нормали вершин для разных граней разные? Например у куба? Тогда все фейсы объекта дисплесементятся в разные стороны, т.е. по нормалям плоскостей. И как это обойти?
Насколько я понял для расчета Дисплесемент PRMan использует нормали вершин. Так? А что буде т с объектами, у которых нормали вершин для разных граней разные? Например у куба? Тогда все фейсы объекта дисплесементятся в разные стороны, т.е. по нормалям плоскостей. И как это обойти?
> Насколько я понял для расчета Дисплесемент PRMan использует
> нормали вершин.
Неправильно. Ведь шейдинг того же кубика происходит не только в точках вершин, не так ли? Он происходит по всем точками видимой поверхности в соответствии с установками ShadingRate (зависит от реализации рендерера).
> Так? А что буде т с объектами, у которых
> нормали вершин для разных граней разные? Например у куба?
> Тогда все фейсы объекта дисплесементятся в разные стороны,
> т.е. по нормалям плоскостей. И как это обойти?
А кто сказал, что изменять геометрию можно только в сторону нормали к поверхности? Её ведь можно изменять в любую сторону. Просто к одному вектору прибавили другой. Любой.
Теперь понятна неправильность подхода?
> нормали вершин.
Неправильно. Ведь шейдинг того же кубика происходит не только в точках вершин, не так ли? Он происходит по всем точками видимой поверхности в соответствии с установками ShadingRate (зависит от реализации рендерера).
> Так? А что буде т с объектами, у которых
> нормали вершин для разных граней разные? Например у куба?
> Тогда все фейсы объекта дисплесементятся в разные стороны,
> т.е. по нормалям плоскостей. И как это обойти?
А кто сказал, что изменять геометрию можно только в сторону нормали к поверхности? Её ведь можно изменять в любую сторону. Просто к одному вектору прибавили другой. Любой.
Теперь понятна неправильность подхода?
Хорошо Kidd. Идею я понял. Ноя еще новичек. И не все могу пока реализовать. Может подскажешь доступно как избежать того чтобы дисплесемент был, по по жестким ребрам не смещался, или даже на NURBS сфере дисплесемент смешает граничные изопармы так, что появляются дыры. Как это обойти в MTOR? Или такая информация не распрстраняется ))?
))?> Все очень просто. На граничной изопарме u (v) скачкообразно
> переходит из 1 в 0. Твоя displacement функция либо должна это
> учитывать (как учитывают это те, кто рисуют tileable
> текстуры), либо вообще не должна полагаться на uv (st).
В принципе, это должно быть видно только на шариках и иже с ними?
> переходит из 1 в 0. Твоя displacement функция либо должна это
> учитывать (как учитывают это те, кто рисуют tileable
> текстуры), либо вообще не должна полагаться на uv (st).
В принципе, это должно быть видно только на шариках и иже с ними?
> Может подскажешь доступно как избежать того
> чтобы дисплесемент был, по по жестким ребрам не смещался, или
> даже на NURBS сфере дисплесемент смешает граничные изопармы
> так, что появляются дыры.
> Как это обойти в MTOR?
И не только в мтор - копай в сторону DisplacementBounds.
> Или такая
> информация не распрстраняется))?
Оохххх. Ща как скажу...
1. Вся информация, полученная мной (равно как и многими другими в этом форуме, если не сказать - всеми) - получена путём чтения документации, книг, сайтов по тематике и ЭКСПЕРИМЕНТИРОВАНИЯ. Вот так, с большой буквы. Ой, забыл comp.graphics.rendering.renderman упомянуть.
1.5. Ну и естественно - применения полученных знаний на практике. Практика с теорией связаны навек - этому меня ещё в универе научили)))
2. Поэтому если вы считаете, что информация не распространяется - зачем тогда спрашивать? Делайте то, что описано в пункте #1 - и будет вам щасте.
3. Тем не менее, информация распространяется. И куча людей на этом форуме пытается вам помочь. Или это незаметно?))
Воооот.
> чтобы дисплесемент был, по по жестким ребрам не смещался, или
> даже на NURBS сфере дисплесемент смешает граничные изопармы
> так, что появляются дыры.
> Как это обойти в MTOR?
И не только в мтор - копай в сторону DisplacementBounds.
> Или такая
> информация не распрстраняется
))?Оохххх. Ща как скажу...
1. Вся информация, полученная мной (равно как и многими другими в этом форуме, если не сказать - всеми) - получена путём чтения документации, книг, сайтов по тематике и ЭКСПЕРИМЕНТИРОВАНИЯ. Вот так, с большой буквы. Ой, забыл comp.graphics.rendering.renderman упомянуть.
1.5. Ну и естественно - применения полученных знаний на практике. Практика с теорией связаны навек - этому меня ещё в универе научили
)))2. Поэтому если вы считаете, что информация не распространяется - зачем тогда спрашивать?
Делайте то, что описано в пункте #1 - и будет вам щасте.3. Тем не менее, информация распространяется. И куча людей на этом форуме пытается вам помочь. Или это незаметно?
))Воооот.
Ну во-первых, облом с дисплесементом есть не только на сферах и кубиках. Попробуйте поставить дисплесемент любой геометрии и любого мапинга у которой есть жесткие грани (или не совпадают нормали вершин) и все! Можно обходить конечно же как говорит Alex. Но зачем тогда этот прибоббас. Чтобы на гранях исчезал эффект? А если надо, например, реализовать дисплесементом зубчатое колесо и спроецировать потом карту на цвет?
Имхо проще его смоделить А если задача стоит так принципиально, то наверно придется писать хитровыеденную функцию от SurfacePoint, которая все и сделает... Ей, скорее всего, входные зачения P и N будут не очень-то нужны, она будет вычислять новые сама... Ну и последнее: я бы все-таки предпочел юзать нурбсовый бублик, а не полигоны...
А если задача стоит так принципиально, то наверно придется писать хитровыеденную функцию от SurfacePoint, которая все и сделает... Ей, скорее всего, входные зачения P и N будут не очень-то нужны, она будет вычислять новые сама... Ну и последнее: я бы все-таки предпочел юзать нурбсовый бублик, а не полигоны...