 Cool, I think, are we gonna just kick off? Let's kick off. Hey everyone, hope you Drupal South has been going great so far. I'm Mel, and this is Josh, and we're from the Australian War Memorial. So this is actually our first time presenting, so it claps for us for our first milestone. I've been working for the AWS for about three years as a developer, and currently I lead the development team, but my whole development career has been going for about 10 years, which is just about long enough to outlive a CQCumper. Josh is another one of AWS Full Stack developers. He's a JavaScript wizard, and he's a back-end crack-in, but I'll let him tell you more about himself. Hey all, I've been a web developer for about seven years now. Been at the War Memorial for two years, mostly doing Drupal stuff, React and Voo, but kind of just dabbling pretty much every random web technology around. Cool, so now that you know more about us, let's tell you about the project that we've been building for the Memorial. So as technology advances, the Memorial's always trying to figure out new ways to communicate walkish route of people. Through online resources, we've been able to reach a much larger audience and reach people that really can't physically get to the Memorial. This is where this project comes in, with the sponsorship of Lightos, we were able to build a 3D experience that lets you get around, look around, spin around everything of large technology objects. Yeah. Cool, so this project had to be able to display a 3D object or a 360 image, which would then be used to set a scene. And in each of these scenes, a content author would be able to place a button on the 360 space or object. These buttons could contain a transition to a new scene or information that would be displayed in a pop-up. And the pop-up could also contain a mixture of images, videos, or free text. But it also had to be accessible to a mass audience. So we had to make this available external to the physical Memorial. We opted for a web solution to achieve this. Now, when someone hears the term 360, they might assume that they would require a headset, but reports show only about 10% of the population are using them. We did support basic VR headsets for this project, but our website statistics show that most of our audience are on their phones or their computers. So our primary focus was on those. There's also a requirement to let a project be used offline. So it could be displayed on interactive screens in the Memorial or externally. Our web solution worked well for this because we were able to export the project into static files and host it on an internal server. So now we've talked a bit about the project. We thought we might just touch on a few of the objects that we've used for the first five experiences. So we've got the Mark IV tank, also known as Grid, the Avro Landcaster B1, also known as G for George, the Lockheed Hudson Bomber, HMAS Sydney IV, and the Australian produced Bushmaster. Although these are the first five objects, we've built the project so content editors can continue to add things. And we're also looking at using the project to take snapshots of galleries and big events as well. Okay, but how do we build this? Well, let's kick it off with the back end. If you look at this high level diagram, you can see that we're using Drupal 8. This is kind of why we're all here this week, but why Drupal 8? The AWM website is built in Drupal 8. Our content authors use this every day to make changes to the website. We wanted to build this project in a space that was familiar to them. This way, the authors would be able to continuously update the experiences when they gathered new information on objects. So now that we decided on our back end, we had to work out a way to make this easy for the content authors to create and then send that data to a front end. This was done with custom paragraphs to allow the authors to heavily customize the experiences which would then take and convert into a custom rest API. The API was then sent to the front end to display. Well, this all sounds simple enough, but a simple process does not always equal a really easy development period. So let's break down a couple of the issues that we face. We have a massive amount of data nesting. One experience is over 3,800 lines of nicely formatted JSON code. The issue stems from how much data is needed for each small element. If we have a look at the button, for example, this single element requires information for is the button an informational pop up or is it a transitional button? And then if it's a transitional button, we need the words to display to the front end, the location of the transition, the camera facing point for when the transition happens, the position of the button, which needs to be separated into XYZ coordinates, the rotation of the button, which also needs to be separated into XYZ coordinates. And then if it's an informational button, we need the type of button that defines the icon that is displayed. Again, the position of the button and the rotation of the button, the title of the pop up button, if it has audio and if it does, what's the file audio attachment, the pop up attachment allocation? And now times that single pop up information for each single pop up that's displayed. The experience data gets long and messy and this is just the buttons. There is also data for the scene set up, the introduction pages, and then the content inside of the pop ups. So yeah, that's a lot of data to track and to handle, which leads to the next issue that we faced. There's a disconnect from our front end display. At the moment in this time, authors are basically entering data blind and are required to save the backend node before being able to see how everything will display, which is kind of what's expected in Drupal, but in the 360 world, this becomes an issue. This is because of our use of custom paragraphs, which while helping with the massive amount of data handling for parent child relationships, we're asking our authors to essentially enter in data blind and lots of it. So the information, imagine having to save all that information, checking the front end display, noticing you're way off, going back to the backend, repeating this process a hundred times until you get it exactly right. Our solution to this is to build a scene GUI. This will allow our content authors to place the buttons in a scene and visually sit them with around until they are in the right location. But we'll talk about this a little bit more later on. I'm gonna let Josh take the reins and tell you about the front end. Cool. It's okay. What are you doing? So the front end really consists of a few main parts. We've got React Native up the top and then we're using a library called React 360 that I'll explain a bit later. And then it all goes down into a native module and then into web workers. But we'll go on to speak about what is React 360 and why we chose it. So React 360 is a framework built by Facebook for making interactive experiences. It is built on React Native and then on top of 3JS and one of the big learning curves with it is it's heavily using web workers to achieve the desired performance. Because when you look around, we're still having to keep a track of all the buttons and their movements and everything like that. And I think one of the biggest challenges we had was working out how to coordinate these web workers and we're just gonna talk quickly about them. I put a little lemming up there because that's how I interpret web workers. Their little lemmings running around helping us. But yeah, so for anyone that doesn't know, a web worker is a modern browser feature that allows code to run outside of the main window context in a separate thread. So it basically lets you multi-thread your web browser applications. They're useful on heavy workloads like this where you need the main thread to not be locked up from rendering. Because they're in a separate context, however, they are missing a few things like they don't have access to the window object or history. So you kind of need to help them along a little bit. And to address this, we built a native module that is written in React, that's injected to React 360 and then through to all the web workers. This lets us communicate with them and lets us do some really cool things like grabbing information about large assets that are loading in the background, resizing the canvas element and repositioning pop-up buttons when the window size changes and updating application state outside of the canvas like opening a pop-up over the top of it or a notification, something like that. So here's a quick component diagram. If anyone's done any kind of React or component-based JavaScript stuff, it's pretty straightforward. We've got the experience that fetches all the data and then we've got multiple scenes. We've got a model viewer for the 3D objects that you will see later and then we've got buttons. Now the buttons can transition to a new scene which just causes a re-render throughout the state and there's also the pop-up which is using the native module to render a pop-up actually on the main thread and lock the camera from rotating because we have a lot of information in our pop-ups. Now, putting it all together it kind of looks a bit like this in a high level way. It's really using Drupal 8's rest endpoints heavily which is really awesome because they work really well but yeah, you put it all together and we have a really nice module front end, back end and yeah, but now it's time for an example of what it actually looks like because we've seen some data but what the actual module outputs. So yeah, this is just a montage of it running but yeah, it kind of runs like a YouTube video embedded on a page. Cool, so while we're proud of our current process we're actually not finished yet and we're going to share with you what's on our roadmap for this module. We're looking to introduce the ability to upload 360 videos as an optional scene background. This will give more movement to an experience with the idea that there are simple movements rather than one massive 360 video but if you wanted to upload an entire thing we're not going to stop you. So we spoke about the GUI before and how it's pretty disconnected. We've been working pretty heavily on fixing that so content creators can create experiences a lot quicker and easier and we've got like a quick little demo of what we've got going so far and we're basically looking at embedding a cut down version of the application alongside the paragraphs. So yeah, you can precisely place things and it just makes a lot of sense really. And we want to dig deeper into VR headset compatibility as right now we only really support Google Cardboard. This is aimed to be done by building a downloadable application for places like the Oculus Store and even at some point a mobile application but in order to do this we face one major update coming. Cool, so React 360 is actually getting the first major increment which is going to be awesome and we're really keen to incorporate a lot of its features into the module. Some of the big changes that are happening with it is React Native has been removed for just plain reacts throughout the whole application. Then moving towards WebGL is the render engine so 3GS won't be there. It also means that the web workers won't be so much of an issue in the future and we're hoping that this will let us introduce more advanced state management into it like Redux or MobX. And the last one that is really exciting is the WebXR standard. If anyone knows it, it's a standard that dictates how you should be communicating with VR headsets. Came out about last month and they're looking at supporting that as well. So hopefully more advanced headsets and new headsets that are coming out will support this as well. Finally, we want to open source this project to anyone who might be keen into building their own 360 experience. Our overall goal if you heard the keynote is to build a community that can help build this project for many different user cases. I do wish I could give links today but we'll only open sources after the fifth and final object's been completed. That's looking to be the second half of 2020. But if you wanted to start doing this yesterday then send us an email because we're more than happy to help point you in the right direction and send you code. So we're just about to hit question time but I just wanted to take a moment to thank these three people on the screen. Without our developers, Kate and John, we wouldn't have been, this wouldn't have been possible. There were many times that they doubted they couldn't do it but they managed to create this project. And then we can't forget Lloyd who without, we would have never been able to make this project look nearly as damn fine as it does. They couldn't be here today but we know that they're watching this in the future. If you ever run into them, make sure that you tell them that they read people. If what we've shown you looks amazing and you want to see more, the project is currently available on our site. The URL is up now. We also have a QR code. Josh says that no one uses these anymore. Please prove him wrong. They don't. But we have time for some questions but if you guys have questions later, please do tap us on the shoulder and say hi and we've also got our GitHub things up there and our emails. Cool. Thanks everyone. Thank you. Has anyone got any questions? Have you solved their offline? Sorry, so basically because it is actually just running off Drupal REST point, so that's the connection point. We've actually made it so that you can just take the Drupal REST point, save it as a JSON file, put it in the root of the application and it will just run. So yeah, we're looking at doing that because some of the people want to put it on tablets inside the memorial but yeah, it does run without it. You just also have to put it all the assets related to it in the static assets folder that's in the root as well. Yeah. Is anyone else? No, well, help me save. Oh yeah, one more. For the recording sake. So I'll be interested to understand how much of everything you're managing internally with your own team and... It's 100% built at this round more or more by the internal development team. Congratulations. Thank you. That's awesome. And follow our question, how much of the $500 million new building funding are you gonna get? None. Sadly. We'll petition on your behalf. Thanks. Last chance. You mentioned you're gonna be open sourcing it. Yep. Are you expecting it to be as a kind of turnkey solution for anyone or is the next person who tries to spin it up gonna have to have really deep react knowledge to get it running? Do you want me to speak on this or do you wanna speak? You're a bit of both really. Okay. But the idea is that it'll be a module that someone can install without any development knowledge. And then the open source bit. Yeah, so we're still tossing up how the front end stuff will work but basically the module is gonna come with the compiler driver script. You install the module, add your scenes and your objects and it should just work. And I think the other, the plan for the front end is we'll probably be putting it on GitHub as well if anyone wants to play with that. In theory, you could just like we were saying before I had a static JSON file, if you wanted to you could make a WordPress plugin, whatever. So yeah, should be pretty much just turnkey install add your stuff and it'll work. Yeah, so thanks to Melissa and Joshua. Thank you.