Комментарии 36
12. Сам WebGL. Не работают кастомные потоки (Thread) ни в каком виде, есть решение только через браузерные костыли webworker-ов и тп.
13. Не работают System.Net.Sockets
Конечно. Но есть WebSocket
В нашем случае используется библиотека для работы с ejabberd, не так легко найти аналог на WebSocket'ах.
Вот тут Unity раздает пример клиента для Websocket.
А сервер можно взять на любой вкус. Я для прототипа взял Jetty. В production пойдет сервер на golang.
Хотя, это не аналог ejabberd, конечно.
А сервер можно взять на любой вкус. Я для прототипа взял Jetty. В production пойдет сервер на golang.
Хотя, это не аналог ejabberd, конечно.
Общий принцип включения в статью — неочевидные проблемы, связанные именно с использованием Unity для сборки под WebGL.
Sockets не работает из-за отсутствия поддержки sockets в браузерах. Это — не проблема Unity.
Sockets не работает из-за отсутствия поддержки sockets в браузерах. Это — не проблема Unity.
Это как раз проблемы юнити — write once, run everywhere, почти как у явы. Если платформа не поддерживает какие-то базовые классы — код не должен компилироваться или компилироваться прозрачно для пользователя во что-то иное. Ведь они транслируют основной msil код сборок + clr в js, почему не транслировать автоматом код про сокеты + делать обертки вокруг них в стиле вебсокетов? Получается, что код проекта превращается в кашу и работа перекладывается на юзвера в плане обеспечения совместимости по платформам. В чем тогда смысл использования юнити, если то же самое можно запилить на чистом webgl и оно будет весить не 100мб, а, например, 10?
Я не ставил целью пропаганду юнити. Статья написана для тех, кто столкёнтся с конкретной задачей. Цель статьи — сэкономить людям время. Предполагается (и я прозрачно намекнул об этом в Disclaimer), что этим людям не надо объяснять что такое ассет, рассказывать почему браузер не может запускать треды или пояснять, что браузеры не поддерживают сокеты.
Ваша претензия не к статье, а к технологии. А значит она не по адресу.
Ваша претензия не к статье, а к технологии. А значит она не по адресу.
> почему не транслировать автоматом код про сокеты + делать обертки вокруг них в стиле вебсокетов?
Каким образом вы себе представляете *прозрачное* оворачивание низкоуровневого протокола внутрь высокоуровневого? Вебсокеты — это надстройка над обычными сокетами, в обратную сторону это не работает.
Заверните-ка прозрачно TCP в HTTP, угу.
Каким образом вы себе представляете *прозрачное* оворачивание низкоуровневого протокола внутрь высокоуровневого? Вебсокеты — это надстройка над обычными сокетами, в обратную сторону это не работает.
Заверните-ка прозрачно TCP в HTTP, угу.
Я ведь не зря написал — «или компилироваться прозрачно для пользователя во что-то иное.». У них есть штатная сеть, абстрагированная от сокетов и предоставляющая транспорт данных пользователя — почему она тоже не рабочая? И если штатные сокеты не пашут, то почему бы не предоставить новый слой абстракции в пространстве UnityEngine.xxx для симуляции работы через сокеты? Ведь вебсокет — это тот же tcp stream, отличающийся только способом установки коннекта. Да, отпадут все udp решения, но хоть что-то да будет работать реально кроссплатформенно.
WebSocket не заворачивается в http — это обычный потоковый tcp, который маскируется первыми пакетами под htpp заголовки, чтобы пробиться через браузер. Дальше идет обычный бинарный поток, через который можно слать как текст (заворачиваемый в utf8 и потом в бинарный вид), так и любые бинарные данные.
Заверните-ка прозрачно TCP в HTTP, угу.
WebSocket не заворачивается в http — это обычный потоковый tcp, который маскируется первыми пакетами под htpp заголовки, чтобы пробиться через браузер. Дальше идет обычный бинарный поток, через который можно слать как текст (заворачиваемый в utf8 и потом в бинарный вид), так и любые бинарные данные.
> У них есть штатная сеть, абстрагированная от сокетов и предоставляющая транспорт данных пользователя — почему она тоже не рабочая?
Она рабочая — http://docs.unity3d.com/Manual/webgl-networking.html
>WebSocket не заворачивается в http — это обычный потоковый tcp
Браузеры поддерживают только асинхронную отправку в WebSocket. Как быть с синхронной?
Она рабочая — http://docs.unity3d.com/Manual/webgl-networking.html
>WebSocket не заворачивается в http — это обычный потоковый tcp
Браузеры поддерживают только асинхронную отправку в WebSocket. Как быть с синхронной?
Она рабочая
Это новая сеть, которую они пилят с 5-ки и к которой выкатывают 100500 фиксов к шоустоперам каждый патч. WWW работал, да, но это запрос-ответ с вырезанием keep-alive и принудительным закрытием коннекта, что не всегда подходит.
Как быть с синхронной?
Не совсем понял, с чего сеть вообще должна быть синхронной? Отсюда вытекает и первая проблема — отсутствие потоков. Например, я использовал вебсокеты в своем потоке и все шло прекрасно. Потом меня утомило поддерживать rfc и я переписал сеть на чистый tcp stream со своими костылями и в том же потоке — для остального кода ничего не поменялось, даже в апи, потому что оно все было изначально асинхронное (с возвращением результата через колбеки путем прокидывания данных-событий через очереди в основной поток). Юнитеки двигаются в том же направлении с новой сетью, молодцы. Но на данный момент нет ничего продакшн уровня стабильности + пользователю приходится городить огород вокруг внешних вызовов в js, что доставляет с той же отладкой и тп.
>Это новая сеть, которую они пилят с 5-ки и к которой выкатывают 100500 фиксов к шоустоперам каждый патч.
Так часто бывает с ноыми продуктами. Скорее всего, процесс скоро сойдется.
>Не совсем понял, с чего сеть вообще должна быть синхронной?
Сеть не должна быть синхронной. Я к тому, что нельзя просто так обернуть Socket в WebSocket хотя бы потому, что первый поддерживает синхронные сообщения, а второй в браузерах не поддерживает.
Так часто бывает с ноыми продуктами. Скорее всего, процесс скоро сойдется.
>Не совсем понял, с чего сеть вообще должна быть синхронной?
Сеть не должна быть синхронной. Я к тому, что нельзя просто так обернуть Socket в WebSocket хотя бы потому, что первый поддерживает синхронные сообщения, а второй в браузерах не поддерживает.
Рендер / работа со звуком тоже не синхронна по своей сути (не подготовка данных, а сам процессинг), однако это не помешало запилить качественные врапперы вокруг подсистем браузера без изменения пользовательского кода. У меня претензии исключительно к тому, что юнитеки все системы обернули вполне качественно (даже физику), а вот к сети отнеслись абсолютно халатно — переложили работу на потребителя. В остальном все нормально.
И возникнет старая проблема — невозможность создания кастомных серверов без хостинга в юнити. Да, они планируют запилить некую ServerLibrary, но это пока просто строка в роадмапе.
Так часто бывает с ноыми продуктами. Скорее всего, процесс скоро сойдется.
И возникнет старая проблема — невозможность создания кастомных серверов без хостинга в юнити. Да, они планируют запилить некую ServerLibrary, но это пока просто строка в роадмапе.
>И возникнет старая проблема — невозможность создания кастомных серверов без хостинга в юнити.
Тут согласен с вами. Поэтому сам просто взял здесь простой клиент к WebSocket и прицепил его к Jetty (читай — к любому серверу с поддержкой WebSocket). Работает прекрасно.
Тут согласен с вами. Поэтому сам просто взял здесь простой клиент к WebSocket и прицепил его к Jetty (читай — к любому серверу с поддержкой WebSocket). Работает прекрасно.
У нас кстати тоже кастомные штуки для сети: вместо убогого www своя реализация на raw socket, которая, к сожалению, в WebGL не работает =\
Спасибо, полезная статья. Сам пока столкнулся только с ограничением по памяти. Мне вроде не критично, влезаю в 512Mb, но, пожалуй, стоит пережать текстурки в разрешение пониже, может и в 256Mb влезу.
Ресурсы, загружаемые через Resources.Load, я кеширую, соответственно, относительно долго они грузятся только первый раз.
Ресурсы, загружаемые через Resources.Load, я кеширую, соответственно, относительно долго они грузятся только первый раз.
1) C:\Users\{ИМЯЮЗЕРА}\Application Data\Mozilla\Firefox\Profiles\{ИМЯПРОФИЛЯ}\storage\temporary\
…
2) C:\Users\{ИМЯЮЗЕРА}\Application Data\Mozilla\Firefox\Profiles\{ИМЯПРОФИЛЯ}\storage\temporary\
А чем эти пути отличаются. Или это просто ошибка копипасты?
…
2) C:\Users\{ИМЯЮЗЕРА}\Application Data\Mozilla\Firefox\Profiles\{ИМЯПРОФИЛЯ}\storage\temporary\
А чем эти пути отличаются. Или это просто ошибка копипасты?
>> C:\Users\{ИМЯЮЗЕРА}\Application Data\Mozilla\Firefox\Profiles\{ИМЯПРОФИЛЯ}\storage\temporary\
два раза указан
два раза указан
Забавно, запустил создание сборки с настройкой Optimisation level: Fast и как раз наткнулся на вашу статью. Жаль, что так поздно, сэкономил бы время.
> 4. Инициализация WebGL и компиляция шейдеров
А стандартный подход с использованием Shader Variant Collections не работает на WebGL?
А стандартный подход с использованием Shader Variant Collections не работает на WebGL?
Да проблем хоть отбавляй! Одно могу сказать со времен 5.0бета все стало горааааздо лучше. Билды собираются более стабильно (раньше валились раз через раз), уменьшилось потребление памяти, увеличилась производительнось, починили шейдеры и тени.
А проблемы вот на вскидку: Пока не работает антиалиасинг. Проблемы с работой IndexedDB в сафари при использовании LoadaFromCacheOrDownload (лечится кастомным js лоадером). Проблемы с переходом в полноэкранный режим по нажатию кнопки в гуи — в разных браузерах не всегда отрабатывает маусап (тут пока вылечил жутким костылем с проверкой фулскрина на апдейт). Проблемы с переходом в фулскрин в опере (часть экрана обрезается). Для звуков нужно принудительно отключать эффект Доплера. В ИЕ билд валится из за отсутсвия поддержки аудио апи (раньше валился только при обращении к звуковой системе). И такого еще полно.
А проблемы вот на вскидку: Пока не работает антиалиасинг. Проблемы с работой IndexedDB в сафари при использовании LoadaFromCacheOrDownload (лечится кастомным js лоадером). Проблемы с переходом в полноэкранный режим по нажатию кнопки в гуи — в разных браузерах не всегда отрабатывает маусап (тут пока вылечил жутким костылем с проверкой фулскрина на апдейт). Проблемы с переходом в фулскрин в опере (часть экрана обрезается). Для звуков нужно принудительно отключать эффект Доплера. В ИЕ билд валится из за отсутсвия поддержки аудио апи (раньше валился только при обращении к звуковой системе). И такого еще полно.
Загрузка типов с помощью reflection — это вообще очень-очень плохая идея, и дело тут не в OpenGL. Если ваш тип используется только в виде строки, то нет никакой гарантии что code stripping не пометит этот код как неиспользуемый и не удалит этот код. Именно поэтому в 5й Unity убрали AddComponent(string). Поправьте, если не прав.
Эмитировать MSIL с помощью рефлекшна — плохая идея. Пытаться создавать новые домены и грузить в них сборки — плохая идея. Получение мета-информации о типе (поля и тп) — вполне нормально (правда не по строковому имени, а по уже существующему и используемому типу), часто используется, например, при мапинге json данных на типы. Те reflection сильно ограничен со времен AOT (а скоро и на всех платформах с приходом il2cpp), об этом нужно помнить.
В целом, вы правы. Если для чего-то сильно нужна такая техника, с ней надо быть аккуратным.
Какие-то костыли и подпорки. Это называется «вышла из беты»? Интересно, куда.
а воз и ныне там
https://habrahabr.ru/post/310086/
https://habrahabr.ru/post/310086/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WebGL на Unity3d — двенадцать проблем при сборке проекта