@softaria12 апр 2016 в 08:26

WebGL на Unity3d — двенадцать проблем при сборке проекта

6 мин

47K

Unity * WebGL *

Из песочницы

+20

Комментарии 36

@Leopotam 12 апр 2016 в 08:42

12. ~~Сам WebGL.~~ Не работают кастомные потоки (Thread) ни в каком виде, есть решение только через браузерные костыли webworker-ов и тп.

@softaria 12 апр 2016 в 09:27

Потому что в браузере яваскрипт однопоточный. Тут ничего не сделать.
В Unity можно использовать CoRoutine-ы. Хотя и с осторожностью — они используют тот же единственный поток, замедляя основной процесс.

@Leopotam 12 апр 2016 в 09:38

Мне это не нужно объяснять, я просто указал, что можно дописать в статью. :)

@softaria 12 апр 2016 в 09:47

Я описал то, что счёл неочевидным. То что в браузере один поток — общеизвестно.

@Suvitruf 12 апр 2016 в 08:44

13. Не работают System.Net.Sockets

@softaria 12 апр 2016 в 09:25

Конечно. Но есть WebSocket

@Suvitruf 12 апр 2016 в 18:13

В нашем случае используется библиотека для работы с ejabberd, не так легко найти аналог на WebSocket'ах.

@softaria 12 апр 2016 в 19:04

Вот тут Unity раздает пример клиента для Websocket.
А сервер можно взять на любой вкус. Я для прототипа взял Jetty. В production пойдет сервер на golang.
Хотя, это не аналог ejabberd, конечно.

@softaria 12 апр 2016 в 09:54

Общий принцип включения в статью — неочевидные проблемы, связанные именно с использованием Unity для сборки под WebGL.
Sockets не работает из-за отсутствия поддержки sockets в браузерах. Это — не проблема Unity.

@Leopotam 12 апр 2016 в 14:01

Это как раз проблемы юнити — write once, run everywhere, почти как у явы. Если платформа не поддерживает какие-то базовые классы — код не должен компилироваться или компилироваться прозрачно для пользователя во что-то иное. Ведь они транслируют основной msil код сборок + clr в js, почему не транслировать автоматом код про сокеты + делать обертки вокруг них в стиле вебсокетов? Получается, что код проекта превращается в кашу и работа перекладывается на юзвера в плане обеспечения совместимости по платформам. В чем тогда смысл использования юнити, если то же самое можно запилить на чистом webgl и оно будет весить не 100мб, а, например, 10?

@softaria 12 апр 2016 в 16:18

Я не ставил целью пропаганду юнити. Статья написана для тех, кто столкёнтся с конкретной задачей. Цель статьи — сэкономить людям время. Предполагается (и я прозрачно намекнул об этом в Disclaimer), что этим людям не надо объяснять что такое ассет, рассказывать почему браузер не может запускать треды или пояснять, что браузеры не поддерживают сокеты.
Ваша претензия не к статье, а к технологии. А значит она не по адресу.

@ZimM 13 апр 2016 в 01:05

> почему не транслировать автоматом код про сокеты + делать обертки вокруг них в стиле вебсокетов?
Каким образом вы себе представляете *прозрачное* оворачивание низкоуровневого протокола внутрь высокоуровневого? Вебсокеты — это надстройка над обычными сокетами, в обратную сторону это не работает.
Заверните-ка прозрачно TCP в HTTP, угу.

@Leopotam 13 апр 2016 в 05:53

Я ведь не зря написал — «или компилироваться прозрачно для пользователя во что-то иное.». У них есть штатная сеть, абстрагированная от сокетов и предоставляющая транспорт данных пользователя — почему она тоже не рабочая? И если штатные сокеты не пашут, то почему бы не предоставить новый слой абстракции в пространстве UnityEngine.xxx для симуляции работы через сокеты? Ведь вебсокет — это тот же tcp stream, отличающийся только способом установки коннекта. Да, отпадут все udp решения, но хоть что-то да будет работать реально кроссплатформенно.

Заверните-ка прозрачно TCP в HTTP, угу.

