The Series

Future of Video Games and Metaverse Industries

Future of Video Games and Metaverse Industries II

Video Game and Metavese Industry Series

1. In the first article of the series, we tried to approach it from an architectural and topological point of view.
2. In the second article of the series, we approached it in terms of data architectures and processing.
3. In the 3rd and last article of the series, we will focus on how we approached the issues discussed in Articles 1 and 2 as a team and what solutions we came up with.

Before this article, please look at The Story of Arsuite Immersive Intelligence article.

• Year 2000s, 3D design and rendering is just a hobby for Alper.
• Between 2000-2017, Many enterprise companies, four academic books, and a software community spoke at 30 conferences.
• Year 2017, the spark of Arsuite

Arsuite has grown and formed after a very long journey of about six years. When Arsuite first started, every component other than the Core Engine was designed 80% appropriately in the current topology. In other words, the cloud-native infrastructure that Arsuite should have and the components that it will/will have, such as Smart Asset Manager, were designed and planned in detail in 2017. Even though we made a 20% improvement/replacement today, the entire platform and the future technical capacity of the platform were calculated in 2017.

The team’s dedication to the goals was the biggest reason this journey was long, tedious, scary and “mostly” exciting.

Think of it from this angle; you want to develop a new platform and engine. Some engines and platforms are quite common when you start developing and have been used for almost 25-30 years. They have ossified habits and communities. You want to do something other than all this. However, since it has not been done before, you have no starting point from which you can take an example. Probably that was the scariest part of the job.

Initially, we experimented with the famous game engine and various platforms to quickly prepare an MVP. For example, in a game engine, you can only get builds from the editor of that platform; you can’t get it any other way. In our experiments, we could bypass that platform’s editor and get build/export directly from the engine. We have also automated mobile application development. The user enters a few parameters, selects the template, and the Android AR App is ready. Since WebAR is in a very early stage in the 2017-2018 period, we looked for some mobile app solutions.

In parallel, extended research and discussions on 3D model algorithms, 3D model rendering and loading algorithms were never missing. In fact, we learned a lot in our tests with game engine platforms and gained two invaluable experiences in these tests.

1. We learned that producing cloud-native and modular solutions with existing game engines and platforms is impossible.
2. We learned that producing dynamic-data-driven solutions with existing 3D model architectures is impossible.

Since the Arsuite team has a profound experience in cloud-native, modular and dynamic architectures that have developed software for a long time in the enterprise world, the results were unsatisfactory. As our team, our aim was not only to develop a new engine or platform but also to create a different engine and platform that meets the needs of today’s world built on truly modern architectures, so the tests were quite challenging.

1. The platform had to be completely cloud-native.
2. Every product produced on the platform had to be completely cloud-native.
3. The platform had to be fully modular.
4. Every product produced on the platform had to be modular.
5. The platform had to be data-driven and dynamic.
6. Every product produced on the platform had to be data-driven and dynamic.

Today, users want to access everything from anywhere, anytime. They want all products such as chat, photo, video, shopping, banking, commerce and video games to be cloud-native on the internet. We can extend this list further, but the remarkable point is that even cumbersome sectors like all banks have quickly adapted to cloud-native. While the video game and 3D industry, which is at the centre of technology, still resists.

Isn’t it tragicomic that the Video Game and 3D industry, which makes money entirely on technology and software, force users to spend thousands of dollars on device setups instead of improving themselves? 

For example, any designer can create an AR/XR scene in one of the known game editors and build and export it in WebGL, infrastructures compatible with web/mobile platforms or target VR glasses. “However, it will be in the form of a one-piece, monolith, static APP.” Everything is great so far; we have an AR/XR app, then what?

We believe the problem begins after this stage. When we set out as Arsuite, we made ourselves a long list of questions/problems. Below we have listed 10 critical questions emerging as blockers ahead of the industry. However, the number of questions is much more than here.

1. How will we upload this 3D scene APP to a server in the cloud and share it with the globe?
2. How do we stream this scene you exported as a monolith block APP?
3. Will these stage and stage materials that we export be suitable for cloud streaming?
4. What performance improvements should we make in this scene where we will export?
   • How do we make sure that the improvements we make will be sufficient?
