не имел дело с пико, но думаю там должен быть резистор между ногой и светодиодом - можно перепаять на больший номинал и сделать свечение тише. Или выпаять вообще. А пику можно куском оргстекла закрыть, для сохранения аутентичности :)
насчет семи кадров на первом запуске - скорее всего они продолжают компилировать шейдера для игры, но это только предположение из знакомства с Юнити, в саму игру даже не играл.
В более старых версиях юнитаска, может? Потому что UniTask не является частью юнити. По теме - лучше сразу повесить AsyncDestroyTrigger на компонент, потому что TryGetComponent это еще ничего, а вот AddComponent уже побольнее будет
SO вам подтянет все зависимости которые вы в нем укажете - все иконки, конфиги и другие ресурсы, которые вы возможно в будущем захотите в этом конфиге описывать. Даже те, которые не нужны, например прошедшие миссии. Не страшно, если миссий 5-10. А если 50-100? Все это будет в памяти. Так что как минимум для самих СО конфигов стоит предусмотреть загрузку по требованию, хотя бы из ресурсов, а лучше из бандлов/аддрессаблов.
немного не по теме статьи, но папку Resources лучше не использовать вообще. Мало того, что оно плохо контролируема, и туда вероятно попадает много лишнего, так и при большом количестве файлов замедляется запуск приложения, из-за индексации всего содержимого. После появления Addressables стало намного проще организовывать локально подгружаемые ресурсы, и к тому же в любой момент можно все перенести на CDN без переработки кода. В конце концов, можно и бандлами ограничиться, если захочется чуть производительности сэкономить и отказаться от Addressables
Вообще, в контексте "Размера билда Юнити", хотелось увидеть что-то более неожиданное, как например уменьшение размера даже пустого билда, путем пересмотра содержимого PackageManager, или еще каких-нибудь грязных трюков :)
что-то мне думается, что вы не правы насчет того, что если анимации лежат по разным fbx, то это увеличит размер билда. Не fbx ведь в билд попадает, а импортированные Юнити и конвертированные бинарные данные из него - отдельно меши и анимации, в зависимости от того что вы используете в сценах/префабах. Из FBX с анимацией в билд попадут только анимационные клипы, на которые будет ссылаться ваш Animator/Animation.
Если я буду вращать ручку яркости своего светильника с постоянной скоростью, я ожидаю такое же изменение и яркости (в моих глазах, а не на графике прибора)
Тогда может подскажете алгоритм гамма коррекции на пассивных элементах?
Я понимаю, что воспроизвести линейную яркость (да, именно речь про человеческий глаз, а не показания приборов) проще и может даже дешевле на тиньке какой сделать, но вот просто любопытно, насколько это реально. А поскольку мои знания в электронике ограничиваются повторением готовых схем, давно ищу людей понимающих, которые возможно задавались таким же вопросом))
все просто - идеального белого в природе не существует
не имел дело с пико, но думаю там должен быть резистор между ногой и светодиодом - можно перепаять на больший номинал и сделать свечение тише. Или выпаять вообще.
А пику можно куском оргстекла закрыть, для сохранения аутентичности :)
Очень вдохновила, спасибо
насчет семи кадров на первом запуске - скорее всего они продолжают компилировать шейдера для игры, но это только предположение из знакомства с Юнити, в саму игру даже не играл.
Home Assistant
В более старых версиях юнитаска, может? Потому что UniTask не является частью юнити.
По теме - лучше сразу повесить AsyncDestroyTrigger на компонент, потому что TryGetComponent это еще ничего, а вот AddComponent уже побольнее будет
Класс!
А меня все не оставляет идея сделать что-то подобное из сантеха)
Прочитал статью, и как-то вообще фотки не задели, в отличие от вашего токсичного комментария. А вот статью нашел для себя полезной.
Вот да. Сейчас, когда все больше появляется моделей с беспроводными зарядками, уже не хочется лишний раз расшатывать разъем на телефоне.
SO вам подтянет все зависимости которые вы в нем укажете - все иконки, конфиги и другие ресурсы, которые вы возможно в будущем захотите в этом конфиге описывать. Даже те, которые не нужны, например прошедшие миссии. Не страшно, если миссий 5-10. А если 50-100? Все это будет в памяти. Так что как минимум для самих СО конфигов стоит предусмотреть загрузку по требованию, хотя бы из ресурсов, а лучше из бандлов/аддрессаблов.
У меня на флешке в машине саундтреки из ГТА с 3й по Сан Андреас, приходится себя мысленно заставлять не ездить по тротуарам.
и Shenzhen IO
немного не по теме статьи, но папку Resources лучше не использовать вообще. Мало того, что оно плохо контролируема, и туда вероятно попадает много лишнего, так и при большом количестве файлов замедляется запуск приложения, из-за индексации всего содержимого. После появления Addressables стало намного проще организовывать локально подгружаемые ресурсы, и к тому же в любой момент можно все перенести на CDN без переработки кода. В конце концов, можно и бандлами ограничиться, если захочется чуть производительности сэкономить и отказаться от Addressables
Вообще, в контексте "Размера билда Юнити", хотелось увидеть что-то более неожиданное, как например уменьшение размера даже пустого билда, путем пересмотра содержимого PackageManager, или еще каких-нибудь грязных трюков :)
что-то мне думается, что вы не правы насчет того, что если анимации лежат по разным fbx, то это увеличит размер билда. Не fbx ведь в билд попадает, а импортированные Юнити и конвертированные бинарные данные из него - отдельно меши и анимации, в зависимости от того что вы используете в сценах/префабах. Из FBX с анимацией в билд попадут только анимационные клипы, на которые будет ссылаться ваш Animator/Animation.
вот, если не сочтут за рекламу, инженер Яндекс станции как раз рассказывает как добивался плавного изменения яркости светодиода:
Видео с YouTube
Это наверно самый очевидный и верный подход :)
Если я буду вращать ручку яркости своего светильника с постоянной скоростью, я ожидаю такое же изменение и яркости (в моих глазах, а не на графике прибора)
Я под яркостью понимаю то что под яркостью понимает среднестатистический пользователь)
Тогда может подскажете алгоритм гамма коррекции на пассивных элементах?
Я понимаю, что воспроизвести линейную яркость (да, именно речь про человеческий глаз, а не показания приборов) проще и может даже дешевле на тиньке какой сделать, но вот просто любопытно, насколько это реально. А поскольку мои знания в электронике ограничиваются повторением готовых схем, давно ищу людей понимающих, которые возможно задавались таким же вопросом))