WebSocket не заворачивается в http — это обычный потоковый tcp, который маскируется первыми пакетами под htpp заголовки, чтобы пробиться через браузер. Дальше идет обычный бинарный поток, через который можно слать как текст (заворачиваемый в utf8 и потом в бинарный вид), так и любые бинарные данные.

@softaria 13 апр 2016 в 06:15

> У них есть штатная сеть, абстрагированная от сокетов и предоставляющая транспорт данных пользователя — почему она тоже не рабочая?

Она рабочая — http://docs.unity3d.com/Manual/webgl-networking.html

>WebSocket не заворачивается в http — это обычный потоковый tcp

Браузеры поддерживают только асинхронную отправку в WebSocket. Как быть с синхронной?

@Leopotam 13 апр 2016 в 06:26

Она рабочая

Это новая сеть, которую они пилят с 5-ки и к которой выкатывают 100500 фиксов к шоустоперам каждый патч. WWW работал, да, но это запрос-ответ с вырезанием keep-alive и принудительным закрытием коннекта, что не всегда подходит.

Как быть с синхронной?

Не совсем понял, с чего сеть вообще должна быть синхронной? Отсюда вытекает и первая проблема — отсутствие потоков. Например, я использовал вебсокеты в своем потоке и все шло прекрасно. Потом меня утомило поддерживать rfc и я переписал сеть на чистый tcp stream со своими костылями и в том же потоке — для остального кода ничего не поменялось, даже в апи, потому что оно все было изначально асинхронное (с возвращением результата через колбеки путем прокидывания данных-событий через очереди в основной поток). Юнитеки двигаются в том же направлении с новой сетью, молодцы. Но на данный момент нет ничего продакшн уровня стабильности + пользователю приходится городить огород вокруг внешних вызовов в js, что доставляет с той же отладкой и тп.

@softaria 13 апр 2016 в 06:48

>Это новая сеть, которую они пилят с 5-ки и к которой выкатывают 100500 фиксов к шоустоперам каждый патч.

Так часто бывает с ноыми продуктами. Скорее всего, процесс скоро сойдется.

>Не совсем понял, с чего сеть вообще должна быть синхронной?

Сеть не должна быть синхронной. Я к тому, что нельзя просто так обернуть Socket в WebSocket хотя бы потому, что первый поддерживает синхронные сообщения, а второй в браузерах не поддерживает.

@Leopotam 13 апр 2016 в 06:56

Рендер / работа со звуком тоже не синхронна по своей сути (не подготовка данных, а сам процессинг), однако это не помешало запилить качественные врапперы вокруг подсистем браузера без изменения пользовательского кода. У меня претензии исключительно к тому, что юнитеки все системы обернули вполне качественно (даже физику), а вот к сети отнеслись абсолютно халатно — переложили работу на потребителя. В остальном все нормально.

Так часто бывает с ноыми продуктами. Скорее всего, процесс скоро сойдется.

И возникнет старая проблема — невозможность создания кастомных серверов без хостинга в юнити. Да, они планируют запилить некую ServerLibrary, но это пока просто строка в роадмапе.

@softaria 13 апр 2016 в 07:02

>И возникнет старая проблема — невозможность создания кастомных серверов без хостинга в юнити.

Тут согласен с вами. Поэтому сам просто взял здесь простой клиент к WebSocket и прицепил его к Jetty (читай — к любому серверу с поддержкой WebSocket). Работает прекрасно.

@Suvitruf 14 апр 2016 в 05:14

У нас кстати тоже кастомные штуки для сети: вместо убогого www своя реализация на raw socket, которая, к сожалению, в WebGL не работает =\

@Miwwa 12 апр 2016 в 11:35

Спасибо, полезная статья. Сам пока столкнулся только с ограничением по памяти. Мне вроде не критично, влезаю в 512Mb, но, пожалуй, стоит пережать текстурки в разрешение пониже, может и в 256Mb влезу.
Ресурсы, загружаемые через Resources.Load, я кеширую, соответственно, относительно долго они грузятся только первый раз.

@OneOfUs 12 апр 2016 в 14:31

