Помните, тут пару-тройку месяцев назад был разговор о шейдере для футбольного мяча - так вот, я тогда эту затею бросил, а вчера меня осенило. Все оказалось проще простого. Картинка лежит на http://www.r-m-c.ru/3ds2rib/ball.jpg Естественно, это только схема шейдера. Надо добить "кожу", швы и т.д. Если кому-то топик еще интересен - пишите, растолкую.
Ну, в общем, я читал АрМан - про фокусы с Voronoi и пр. Они там строят сетку feature point'ов, а потом проверяют расстояние от P до этих "центров патчей", сортируют, находят ближайший и второй по близости. А с ними уже можно творить всяческие чудеса. Вот тут я и понял, что надо иметь массив центров всех "заплаток" мяча, и проверять P на близость к каждому. Тут пришлось повозиться с Хедрой в Максе, из которой я выдрал в текстовом виде эти координаты:
---------------------------------------------------
#define nPatches 32
#define nPentagons 12
uniform point patch_centers[nPatches] = {
/* 0..11 - Pentagons: */
point(0.0000, 0.5397, 0.8732),
point(-0.0000, -0.5397, 0.8732),
point(0.8732, -0.0000, 0.5397),
point(0.5397, -0.8732, 0.0000),
point(0.8732, -0.0000, -0.5397),
point(-0.0000, -0.5397, -0.8732),
point(0.0000, 0.5397, -0.8732),
point(-0.8732, 0.0000, -0.5397),
point(-0.5397, 0.8732, -0.0000),
point(-0.8732, 0.0000, 0.5397),
point(-0.5397, -0.8732, -0.0000),
point(0.5397, 0.8732, 0.0000),
/* 12..31 - Hexagons: */
point(0.3568, -0.0000, 0.9342),
point(0.5774, 0.5774, 0.5774),
point(0.0000, 0.9342, 0.3568),
point(-0.5774, 0.5774, 0.5774),
point(-0.3568, 0.0000, 0.9342),
point(-0.5774, -0.5774, 0.5774),
point(-0.0000, -0.9342, 0.3568),
point(0.5774, -0.5774, 0.5774),
point(0.9342, 0.3568, 0.0000),
point(0.9342, -0.3568, 0.0000),
point(-0.0000, -0.9342, -0.3568),
point(0.5774, -0.5774, -0.5774),
point(0.5774, 0.5774, -0.5774),
point(0.3568, -0.0000, -0.9342),
point(-0.5774, -0.5774, -0.5774),
point(-0.3568, 0.0000, -0.9342),
point(0.0000, 0.9342, -0.3568),
point(-0.5774, 0.5774, -0.5774),
point(-0.9342, -0.3568, -0.0000),
point(-0.9342, 0.3568, -0.0000)
};
------------------------------------------------------------------------
А сами шейдеры очень простые. Вот, к примеру, дисплейсмент:
displacement
balldisp (float Kdisp = 0.25)
{
point Pn = normalize(transform("object", P));
uniform float i;
float mindist;
float nearestPatch;
float tmp;
mindist = 1e10;
for (i = 0; i < nPatches; i += 1) {
tmp = distance(patch_centers, Pn);
if (tmp < mindist) {
mindist = tmp; nearestPatch = i;
}
}
P -= normalize(N) * pow(mindist, 3) * Kdisp;
N = calculatenormal(P);
}
pow(mindist, 3) - это от балды, на самом деле функция "закругления" может быть хитрее. А если еще кроме mindist находить mindist2 - расстояние до второго по близости патча, можно вообще состряпать границу "с толщиной".
А surface шейдер еще проще: если nearestPatch < nPentagons - бери цвет пентагона, больше - гексагона. Вот и все!
Скорее всего, все это поддается оптимизации, хотя и так рендерится довольно быстро...
---------------------------------------------------
#define nPatches 32
#define nPentagons 12
uniform point patch_centers[nPatches] = {
/* 0..11 - Pentagons: */
point(0.0000, 0.5397, 0.8732),
point(-0.0000, -0.5397, 0.8732),
point(0.8732, -0.0000, 0.5397),
point(0.5397, -0.8732, 0.0000),
point(0.8732, -0.0000, -0.5397),
point(-0.0000, -0.5397, -0.8732),
point(0.0000, 0.5397, -0.8732),
point(-0.8732, 0.0000, -0.5397),
point(-0.5397, 0.8732, -0.0000),
point(-0.8732, 0.0000, 0.5397),
point(-0.5397, -0.8732, -0.0000),
point(0.5397, 0.8732, 0.0000),
/* 12..31 - Hexagons: */
point(0.3568, -0.0000, 0.9342),
point(0.5774, 0.5774, 0.5774),
point(0.0000, 0.9342, 0.3568),
point(-0.5774, 0.5774, 0.5774),
point(-0.3568, 0.0000, 0.9342),
point(-0.5774, -0.5774, 0.5774),
point(-0.0000, -0.9342, 0.3568),
point(0.5774, -0.5774, 0.5774),
point(0.9342, 0.3568, 0.0000),
point(0.9342, -0.3568, 0.0000),
point(-0.0000, -0.9342, -0.3568),
point(0.5774, -0.5774, -0.5774),
point(0.5774, 0.5774, -0.5774),
point(0.3568, -0.0000, -0.9342),
point(-0.5774, -0.5774, -0.5774),
point(-0.3568, 0.0000, -0.9342),
point(0.0000, 0.9342, -0.3568),
point(-0.5774, 0.5774, -0.5774),
point(-0.9342, -0.3568, -0.0000),
point(-0.9342, 0.3568, -0.0000)
};
------------------------------------------------------------------------
А сами шейдеры очень простые. Вот, к примеру, дисплейсмент:
displacement
balldisp (float Kdisp = 0.25)
{
point Pn = normalize(transform("object", P));
uniform float i;
float mindist;
float nearestPatch;
float tmp;
mindist = 1e10;
for (i = 0; i < nPatches; i += 1) {
tmp = distance(patch_centers, Pn);
if (tmp < mindist) {
mindist = tmp; nearestPatch = i;
}
}
P -= normalize(N) * pow(mindist, 3) * Kdisp;
N = calculatenormal(P);
}
pow(mindist, 3) - это от балды, на самом деле функция "закругления" может быть хитрее. А если еще кроме mindist находить mindist2 - расстояние до второго по близости патча, можно вообще состряпать границу "с толщиной".
А surface шейдер еще проще: если nearestPatch < nPentagons - бери цвет пентагона, больше - гексагона. Вот и все!
Скорее всего, все это поддается оптимизации, хотя и так рендерится довольно быстро...
Супер!!!!
V II V II V II - это тебе аплодисменты!
Насколько я понял фишка с normalize(P) имеет смысл
для сферы с origin по центру сферы ?
Ежели будеш доводить до кондиции
то неплохо былобы использовать Ppref
вместо P если таковая имеется . Мячик
всетаки деформиться при буцании...
Мда книжки - весч полезная.
Когдаж ты в "плановом порядке" доберешся до 15 главы
Кстати ктонить знает как сильно по
содержанию отличаются ARMan от Texturing&Modeling
А то у меня есть шейдеры от обойх - одно и тоже....
V II V II V II - это тебе аплодисменты!
Насколько я понял фишка с normalize(P) имеет смысл
для сферы с origin по центру сферы ?
Ежели будеш доводить до кондиции
то неплохо былобы использовать Ppref
вместо P если таковая имеется . Мячик
всетаки деформиться при буцании...
Мда книжки - весч полезная.
Когдаж ты в "плановом порядке" доберешся до 15 главы
Кстати ктонить знает как сильно по
содержанию отличаются ARMan от Texturing&Modeling
А то у меня есть шейдеры от обойх - одно и тоже....
Сдутый красивше ;-)
Это извраты c pow
или пошел в ход второй ближайший?
Кстати о зайцах....
Волейбольный мяч...
Я немного пойзвращался с массивом из 18 центров.
Массив из 6 дает правильную раскладку
основных 6 заплаток волейбольного мяча,
но когда в ход пускаються остальные 12 то получаеться немного
не то. Я посмотрел на реальный ВМяч. У него немного нестандартная
раскроика у самых центральных заплаток.
Какие нибудь идеи будут? (в смысле можливо ль це пофиксить)
Найти бы где мат описалово хедры.....
Можно было бы ваще ее полностью заимплементить.
Я тут в волейбольный мяч ввел пару параметров влияющих
на координаты центров. Прям калейдоскоп какойто получился.
Короче огромное тебе сенкс за то что так просто в двух словах
раскрыл глаза на Вороного. Сколько я не пытался въехать
в worley,cellular и иже с ними суть всегда кудато ускользала.
И вот еще что....
Выбирать меж расстрелянием и повешанием придеться усетаки мине.
Действительно теням плевать кто и откуда их спрашивает.
Жрут они поинты в current и не давяться.
Я тут наверное уже достал всех своими волумами в тенях.
Но всетаки ктонить может объяснить чо происходит?
Когда я вместо 6 разных теней подставляю
какую нибудь одну (всмысле вместо 6 разных - 6 одинаковых)
то шейдер начинает честно маршировать
тот участок за который эта тень отвечает. Но вместе они
работать нехотят. Или у меня с логикой невпорядке?
http://www.geocities.com/andrewvk107/SurfVolum/Madness.zip
Это извраты c pow
или пошел в ход второй ближайший?
Кстати о зайцах....
Волейбольный мяч...
Я немного пойзвращался с массивом из 18 центров.
Массив из 6 дает правильную раскладку
основных 6 заплаток волейбольного мяча,
но когда в ход пускаються остальные 12 то получаеться немного
не то. Я посмотрел на реальный ВМяч. У него немного нестандартная
раскроика у самых центральных заплаток.
Какие нибудь идеи будут? (в смысле можливо ль це пофиксить)
Найти бы где мат описалово хедры.....
Можно было бы ваще ее полностью заимплементить.
Я тут в волейбольный мяч ввел пару параметров влияющих
на координаты центров. Прям калейдоскоп какойто получился.
Короче огромное тебе сенкс за то что так просто в двух словах
раскрыл глаза на Вороного. Сколько я не пытался въехать
в worley,cellular и иже с ними суть всегда кудато ускользала.
И вот еще что....
Выбирать меж расстрелянием и повешанием придеться усетаки мине.
Действительно теням плевать кто и откуда их спрашивает.
Жрут они поинты в current и не давяться.
Я тут наверное уже достал всех своими волумами в тенях.
Но всетаки ктонить может объяснить чо происходит?
Когда я вместо 6 разных теней подставляю
какую нибудь одну (всмысле вместо 6 разных - 6 одинаковых)
то шейдер начинает честно маршировать
тот участок за который эта тень отвечает. Но вместе они
работать нехотят. Или у меня с логикой невпорядке?
http://www.geocities.com/andrewvk107/SurfVolum/Madness.zip
Этим летом на МУМе презентовали скрипт майевский, который делал геометрию любых полихедр - ссылка внизу:
http://www.rusrender.net/events/mum/11/
в том числе и всяких мячей. Я не очень уверен, что оно чем-то пригодится, но как референс очень даже ничего.
На случай, если админы опять уберут ссылку на rr.net - я не виноват, такая у них долбаная политика...
http://www.rusrender.net/events/mum/11/
в том числе и всяких мячей. Я не очень уверен, что оно чем-то пригодится, но как референс очень даже ничего.
На случай, если админы опять уберут ссылку на rr.net - я не виноват, такая у них долбаная политика...
У тебя в шейдере кусок вот такой:
testS1 = ShdTest (ShdTex1, Psamp);
testS2 = ShdTest (ShdTex1, Psamp);
testS3 = ShdTest (ShdTex1, Psamp);
testS4 = ShdTest (ShdTex1, Psamp);
testS5 = ShdTest (ShdTex1, Psamp);
testS6 = ShdTest (ShdTex1, Psamp);
то есть везде проверяется ShdTex1.
А зачем тогда остальные? ;-)
testS1 = ShdTest (ShdTex1, Psamp);
testS2 = ShdTest (ShdTex1, Psamp);
testS3 = ShdTest (ShdTex1, Psamp);
testS4 = ShdTest (ShdTex1, Psamp);
testS5 = ShdTest (ShdTex1, Psamp);
testS6 = ShdTest (ShdTex1, Psamp);
то есть везде проверяется ShdTex1.
А зачем тогда остальные? ;-)
Я ж говорю что когда я подставляю туда 6 разных мапок
(как и предпологалось изначально, как и было задумано)
то он нихрена не считает.
Выходит из цикла на первом же шаге.
А это я просто забыл поправить после экспериментов.
(когда подставлял 6 одинаковых)
При этом он считал кусок объекта находящийся
в "тени" этой самой мапы. Что и видно из
картинок (для каждой из 6 мап)
(как и предпологалось изначально, как и было задумано)
то он нихрена не считает.
Выходит из цикла на первом же шаге.
А это я просто забыл поправить после экспериментов.
(когда подставлял 6 одинаковых)
При этом он считал кусок объекта находящийся
в "тени" этой самой мапы. Что и видно из
картинок (для каждой из 6 мап)
Это и второй и даже третий ближайшие... Второй дает загиб у шва и антиалиасинг на границе, а третий работает на приближениях к "углам".
Волейбольный мяч - это когда по 3 длинных кусочка сшито? У меня тут идейка возникла - не центры определять, а отрезки вдоль середин кусочков. И расстояние определять не distance(), а как его там... ptlined(). Хотя концы кусочков будут слегка кривоваты... Но, может, так оно и надо? Мне, кстати, при доводке soccer пришлось помножить хедровые центры пятиугольников на 1.15 (вроде бы... уже не помню точно), иначе пятиугольные заплатки получались чуть больше, чем надо, и, в результате шестиугольные оказывались неравносторонними. Почему - сам не вполне понимаю: я сначала думал, это из-за того, что центры пяти- и шестиугольников в хедре оказывались на разных расстоянях от центра, попробовл _все_ центры прогонять через normalize(), но это не помогло (!).
Про смертную казнь: я всегда верил в торжество идеалов <...> (вставить нужное)
А с твоим шейдером действительно фигня какая-то. Вроде, с виду все похоже на правду...
Волейбольный мяч - это когда по 3 длинных кусочка сшито? У меня тут идейка возникла - не центры определять, а отрезки вдоль середин кусочков. И расстояние определять не distance(), а как его там... ptlined(). Хотя концы кусочков будут слегка кривоваты... Но, может, так оно и надо? Мне, кстати, при доводке soccer пришлось помножить хедровые центры пятиугольников на 1.15 (вроде бы... уже не помню точно), иначе пятиугольные заплатки получались чуть больше, чем надо, и, в результате шестиугольные оказывались неравносторонними. Почему - сам не вполне понимаю: я сначала думал, это из-за того, что центры пяти- и шестиугольников в хедре оказывались на разных расстоянях от центра, попробовл _все_ центры прогонять через normalize(), но это не помогло (!).
Про смертную казнь: я всегда верил в торжество идеалов <...> (вставить нужное)
А с твоим шейдером действительно фигня какая-то. Вроде, с виду все похоже на правду...
....лохонуться. Но обовсем попорядку.
Насчет ВМяча именно 6 кусков состоящих из 3 .
вот его массив:
uniform point centers[18]={
point(0.0, 0.0, 1.0),
point(0.0, 1.0, 0.0),
point(1.0, 0.0, 0.0),
point(0.0, 0.0, -1.0),
point(0.0, -1.0, 0.0),
point(-1.0, 0.0, 0.0),
point(0.866025, 0.5, 0.0),
point(0.866025, -0.5, 0.0),
point(-0.866025, 0.5, 0.0),
point(-0.866025, -0.5, 0.0),
point(0.0, 0.866025, 0.5),
point(0.0, 0.866025, -0.5),
point(0.0, -0.866025, 0.5),
point(0.0, -0.866025, -0.5),
point(0.5, 0.0, 0.866025),
point(-0.5, 0.0, 0.866025),
point(0.5, 0.0, -0.866025),
point(-0.5, 0.0, -0.866025)
};
Результат похож на неправильный ВМяч
Хотя первые 6 коорд. дают правильную раскройку
основных больших заплат.
Кстати о ptlined....
Что она вернет если проверяемая точка лежит вне пределов отрезка
заданного двумя другими? Пердикуляр то в таком случае не проведеш.
Насчет волума. Это не у него фигня. Это у меня в голове фигня.
Я сейчас ржал истерическим хохотом с элементами идиотизма.
Как было дело. Думаю нафига сейчас вдаваться в мелочи,
нужно сначала идею проверить. Соответственно shadow вызывал
в урезанном варианте. А вот вчерась учитался sigg2000 где Ланкастер
и други его таким гемороем страдали чтобы победить шедовские
артифаки. Думаю может я слишком хорошего мнения об етих тенях.
Ну и влепил туда "bias", -0.01 (вынес тень немного за пределы объекта)
Ну ты понял чем все это закончилось.....
Для kidd:
Результат - покажу ;-)
когда оформлю slim template и доведу до ума.
Вобщем я свистну.
Насчет ВМяча именно 6 кусков состоящих из 3 .
вот его массив:
uniform point centers[18]={
point(0.0, 0.0, 1.0),
point(0.0, 1.0, 0.0),
point(1.0, 0.0, 0.0),
point(0.0, 0.0, -1.0),
point(0.0, -1.0, 0.0),
point(-1.0, 0.0, 0.0),
point(0.866025, 0.5, 0.0),
point(0.866025, -0.5, 0.0),
point(-0.866025, 0.5, 0.0),
point(-0.866025, -0.5, 0.0),
point(0.0, 0.866025, 0.5),
point(0.0, 0.866025, -0.5),
point(0.0, -0.866025, 0.5),
point(0.0, -0.866025, -0.5),
point(0.5, 0.0, 0.866025),
point(-0.5, 0.0, 0.866025),
point(0.5, 0.0, -0.866025),
point(-0.5, 0.0, -0.866025)
};
Результат похож на неправильный ВМяч
Хотя первые 6 коорд. дают правильную раскройку
основных больших заплат.
Кстати о ptlined....
Что она вернет если проверяемая точка лежит вне пределов отрезка
заданного двумя другими? Пердикуляр то в таком случае не проведеш.
Насчет волума. Это не у него фигня. Это у меня в голове фигня.
Я сейчас ржал истерическим хохотом с элементами идиотизма.
Как было дело. Думаю нафига сейчас вдаваться в мелочи,
нужно сначала идею проверить. Соответственно shadow вызывал
в урезанном варианте. А вот вчерась учитался sigg2000 где Ланкастер
и други его таким гемороем страдали чтобы победить шедовские
артифаки. Думаю может я слишком хорошего мнения об етих тенях.
Ну и влепил туда "bias", -0.01 (вынес тень немного за пределы объекта)
Ну ты понял чем все это закончилось.....
Для kidd:
Результат - покажу ;-)
когда оформлю slim template и доведу до ума.
Вобщем я свистну.