5. Do we know the data model of this app/scene we will export?
6. Is our data model suitable for the easy and fast delivery of the staging app to large audiences?
7. Will our data model support cloud-based operation and stream logic?
8. How do we make the necessary updates to the scene/app to improve user experience and interaction?
9. How do we send the new feature or asset that we will add to the user to keep the user’s interest alive?
   • How do we run new features and assets in the application?
10. How will our app work as the 3D scene in the app grow?
    • For example, what should we do when our application, which starts with 100 MB, reaches 10,000 MB?
    • How can we deliver a vast new application to the user?

As a result of our tests and discussions with communities, while we were looking for answers to these questions, we realised that the main problem is in the approach strategies of the Video Game and 3D industry to games and 3D assets.

In the Video Game and 3D industry, 3D assets are approached as monolith data blocks, not atomic ones. For example, when a new unit/part is added to a 3D model, this new unit is directly added to that 3D model. So it becomes an embedded part of that model. In the Cloud-Native world, non-modular products have little chance of survival.

Reminder: 98% of the Video Game and 3D industry only consists of end-users. Some platforms, game engines, game editors and 3D design tools exist, and those users try to develop games or 3D models with them. Therefore, most users are interested in something other than atomic parts or the core architecture of the technology.

3D file formats are a database of 3D models and scenes. The 3D model and scene can be as dynamic and fast as its database.

Alper Akalin

Arsuite, on the other hand, approaches the event from many different perspectives. Everything in Arsuite is a dynamic and updatable atomic data block. In Arsuite, each asset is stored and managed by dividing it into atomic parts within the framework of the SoC principle in the big picture. Thus, everything in Arsuite is used as a plug-and-play anywhere and anytime.

Create Once, Run Anywhere

Arsuite

Let’s compare several common 3D file formats with Arsuite/Arsx. After this comparison, let’s try to answer the question of why Arsx. This review is not a criticism, just an analysis.

USD/USDz file format can store all the animation and interactive features a 3D scene should have. However, usd keeps all texture, material, etc., data in a single file. You cannot modify or compress in run-time. An AR scene 10MB in Arsuite/arsx file format can be around 80-100MB in/3Dmodel usd format. In addition, you can compress Usd / usdz with an algorithm such as Draco, but you cannot open it as AR on iPhone phones. (.arsx is 8 times smaller and 14 times faster than USD.)

OBJ file format keeps everything as plain text/string. It does not support animation, interactivity and advanced compression. The size of the car model in the 3 Million Polygons Sample – Aston Martin DBX example you can see in the link is 445 MB in .obj file format. Its size in Arsuite/arsx file format is 65 MB. (.arsx is 7 times smaller than obj and, on average, 320 times faster.)

FBX file format keeps data in a single file in an algorithm close to LinkedList architecture. It supports features such as animation, interaction and binary compression. Again, the car model in the 3 Million Polygons Sample – Aston Martin DBX example is 118 MB with .fbx binary compression. Its size in Arsuite/arsx file format is 65 MB. (.arsx is about 2x smaller and 30x faster than fbx.)

GLTF/GLB is currently the only file format we consider as a competitor to Arsuite/arsx. Gltf is about 10-30% smaller than .arsx for now when compressed with an algorithm like Draco. However, in any case, arsx is about 10 times faster than gltf in terms of load/render time.

In short, the OBJ file format was released in 1980, and the FBX file format was released in 1996. Since successfully serving the industry, they have become the two most common file formats. Many updates have been made for these file formats. However, they must still be upgraded or updated with today’s cloud-native requirements. Many intermediate solutions can be produced with these file formats for Cloud-Native architectures, but these intermediate solutions will further complicate the process; we tried it, don’t try it. 🙂

We hear you, who say that the file format is that important. There is no need to mention the importance of databases and data algorithms here. On the other hand, these files are databases for vertices, polygons and assets. The better you choose or create your database, the more surprising the results will be. In this context, Arsx is in a very different position with its unique data architecture, dynamic asset loading, etc. For example, .arsx keeps only the basic information of the 3D model with a unique algorithm.

Please look at the average speed column in the Arsuite & Others Comparison Table. The tests are done with a 3D model with 1.5 million polygons and an Nvidia GTX860 graphics card. You can find the video on the Arsuite Youtube channel.

