WiP
- Автор темы n1x3r
- Дата создания
не совсем) архитекторы смогут точно посчитать любое сооружение минут за 10, т.к. они знают формулы)) мне известна лишь общая инфа плюс личные наблюдения)
вся архитектура строится по определенным формулам и канонам, которые заложены еще древними греками и римлянами, если память не отшибло - зная один параметр можно вычислить другой с помощью линейки и циркуля) даже визуально сложная архитектура на самом деле состоит из примитивов - квадрат, окружность, треугольник.. комбинируя их, архитекторы получают "Вау!".. но это лирика))
вся архитектура строится по определенным формулам и канонам, которые заложены еще древними греками и римлянами, если память не отшибло - зная один параметр можно вычислить другой с помощью линейки и циркуля) даже визуально сложная архитектура на самом деле состоит из примитивов - квадрат, окружность, треугольник.. комбинируя их, архитекторы получают "Вау!".. но это лирика))
Трям! 
Даже не знаю где писать - сюда, в блог или в основной вип перебираться, хмм.
Понимаю, что скоро за мои эксперименты "классики" сожгут меня на костре, как еретика, но кому ж сейчас легко.
Вчера посмотрел видео, из которого узнал, что для движков больше важно количество вертексов, а не поликов. Также прозрел от следующей инфы: из-за групп сглаживания это количество может значительно вырасти после экспорта модели в движок. Век живи, век учись!
В двух словах о проблеме.
Например, у нас есть такой объект, к которому применены 2-е группы сглаживания. Сейчас у него 6 вертексов, но после экспорта их станет условно 8 - в отмеченных точках они будут дублироваться. Имхо, это странно и тем не менее нам-моделерам от этого никуда не деться, пока программеры что-то не придумают.
Посмотрел и задумался: "Ок, если есть такая бяка, значит ее и обойти можно. Вопрос: как?" В итоге вспомнил, что решение точно есть - когда-то мне попадалась одна моделька.
Она была ничем не примечательная, если бы не один момент: к ней полностью была применена только одна гр.сгл. и при этом геометрия сглаживалась только в нужных местах.
"Вот так номер!" - подумал тогда я и сразу начал ломать себе голову, пытаясь найти ответ на вопрос "Каким же макаром это все провернули?".
Анализировал, сравнивал, танцевал шаманские танцы и все мимо. У меня ничего не получилось и я оставил эту затею. Тем более для рендеров в принципе это не сильно было важно.
Сейчас ситуация изменилась и проблема стала ребром.
Вчера ночью снова возобновил поиски - повторный анализ ни к чему естественно не привел. Однако на глаза попалась одна интересная штука. На каком-то форуме (через Гугл) нашел проблему - ребята там исправляли какие-то косяки с помощью модификатора Edit Normals. Дай думаю посмотрю, что за фрукт.
Открываю и вижу "непонятные" кнопочки: "А что будет, если я нажму сюда?" И что вы думаете? Эврика - загадка разгадана и лекарство кажется найдено!
Сегодня еще раз пощупал - вроде бы работает.
"Труба" видео подпортила, сорри за качество. Для понимания процесса: в моде Edit Normals я юзаю кнопки "Break" и "Reset" - для уничтожения сглаживания и его восстановления соответственно.
Способ конечно немного корявый:
1. Редактить таким образом сглаживание желательно только финальную модель, т.к. любые изменения геометрии приводят к косякам в сглаживании и их нужно править повторно. В видео это есть на примере арки.
2. Второго момента нет. Применение к геометрии 100500 мод-слоев будет затруднительно. Например, когда вешаем поверх уже отредактированной болванки тот же Edit Poly, то эффект наших настроек сбрасывается. Увы, п.1 - это аксиома.
3. Иногда почему-то внутри модификатора криво работает выделение через Ctrl , но это скорее всего максовский глюк.
В теории метод может стать для геймдева "лекарством от экспортного дублирования". На практике - не знаю.
В каком-либо движке не тестил, но уже есть мысль ломать все свои заготовки, которые сейчас делаю-переделываю.
Поэтому, эксперты по движкам, очень прошу вас при наличии свободного времени провести плиз доп.тест и дать фидбек: адекватность экспорта такой геометрии (особенно интересуют нормали "Что с ними происходит?"), реакция на освещение ("Возникают ли побочные эффекты?") и главное - просчет ("Проблема с дубляжом решена в связи с единственной гр.сгл.?").
Даже не знаю где писать - сюда, в блог или в основной вип перебираться, хмм.Понимаю, что скоро за мои эксперименты "классики" сожгут меня на костре, как еретика, но кому ж сейчас легко.
Вчера посмотрел видео, из которого узнал, что для движков больше важно количество вертексов, а не поликов. Также прозрел от следующей инфы: из-за групп сглаживания это количество может значительно вырасти после экспорта модели в движок. Век живи, век учись!
В двух словах о проблеме.
Например, у нас есть такой объект, к которому применены 2-е группы сглаживания. Сейчас у него 6 вертексов, но после экспорта их станет условно 8 - в отмеченных точках они будут дублироваться. Имхо, это странно и тем не менее нам-моделерам от этого никуда не деться, пока программеры что-то не придумают.
Посмотрел и задумался: "Ок, если есть такая бяка, значит ее и обойти можно. Вопрос: как?" В итоге вспомнил, что решение точно есть - когда-то мне попадалась одна моделька.
Она была ничем не примечательная, если бы не один момент: к ней полностью была применена только одна гр.сгл. и при этом геометрия сглаживалась только в нужных местах.
"Вот так номер!" - подумал тогда я и сразу начал ломать себе голову, пытаясь найти ответ на вопрос "Каким же макаром это все провернули?
".Анализировал, сравнивал, танцевал шаманские танцы и все мимо. У меня ничего не получилось и я оставил эту затею. Тем более для рендеров в принципе это не сильно было важно.
Сейчас ситуация изменилась и проблема стала ребром.
Вчера ночью снова возобновил поиски - повторный анализ ни к чему естественно не привел. Однако на глаза попалась одна интересная штука. На каком-то форуме (через Гугл) нашел проблему - ребята там исправляли какие-то косяки с помощью модификатора Edit Normals. Дай думаю посмотрю, что за фрукт.
Открываю и вижу "непонятные" кнопочки: "А что будет, если я нажму сюда?" И что вы думаете? Эврика - загадка разгадана и лекарство кажется найдено!
Сегодня еще раз пощупал - вроде бы работает.
"Труба" видео подпортила, сорри за качество.
Для понимания процесса: в моде Edit Normals я юзаю кнопки "Break" и "Reset" - для уничтожения сглаживания и его восстановления соответственно.Способ конечно немного корявый:
1. Редактить таким образом сглаживание желательно только финальную модель, т.к. любые изменения геометрии приводят к косякам в сглаживании и их нужно править повторно. В видео это есть на примере арки.
2. Второго момента нет. Применение к геометрии 100500 мод-слоев будет затруднительно. Например, когда вешаем поверх уже отредактированной болванки тот же Edit Poly, то эффект наших настроек сбрасывается. Увы, п.1 - это аксиома.
3. Иногда почему-то внутри модификатора криво работает выделение через Ctrl , но это скорее всего максовский глюк.
В теории метод может стать для геймдева "лекарством от экспортного дублирования". На практике - не знаю.
В каком-либо движке не тестил, но уже есть мысль ломать все свои заготовки, которые сейчас делаю-переделываю.
Поэтому, эксперты по движкам, очень прошу вас при наличии свободного времени провести плиз доп.тест и дать фидбек: адекватность экспорта такой геометрии (особенно интересуют нормали "Что с ними происходит?"), реакция на освещение ("Возникают ли побочные эффекты?") и главное - просчет ("Проблема с дубляжом решена в связи с единственной гр.сгл.?").
Придется вас разочаровать, этот способ на выходе создает то же самое что и группы сглаживания. Я думаю вы заметили что после Edit Normals у вас вместо одной нормали получается несколько. Так вот, сколько нормалей - столько и вершин, у одной вершины не может быть несколько нормалей. Избежать "лишних" вершин можно с помощью карты нормалей.
Желательно чтобы все полигоны модели принадлежали группам, отсутствие групп может означать как и единственную "группу", так и то что у каждого полигона своя "группа", и у вас могут быть лишние вершины там где это совсем не нужно. Можно конечно это проконтролировать с помощью Edit Normals, но зачем усложнять все.
Блин, никак из головы не шла эта мысль и появилась зацепка.
Итак мы знаем, что движок реагирует на нормали при подсчете и множит вертексы не просто так. Соответственно в теории привязывается он именно к "лучам" - направляющим нормалей. Т.е. сколько их в точке, столько и вершин посчитает. Иначе этого не происходило бы на практике.
Например, у нас есть 3 грани с таким же количеством групп сглаживания.
В отмеченной точке движок нам создаст 3 условных вертекса.
Отсюда задумался: "А что будет, если свести эти 3 направляющие "в ноль" - предположим вручную?"
Самое удивительное, что ничего не произойдет и движок нам все-равно посчитает 3 вертекса.
Решение снова пришло методом научного тыка. Взял ту же фигуру и применил к ней 1 группу.
Думал, что в отмеченной точке у нас будет "Nescafe 3 в 1". Каково было мое удивление, когда дернул эту направляющую...
Получается следующее: при наличии общей гр.сгл. все направляющие нормалей в каждой соответствующей точке колапсятся.
Если бы этого не происходило, а лишь сводилось бы "в ноль", то после экспорта в движок каждый вертекс нашей геометрии множился бы в том количестве, сколько у него полюсов.
Например, создали цилиндр (sides=30), свели крышки в центре и закинули в движок. В итоге мы получили бы 300 вертексов: по 30 в центре крышек и еще по 4 в каждой точке окружностей.
Кроме того, если взять 1-ю фигуру и попробовать сколапсить лучи (нажать Reset), то у нас ничего не получится. Это фиксируется на уровне групп. Break, который разбивает лучи, тоже ничего не даст, т.к. уже получили максимум направляющих.
Это и есть зацепка: если в алгоритме просчета попробовать каким-то образом исключить привязку к направляющим нормалей или перекрыть этот побочный эффект от просчета сглаживания какой-то новой переменной, то дубляж может быть исправлен.
P.S. Вспомнил ситуацию. Когда-то давно мне в больничке, еще мальчишке, классный молодой врач толково объяснил почему такой список лекарств:
1. твой вирус убиваем мощным антибиотиком;
2. для поддержки ослабленного организма глюкоза с иммун.препаратами;
3. от кашля амброксол;
4. астматику устраним кетотифеном;
5. колес много - может быть аллергия, глотай диазолин;
6. кроме этого нужно вылечить еще кучу симптомов и предотвратить последствия от лекарств - шуруй в аптеку, пацан.
Итак мы знаем, что движок реагирует на нормали при подсчете и множит вертексы не просто так. Соответственно в теории привязывается он именно к "лучам" - направляющим нормалей. Т.е. сколько их в точке, столько и вершин посчитает. Иначе этого не происходило бы на практике.
Например, у нас есть 3 грани с таким же количеством групп сглаживания.
В отмеченной точке движок нам создаст 3 условных вертекса.
Отсюда задумался: "А что будет, если свести эти 3 направляющие "в ноль" - предположим вручную?"
Самое удивительное, что ничего не произойдет и движок нам все-равно посчитает 3 вертекса.
Решение снова пришло методом научного тыка. Взял ту же фигуру и применил к ней 1 группу.
Думал, что в отмеченной точке у нас будет "Nescafe 3 в 1". Каково было мое удивление, когда дернул эту направляющую...
Получается следующее: при наличии общей гр.сгл. все направляющие нормалей в каждой соответствующей точке колапсятся.
Если бы этого не происходило, а лишь сводилось бы "в ноль", то после экспорта в движок каждый вертекс нашей геометрии множился бы в том количестве, сколько у него полюсов.
Например, создали цилиндр (sides=30), свели крышки в центре и закинули в движок. В итоге мы получили бы 300 вертексов: по 30 в центре крышек и еще по 4 в каждой точке окружностей.
Кроме того, если взять 1-ю фигуру и попробовать сколапсить лучи (нажать Reset), то у нас ничего не получится. Это фиксируется на уровне групп. Break, который разбивает лучи, тоже ничего не даст, т.к. уже получили максимум направляющих.
Это и есть зацепка: если в алгоритме просчета попробовать каким-то образом исключить привязку к направляющим нормалей или перекрыть этот побочный эффект от просчета сглаживания какой-то новой переменной, то дубляж может быть исправлен.
P.S. Вспомнил ситуацию. Когда-то давно мне в больничке, еще мальчишке, классный молодой врач толково объяснил почему такой список лекарств:
1. твой вирус убиваем мощным антибиотиком;
2. для поддержки ослабленного организма глюкоза с иммун.препаратами;
3. от кашля амброксол;
4. астматику устраним кетотифеном;
5. колес много - может быть аллергия, глотай диазолин;
6. кроме этого нужно вылечить еще кучу симптомов и предотвратить последствия от лекарств - шуруй в аптеку, пацан.
Если три объекта поставить в одну точку, то всё равно останется три объекта, здесь нет ничего удивительного.
Про группы сглаживания я вам говорил, но то же самое можно сделать и с помощью Edit Normals, внимательно изучите этот инструмент.
Ничего не получится, потому что это делает не Reset, а другая кнопка.
И еще... Вы упускаете одну важную деталь, из-за этого на вашем первом изображении Посмотреть вложение 199188 в указанной точке может быть 4, 5 или даже 6 нормалей. Попробуйте догадаться почему.
Это далеко не всё что я хотел сказать, остальное позже, а может вы и сами наконец поймете.
Про группы сглаживания я вам говорил, но то же самое можно сделать и с помощью Edit Normals, внимательно изучите этот инструмент.
Ничего не получится, потому что это делает не Reset, а другая кнопка.
И еще... Вы упускаете одну важную деталь, из-за этого на вашем первом изображении Посмотреть вложение 199188 в указанной точке может быть 4, 5 или даже 6 нормалей. Попробуйте догадаться почему.
Это далеко не всё что я хотел сказать, остальное позже, а может вы и сами наконец поймете.
это может происходить, если там не сшиты вершины.. верно?)
то, что на уровне моделинга не выкрутиться - понял сразу.. спасибо и вам, и еще одному человеку, за потраченное время на разъяснение.. без этой вводной не смог бы решить задачу)
вчерашний эксперимент у меня закончился очередной головоломкой: "К каким же формулам можно свести весь код просчета?"
Сегодня утром не успел дойти до балкона, как меня осенило.)
Скорее всего, исходя из того, что мы получаем на практике, весь алгоритм просчета можно свести к такому уравнению: 1х=1х, где х - это переменная возможного количества направляющих нормалей одного вертекса, а 1 - их минимальное значение. Все логично, математически верно и движок считает "правильно" - как написали, так и считает.
Однако на выходе мы не получаем нужную единицу в правой части уравнения, которая отвечает за количество вертексов - отсюда дубляж. Поэтому для исправления ошибки, можем пойти двумя путями:
1. Перекрытие. Можем не трогать код и ввести в него новую переменную, которая будет нейтрализовать предыдущее. В итоге получаем вот такую штуку: 1х=1х/х. Последняя переменная является нейтрализатором и на финише в правой части мы получим важную нам единицу.
2. Исключение. Можем не добавлять, а заняться исправлением кода, убрав одну переменную, чтобы в итоге получить такое: 1х=1.
Математики за такие уравнения сразу сжигают на костре. Поскольку при подмене "х" любым значением мы получим неравенство, т.е. вместо "=" нужно ставить "≠". Но! Это один из тех случаев, когда ошибка в самом уравнение приведет к положительному результату и движки будут выдавать нам правильное количество вертексов.
то, что на уровне моделинга не выкрутиться - понял сразу.. спасибо и вам, и еще одному человеку, за потраченное время на разъяснение.. без этой вводной не смог бы решить задачу)
вчерашний эксперимент у меня закончился очередной головоломкой: "К каким же формулам можно свести весь код просчета?"
Сегодня утром не успел дойти до балкона, как меня осенило.)
Скорее всего, исходя из того, что мы получаем на практике, весь алгоритм просчета можно свести к такому уравнению: 1х=1х, где х - это переменная возможного количества направляющих нормалей одного вертекса, а 1 - их минимальное значение. Все логично, математически верно и движок считает "правильно" - как написали, так и считает.
Однако на выходе мы не получаем нужную единицу в правой части уравнения, которая отвечает за количество вертексов - отсюда дубляж. Поэтому для исправления ошибки, можем пойти двумя путями:
1. Перекрытие. Можем не трогать код и ввести в него новую переменную, которая будет нейтрализовать предыдущее. В итоге получаем вот такую штуку: 1х=1х/х. Последняя переменная является нейтрализатором и на финише в правой части мы получим важную нам единицу.
2. Исключение. Можем не добавлять, а заняться исправлением кода, убрав одну переменную, чтобы в итоге получить такое: 1х=1.
Математики за такие уравнения сразу сжигают на костре.
Поскольку при подмене "х" любым значением мы получим неравенство, т.е. вместо "=" нужно ставить "≠". Но! Это один из тех случаев, когда ошибка в самом уравнение приведет к положительному результату и движки будут выдавать нам правильное количество вертексов.