Пользуюсь https://github.com/LykosAI/StabilityMatrix Это пакет, который - сам ставит и обновляет и A1111, и Foooocus и другие популярные и не очень популярные оболочки - собирает модели нейронок в общую папку для всех оболочек
Есть SolidJS и SvelteJS, вероятно, вы сможете подрезать оттуда пару идей для развития своего Фреймворка.
SolidJS интересен синтаксисом JSX, который максимально напоминает React, для этого используется кастомный JSX (если кто не в курсе, то JSX это просто синтаксис записи объектов в XMLподобном виде, Babel превращает все эти теги и атрибуты в объекты и их поля)
Я даю только одну ссылку, потому что мне, человеку далекому от науки, но живущему рядом с академгородками - строительство новых зданий, не только административных, заметно.
И если вы не заметили ни новых зданий, ни даже новостей - я боюсь, ничем не смогу вам помочь.
да, у меня скорее стратегия, где возможно несколько движущихся юнитов и множество статичных
В игровом движке Phaser, с которым я работаю, метод коллизий по умолчанию реализован как перебор массивов. Правда из плюсов - что добавлять к массивам, можно решить самому, не все спрайты мира запихиваются в эти массивы по умолчанию. Но я прикинул, что сотня объектов точно будет, а перебор 100^2 даже с минимальной нагрузкой - уже заметное время даже на хорошей декстопной системе. Поэтому озаботился концепцией разделения по площади.
С одиночным игроком в принципе проще. Но если он стреляет, как в Vampire Survivor (а это тоже реализовано на Phaser), все равно возникает множество движущихся объектов.
Полагаю, создатель Vampire Survivor тоже писал свою систему или ловко жонглировал массивами
Спасибо за статью об оптимизации столкновений на карте. Работаю в аналогичной области, на другом языке.
Почитал ваш код SpatialGrid. Я правильно понял, что ему передается компонент, движение которого надо отслеживать?
SpatialGrid - хорошая тема, я использовал нечто подобное, только проще - двухмерный массив, спрятанный в классе Collider у Collider по сути три основных метода, я нарасти больше, но основных три - addObject(obj) - updateObj(obj) - который обновляет позицию объекта - getCollision(obj) - возвращает другой объект, с которым столкнулся наш obj, или null
Почитав ваш код, я понял, что массив ячеек можно заменить на Map, так как огромная часть ячеек не используется. Возможно, в будущем так и сделаю.
Collider прост, потому что пассивен - это забота обновляющегося объекта уведомить его об обновлении позиции. Мне нужно несколько двигающихся объектов, поэтому я решил пойти именно таким образом.
Почитал еще раз свой код - да, HashMap с ключом по координатам ячейки будет лучшим выбором, так позволяет освободиться от зависимости от заранее заданных размеров. Двухмерный массив хорош, но в коллизиях он пожалуй не нужен, уберу его оттуда совсем.
В оригинале "The billion-dollar revenue figure implies that the Microsoft-backed company, which was valued on paper at $27 billion when investors bought stock from existing shareholders earlier this year, is generating more than $80 million in revenue per month. "
Мне кажется, у ончейн-игр есть ощутимый технический лимит. Можем ли мы хранить в блокчейне текстуры? Можем ли мы хранить там 50 гигабайт?
Какова вообще архитектура ончейн-игры, что мы можем положить в блокчейн - все или только часть? Что выйдет по деньгам?
Если в блокчейн заливается дистрибутив 50 гигабайт (предположим, вы ответили да на ответ выше) - значит все остальные юзеры блокчейна, включая даже не игроков, вынуждены получить эти 50 гигабайт?
Что с апдейтами, патчами? В оффчейн-софте это критически важная составляющая цикла сегодня. Мы можем обновлять блокчейн-игры? Сколько это будет стоить для разработчика, для юзера?
То есть - полиэтилен пока не по зубам - полиуретан - по зубам и выбор из штаммов есть - пластиковые смеси PBAT и PLA - по зубам и выбор из штаммов есть
это не те же хуки, извините. Они могут стать хуками, когда, и я это видел, их зачем-то начинают тащить в Реакт и там заворачивают в хуки
Хук - это функция, исполняемая в контексте компонента. За пределами компонента хук и нельзя вызывать, и он просто не заработает вне его, даже если вы обманете все линтеры и сборщики. Хук - это функция, которая рассчитывает на существование неких внутренних состояний React на момент рендера компонента.
сигналы можно создавать и использовать вне компонентов, вне фреймворков, глобально или локально - это почти чистая функция, которая создает экземпляр наблюдаемого состояния и возвращает функцию для подписки на него.
Я прочитал комментарии и нашел, что могу еще сказать о Solid JS
Смотрите, вы хотите избежать лишнего создания объектов. Это максимизировано в SolidJS и в Svelte.
SolidJS хорош тем, что максимально приближен по синтаксису к React. Хуки в нем не нужны, функции создаются за пределами функционального компонента. Да собственно и если создавать внутри компонента - не страшно, потому что функция компонента вызывается только один раз. JSX конвертируется в нативный HTML, к которому под капотом привязываются обработчики и обновления на базе местных аналогов хуков.
Svelte использует тот же принцип, но с ним я работал очень давно. Когда работал - в нем JSX не было.
Но JSX - это такой слой концепции, который по идее можно прикрутить к чему угодно, я прикручивал его даже к игровому фреймворку Phaser (кастомный jSX - это по сути описание неких объектов/конфигураций в формате, приближенному к XML, после трансформации jSX превращается в набор объектов, с которыми вы дальше можете делать что угодно).
Поэтому я не удивлюсь, если узнаю, что JSX/TSX завезли и в Svelte.
Чем интересен ваш путь - тем, что вы пытаетесь выйти за рамки концепции, оставаясь внутри фреймворка.
Этим же он неприятен для многих, потому что таким образом вы сбиваете паттерн распознавания. То есть вы создаете как бы React, но используете совсем другой путь, что затрудняет чтение и понимание для тех, кто уже привык к React.
Поэтому я бы рекомендовал все же обратить внимание на SolidJS. Он пока более скромный по базе и времени существования, чем Svelte, но очень хорошо пытается облегчить миграцию на него с React.
Нейронка не создает картинку сама, она формирует ее по запросу пользователя.
В случае с обезьяной и селфи - обезьяна или человек являются пользователем инструмента. Юристы не рассматривали кейс "селфи является продуктом фотоаппарата, следовательно, права принадлежат или не принадлежат фотоаппарату".
Точно так же человек является пользователем нейронки. Он делает работу, он совершает выбор, он выбирает тему, он перебирает стили и ищет картинку без артефактов.
Нейронка это инструмент. Она не снимает сама автоматически. Ей нужен триггер, нужно "нажатие кнопки спуска" - то есть ввод конкретного текстового запроса с описанием картинки и нажатие кнопки, а то и не одной. И чтобы получить хорошую картинку, речь идет не о Миджорни, нужно много-много попыток, совсем как у фотографов.
В Фотошопе тоже есть сложные артистические фильтры, которые могут создавать из шума абстрактные картины (начните с белого полотна, примените Noise, далее фильтры по вкусу). Но никто, даже в РФ, не сформулирует "изображения, созданные Photoshop, не являются объектами авторского права".
Следовательно
1. Каждая "нейрокартинка" сегодня создается человеком - который вводит текст и нажимает кнопку.
2. Если вы украли чужой промпт и просто вбили его - то да, вы не автор. Но обычно люди все же сами пытаются сочинить текст для генерации картинки. Откройте любой доступный онлайн-генератор, попробуйте сами. Там нужно очень постараться, чтобы подобрать уникальную и красивую картинку. Следовательно, интеллектуальная работа есть. Следовательно пункт 2 выполняется.
За каждой "нейро-картинкой" стоит уникальный текст, это и есть тот самый авторский продукт, на который требуется и человек, и интеллектуальные, без иронии, по факту, усилия.
Пользуюсь https://github.com/LykosAI/StabilityMatrix
Это пакет, который
- сам ставит и обновляет и A1111, и Foooocus и другие популярные и не очень популярные оболочки
- собирает модели нейронок в общую папку для всех оболочек
Пока удобно, обновление - просто кнопку кликнуть
старый добрый компас
а еще можно ориентироваться по мху
Есть SolidJS и SvelteJS, вероятно, вы сможете подрезать оттуда пару идей для развития своего Фреймворка.
SolidJS интересен синтаксисом JSX, который максимально напоминает React, для этого используется кастомный JSX (если кто не в курсе, то JSX это просто синтаксис записи объектов в XMLподобном виде, Babel превращает все эти теги и атрибуты в объекты и их поля)
спасибо
PS: в чате "Вы превысили максимальное количество символов: 8476 / 1000."
Размер контекста какой? Мне нужен промпт длиной 8000 знаков на кириллице и еще 4000 на вывод хотя бы
// инвестировал хоть кто-то в Новосиб ил иТомск
да. Просто погуглите.
https://ria.ru/20221025/uskoritel-1826606213.html
Я даю только одну ссылку, потому что мне, человеку далекому от науки, но живущему рядом с академгородками - строительство новых зданий, не только административных, заметно.
И если вы не заметили ни новых зданий, ни даже новостей - я боюсь, ничем не смогу вам помочь.
Но на вопрос
- инвестировал хоть кто-то?
есть четкий ответ
- да
да, у меня скорее стратегия, где возможно несколько движущихся юнитов
и множество статичных
В игровом движке Phaser, с которым я работаю, метод коллизий по умолчанию реализован как перебор массивов. Правда из плюсов - что добавлять к массивам, можно решить самому, не все спрайты мира запихиваются в эти массивы по умолчанию. Но я прикинул, что сотня объектов точно будет, а перебор 100^2 даже с минимальной нагрузкой - уже заметное время даже на хорошей декстопной системе. Поэтому озаботился концепцией разделения по площади.
С одиночным игроком в принципе проще. Но если он стреляет, как в Vampire Survivor (а это тоже реализовано на Phaser), все равно возникает множество движущихся объектов.
Полагаю, создатель Vampire Survivor тоже писал свою систему или ловко жонглировал массивами
Спасибо за статью об оптимизации столкновений на карте.
Работаю в аналогичной области, на другом языке.
Почитал ваш код SpatialGrid. Я правильно понял, что ему передается компонент, движение которого надо отслеживать?
SpatialGrid - хорошая тема, я использовал нечто подобное, только проще - двухмерный массив, спрятанный в классе Collider
у Collider по сути три основных метода, я нарасти больше, но основных три
- addObject(obj)
- updateObj(obj) - который обновляет позицию объекта
- getCollision(obj) - возвращает другой объект, с которым столкнулся наш obj, или null
Почитав ваш код, я понял, что массив ячеек можно заменить на Map, так как огромная часть ячеек не используется. Возможно, в будущем так и сделаю.
Collider прост, потому что пассивен - это забота обновляющегося объекта уведомить его об обновлении позиции. Мне нужно несколько двигающихся объектов, поэтому я решил пойти именно таким образом.
Почитал еще раз свой код - да, HashMap с ключом по координатам ячейки будет лучшим выбором, так позволяет освободиться от зависимости от заранее заданных размеров. Двухмерный массив хорош, но в коллизиях он пожалуй не нужен, уберу его оттуда совсем.
Кто в юности не делал свою Фигму, у того не было юности))
Вы использовали IP-adapter для SD1.5 ?
сейчас у них туча файлов, и ноль информации о том, что надо качать для ControlNet
писать очень мелкие приложухи на JavaScript под WebView - да, возможно, я так делал
размер билда сейчас не помню
В оригинале "The billion-dollar revenue figure implies that the Microsoft-backed company, which was valued on paper at $27 billion when investors bought stock from existing shareholders earlier this year, is generating more than $80 million in revenue per month. "
не 80 миллиардов
Мне кажется, у ончейн-игр есть ощутимый технический лимит. Можем ли мы хранить в блокчейне текстуры? Можем ли мы хранить там 50 гигабайт?
Какова вообще архитектура ончейн-игры, что мы можем положить в блокчейн - все или только часть? Что выйдет по деньгам?
Если в блокчейн заливается дистрибутив 50 гигабайт (предположим, вы ответили да на ответ выше) - значит все остальные юзеры блокчейна, включая даже не игроков, вынуждены получить эти 50 гигабайт?
Что с апдейтами, патчами? В оффчейн-софте это критически важная составляющая цикла сегодня. Мы можем обновлять блокчейн-игры? Сколько это будет стоить для разработчика, для юзера?
То есть
- полиэтилен пока не по зубам
- полиуретан - по зубам и выбор из штаммов есть
- пластиковые смеси PBAT и PLA - по зубам и выбор из штаммов есть
хук - это очень просто
Хук - это грязная функция, которая работает со скрытыми глобальными объектами React, чтобы придать видимость чистоты в момент вызова ))
это не те же хуки, извините. Они могут стать хуками, когда, и я это видел, их зачем-то начинают тащить в Реакт и там заворачивают в хуки
Хук - это функция, исполняемая в контексте компонента. За пределами компонента хук и нельзя вызывать, и он просто не заработает вне его, даже если вы обманете все линтеры и сборщики. Хук - это функция, которая рассчитывает на существование неких внутренних состояний React на момент рендера компонента.
createSignal в Solid - это хитрожопый функциональный вариант шаблона Observable, он обсуждался здесь - https://habr.com/ru/companies/timeweb/articles/725504/
сигналы можно создавать и использовать вне компонентов, вне фреймворков, глобально или локально - это почти чистая функция, которая создает экземпляр наблюдаемого состояния и возвращает функцию для подписки на него.
если есть ссылка на issues, кидайте, чтобы люди были в курсе
в продакшен Solid JS не заряжали пока
Я прочитал комментарии и нашел, что могу еще сказать о Solid JS
Смотрите, вы хотите избежать лишнего создания объектов. Это максимизировано в SolidJS и в Svelte.
SolidJS хорош тем, что максимально приближен по синтаксису к React. Хуки в нем не нужны, функции создаются за пределами функционального компонента. Да собственно и если создавать внутри компонента - не страшно, потому что функция компонента вызывается только один раз. JSX конвертируется в нативный HTML, к которому под капотом привязываются обработчики и обновления на базе местных аналогов хуков.
Svelte использует тот же принцип, но с ним я работал очень давно. Когда работал - в нем JSX не было.
Но JSX - это такой слой концепции, который по идее можно прикрутить к чему угодно, я прикручивал его даже к игровому фреймворку Phaser (кастомный jSX - это по сути описание неких объектов/конфигураций в формате, приближенному к XML, после трансформации jSX превращается в набор объектов, с которыми вы дальше можете делать что угодно).
Поэтому я не удивлюсь, если узнаю, что JSX/TSX завезли и в Svelte.
Чем интересен ваш путь - тем, что вы пытаетесь выйти за рамки концепции, оставаясь внутри фреймворка.
Этим же он неприятен для многих, потому что таким образом вы сбиваете паттерн распознавания. То есть вы создаете как бы React, но используете совсем другой путь, что затрудняет чтение и понимание для тех, кто уже привык к React.
Поэтому я бы рекомендовал все же обратить внимание на SolidJS. Он пока более скромный по базе и времени существования, чем Svelte, но очень хорошо пытается облегчить миграцию на него с React.
Нейронка не создает картинку сама, она формирует ее по запросу пользователя.
В случае с обезьяной и селфи - обезьяна или человек являются пользователем инструмента. Юристы не рассматривали кейс "селфи является продуктом фотоаппарата, следовательно, права принадлежат или не принадлежат фотоаппарату".
Точно так же человек является пользователем нейронки. Он делает работу, он совершает выбор, он выбирает тему, он перебирает стили и ищет картинку без артефактов.
Нейронка это инструмент. Она не снимает сама автоматически. Ей нужен триггер, нужно "нажатие кнопки спуска" - то есть ввод конкретного текстового запроса с описанием картинки и нажатие кнопки, а то и не одной. И чтобы получить хорошую картинку, речь идет не о Миджорни, нужно много-много попыток, совсем как у фотографов.
В Фотошопе тоже есть сложные артистические фильтры, которые могут создавать из шума абстрактные картины (начните с белого полотна, примените Noise, далее фильтры по вкусу). Но никто, даже в РФ, не сформулирует "изображения, созданные Photoshop, не являются объектами авторского права".
Следовательно
1. Каждая "нейрокартинка" сегодня создается человеком - который вводит текст и нажимает кнопку.
2. Если вы украли чужой промпт и просто вбили его - то да, вы не автор. Но обычно люди все же сами пытаются сочинить текст для генерации картинки. Откройте любой доступный онлайн-генератор, попробуйте сами. Там нужно очень постараться, чтобы подобрать уникальную и красивую картинку. Следовательно, интеллектуальная работа есть. Следовательно пункт 2 выполняется.
За каждой "нейро-картинкой" стоит уникальный текст, это и есть тот самый авторский продукт, на который требуется и человек, и интеллектуальные, без иронии, по факту, усилия.
Вот так забота об окружающей среде резко тормозит технический прогресс
Мне, конечно, жалко глубоководных рыб. Но