The remarkable difference between the arsuite/arsx engine and the others becomes noticeable as the file size grows. For example, while the load/render time of a .obj 3D model with 1.5 million polygons is around 320 seconds, the load/render time of an obj 3D model with 3 million polygons increases to 960-1200 seconds. The Arsuite/arsx load/render time of the same 3D model with 1.5 million polygons is only 1 second, while the Arsuite/arsx load/render time of the same model with 3 million polygons is only 1.1-1.2 seconds. In other words, as the file size grows, the real power of the Arsuite/Arsx engine family emerges. This is the magic.

We have only examined the Obj, Fbx, Usd, and Gltf formats. Even these four file formats are very different from each other in terms of architecture, size and speed. Based on the performance differences with Arsuite/arsx, you can calculate the differences between them. There are more than 60 3D model file formats on the market; they all have similar algorithms. The most crucial point is that they all are unsuitable for cloud/stream-based web/mobile games and applications.

Today, all platforms that claim to be dynamic while creating a 3D scene put all 3D mesh, texture and materials into the 3D scene, then bake/build/export. For example, we need an XR scene for a chair. Let this chair have 10 different woods and 10 different fabrics. Let’s say 20 different views are created, ignoring diagonal combinations. In this case, the math would look like this:

• In order to obtain 10 photorealistic chairs XR presentations with 10 different wooden appearances, at least 10 x 6 = 60 texture/material must be loaded into the XR app.
• In order to obtain 10 photorealistic chairs XR presentations with 10 different fabric appearances, at least 10 x 6 = 60 texture/material must be loaded into the XR app.

In this case, our XR app will have 120 textures/materials. These numbers are the minimum figures. This number will increase to 240 when you want a higher image quality. When this chair XR app is requested to be sent to the user, all materials and assets will be sent as a single package in a single app/file.

The players or the end users will probably have to download many files they will never use. Only 2 different pattern tests could be enough for the users/players. They wouldn’t need another file after the 3D model and 8-10 textures in this case. But they had to download a 3D model + 120 files. 3D designers know that high-quality textures have larger file sizes than 3D models. As an end user, why would they download 100-240 MB files instead of 7-8 MB?

Worse, this 3D scene/model/app is no longer flexible. So when you want to add a new pattern/texture later, you must bake/build/export this app again. The user, on the other hand, has to re-download the entire app for the latest scene. In today’s cloud-based world, immutable/updatable static data is unacceptable.

Arsuite/Arsx has been developed and continues to be developed as a solution to this and many similar problems.

The Rise of Arsuite Modularity and Cloud Computing – Streaming

Anyone who wants to create something new, different and more advanced in any engineering field should start their dream project from scratch. Even though they don’t have to create the most atomic parts, they should thoroughly absorb the most atomic elements, choose the most suitable one and start the project that way.

At Arsuite, we had to design our own data architecture and cloud platform from the ground up and create it from scratch. We would have loved to have some components ready, but unfortunately, we did not have such a chance.

Arsuite Dynamic Asset Loading – aDAL

Arsuite/Arsx is just a database containing basic information about the 3D model. It does not store any details or ownership information. For example, texture, material or animation components are loaded into Arsx at run time. In this way, Arsx can always be shaped according to the stage requirements for which it is called in all circumstances. This loading method is similar to Dependency Injection in advanced software engineering. At Arsuite, we call this Dynamic Asset Loading. In the Arsuite Platform, Arsx and every component are dynamic and modular. In Arsuite, everything is treated as atomic modules, and each atomic element is loaded into the scene at run time.

Dynamic Asset Loading is essential for modularity and cloud-native operations. Dynamic Asset Loading works wonders not only in micro-transactions but also in macro-transactions. Thanks to this technology we have developed, we can divide the 3D scenes and models into minimal parts and transmit the module to the desired location quickly. Then Arsuite can load and render 3D scenes divided into small pieces at the actual run-time.

Arsuite Cloud Computing & Streaming

Arsuite 3D does not use external cloud services due to the world’s different requirements and performance concerns. Arsuite serves as a cloud service provider on its own servers in various locations globally.

Arsuite does not perform server-side rendering. Each Arsuite/Arsx scene is loaded and rendered at run-time on client devices. This rule applies to all scenes, from the smallest to the largest. Client Side Rendering is one of the most significant features of the Arsuite/Arsx engine family.

