Он переопределит операцию сравнения вместо хеша, и у него неправильно будет работать код. Как это повлияет на работу программы?
Да как угодно:) В зависимости от того, как и зачем используется таблица:)
Согласен с вопросом. Написана дичь. Способ обхода надо выбирать в зависимости от того, как ни странно, в каком порядке вы желаете обойти граф! Внимание, любой граф, а не только дерево.
Да, для русского пользователя дороговато:)
Но это дешевле чем большая часть подобных ассетов, а разработка подобной штуки без соответствующего опыта — не меньше 80 часов займет даже зная что надо делать (очень сложно отлаживать; много платформо-зависимых штук).
Так что купить дешевле. Но если это для саморазвития — флаг вам в руки:)
P.S. Подпишитесь на меня, скоро расскажу как крутой шум генерировать.
Да, показать с разных ракурсов стоит, вы абсолютно правы:)
Сделать облако более размытым безусловно можно.
Центр не может быть прозрачным, если это происходит не засчёт fallofff, т.к. наложение двух облаков друг на друга не сделать корректным. Считайте, что тут мы делаем только кучевые облака или стелящийся туман.
Как корректно замерять производительность видеовычислений — это вообще ужасная тема, достойная отдельной статьи. Я даже не уверен что готов такую сейчас написать:)
FPS считается просто: берём время между началом кадров n и n+1. Для удобства можно строить график с указанием медианы и 95 перцентиля за последние k кадров.
Но есть одно маленькое "но": на Андроиде включен оркестратор, который, по сути, навязывает частоту обновления не более 60 кадров в секунду.
Так что если хочется посчитать производительность конкретного эффекта — у вас большие проблемы.
Я решаю эту проблему так: даю нагрузку в размере 16 МС(1 кадр при частоте 60 ФПС) и замеряют разницу между частотой кадров со включенным плагином и с выключенным.
Но на IOS такое не прокатывает — у них насильно включена вертикальная синхронизация, так что если ты не уложился в 16.6 мм, fps сразу падает до 30:)
Производительность не зависит от покрытия экрана туманом/облаками (Кстати, я этого не упомянул, но все операции до момента наложения облаков на остальной мир происходят в пониженном разрешении).
Тригонометрических функций на самом деле нет:
sin(t) нет необходимости вычислять в каждом пикселе, т.к. он одинаковый => вычисляем на CPU.
cos(a) где a — угол между n и light вычисляется как dot(n, light) если n и light единичной длины.
А вообще такие функции в шейдерах и так оптимизируются через таблицы + ряды.
В ограничения по количеству операций не упираюсь, шейдеры довольно маленькие (каждая операция преобразования — 1 шейдер).
Мне кажется, это неспроста:)
В ваших комметариях альтернативные варианты не просвечивают. А ничего кроме комментариев и не видно:)
А вы, стало быть, флора?)
Да, до меня тоже.
Я сначала подумал, что Синтакс Цукор — это как Jon Skeet:)
м.б. все же дискредитируют?)
Он переопределит операцию сравнения вместо хеша, и у него неправильно будет работать код. Как это повлияет на работу программы?
Да как угодно:) В зависимости от того, как и зачем используется таблица:)
Согласен с вопросом. Написана дичь. Способ обхода надо выбирать в зависимости от того, как ни странно, в каком порядке вы желаете обойти граф! Внимание, любой граф, а не только дерево.
Спасибо за переводы.
Сложно писать так чтобы легко читалось:)
Да, тяжело читать. Zanak достаточно адекватно ответил на широкий вопрос, который можно было интерпретировать тысячей способов:)
А такого вы и не увидите в книгах по алгоритмам.
Вы можете увидеть псевдокод RSA, можете увидеть декартово дерево. Но до 1500 строк там очень далеко:)
… И вы там не найдете такого псевдокода:)
Алгоритмы обычно более короткие.
да, неплохая идея.
Если захочется сколлаборироваться/побрейнштормить/.., я в вашем распоряжении:)
Да, для русского пользователя дороговато:)
Но это дешевле чем большая часть подобных ассетов, а разработка подобной штуки без соответствующего опыта — не меньше 80 часов займет даже зная что надо делать (очень сложно отлаживать; много платформо-зависимых штук).
Так что купить дешевле. Но если это для саморазвития — флаг вам в руки:)
P.S. Подпишитесь на меня, скоро расскажу как крутой шум генерировать.
Да, показать с разных ракурсов стоит, вы абсолютно правы:)
Сделать облако более размытым безусловно можно.
Центр не может быть прозрачным, если это происходит не засчёт fallofff, т.к. наложение двух облаков друг на друга не сделать корректным. Считайте, что тут мы делаем только кучевые облака или стелящийся туман.
P.S. обожаю ваши статьи)
Как корректно замерять производительность видеовычислений — это вообще ужасная тема, достойная отдельной статьи. Я даже не уверен что готов такую сейчас написать:)
FPS считается просто: берём время между началом кадров n и n+1. Для удобства можно строить график с указанием медианы и 95 перцентиля за последние k кадров.
Но есть одно маленькое "но": на Андроиде включен оркестратор, который, по сути, навязывает частоту обновления не более 60 кадров в секунду.
Так что если хочется посчитать производительность конкретного эффекта — у вас большие проблемы.
Я решаю эту проблему так: даю нагрузку в размере 16 МС(1 кадр при частоте 60 ФПС) и замеряют разницу между частотой кадров со включенным плагином и с выключенным.
Но на IOS такое не прокатывает — у них насильно включена вертикальная синхронизация, так что если ты не уложился в 16.6 мм, fps сразу падает до 30:)
Как корректно рендерить изнутри я пока не придумал:)
Верно, плотность, динамичность и цвета настраиваются.
Я просто так вижу облака:)
Производительность не зависит от покрытия экрана туманом/облаками (Кстати, я этого не упомянул, но все операции до момента наложения облаков на остальной мир происходят в пониженном разрешении).
Тригонометрических функций на самом деле нет:
sin(t) нет необходимости вычислять в каждом пикселе, т.к. он одинаковый => вычисляем на CPU.
cos(a) где a — угол между n и light вычисляется как dot(n, light) если n и light единичной длины.
А вообще такие функции в шейдерах и так оптимизируются через таблицы + ряды.
В ограничения по количеству операций не упираюсь, шейдеры довольно маленькие (каждая операция преобразования — 1 шейдер).
А, я просто так подумал, что вы раскроете дальше ARCore:) Но перечитал и понял что будет OpenCV