1) C:\Users\{ИМЯЮЗЕРА}\Application Data\Mozilla\Firefox\Profiles\{ИМЯПРОФИЛЯ}\storage\temporary\
…
2) C:\Users\{ИМЯЮЗЕРА}\Application Data\Mozilla\Firefox\Profiles\{ИМЯПРОФИЛЯ}\storage\temporary\

А чем эти пути отличаются. Или это просто ошибка копипасты?

@softaria 12 апр 2016 в 16:13

Спасибо. Поправил.

@Xalium 12 апр 2016 в 14:31

>> C:\Users\{ИМЯЮЗЕРА}\Application Data\Mozilla\Firefox\Profiles\{ИМЯПРОФИЛЯ}\storage\temporary\

два раза указан

@softaria 12 апр 2016 в 16:13

Спасибо, поправил

@PatientZero 12 апр 2016 в 18:43

Забавно, запустил создание сборки с настройкой Optimisation level: Fast и как раз наткнулся на вашу статью. Жаль, что так поздно, сэкономил бы время.

@softaria 12 апр 2016 в 19:08

Вы ведь не один раз будете собирать. Надеюсь, еще сэкономите. Сам я потратил почти две недели на добычу этих знаний.

@Gasparfx 12 апр 2016 в 19:42

> 4. Инициализация WebGL и компиляция шейдеров
А стандартный подход с использованием Shader Variant Collections не работает на WebGL?

@softaria 13 апр 2016 в 06:16

Работает. Пожалуй, об этом тоже стоило написать.

@Large 12 апр 2016 в 19:47

Да проблем хоть отбавляй! Одно могу сказать со времен 5.0бета все стало горааааздо лучше. Билды собираются более стабильно (раньше валились раз через раз), уменьшилось потребление памяти, увеличилась производительнось, починили шейдеры и тени.

А проблемы вот на вскидку: Пока не работает антиалиасинг. Проблемы с работой IndexedDB в сафари при использовании LoadaFromCacheOrDownload (лечится кастомным js лоадером). Проблемы с переходом в полноэкранный режим по нажатию кнопки в гуи — в разных браузерах не всегда отрабатывает маусап (тут пока вылечил жутким костылем с проверкой фулскрина на апдейт). Проблемы с переходом в фулскрин в опере (часть экрана обрезается). Для звуков нужно принудительно отключать эффект Доплера. В ИЕ билд валится из за отсутсвия поддержки аудио апи (раньше валился только при обращении к звуковой системе). И такого еще полно.

@softaria 13 апр 2016 в 06:18

Технология сырая пока. Но есть надежда, что будет становиться лучше.

@splatt 13 апр 2016 в 00:18

Загрузка типов с помощью reflection — это вообще очень-очень плохая идея, и дело тут не в OpenGL. Если ваш тип используется только в виде строки, то нет никакой гарантии что code stripping не пометит этот код как неиспользуемый и не удалит этот код. Именно поэтому в 5й Unity убрали AddComponent(string). Поправьте, если не прав.

@Leopotam 13 апр 2016 в 06:01

Эмитировать MSIL с помощью рефлекшна — плохая идея. Пытаться создавать новые домены и грузить в них сборки — плохая идея. Получение мета-информации о типе (поля и тп) — вполне нормально (правда не по строковому имени, а по уже существующему и используемому типу), часто используется, например, при мапинге json данных на типы. Те reflection сильно ограничен со времен AOT (а скоро и на всех платформах с приходом il2cpp), об этом нужно помнить.

@softaria 13 апр 2016 в 06:19

В целом, вы правы. Если для чего-то сильно нужна такая техника, с ней надо быть аккуратным.

@slonopotamus 13 апр 2016 в 06:46

Какие-то костыли и подпорки. Это называется «вышла из беты»? Интересно, куда.

@softaria 13 апр 2016 в 07:04

Релиз 1.0.0 редко бывает беспроблемным. Но разница с тем, что было в бете, огромна.
Это даёт основания рассчитывать на улучшение ситуации в следующих релизах.

@gfxdevrus 15 сен 2016 в 14:29

а воз и ныне там
https://habrahabr.ru/post/310086/

Зарегистрируйтесь на Хабре, чтобы оставить комментарий