Ответ: Новости
 

Unity for Linux. Наконец-то !
http://blogs.unity3d.com/2015/08/26/...now-available/

Ответ: Новости
 

Вчера скачал - работает и на встроенной карте с MESA

Упал и не запускается больше после того, как окно game вытащил за редактор. вот так

Ответ: Новости
 

Unity Deferred Decals

Ответ: Новости
 

Ответ: Новости
 

F*ck, минут 40 назад 5.1.3f скачал инсталятором. Не мог же подождать....

Ответ: Новости
 

Эх, похоже оптимизированный UI у нас все поломал. Остаемся на Unity 4.6 пока

Ответ: Новости
 

Вроде как гуй теперь можно строить трианглами
В BaseVertexEffect теперь входной параметр не "List<UIVertex>" а "Mesh", но как оно на самом деле еще не смотрел
Или я запоздал с "новостью" и все уже опробовали фичу?)

Ответ: Новости
 

Ответ: Новости
 

Ответ: Новости
 

Почитал про обновление. Кроме LZ4, который есть альтернатива отсутствию gzip (который сегодня включается пару строками на веб серверах), ничего толком не изменили, и продолжают тыкать в сторону броузеров?

Тестировали webgl билды между 5.2 и 5.3? Какова реально разница. Мобильники так же в стороне?
У меня до сих пор демки в хроме на маке не работают многие.

Ответ: Новости
 

LZ4 не альтернатива, а метод сжатия ассетов на клиенте. Т.к. ассеты в WebGL хранятся в памяти, то это существенно лучше чем полностью распакованные ассеты в памяти. gzip теперь распаковывается на клиенте, если не поддерживается браузером. Так же GZ4 можно использовать для бандлей и в остальных таргетах вместо не сжатых бандлей для экономии места.

Билды Unity 5.3 под WebGL сейчас стали более менее похожи на продакшн билды. В 5.2 было больше проблем.

Ответ: Новости
 

Получается LZ4, экономит RAM на клиенте, но увеличивает время загрузки за счет необходимости распаковывать сжатые данные.

Хочется видеть реальные примеры, реальных проектов.

Ответ: Новости
 

LZ4 по тестам очень быстрый, почти такая же скорость, как и не распакованные ассеты читать. Вон там таблица скоростей: https://code.google.com/p/lz4/

Ответ: Новости
 

Значит, улучшили ситуацию с RAM'ом.
А как быть с VRAM'ом (pvrtc, etc1, s3tc)? - тут им нужно что-то делать чтобы на мобилках ресурсы влезали в VRAM.

Также все равно держать большой блок данных в сжатом виде - это не для веба. В вебе нужно грузить, переводить в нативный формат (gl текстура например), и выбрасываешь загруженные данные. При этом асинхронно, когда это нужно разработчику, а не одним блоком и держать все в памяти.
Тут фундаментальные различия, и Unity просто либо технически не могут, либо не желают адаптироваться под специфики данной платформы.

Также как быть с огромным JS кодом движка? Нужна модульная сборка элементов кода которые используются в проекте, а не всего движка. Например большинство казуалок не будут использовать mechanim, следственно тащить код этой системы - просто не нужно. Но тут снова нужно архитектурно адаптироваться под данную платформу.

Нигде не видно что они пытаются решить данные проблемы.

Да и разработчикам игр, нужно понимать что WebGL - это не просто очередная платформа, она отличается больше всех платформ, нет ни одной столь "другой" платформы как web, и это нужно учитывать при разработке как движка, так и игры.

Ответ: Новости
 

Да все это понятно, сам подумай, как оптимизировать код, который игрок пишет на C# или JavaScript(UnityScript)? Это же не javascript, там вообще двойная конвертация C# => C++ => javascript. Стриппинг кода Unity они сделали, но там ведь не только код Unity, а еще же Mono. Все ждут WebAssembly, который должен улучшить ситуацию.

Но одно то, что игру, написанную на C#, можно запустить на WebGL это круто. Я уверен, что многие проблемы решаться с развитием веб платформы. Не все конечно, но многие.