Давайте считать вместе. Сколько метров антенны можно намотать вокруг несущих конструкций чемодана, или, скажем, вдоль его жёсткой спинки? Я думаю, метра три. Пусть, скажем, даже приведённая оценка в 0.7мВт на метр антенны завышена на порядок (особенно с учётом разных преобразователей и прочих потерь) — тогда мощность устройства будет 0.0021 Вт. За час работы такое устройство, соответственно, произведёт ~7.56 Ватт-часов энергии. Цифра выглядит как-то даже слишком солидно. Где у нас с Вами ошибка?
Самый обычный, не оптимизированный по критерию энергоэффективности модуль GPS в активном режиме потребляет ~25мА при 3В питании. Миниатюрный модуль GSM — примерно 0.3А при работе на передачу при схожем питании, и какие-то крохи в дежурном режиме. Но это — режим активного "маякования", который может включаться ненадолго и раз в 6 / 12 / 24 часа. Собственно, в остальном время можно спокойно и подзаряжать наш суперконденсатор. Хотя тут может возникнут энное количество проблем, признаю.
Кстати, интересно было бы увидеть соображения по плотности энергии для плоских антенн.
Можно поставить какой-нибудь ионистор, а в дополнение — собрать схему вроде вот такой, обеспечивающей мал-мало питания от радиоволн любого подходящего диапазона. Питания схема даёт негусто, но стабильно и в любом месте.
Можно отключить объект целиком. Тогда не идёт его отрисовка, не осуществляется обновление для скриптов поведения, не рассчитывается физика, и так далее. Идея с отключение отдельных компонентов — хорошая, но с ней очень просто запутаться при настройке (хотя я и думал о таком функционале). Потому я сделал ассет так, чтобы объект деактивировать целиком. Условия деактивации задаёт левел-дизайнер: например, монстры могут деактивироваться чтобы при достаточном удалении игрока от комнаты, где они спавнятся, а разрушаемые предметы — при выходе их из зоны видимости игрока. Соответственно, активируется они при приближении игрока и возвращении в зону видимости соответственно. Это просто и довольно надёжно.
P.S. Если есть интерес, напишите в личку — могу сбросить посмотреть сам ассет :)
В первую очередь, я отключаю объекты со сложными и/или ресурсоёмкими скриптами — это, в основном, персонажи и противники, особо мудрёные интерактивные объекты уровня, даже интерактивные двери и тому подобное. Пробую отключать объекты со сложной постоянно обсчитываемой физикой, но пока однозначного ответа, стоит ли это делать, не могу дать. Отключать сложные для рендера объекты реального смысла нет — с этим хорошо справляются встроенные механизмы движка, отсечение невидимых граней и OC — с ними не попадающее в кадр просто не рендерится.
Но не всё так просто — например, если враг зашёл за спину героя, то он должен напроситься на него сзади, а не остановиться, пропав из поля зрения камеры. С этим пришлось потрудиться, но решение нашлось :)
О! Я как раз писал для Unity ассет, который (по-умному) отключает объекты за пределами области видимости. По опыту — совет дельный, производительность подскакивает довольно круто — однако, существуют проблемы с увязкой логики и с интеграцией Occlusion Culling. Другое дело, что реализовывать это лучше централизованным менеджером, так достигается экономия и на числе вызовов update.
Тебе платят солидные деньги за то, чтобы ты сделал свою работу, но при этом в итоге ты делаешь так, как нравится дяде в малиновом пиджаке. Нет на российском рынке людей, которые бы могли признать, что кто-то может лучше разбираться в рекламе и маркетинге, чем они. Ведь это презренная профессия — пиарщик. В сознании масс руководителей, это профессия для тех, кто умеет просто громко кричать.
Напомнило одну историю родом из ранних 2000-х. У знакомых была маленькая полиграфическая фирма, с невесть откуда взятым названием «Викман», размещавшаяся почти в центре Москвы в маленьком подвале. Рекламу фирма активно давала в газеты-журналы, а ещё выставляла на улицу штендеры и имела небольшую вывеску-выноску — место было людное, и примерно половина визитёров приходила именно по уличной рекламе.
Прибыль была устойчивая, но какая-то не очень большая.
Появился «маркетолог». Туда-сюда побродил, во все мониторы поглядел, в затылке почесал, мозгами поскрипел — и кааак сгенерирует! Говорит, фирме нужно новое, привлекающее людей название, и много-много вкусной рекламы с ним! А фирма должна будет назваться «Почему слоны?». Ему — «мил человек, а не диковато ли это малость? может, что-то более… ну… традиционное?»
Маркетолог в ответ заявил — вы все ничего не понимаете в агрессивном продвижении, это же XXI век, вызывающая реклама! Доверьтесь, и будут вам толпы клиентов перед дверью. Ладно, фиг с тобой — увешались слонятками, дали во все концы новую мощную рекламу.
И что бы вы думали? Ни-че-го. Ноль звонков. Конверсия газетной рекламы упала до математически идеального нуля. За время рекламы по объявлениям не позвонил абсолютно никто. Хоть бы телефонные хулиганы для разнообразия поинтересовались, а почему, собственно, слоны. Число клиентов, соответственно, уменьшилось вдвое.
Маркетолог, считавший, что разбирается в рекламе лучше, был шустро изгнан, а «дяди в малиновых пиджаках» обратно назвали фирму непритязательным «Викманом», дали свою обычную скучную рекламу — и дело вновь закрутилось в прежних рамках.
Так что я могу понять, почему заказчик стремится иногда поуправлять маркетологом :)
Как человек, пересевший при присоединении к крупному проекту с Mercurial на Git — могу сказать, что именно степень недружелюбности Git-а к начинающему (что консольного, что GUI) после простого, понятного и наглядного TortoiseHg стала для меня шоком. В Mercurial я «сел и поехал» во многом именно благодаря хорошему «изкоробочному» GUI, а вот вникание в Git было затруднительным. Был бы внятнее пользовательский интерфейс — переход прошёл бы гораздо легче.
Мне очень помог на первых порах SmartGit — по сути, это аналог TortoiseHg, только существенно более продуманный. Идеи Tortoise получили своё развитие — например, возможность в интерактивном режиме делать этакий микро-diff, просматривая в небольшом окошке текущие изменения в проекте, отмечая для себя важные изменения, перенося или удаляя незакомиченные правки — это чудесное изобретение! Можно также смотреть, что за команда передаётся непосредственно бинарнику git при совершении того или иного действия. Да сложную Гит-магию в SmartGit сделать затруднительно, но для 90% простых задач обращаться к консоли, по сути, и не приходится.
Моя основная мысль не в QString — его я привёл как пример — а в том, есть ли КРУПНЫЙ выигрыш от написания, а потом таскания за собой толстого велосипеда. Жизнь слишком коротка для такой "экономии на спичках" путём выпиливания их вручную из цельного массива сосны :)
P.S. Весь Qt, кстати, тащить не надо — ЕМНИП, хватает Core, в котором при этом много и других полезных штук. Ужасы же copy-on-write, как по мне, сильно преувеличены. Основные статьи идеологов борьбы с COW относятся к нулевым, причём рассматривают не самые жизненные ситуации. На многоядерных процессорах COW, несомненно, даёт проигрыш при частых операциях, касающихся необходимости соблюдения atomic — но я совсем не уверен, что этот проигрыш нынче так велик, каким он выглядел в том десятилетии. Вопрос интересный, хотелось бы провести парочку синтетических тестов.
AString… автору, конечно, виднее, но как-то не совсем ясно, почему нельзя обойтись готовыми реализациями строк. Что за специфические требования к работе с памятью такие? std::string не всем удобен, могу согласиться — но почему бы тогда не использовать что-нибудь вроде QString из состава Qt?
Думаю, опыт обслуживания механики, работающей десятки или уже сотни лет без остановки, у человечества есть. Биг Бэн, к примеру. Или — по недавно прочитанному — в МБР семейства Минитмен стоят гироскопы, где узлы повышенного трения выполнены из рубина. Это сделано потому, что когда Минитмены разрабатывались, не умели делать быстро приводимые в действие гироскопы, и перед запуском автоматике их надо было долго и мучительно раскручивать — а ракета должна быть готова к запуску сразу же, через минуты после приказа. Принятое решение было непростым. И теперь за счëт "рубинового" подвеса гироскопы работают на максимальных оборотах без остановки весь срок стояния ракеты на боевом дежурстве, не нуждаясь ни в какой в предварительной раскрутке. Электричества, полагаю, это жрëт массу… но, вероятно, до сих пор (чуть меньше полувека?) в таком варианте система может стоять на вооружении, а гироскопы — наматывать обороты тысяча за тысячей.
В этом-то и проблема — мозг воспринимает ситуацию с возможностью ВНЕЗАПНОГО появления наблюдателей и критики посреди мыслительного процесса как тревожную. Это как знать (простите за неприятную аналогию), что, посреди посещения санузла, в Вашу кабинку может распахнуться дверь и ворваться с проверкой наряд полиции. Вроде и ничего стыдного в посещении уборной нет, и задержать Вас не за что — а всё равно расслабиться и сосредоточиться уже не получится.
P.S. Переговорных нет. Всё огромное крыло этажа, по сути, одна большая комната. И так всё здание: мега-комнаты порой не отделены от коридоров ничем. Старая планировка — она вроде ада для интровертов :) для личных разговоров по телефону едва не на крышу порой приходится выбираться :)
Вот интересно, у меня ли одного так, но почему-то, когда на работе нечего делать, не выходит заняться чем-то полезным по-настоящему эффективно. Вокруг на работе сидит множество людей, и даже если они ведут себя спокойно, не говорят громко и не ходят рядом, мозг всё равно не желает переходить в состояние «сядем и спокойно всё обдумаем». Мозг вместо этого работает в режиме «бей или беги» — или бери и немедленно педалируй не требующую обдумывания задачу (двигай кнопки, пиши 125-ю необязательную форму...), или залипай без дела в интернетах.
Вот и залипаешь. Вдумчиво отстраниться и заняться, например, самообучением не выходит.
Причём вроде бы никто и не надзирает с хлыстом за процессом твоего самосовершенствования, и ругать не будут, но в воздухе висит некое чувство… незащищённости от внезапного прерывания мыслительно-экспериментаторского процесса на самом уязвимом месте и внезапной критики, что ли. И вроде бы даже никто не умрёт, если товарищ выпрыгнет из-за монитора и ехидно спросит — «ну-у, и что это мы такое тут программируем?» (а некоторых хлебом не корми, дай только так выпрыгнуть) — но всё равно искра желания заняться полезной деятельностью гаснет при подобной мысли.
С таким — как бороться?
Backface culling я и имел в виду. Если модели сделаны по уму, импортированы верно, и полигоны не double-sided, то дальние заслонëнные грани объекта будут отброшены и не нарисуются. Это копеечная по трудоëмкости операция, и Юнити это делает, да.
Про память — разговор особый. По статье просто так читается, что именно отрисовка и оптимизируется. Про загрузку шины памяти — вот это надо обдумать. Велик ли импакт на рядовых мобильных моделях?
Но разве этим стандартные механизмы culling-а движка не занимаются? Отсечение невидимых вершин — то, что базово умеют все игровые движки уже лет 10.
Интересно было бы увидеть сравнение производительности с и без Вашего механизма.
P.S. Для Unity есть гораздо более эффективный способ оптимизации — отключать скрипты невидимым игроку объектам. Когда объект не в кадре — он не рисуется, но его физика работает, коллизии считаются, скрипты действуют, и всë это бодро кушает ресурсы. Большие движки раньше умели это отключать, а вот Unity не умеет. Я написал крохотный оптимизатор, который это всë делает (можно выборочно и при определëнных условиях). В нагруженных сценах даëт прирост до 20%. Могу поделиться наработками по этому методу, если интересно :)
Вообще, дыр, судя по всему, огромное количество. Страшно подумать, что будет, если это начнут ковырять всерьёз. Меня, в своё время, впечатлило вот это (перекликается с темой статьи, кстати).
Очень просто получить «быстрый старт» с чего-то, имеющего вменяемый и доступный GUI, типа SmartGit. Я вот начинал знакомство с системы контроля версий Mercurial, к которой по умолчанию прилагается неплохой такой GUI-клиент TortoseHg. Не пир духа, но, ИМХО, гораздо вменяемее «изкоробочного» git gui. ЕМНИП, покорило то, что диффы представлены в максимально наглядном (читай «и дураку понятном») виде, можно поправить файлы оттуда же перед коммитом, и, что особо ценно, можно откатить изменения одной-двух строк, а не всего файла.
Когда я начал работать там, где Git был стандартом (и особо в чести была консольная работа с ним), то — после неудачного эксперимента по спариванию разных систем контроля версий при помощи бриджей (ещё то извращение, бррр!) — я долго выл на тему «изверги, неудобно же без визуальных плюшек!».
А потом мне дали SmartGit. Он покрывает 95% джуновских потребностей в Гите и 60-70% потребностей сеньора. Сложные и замороченные вещи в нём делать сложно, зато простые вещи — очень и очень просто. Как показал опыт — новые бойцы втягиваются в Гит где-то после часа инструктажа по интерфейсу SmartGit, и новых проблем (при условии адекватности бойца) он сам по себе создавать не склонен. Рекомендую!
Дома хранятся сотни дисков разного возраста, качества и происхождения. Хранится, кажется, даже что-то досовских времён. Иногда, под настроение, кое-что из коллекции достаётся, обдувается, ставится и перепроходится. Недавно вот прошёл первую Majesty с замечательной пиратской локализацией, бегающей даже под Семёрку (что удивительно, ибо оригинал вроде не способен) под звуки тёплой и ламповой CD-музыки. Шуршание диска в приводе, когда начинается новая дорожка… да и само удовольствие от обладания физической копией… таких приятных мелочей не хватает нынешним Стимовским играм.
Вот я долго думаю — а как её, собственно, выкидывать иначе? Даже если представить, что в округе появятся пункты раздельного сбора мусора — то как организовать этот самый сбор дома? Иметь на кухне три-четыре разных мусорных ведра? Я видел кухни площадью в 2 квадратных метра, где человек-то умещается с трудом. Эх.
Когда-то давным-давно, во времена моего детства, это называлось CASE-системами, и было жутко перспективным… я даже сам писал такие простенькие редакторы, которые транслировали нарисованные по правилам блок-схемы в код программ для своего крооохотного интерпретируемого языка. Visual Basic 6, Win98, было время. CASE-системы нынче почти вымерли, а идея… хм… до сих пор жутко перспективна :)
Давайте считать вместе. Сколько метров антенны можно намотать вокруг несущих конструкций чемодана, или, скажем, вдоль его жёсткой спинки? Я думаю, метра три. Пусть, скажем, даже приведённая оценка в 0.7мВт на метр антенны завышена на порядок (особенно с учётом разных преобразователей и прочих потерь) — тогда мощность устройства будет 0.0021 Вт. За час работы такое устройство, соответственно, произведёт ~7.56 Ватт-часов энергии. Цифра выглядит как-то даже слишком солидно. Где у нас с Вами ошибка?
Самый обычный, не оптимизированный по критерию энергоэффективности модуль GPS в активном режиме потребляет ~25мА при 3В питании. Миниатюрный модуль GSM — примерно 0.3А при работе на передачу при схожем питании, и какие-то крохи в дежурном режиме. Но это — режим активного "маякования", который может включаться ненадолго и раз в 6 / 12 / 24 часа. Собственно, в остальном время можно спокойно и подзаряжать наш суперконденсатор. Хотя тут может возникнут энное количество проблем, признаю.
Кстати, интересно было бы увидеть соображения по плотности энергии для плоских антенн.
P.S. Если есть интерес, напишите в личку — могу сбросить посмотреть сам ассет :)
В первую очередь, я отключаю объекты со сложными и/или ресурсоёмкими скриптами — это, в основном, персонажи и противники, особо мудрёные интерактивные объекты уровня, даже интерактивные двери и тому подобное. Пробую отключать объекты со сложной постоянно обсчитываемой физикой, но пока однозначного ответа, стоит ли это делать, не могу дать. Отключать сложные для рендера объекты реального смысла нет — с этим хорошо справляются встроенные механизмы движка, отсечение невидимых граней и OC — с ними не попадающее в кадр просто не рендерится.
Но не всё так просто — например, если враг зашёл за спину героя, то он должен напроситься на него сзади, а не остановиться, пропав из поля зрения камеры. С этим пришлось потрудиться, но решение нашлось :)
Напомнило одну историю родом из ранних 2000-х. У знакомых была маленькая полиграфическая фирма, с невесть откуда взятым названием «Викман», размещавшаяся почти в центре Москвы в маленьком подвале. Рекламу фирма активно давала в газеты-журналы, а ещё выставляла на улицу штендеры и имела небольшую вывеску-выноску — место было людное, и примерно половина визитёров приходила именно по уличной рекламе.
Прибыль была устойчивая, но какая-то не очень большая.
Появился «маркетолог». Туда-сюда побродил, во все мониторы поглядел, в затылке почесал, мозгами поскрипел — и кааак сгенерирует! Говорит, фирме нужно новое, привлекающее людей название, и много-много вкусной рекламы с ним! А фирма должна будет назваться «Почему слоны?». Ему — «мил человек, а не диковато ли это малость? может, что-то более… ну… традиционное?»
Маркетолог в ответ заявил — вы все ничего не понимаете в агрессивном продвижении, это же XXI век, вызывающая реклама! Доверьтесь, и будут вам толпы клиентов перед дверью. Ладно, фиг с тобой — увешались слонятками, дали во все концы новую мощную рекламу.
И что бы вы думали? Ни-че-го. Ноль звонков. Конверсия газетной рекламы упала до математически идеального нуля. За время рекламы по объявлениям не позвонил абсолютно никто. Хоть бы телефонные хулиганы для разнообразия поинтересовались, а почему, собственно, слоны. Число клиентов, соответственно, уменьшилось вдвое.
Маркетолог, считавший, что разбирается в рекламе лучше, был шустро изгнан, а «дяди в малиновых пиджаках» обратно назвали фирму непритязательным «Викманом», дали свою обычную скучную рекламу — и дело вновь закрутилось в прежних рамках.
Так что я могу понять, почему заказчик стремится иногда поуправлять маркетологом :)
Мне очень помог на первых порах SmartGit — по сути, это аналог TortoiseHg, только существенно более продуманный. Идеи Tortoise получили своё развитие — например, возможность в интерактивном режиме делать этакий микро-diff, просматривая в небольшом окошке текущие изменения в проекте, отмечая для себя важные изменения, перенося или удаляя незакомиченные правки — это чудесное изобретение! Можно также смотреть, что за команда передаётся непосредственно бинарнику git при совершении того или иного действия. Да сложную Гит-магию в SmartGit сделать затруднительно, но для 90% простых задач обращаться к консоли, по сути, и не приходится.
Моя основная мысль не в QString — его я привёл как пример — а в том, есть ли КРУПНЫЙ выигрыш от написания, а потом таскания за собой толстого велосипеда. Жизнь слишком коротка для такой "экономии на спичках" путём выпиливания их вручную из цельного массива сосны :)
P.S. Весь Qt, кстати, тащить не надо — ЕМНИП, хватает Core, в котором при этом много и других полезных штук. Ужасы же copy-on-write, как по мне, сильно преувеличены. Основные статьи идеологов борьбы с COW относятся к нулевым, причём рассматривают не самые жизненные ситуации. На многоядерных процессорах COW, несомненно, даёт проигрыш при частых операциях, касающихся необходимости соблюдения atomic — но я совсем не уверен, что этот проигрыш нынче так велик, каким он выглядел в том десятилетии. Вопрос интересный, хотелось бы провести парочку синтетических тестов.
Думаю, опыт обслуживания механики, работающей десятки или уже сотни лет без остановки, у человечества есть. Биг Бэн, к примеру. Или — по недавно прочитанному — в МБР семейства Минитмен стоят гироскопы, где узлы повышенного трения выполнены из рубина. Это сделано потому, что когда Минитмены разрабатывались, не умели делать быстро приводимые в действие гироскопы, и перед запуском автоматике их надо было долго и мучительно раскручивать — а ракета должна быть готова к запуску сразу же, через минуты после приказа. Принятое решение было непростым. И теперь за счëт "рубинового" подвеса гироскопы работают на максимальных оборотах без остановки весь срок стояния ракеты на боевом дежурстве, не нуждаясь ни в какой в предварительной раскрутке. Электричества, полагаю, это жрëт массу… но, вероятно, до сих пор (чуть меньше полувека?) в таком варианте система может стоять на вооружении, а гироскопы — наматывать обороты тысяча за тысячей.
P.S. Переговорных нет. Всё огромное крыло этажа, по сути, одна большая комната. И так всё здание: мега-комнаты порой не отделены от коридоров ничем. Старая планировка — она вроде ада для интровертов :) для личных разговоров по телефону едва не на крышу порой приходится выбираться :)
Вот и залипаешь. Вдумчиво отстраниться и заняться, например, самообучением не выходит.
Причём вроде бы никто и не надзирает с хлыстом за процессом твоего самосовершенствования, и ругать не будут, но в воздухе висит некое чувство… незащищённости от внезапного прерывания мыслительно-экспериментаторского процесса на самом уязвимом месте и внезапной критики, что ли. И вроде бы даже никто не умрёт, если товарищ выпрыгнет из-за монитора и ехидно спросит — «ну-у, и что это мы такое тут программируем?» (а некоторых хлебом не корми, дай только так выпрыгнуть) — но всё равно искра желания заняться полезной деятельностью гаснет при подобной мысли.
С таким — как бороться?
Backface culling я и имел в виду. Если модели сделаны по уму, импортированы верно, и полигоны не double-sided, то дальние заслонëнные грани объекта будут отброшены и не нарисуются. Это копеечная по трудоëмкости операция, и Юнити это делает, да.
Про память — разговор особый. По статье просто так читается, что именно отрисовка и оптимизируется. Про загрузку шины памяти — вот это надо обдумать. Велик ли импакт на рядовых мобильных моделях?
Но разве этим стандартные механизмы culling-а движка не занимаются? Отсечение невидимых вершин — то, что базово умеют все игровые движки уже лет 10.
Интересно было бы увидеть сравнение производительности с и без Вашего механизма.
P.S. Для Unity есть гораздо более эффективный способ оптимизации — отключать скрипты невидимым игроку объектам. Когда объект не в кадре — он не рисуется, но его физика работает, коллизии считаются, скрипты действуют, и всë это бодро кушает ресурсы. Большие движки раньше умели это отключать, а вот Unity не умеет. Я написал крохотный оптимизатор, который это всë делает (можно выборочно и при определëнных условиях). В нагруженных сценах даëт прирост до 20%. Могу поделиться наработками по этому методу, если интересно :)
Когда я начал работать там, где Git был стандартом (и особо в чести была консольная работа с ним), то — после неудачного эксперимента по спариванию разных систем контроля версий при помощи бриджей (ещё то извращение, бррр!) — я долго выл на тему «изверги, неудобно же без визуальных плюшек!».
А потом мне дали SmartGit. Он покрывает 95% джуновских потребностей в Гите и 60-70% потребностей сеньора. Сложные и замороченные вещи в нём делать сложно, зато простые вещи — очень и очень просто. Как показал опыт — новые бойцы втягиваются в Гит где-то после часа инструктажа по интерфейсу SmartGit, и новых проблем (при условии адекватности бойца) он сам по себе создавать не склонен. Рекомендую!