В нашата предишна публикация в GWT Web Toolkit , обсъдихме силните страни и характеристиките на GWT , което, за да си припомним общата идея, ни позволява да транслираме изходния код на Java в JavaScript и да смесваме безпроблемно Java и JavaScript библиотеките. Забелязахме, че JavaScript, генериран от GWT, е драматично оптимизиран.
В днешната публикация бихме искали да отидем малко по-дълбоко и да видим GWT Toolkit в действие. Ще демонстрираме как можем да се възползваме от GWT, за да създадем своеобразно приложение: an добавена реалност (AR) уеб приложение, което се изпълнява в реално време, изцяло на JavaScript, в браузъра.
потърсете информация за кредитна карта
В тази статия ще се съсредоточим върху това как GWT ни дава възможността да взаимодействаме лесно с много API на JavaScript, като WebRTC и WebGL, и ни позволява да използваме голяма Java библиотека, NyARToolkit, която никога не е била предназначена за използване в браузъра. Ще покажем как GWT позволи на моя екип и аз в Jooink да съберем всички тези парчета, за да създадем нашия проект за домашни любимци, Picshare , базирано на маркери AR приложение, което можете да опитате във вашия браузър точно сега .
Тази публикация няма да бъде изчерпателно ръководство за това как да се създаде приложението, а по-скоро ще покаже използването на GWT за преодоляване на привидно непреодолимите предизвикателства с лекота.
Преглед на проекта: От реалността до разширената реалност
Picshare използва добавена реалност, базирана на маркери. Този тип AR приложение търси сцената за a маркер : специфичен, лесно разпознаваем геометричен модел, като този . Маркерът предоставя информация за позицията и ориентацията на маркирания обект, позволявайки на софтуера да проектира допълнителни 3D пейзажи в изображението по реалистичен начин. Основните стъпки в този процес са:
- Достъп до камерата: Когато се занимава с местни настолни приложения, операционната система осигурява вход / изход за голяма част от хардуера на устройството. Не е същото, когато се занимаваме с уеб приложения. Браузърите са създадени, за да бъдат нещо като „пясъчник“ за JavaScript код, изтеглен от мрежата, и първоначално не са били предназначени да позволяват на уебсайтовете да взаимодействат с повечето хардуери на устройства. WebRTC пробива тази бариера, използвайки HTML5s функции за улавяне на мултимедия, позволявайки на браузъра да има достъп, наред с други неща, до камерата на устройството и неговия поток.
- Анализирайте видео потока: Имаме видео потока ... какво сега? Трябва да анализираме всеки кадър, за да открием маркери и да изчислим позицията на маркера в реконструирания 3D свят. Тази сложна задача е бизнесът на TheARToolkit .
- Увеличете видеото: И накрая, искаме да покажем оригиналното видео с добавени синтетични 3D обекти. Ние използваме WebGL за да нарисувате последната, увеличена сцена на уеб страницата.
Възползване от API на HTML5 с GWT
Използването на JavaScript API като WebGL и WebRTC позволява неочаквани и необичайни взаимодействия между браузъра и потребителя.
Например WebGL позволява хардуерно ускорена графика и с помощта на въведен масив спецификация, дава възможност на JavaScript механизма да изпълнява смачкване на числа с почти естествена производителност. По същия начин, с WebRTC, браузърът има достъп до потоци на видео (и други данни) директно от хардуера на компютъра.
WebGL и WebRTC са и двете библиотеки на JavaScript, които трябва да бъдат вградени в уеб браузъра. Повечето съвременни HTML5 браузъри идват с поне частична поддръжка и за двата API (както можете да видите тук и тук ). Но как можем да използваме тези инструменти в GWT, който е написан на Java? Като обсъдени в предишния пост , Слой на оперативна съвместимост на GWT, JsInterop (публикувано официално в GWT 2.8) прави това парче торта.
Използването на JsInterop с GWT 2.8 е толкова лесно, колкото добавянето -generateJsInteropExports като аргумент на компилатора. Наличните пояснения са дефинирани в пакета jsinterop.annotations, пакетиран в gwt-user.jar.
WebRTC
Като пример, с минимална работа по кодиране, използвайки getUserMedia на WebRTC в Chrome с GWT става толкова просто, колкото писането:
Navigator.webkitGetUserMedia( configs, stream -> video.setSrc( URL.createObjectURL(stream) ), e -> Window.alert('Error: ' + e) ); Където класът Navigator може да се определи, както следва:
@JsType(namespace = JsPackage.GLOBAL, isNative = true, name='navigator') final static class Navigator { public static native void webkitGetUserMedia( Configs configs, SuccessCallback success, ErrorCallback error); } Интерес представлява дефиницията на интерфейсите SuccessCallback и ErrorCallback, и двете изпълнени от ламбда израза по-горе и дефинирани в Java с помощта на @JsFunction анотация:
@JsFunction public interface SuccessCallback { public void onMediaSuccess(MediaStream stream); } @JsFunction public interface ErrorCallback { public void onError(DomException error); } И накрая, дефиницията на класа URL е почти идентичен с този на Navigator, и по същия начин, Configs клас може да бъде дефиниран от:
@JsType(namespace = JsPackage.GLOBAL, isNative = true, name='Object') public static class Configs { @JsProperty public native void setVideo(boolean getVideo); } Действителното внедряване на всички тези функции се извършва в JavaScript двигателя на браузъра.
Можете да намерите горния код на GitHub тук .
В този пример, за по-голяма простота, остарелите navigator.getUserMedia() API се използва, защото той е единственият, който работи без полифилиране в текущата стабилна версия на Chrome. В производствено приложение можем да използваме adapter.js за достъп до потока през по-новата navigator.mediaDevices.getUserMedia() API, еднакво във всички браузъри, но това е извън обхвата на настоящата дискусия.
WebGL
Използването на WebGL от GWT не е много по-различно в сравнение с използването на WebRTC, но е малко по-досадно поради присъщата сложност на стандарта OpenGL.
Нашият подход отразява този, последван в предишния раздел. Резултатът от обвиването може да се види в реализацията на GWT WebGL, използвана в Picshare , които могат да бъдат намерени тук и може да се намери пример за резултатите, получени от GWT тук .
Активирането на WebGL само по себе си всъщност не ни дава възможност за 3D графика. Както пише Грег Таварес :
Това, което много хора не знаят, е, че WebGL всъщност е 2D API, а не 3D API.
3D аритметиката трябва да се изпълнява от някакъв друг код и да се трансформира в 2D изображение за WebGL. Има някои добри GWT библиотеки за 3D WebGL графики. Любимото ми е Паралакс , но за първата версия на Picshare последвахме по-пътека „направи си сам“, като написахме малка библиотека за изобразяване на прости 3D мрежи. Библиотеката ни позволява да дефинираме a перспективна камера и управлява сцена от обекти. Чувствайте се свободни да го проверите, тук .
Компилиране на Java библиотеки на трети страни с GWT
NyARToolkit е чисто Java порт на ARToolKit , софтуерна библиотека за изграждане на приложения за добавена реалност. Портът е написан от японските разработчици на Нятла . Въпреки че оригиналният ARToolKit и версията Nyatla са се разминали до известна степен от първоначалния порт, NyARToolkit все още се поддържа активно и се подобрява.
Базираната на маркери AR е специализирана област и изисква компетентност в компютърното зрение, цифровата обработка на изображенията и математиката, както е видно тук:
Възпроизведено от Документация за ARToolKit .
Възпроизведено от Документация за ARToolKit .
Всички алгоритми, използвани от инструментариума, са документирани и добре разбрани, но пренаписването им от нулата е дълъг и склонен към грешки процес, така че е за предпочитане да се използва съществуващ, доказан инструментариум, като ARToolKit. За съжаление, когато насочвате към мрежата, няма такова нещо на разположение. Най-мощните, усъвършенствани набори от инструменти нямат реализация в JavaScript, език, който се използва предимно за манипулиране на HTML документи и данни. Това е мястото, където GWT доказва своята безценна сила, като ни позволява просто да транслираме NyARToolkit в JavaScript и да го използваме в уеб приложение с много малко неприятности.
Компилиране с GWT
Тъй като проектът GWT по същество е проект на Java, използването на NyARToolkit е само въпрос на импортиране на изходните файлове във вашия източник. Имайте предвид обаче, че тъй като транслирането на GWT кода в JavaScript се извършва на ниво изходен код, имате нужда от източниците на NyARToolkit, а не само от JAR с компилираните класове.
Библиотеката, използвана от Picshare може да се намери тук . Зависи само от пакетите, намерени вътре lib/src и lib/src.markersystem от архива на NyARToolkit тук . Трябва да копираме и импортираме тези пакети в нашия GWT проект.
Трябва да държим тези пакети на трети страни отделно от нашето собствено внедряване, но за да продължим с „GWT-изацията“ на NyARToolkit, трябва да предоставим XML конфигурационен файл, който информира GWT компилатора къде да търси източници. В пакета jp.nyatla.nyartoolkit добавяме файла NyARToolkit.gwt.xml
com.jooink.gwt.nyartoolkitСега, в нашия основен пакет, GWT_NyARToolKit.gwt.xml, ние създаваме основния конфигурационен файл, No source code is available for type java.io.InputStream; did you forget to inherit a required module? , и инструктираме компилатора да включи източника на Nyatla в пътя на класа чрез наследяване от неговия XML файл:
InputStreamВсъщност доста лесно. В повечето случаи това е всичко, което е необходимо, но за съжаление все още не сме приключили. Ако се опитаме да компилираме или изпълним чрез Режим Super Dev на този етап срещаме грешка, която изненадващо гласи:
jreПричината за това е, че NyARToolkit (т.е. Java библиотека, предназначена за Java проекти) използва класове на JRE, които не се поддържат от GWT Емулиран JRE . Ние обсъдихме това накратко в предишния пост.
В този случай проблемът е с java.io.FileInputStream java.io.InputStream java.io.InputStreamReader java.io.StreamTokenizer java.lang.reflect.Array java.nio.ByteBuffer java.nio.ByteOrder и свързани IO класове. В крайна сметка дори не е необходимо да използваме повечето от тези класове, но трябва да осигурим някаква реализация на компилатора. Е, бихме могли да инвестираме много време в ръчно премахване на тези препратки от източника на NyARToolkit, но това би било лудост. GWT ни дава по-добро решение: Осигурете собствени реализации на неподдържаните класове чрез XML тага.
Както е описано в официална документация :
Thetag инструктира компилатора да изкорени отново пътя на източника. Това е полезно за случаите, когато искате да използвате повторно съществуващ Java API за GWT проект, но оригиналният източник не е наличен или не може да се преведе. Честа причина за това е да се емулира част от JRE, неприложена от GWT.
Sois точно това, от което се нуждаем.
Можем да създадем java.lang.reflect.Array директория в проекта GWT, където можем да поставим нашите реализации за класовете, които ни създават проблеми:
FileInputStreamВсички те, с изключение на package java.io; import java.io.InputStream; import com.google.gwt.user.client.Window; public class FileInputStream extends InputStream { public FileInputStream(String filename) { Window.alert('WARNING, FileInputStream created with filename: ' + filename ); } @Override public int read() { return 0; } } , са наистина неизползвани, така че се нуждаем само от тъпи реализации. Например, нашите Window.alert гласи, както следва:
как да използвате шаблон за стартиране
java.lang.reflect.Arraypackage java.lang.reflect; import jp.nyatla.nyartoolkit.core.labeling.rlelabeling.NyARRleLabelFragmentInfo; import jp.nyatla.nyartoolkit.markersystem.utils.SquareStack; import com.google.gwt.user.client.Window; public class Array { public static Object newInstance(Class c, int n) { if( NyARRleLabelFragmentInfo.class.equals(c)) return new NyARRleLabelFragmentInfo[n]; else if(SquareStack.Item.class.equals(c)) return new SquareStack.Item[n]; else Window.alert('Creating array of size ' + n + ' of ' + c.toString()); return null; } } израз в конструктора е полезен по време на разработката. Въпреки че трябва да можем да компилираме класа, ние искаме да гарантираме, че никога няма да го използваме, така че това ще ни предупреди в случай, че класът се използва неволно.
GWT_NyARToolkit.gwt.xml всъщност се използва от кода, от който се нуждаем, така че се изисква не напълно тъпо изпълнение. Това е нашият код:
Sensor.update()Сега, ако поставим // given a drawing context with appropriate width and height // and a where the mediastream is drawn ... // for each video frame // draw the video frame on the canvas ctx.drawImage(video, 0, 0, w, h); // extract image data from the canvas ImageData capt = ctx.getImageData(0, 0, w, h); // convert the image data in a format acceptable by NyARToolkit ImageDataRaster input = new ImageDataRaster(capt); // push the image in to a NyARSensor sensor.update(input); // update the NyARMarkerSystem with the sensor nyar.update(sensor); // the NyARMarkerSystem contains information about the marker patterns and is able to detect them. // After the call to update, all the markers are detected and we can get information for each // marker that was found. if( nyar.isExistMarker( marker_id ) ) { NyARDoubleMatrix44 m = nyar.getMarkerMatrix(marker_id); // m is now the matrix representing the pose (position and orientation) of // the marker in the scene, so we can use it to superimpose an object of // our choice ... } ... модулен файл, можем спокойно да компилираме и използваме NyARToolkit в нашия проект!
Залепване на всичко заедно с GWT
Сега сме в положението да имаме:
- WebRTC, технология, способна да вземе поток от уеб камерата и да го покаже в атаг.
- WebGL, технология, способна да манипулира хардуерно ускорена графика в HTML.
- NyARToolkit, библиотека на Java, способна да заснеме изображение (като масив от пиксели), да търси маркер и, ако бъде намерен, ни дава матрица за трансформация, която напълно определя позицията на маркера в 3D пространството.
Предизвикателството сега е да се интегрират всички тези технологии заедно.
Няма да навлизаме в дълбочина как да постигнем това, но основната идея е да използваме видео изображенията като фон на нашата сцена (текстура, приложена към „далечната“ равнина в изображението по-горе) и да изградим 3D структура на данните което ни позволява да проектираме това изображение в космоса, използвайки резултатите от NyARToolkit.
Тази конструкция ни дава правилната структура за взаимодействие с библиотеката на NyARToolkit за разпознаване на маркери и изчертаване на 3D модела върху сцената на камерата.
Правенето на поток от камера е малко сложно. Видео данните могат да бъдат изтеглени само към елемент. Елементът HTML5 е непрозрачен и не ни позволява директно да извличаме данните от изображението, така че сме принудени да копираме видеото в междинен продукт, да извлечем данните от изображението, да го трансформираме в масив от пиксели и накрая да го изпратим в NyARToolkit's _ | метод. Тогава NyARToolkit може да свърши работата по идентифициране на маркера в изображението и връщане на матрица за трансформация, съответстваща на нейната позиция в нашето 3D пространство.
С тези елементи можем да съпоставим синтетичен обект точно над маркера, в 3D, в видео потока на живо! Благодарение на високата производителност на GWT, ние разполагаме с много изчислителни ресурси, така че дори можем да приложим някои видео ефекти върху платното, като сепия или размазване, преди да го използваме като фон за сцената на WebGL.
Следният съкратен код описва ядрото на процеса:
|_+_|
С тази техника можем да генерираме резултати като тази:
Това е процесът, който използвахме за създаване Picshare , където сте поканени принтирам маркер или покажете го на мобилния си телефон и играйте с AR на базата на маркери във вашия браузър. Наслади се!
Заключителни бележки
Picshare е дългосрочен проект за домашни любимци за нас в Jooink. Първото внедряване датира от няколко години и дори тогава беше достатъчно бързо, за да бъде впечатляващо. В тази връзка можете да видите един от нашите по-ранни експерименти, съставен през 2012 г. и никога не е докосван. Имайте предвид, че в извадката има само един. Другите два прозореца са елементи, показващи резултатите от обработката.
GWT беше достатъчно мощен дори през 2012 г. С пускането на GWT 2.8 получихме много подобрен слой на оперативна съвместимост с JsInterop, допълнително повишаване на производителността. Също така, за празнуването на мнозина, ние също получихме много по-добро развитие и среда за отстраняване на грешки, режим Super Dev. О, да, и поддръжка на Java 8.
Очакваме с нетърпение GWT 3.0!