If your infrastructure and technologies are not specially designed and do not have top-notch optimizations, client-side creation of Hyper-Realistic or Photo-Realistic scenes can be challenging. You should develop customized intelligent tools to deliver high-quality files to the client, load/render on the client, and manage communication between clients.

Classification and management of assets is a problem well known to anyone who develops and designs in the Video Game and 3D world. The size and variety of files complicate the management of assets.

We said that 3D file formats are databases of 3D scenes. Massive and monolith 3D files/databases have emerged to manage this file/data diversity in the 3D world. A lot of information is required for a 3D model/scene, such as 3D mesh, texture, material, rig and animation. Managing such a large amount of data with different characteristics is troublesome. Since the game developer and 3D designer should not waste time with such issues, 3D design tool developers have preferred to develop huge 3D file formats to keep all this data. Although this preference is a good solution in the conditions of that day, it cannot adapt to the rules of today’s cloud-native world.

Arsuite Smart Asset Manager – aSAM

Arsuite smart and centralized asset manager distributes and manages components such as 3D mesh, texture, material, skybox and animation required for a 3D scene with a unique and highly advanced algorithm. For example, you can upload a chair 3D model like the one above to Arsuite once and use it in millions of 3D scenes. You can use this chair with a different texture or material combination in each scene.

Arsuite stores all data and assets required for this scene to be created in different places as distributed. When the Client/User wants to examine this scene, aSAM finds all the components and sends them to the user as a stream. All rendering and load operations are done on the client/user machine at run time.

• When the designer makes any changes to this scene, the scene is instantly rendered according to the new changes. There is no need to recreate the scene for this.
• When the user wants to examine different variations of this scene, only the data of the desired variation is sent to the user. Thus, unnecessary file and data transfer is not made.

Arsuite Smart Connection Router – aTUBE

If you are developing a Cloud-Native and Distributed product, load balancing will have a critical role in your life. Load balancing solutions manage the load distribution on the platforms. However, for the many reasons we have mentioned so far, more than a traditional load-balancing product will be needed in the cloud gaming and 3D world.

For example, when a player connects to a game from any point, LB will direct that player to the most suitable server. The 3D world and games are different from the classic websites. In the 3D world and games, users or players must constantly act and communicate with each other. A player in Singapore and a player in the UK may need to be in contact with each other in the fastest and most uninterrupted way. In this case, the classic LBs have nothing to do. More different and intelligent solutions are needed to establish this seamless and flawless connection.

Arsuite Smart Connection Router helps any user/player from the moment he logs in to the system and manages his connection. While establishing the best connection between the server and the user also ensures that all connections between players are healthy and fair. aTUBE constantly checks all client-server connections and server statuses and ensures the best connection performance. For example, if the connection speeds of player A and player B in the X game are at a level that will affect the game quality and fair play, it warns the players or does not allow the match.

Arsuite Smart Stream API – aSSA

We have stored the 3D assets and data in an atomically distributed architecture. After establishing the client-server and client-client connections in a highly optimized way, all that remains is to send the data to the users. Since the data to be sent will be very diverse, 3D and extensive in size, it needs to be approached more carefully and differently. Arsuite Smart Stream API sends 3D scenes and assets to the client depending on the client’s device features and connection strength. For example, the chair above can be sent to one user with a 2K texture and a 2K skybox, while it can be sent to another user with a 4K texture and a 4K skybox.

Conclusion

Arsuite is not an AI-powered platform. The Arsuite platform is a highly advanced AI. Every step, from the design of 3D scenes to delivery to the client, is monitored and managed by Arsuite intelligent tools.

Let’s give an example. When user A calls scene X at any T time, a unique key is generated, and all movements of user A are monitored with this key. During this monitoring, the user is directed to the most uninterrupted node and the appropriate server. If there is an error in the user experience, the system immediately generates a warning, directing the user to the best service. Thus, it is ensured that the user/player receives the best service. Since the errors can be tracked end-to-end on a scenario-based basis, immediate solutions are produced.

Reminder: This tracking is only anonymous to improve the user experience. The user’s personal information is never within the scope of this monitoring.

The Series

Future of Video Games and Metaverse Industries

Future of Video Games and Metaverse Industries II

Arsuite, Architecting Tomorrow’s Immersion, Today!