Комментарии 24
А зачем? VRML (а это стандарт аж с 1997 года!) за столько лет так и не прижился, что означается лишь одно — неудобно с компьютера с 2D управлением пользоваться 3D интерфейсами. Кроме того, нет прямой нужны сделать 3D, кроме как для очень специальных задач. Тянуть поддержку 3D в браузеры… Зачем?
Например мы разрабатываем видеослоты, и смотрим в сторону WEB — не на флеше же писать
Хабр предложил интересные публикации по похожим темам. Захожу в эту https://habrahabr.ru/post/247811/. Статья написана 2 года назад в 2015. В комментариях взрываются пуканы хомячья недовольных размером шапки в 400кб и общей тормознутостью сайта. Сейчас 2017 рок, захожу на сайт приведенный в примере https://www.phyramid.com/en/ из статьи. Есть ужасающий дизайн, кровоточиво-глазные сочетание цветов, но нет трехмерной шапки. Даже такие упоротые в плане дизайна, как создатели этого сайта (у них наверняка в каждом глазу по включенному миксеру), осознали за 2 года, как говорят на этих ваших оманьяченных лорах: "не нужно" и выпилили 3 мерную шапку к херам.
Веб игры? Ну если только всякие казино и прочие вулканы. Продвинутые геймеры ставят титаны и затариваются в стимах кризисами да батлами разными.
Так вот, если игра не требовательна к большему числу полигонов модели — то ресурсов компьютера и технологий современных браузеров вполне хватит, чтобы рендерить вполне себе крутые игрушки. Так что 3D в бразуерах — это скорее светлое будущее, чем утопия. Просто такие технологии надо применять с умом. Да и сами проекты должны привлекать геймера в первую очередь не красотой картинки, а качеством геймплея. А тут уж и браузер и десктоп и мобильное приложение — все равны. Вопрос на что хватит фантазии.
Мозила вот не отстает https://hacks.mozilla.org/2017/01/webgl-2-lands-in-firefox/
Ну и вот потрогать немного
https://playcanv.as/e/p/44MRmJRU/
http://toji.github.io/webgl2-particles-2/
http://toji.github.io/webgl2-crowd/
Нажмите кнопку + Показать дополнительные настройки
В разделе Система, найдите пункт Использование аппаратного ускорение включите кликнув на флажок ( и далее вам необходимо перезапустить Chrome для того чтобы изменения вступили в силу)
Затем включите WebGL:
Перейти в chrome://flags
Найдите пункт Включить прототип WebGL 2.0
Убедитесь в том, что WebGL активирован (вам необходимо перезапустить Chrome чтобы любые изменения вступили в силу)
Затем проверьте состояние WebGL:
Перейти в chrome://gpu
Найдите элемент WebGL: Hardware accelerated в списке Graphics Feature Status. Надпись Hardware accelerated должна гореть зеленым
Вот такой есть мануал
Ну судя по тому что сафари не поддерживает WebGl 2.0 Apple не сильно торопиться с внедрением стандарта, так что могут быть проблемы на аппаратном уровне. Хром на эпловских осях иногда выдает такие финты что волосы дыбом становятся.
не требует установки специализированных расширений или библиотек
без драйверов видеокарты, а в случае Линукса ещё и правильно настроенных тех самых библиотек, ничего не взлетит.
втоматическое управление памятью. В отличие от OpenGL, в WebGL не надо выполнять специальные действия для выделения и очистки памяти.
если прошлое замечание больше похоже на придирку, то в этом случае всё серьёзно — это уже откровенная ложь. Лучше уберите этот пункт. Все данные, которые будут отображаться с помощью WebGL выделяются в памяти видеокарты. Соответственно, их также надо вручную освобождать, никакой сборщик мусора не поможет.
В данном языке конкретных функций ручного управления памятью не предусмотрено, значение переменной в памяти остается до тех пор пока есть хотя бы одна ссылка на переменную далее вступает в действие сборщик мусора.
Понятно, что если бездумно плодить переменные и оставлять их висеть в памяти ничего хорошего не будет, но это уже вопрос оптимизации программы.Так как WebGL программируется в JavaScript эти принципы так же применимы.
Тезис об автоматическом управлении памятью подтверждается и печатными источниками. Однако я не буду утверждать, что вы не правы в своем высказывании, если у вас есть информация или конкретное руководство по ручному управлению памятью при разработке WebGL приложений прошу поделиться. Очень интересно будет почитать и применить на практике для создания качественных, оптимизированных приложений.
вот на примере буфера: https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteBuffer
Да, когда переменная buffer выйдет из блока (т.е. попадёт к сборщику в руки), он что-то связанное с ней подчистит, однако deleteBuffer вызывать не будет (Конечно, может в обозревателях и реализовали такую возможность, но я сильно сомневаюсь), произойдёт потеря идентификатора, с помощью которого адресуются данные и освободить их в данном процессе уже никак не получится. Происходит это из-за того, что buffer "держит" данные непосредственно в памяти видеоускорителя.
Конечно, если речь идёт о какой-нибудь демке, то там всё равно, вызывать дилит объектам или нет — при закрытии вкладки/обозревателя ОС всё подчистит — кстати также, как и при закрытии родного приложения.
Однако для долгоиграющих приложений (игры, 2Д/3Д-редакторы графики, редакторы видео, ПО для моделирования) это должно учитываться. И выглядеть этот код будет один-в-один, как на C++. =)
И для каждого GL-ного объекта такая пара методов есть:
- текстуры — https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteTexture
- шейдеры — https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteShader, https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteProgram
- буфер отображения — https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteRenderbuffer
- буфер кадра — https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/deleteFramebuffer
Развивая тему, хотелось бы отметить, что это не проблема JavaScript/WebGL в частности. Это вообще проблема сборщиков мусора — все думают, что они могут всё и ни за чем следить не нужно. Самое большое заблуждение! В общем случае приходится управлять ресурсами (память же — лишь частный её случай) и тут сборщики мусора никак не облегчают задачу, но даже мешают.
Трехмерная графика в вебе