Today Bernstein came in to give us an interview although half of the class was spent programming as Bernstein set up the lighting and recording equipment. During the first half of class I had the idea of adding some console.logs in the code to help debug. ChromiumXR is basically split into about 5 codebases, which are layered like this:
[Chromium Layer for rendering the webpages]
Chromium (C++, browser by Google that Google Chrome is based off of)
-> Chromium Embedded Framework (C++, library for embedding Chromium into programs)
-> ChromeTex Server (C#, library by me that attaches to CEF and creates wrapper functions that can be used by Unity)
[Unity3d Layer for rendering on the AR device]
-> ChromeTex Client (C#, Unity3d library I made that makes it so you can easily use Chromium in a Unity3d scene)
[Web/Application Layer for creating the AR content]
-> ChromiumXR Low Level API (js, Javascript library I made that adds low level WebGL functions for sending HTML and web content to the AR compositor)
-> xr.js (js, high level api to make creating AR content quick and easy)
At this point all those layers are coded and pretty much functional, although there has still been a flickering problem for a while. The ChromeTex Client has been rendering blank frames and I've spent most of my time trying to debug it in that layer. During this class I had the idea of assuming it's not a problem with the rendering or a error in parsing the data sent by the ChromeTex Server, but rather an issue with Chromium Embedded Framework itself. To test this theory I logged the data received by CEF in ChromeTex Server and discovered that CEF sends the correct frame then instantly sends a blank frame which causes the flickering. By ignoring every other frame I managed to solve the flickering without any noticeable performance issues which means I finally tackled the only major bug for ChromiumXR. After that we had an interview about the project which went pretty good.
🌭 > dillon's weblog_
Comments