1. Пользоваться форумом на планшетах и телефонах стало удобнее благодаря Tapatalk

Soccer ball

Тема в разделе "RenderMan", создана пользователем -, 21 ноя 2000.

Модераторы: Moderator.
  1. Guest

    Помните, тут пару-тройку месяцев назад был разговор о шейдере для футбольного мяча - так вот, я тогда эту затею бросил, а вчера меня осенило. Все оказалось проще простого. Картинка лежит на http://www.r-m-c.ru/3ds2rib/ball.jpg Естественно, это только схема шейдера. Надо добить "кожу", швы и т.д. Если кому-то топик еще интересен - пишите, растолкую.
     
  2. Guest

    Слушай, а ведь это - победа ;-) Расскажи, как, я до сих пор не могу понять ;-)))
     
  3. Guest

    Ну, в общем, я читал АрМан - про фокусы с 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 - бери цвет пентагона, больше - гексагона. Вот и все!
    Скорее всего, все это поддается оптимизации, хотя и так рендерится довольно быстро...
     
  4. Guest

    (-)
     
  5. Guest

    ЗдОрово!
    Если не сложно - растолкуй, очень интересно...
     
  6. Guest

    Супер!!!!
    V II V II V II - это тебе аплодисменты!
    Насколько я понял фишка с normalize(P) имеет смысл
    для сферы с origin по центру сферы ?
    Ежели будеш доводить до кондиции
    то неплохо былобы использовать Ppref
    вместо P если таковая имеется . Мячик
    всетаки деформиться при буцании...
    Мда книжки - весч полезная.
    Когдаж ты в "плановом порядке" доберешся до 15 главы :)
    Кстати ктонить знает как сильно по
    содержанию отличаются ARMan от Texturing&Modeling
    А то у меня есть шейдеры от обойх - одно и тоже....
     
  7. Guest

    Про деформацию и центр - это ты прав. Как и про то, что я до Ppref или как там его... еще не доехал :))
     
  8. Guest

    T&M по содержанию - всего лишь пятая часть Arman. И по качеству, боюсь - тоже - все таки сколько лет прошло.

    Говорю ответственно - есть и читал обе.
     
  9. Guest

    Результат очередных ночных бдений:
    http://www.r-m-c.ru/3ds2rib/ball.jpg - надутый
    http://www.r-m-c.ru/3ds2rib/ball1.jpg - сдутый ;-)
     
  10. Guest

    Сдутый красивше ;-)
    Это извраты c pow
    или пошел в ход второй ближайший?
    Кстати о зайцах....
    Волейбольный мяч...
    Я немного пойзвращался с массивом из 18 центров.
    Массив из 6 дает правильную раскладку
    основных 6 заплаток волейбольного мяча,
    но когда в ход пускаються остальные 12 то получаеться немного
    не то. Я посмотрел на реальный ВМяч. У него немного нестандартная
    раскроика у самых центральных заплаток.
    Какие нибудь идеи будут? (в смысле можливо ль це пофиксить)
    Найти бы где мат описалово хедры.....
    Можно было бы ваще ее полностью заимплементить.
    Я тут в волейбольный мяч ввел пару параметров влияющих
    на координаты центров. Прям калейдоскоп какойто получился.
    Короче огромное тебе сенкс за то что так просто в двух словах
    раскрыл глаза на Вороного. Сколько я не пытался въехать
    в worley,cellular и иже с ними суть всегда кудато ускользала.
    И вот еще что....
    Выбирать меж расстрелянием и повешанием придеться усетаки мине.
    Действительно теням плевать кто и откуда их спрашивает.
    Жрут они поинты в current и не давяться.

    Я тут наверное уже достал всех своими волумами в тенях.
    Но всетаки ктонить может объяснить чо происходит?
    Когда я вместо 6 разных теней подставляю
    какую нибудь одну (всмысле вместо 6 разных - 6 одинаковых)
    то шейдер начинает честно маршировать
    тот участок за который эта тень отвечает. Но вместе они
    работать нехотят. Или у меня с логикой невпорядке?
    http://www.geocities.com/andrewvk107/SurfVolum/Madness.zip
     
  11. Guest

    Этим летом на МУМе презентовали скрипт майевский, который делал геометрию любых полихедр - ссылка внизу:

    http://www.rusrender.net/events/mum/11/

    в том числе и всяких мячей. Я не очень уверен, что оно чем-то пригодится, но как референс очень даже ничего.

    На случай, если админы опять уберут ссылку на rr.net - я не виноват, такая у них долбаная политика...
     
  12. Guest

    У тебя в шейдере кусок вот такой:

    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.

    А зачем тогда остальные? ;-)
     
  13. Guest

    Я ж говорю что когда я подставляю туда 6 разных мапок
    (как и предпологалось изначально, как и было задумано)
    то он нихрена не считает.
    Выходит из цикла на первом же шаге.
    А это я просто забыл поправить после экспериментов.
    (когда подставлял 6 одинаковых)
    При этом он считал кусок объекта находящийся
    в "тени" этой самой мапы. Что и видно из
    картинок (для каждой из 6 мап)
     
  14. Guest

    Это и второй и даже третий ближайшие... Второй дает загиб у шва и антиалиасинг на границе, а третий работает на приближениях к "углам".
    Волейбольный мяч - это когда по 3 длинных кусочка сшито? У меня тут идейка возникла - не центры определять, а отрезки вдоль середин кусочков. И расстояние определять не distance(), а как его там... ptlined(). Хотя концы кусочков будут слегка кривоваты... Но, может, так оно и надо? Мне, кстати, при доводке soccer пришлось помножить хедровые центры пятиугольников на 1.15 (вроде бы... уже не помню точно), иначе пятиугольные заплатки получались чуть больше, чем надо, и, в результате шестиугольные оказывались неравносторонними. Почему - сам не вполне понимаю: я сначала думал, это из-за того, что центры пяти- и шестиугольников в хедре оказывались на разных расстоянях от центра, попробовл _все_ центры прогонять через normalize(), но это не помогло (!).
    Про смертную казнь: я всегда верил в торжество идеалов <...> (вставить нужное) :)
    А с твоим шейдером действительно фигня какая-то. Вроде, с виду все похоже на правду...
     
  15. Guest

    ....лохонуться. Но обовсем попорядку.
    Насчет ВМяча именно 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 и доведу до ума.
    Вобщем я свистну.
     
  16. Guest

    Я сейчас помучил ptlined. Так и есть, полная фигня получается. Как вариант: проверять, в пределах ли мы перепендикуляров на концах отрезка, и если нет - мерить расстояние до ближайшего конца отрезка. Надо помозговать...
     
Модераторы: Moderator.

Поделиться этой страницей