Не знал, что есть такая штука, но ниже отметили, что все равно отдельный DrawCall для отдельного состояния модели.
Под объектом Я имел в виду модель в своем состоянии, не важно, каким образом она выводится.
Юнити вроде умеет батчить одинаковые материалы с одинаковыми свойствами, но изменение шейдерного юниформа (а кадр анимации получается передается через него) в любом случае меняет стейт рендера, что обрывает Draw Call.
Если честно, Я ковырялся в вопросе довольно давно, возможно в новых Api есть методы для изменения свойств материала в рамках одного кола.
Можно придумать другие хаки, например, прикрепить информацию о сдвиге по времени в пиксели модели. Но не думаю, что это серьезно поможет.
Так можно добиться, чтобы куча одинаковых моделей использовала разное время одной анимации, но при этом для изменения относительного времени нужно будет перегенерить модель, к тому же получиться больше вершинных данных — по сути каждый сдвиг будет давать новую модель.
Я бы хотел возразить по поводу модификации состояния.
Цель ОО дизайна — абстрагирование. Сделать объект с максимально простым поведением (и интерфейсом) снаружи, скрывающий сложное состояние и реализацию внутри.
Это не значит, что объект должен фанатично скрывать свое состояние и выглядеть снаружи как stateless. Частью его поведения вполне может быть то, что использующие его агенты знают его состояние и переводят объект из состояния в состояние. Важно лишь то, что для внешних агентов это делается просто и понятно.
Например объект для взаимодействия с оборудованием вполне может иметь состояния «не подключен», «подключен» и «неисправность» с описанием ошибки. Прекрасный объект, который скрывает в себе константы кодов ошибок, сложное api общения с устройством, детали подключения через usb.
В этом случае даже просто публичная переменная не является нарушением инкапсуляции — она часть публичного контракта и те, кто используют объект, о ней знают.
Геттеры сеттеры — просто сахар для того, чтобы иметь возможность сделать этот контракт безопаснее, оставить его простым снаружи (как переменная), но добавить проверку целостности, логгирование доступа и прочее внутри.
В этом смысле они не нарушают инкапсуляцию, а наоборот, являются удобным инструментом ее обеспечения.
Судя по всему это может быть ООП (а может и не быть, зависит, какой еще код будет)
Если вы будете и дальше каким то образом организовывать Person, методы работы с ним и методы поддержания согласованности в одном месте, и точно так же организовывать другие объекты, с которым работает Person или которые работают с ним — получится вполне себе ОО дизайн.
У вас будет объект Person, с которым вы будете работать через выделенный интерфейс.
Другое дело, что если у вас нет языковых инструментов, то будет тяжело провести это разграничение (его можно будет сделать только организационно) и его могут очень легко поломать.
Занятно, но так себе холст. Мерцание очень сильное.
Сами по себе базовые программистские задачи (ткань, змейка, 3д) гораздо интереснее.
Но почему бы и нет, нормальное экзотическое программирование.
С производительностью будет сравнительно плохо, разные объекты будут иметь разные материалы (разные параметры времени анимации в шейдере). Впрочем, не уверен, возможно автор в этой деме делал тоже разные материалы.
В любом случае будет радикально лучше, чем если делать это на процессоре.
Определять текущее состояние можно только по таймингу.
Состояния как такового в этой системе нет — данные о нем теряются, остается только набор анимаций, идущий подряд.
Но таймер анимации хранится в компоненте и каждый кадр растится процессором и передается в материал. Так как управляется это со стороны процессора, никто не мешает в этом компоненте сохранить диапазоны анимаций и при управлении указывать стейт, и в компоненте доставать из информации о диапазоне время.
В любом случае, этот компонент должен как то работать с этой информацией — именно он управляет зацикленностью и режимом анимаций, для шейдера это просто число от 0 до 1.
Ну можно конечно и ECS, но вообще ситуация разруливается прекрасно и в рамках ООП.
Причем можно использовать сразу несколько методов, и все будут правильными.
Нет, вроде есть и объективные проблемы, проистекающие из типичных способов организации.
Например, организация объектов по ссылкам делает объекты удобными для понимания, но недружными к кешу процессора.
Есть подходы, когда данные реорганизуют под производительность. ECS
Впрочем тяжело сказать, является это проблемой прямо ООП или его нынешних организаций.
Нет, это просто значит, что вы построили хорошую и гибкую архитектуру данных, которая позволяет отложить часть решений по дальнейшей архитектуре данных (реализацию ткацкого станка) на потом.
Но вы все еще придумали архитектуру данных завода до или вместе с кодом завода и архитектуру данных станка до или вместе с кодом станка.
В этом смысле Я пожалуй согласен со статьей — Data-First
Но в остальном так себе — соломенное чучело ООП
Ну статья про то, что не нужно возводить это в абсолют, и шум должен быть оправдан, а не вырождаться в срач и оскорбления.
Важно и то, что код читать сложнее чем писать в принципе. Поэтому любой прочитанный код зачастую хуже, чем написанный.
Радикально не соглашусь.
Код объективен лишь в том, что он, будучи скомпилированным работает и решает задачу.
Хотя в сложных кейсах и это не очевидно — редактор со сложным интерфейсом «решает» задачу редактирования, но насколько эффективно, если пользователям тяжело его понимать?
Код пишется не только для компьютеров, но и для людей.
С точки зрения разработчика все варианты решения задачи и оформления кода для этого решения — глубоко субъективны. Разные люди по разному поймут этот код, будут испытывать проблемы с пониманием в разных местах, могут считать разные места важными или не важными, по разному будут его менять. Субъективны так же варианты расширения и изменения кода при развитии — ведь они опираются на субъективные требования (пример с интерфейсом) и субъективное понимание текущей работы кода.
Гневаться на код разумеется не продуктивно, но «ругать» странную логику, плохое форматирование, сложность чтения и т.д. для того, чтобы этого избежать — вполне продуктивно.
Усилия по улучшению кода, направленные на понимание кода в будущем и разными членами команды — оправданны.
Ну цивилизация плохо симулирует важный фактор — скорость прохождения управленческих сигналов.
А вообще процесс в этом направлении и идет — посмотрите на современные страны, они довольно большие и продолжают агрегироваться, пусть и не так активно.
Под объектом Я имел в виду модель в своем состоянии, не важно, каким образом она выводится.
Юнити вроде умеет батчить одинаковые материалы с одинаковыми свойствами, но изменение шейдерного юниформа (а кадр анимации получается передается через него) в любом случае меняет стейт рендера, что обрывает Draw Call.
Если честно, Я ковырялся в вопросе довольно давно, возможно в новых Api есть методы для изменения свойств материала в рамках одного кола.
Можно придумать другие хаки, например, прикрепить информацию о сдвиге по времени в пиксели модели. Но не думаю, что это серьезно поможет.
Так можно добиться, чтобы куча одинаковых моделей использовала разное время одной анимации, но при этом для изменения относительного времени нужно будет перегенерить модель, к тому же получиться больше вершинных данных — по сути каждый сдвиг будет давать новую модель.
Цель ОО дизайна — абстрагирование. Сделать объект с максимально простым поведением (и интерфейсом) снаружи, скрывающий сложное состояние и реализацию внутри.
Это не значит, что объект должен фанатично скрывать свое состояние и выглядеть снаружи как stateless. Частью его поведения вполне может быть то, что использующие его агенты знают его состояние и переводят объект из состояния в состояние. Важно лишь то, что для внешних агентов это делается просто и понятно.
Например объект для взаимодействия с оборудованием вполне может иметь состояния «не подключен», «подключен» и «неисправность» с описанием ошибки. Прекрасный объект, который скрывает в себе константы кодов ошибок, сложное api общения с устройством, детали подключения через usb.
В этом случае даже просто публичная переменная не является нарушением инкапсуляции — она часть публичного контракта и те, кто используют объект, о ней знают.
Геттеры сеттеры — просто сахар для того, чтобы иметь возможность сделать этот контракт безопаснее, оставить его простым снаружи (как переменная), но добавить проверку целостности, логгирование доступа и прочее внутри.
В этом смысле они не нарушают инкапсуляцию, а наоборот, являются удобным инструментом ее обеспечения.
Если вы будете и дальше каким то образом организовывать Person, методы работы с ним и методы поддержания согласованности в одном месте, и точно так же организовывать другие объекты, с которым работает Person или которые работают с ним — получится вполне себе ОО дизайн.
У вас будет объект Person, с которым вы будете работать через выделенный интерфейс.
Другое дело, что если у вас нет языковых инструментов, то будет тяжело провести это разграничение (его можно будет сделать только организационно) и его могут очень легко поломать.
Сами по себе базовые программистские задачи (ткань, змейка, 3д) гораздо интереснее.
Но почему бы и нет, нормальное экзотическое программирование.
Очень бодро бегает.
В любом случае будет радикально лучше, чем если делать это на процессоре.
Определять текущее состояние можно только по таймингу.
Состояния как такового в этой системе нет — данные о нем теряются, остается только набор анимаций, идущий подряд.
Но таймер анимации хранится в компоненте и каждый кадр растится процессором и передается в материал. Так как управляется это со стороны процессора, никто не мешает в этом компоненте сохранить диапазоны анимаций и при управлении указывать стейт, и в компоненте доставать из информации о диапазоне время.
В любом случае, этот компонент должен как то работать с этой информацией — именно он управляет зацикленностью и режимом анимаций, для шейдера это просто число от 0 до 1.
Причем можно использовать сразу несколько методов, и все будут правильными.
Например, организация объектов по ссылкам делает объекты удобными для понимания, но недружными к кешу процессора.
Есть подходы, когда данные реорганизуют под производительность. ECS
Впрочем тяжело сказать, является это проблемой прямо ООП или его нынешних организаций.
Но вы все еще придумали архитектуру данных завода до или вместе с кодом завода и архитектуру данных станка до или вместе с кодом станка.
В этом смысле Я пожалуй согласен со статьей — Data-First
Но в остальном так себе — соломенное чучело ООП
Код — для людей, задачи — для людей, они субъективны.
Но SOLID не зря придумали, кто же спорит.
Важно и то, что код читать сложнее чем писать в принципе. Поэтому любой прочитанный код зачастую хуже, чем написанный.
Код объективен лишь в том, что он, будучи скомпилированным работает и решает задачу.
Хотя в сложных кейсах и это не очевидно — редактор со сложным интерфейсом «решает» задачу редактирования, но насколько эффективно, если пользователям тяжело его понимать?
Код пишется не только для компьютеров, но и для людей.
С точки зрения разработчика все варианты решения задачи и оформления кода для этого решения — глубоко субъективны. Разные люди по разному поймут этот код, будут испытывать проблемы с пониманием в разных местах, могут считать разные места важными или не важными, по разному будут его менять. Субъективны так же варианты расширения и изменения кода при развитии — ведь они опираются на субъективные требования (пример с интерфейсом) и субъективное понимание текущей работы кода.
Гневаться на код разумеется не продуктивно, но «ругать» странную логику, плохое форматирование, сложность чтения и т.д. для того, чтобы этого избежать — вполне продуктивно.
Усилия по улучшению кода, направленные на понимание кода в будущем и разными членами команды — оправданны.
Через верхнюю часть руля видна панель с циферблатами и ее верхний обрез — она перпендикулярна центральной оси.
А вообще процесс в этом направлении и идет — посмотрите на современные страны, они довольно большие и продолжают агрегироваться, пусть и не так активно.
И полная наверняка не осуществима.
Но это ведь не повод не стараться оценивать?
Они, очевидно, погибли.
Просто отпечаток остался.