Video Game ve Metaverse sektörlerini

• Serinin 1. makalesinde mimari ve topology açıdan yaklaşmaya çalıştık.
• Serininin 2. makalesinde data mimarileri ve data processing açıdan yaklaşmaya çalıştık.
• Serinin 3. ve bu son makalesinde 1 ve 2. Makalelerde tartıştığımız konulara ekip olarak bir nasıl yaklaştık ve ne gibi çözümler ürettik gibi konuların üzerinde duracağız.

Bu makale’den önce The Story of Arsuite Immersive Intelligence makalesine bir göz atmanız iyi olabilir. 

• Sene 2000’ler 3D design ve rendering Alper için sadece bir hobi.
• 2000-2017 arasında birçok enterprise firma, 4 akademik kitap, bir yazılım topluluğu 30 kadar konferansta konuşma.
• Sene 2017 Arsuite kıvılcımı

Arsuite yaklaşık 6 yıl süren çok uzun bir yolculuktan sonra olgunlaştı. Arsuite ilk başladığında Core Engine dışındaki her bileşen şimdiki topology’de 80% uygun şekilde tasarlanmıştı. Yani Arsuite’nin sahip olması gereken cloud-native alt yapı, Smart Asset Manager gibi sahip olacağı/olduğu bileşenler 2017 yılında ince ince ve detaylı olarak tasarlanmış ve planlanmıştı. Bugün 20% lik bir iyileştirme/değiştirme yapmış olsak da tüm platform ve platformun geleceği teknik kapasite 2017 de hesaplanmıştı. 

Zaman zaman sıkıcı, korkutucu en çok da heyecanlı bu yolculuğun biraz uzun olmasının en büyük nedeni tüm ekibin hedeflere olan bağlılığıydı. 

Şöyle düşünün, yeni bir platform ve engine geliştirmek istiyorsunuz. Siz geliştirmeye başladığınızda olukça yaygın ve neredeyse 25-30 yıldır kullanılan bazı engine ve platformlar var. Bunların kemikleşmiş bir alışkanlıkları ve toplulukları var. Siz tüm bunların dışında birşey yapmak istiyorsunuz. Ancak daha önce yapılmadığından elinizde örnek alabileceğiniz hiçbir başlangıç noktası yok. Sanırız işin en korkutucu yanı burasıydı. 

Başlangıçta hızlıca bir MVP hazırlamak için meşhur game engine ve çeşitli platformlarla denemeler yaptık. Örneğin bir game engine’de sadece o platformun editöründen build alabiliyorsunuz, başka türlü alamıyorsunuz. Biz yaptığımız denemelerde o platformun editörünü bypass edip direk engine üzerinden build/export alabilir duruma gelmiştik. Mobile platformlar için özellikle Android platformlar için mobil uygulama geliştirmeyi de otomatize etmiştik. Kullanıcı birkaç parametre giriyor, template seçiyor ve ta-da Android AR App hazır. 2017-2018 aralığında WebAR çok erken evre olduğundan mobile app çözümleri aramıştık. 

Paralelde 3D model algoritmaları, 3D model rendering ve loading algoritmaları üzerine uzun araştırma ve tartışmalar hiç eksik olmuyordu. Aslında game engine platformları ile yaptığımız testlerde çok şey öğrendik. Ancak bu testlerde iki paha biçilemez tecrübe edindik. 

1. Mevcut game engine ve platformlar ile cloud-native ve modüler çözümler üretmenin imkansız olduğunu öğrendik.
2. Mevcut 3D model mimarileri ile dynamic-data-driven çözümler üretmenin imkansız olduğunu öğrendik.

Arsuite ekibi enterprise dünyada uzun süre yazılım geliştirmiş cloud-native, modüler ve dinamik mimariler konusunda oldukça derin bir tecrübeye sahip olduğundan elde edilen sonuçlar kimseyi memnun etmiyordu. Ekip olarak amacımız sadece yeni bir engine ya da platform geliştirmek değil, gerçekten modern mimariler üzerine kurulmuş günümüz dünyasının ihtiyaçlarını karşılayan farklı bir engine ve platform yaratmak olduğundan testler oldukça çetin geçiyordu. 

1. Platform tamamen cloud-native olmalıydı.
2. Platformda üretilen her ürün tamamen cloud-native olmalıydı.
3. Platform tamamen modüler olmalıydı.
4. Platformda üretilen her ürün modüler olmalıydı.
5. Platform data-driven ve dinamik olmalıydı.
6. Platformda üretilen her ürün data driven ve dinamik olmalıydı.

Günümüzde kullanıcılar her şeye her yerden her zaman erişmek istiyorlar. Tüm chat, foto, video, alış-veriş, bankacılık, ticaret ve video game gibi tüm ürünlerin internette yani cloud-native olmasını istiyorlar. Bu listeyi daha da uzatabiliriz ancak burada dikkat çekici nokta tüm bankalar gibi hantal sektörler bile cloud-native’e hızlıca adapte olmuşken teknolojinin merkesinde olan video game ve 3D endüstrisi hala ayak diremektedir.

Tamamen teknoloji ve yazılım üzerinden para kazanan Video Game ve 3D endüstrisinin kendilerini geliştirmek yerine kullanıcılardan binlerce dolarlık setup’lar istemesi traji-komik değil mi? 

Arsuite olara yola çıktığımızda kendimize uzun bir soru/problem listesi yaptık. Örneğin herhangi bir tasarımcı bilinen game editorlerinden birisinde bir AR/XR sahne yaratıp bunu WebGL vb alt yapılarda web/mobile platformlara uyumlu olarak, ya da bir VR gözlüğü hedef alarak build alıp export edebilir. “Ancak bu tek parça ve statik bir APP şeklinde olacaktır.” Buraya kadar herşey süper, peki sonra? 

Bizce problem bu aşamadan sonra başlıyor. Aşağıda sektörün önünde bloker olarak ortaya çıkan 10 tane temel soru listeledik.  Ancak soruların sayısı buradakinden çok daha fazladır.

1. Bu 3D sahne APP ’ini cloud ta bir servera yükleyip tüm dünya ile nasıl paylaşacağız?
2. Tek parça blok bir APP olarak export ettiğiniz bu sahneyi nasıl stream edeceğiz?
3. Export alacağımız bu sahne ve sahne materyalleri cloud-stream için uygun olacak mı?
4. Export alacağımız bu sahnede ne gibi performans iyileştirmeleri yapmalıyız?
   1. Yapacağımız iyileştirmelerin yeterli olacağından nasıl emin olacağız?
5. Export edeceğimiz bu app/sahnenin data modeline hakim miyiz?
6. Data modelimiz sahne app’nin geniş kitlere kolay ve hızlıca ulaştırılması için uygun mu?
7. Data modelimiz cloud-based çalışma ve stream mantığını destekleyecek mi?
8. Kullanıcı deneyimi ve etkileşimini iyileştirmek için gereken güncelelemeleri sahne/app’te nasıl yapacağız?
9. Kullanıcıların ilgisini canlı tutmak için ekleyeceğimiz yeni özellik ya da asseti kullanıcıya nasıl göndereğiz?
   1.  Yeni özellik ve assetleri uygulama içerisinde nasıl çalıştırağız?
10. Uygulamadaki 3D sahne büyüdükçe uygulamamız nasıl çalışacak?
    1. Örneğin 100 MB ile başlayan uygulamamız 10.000 MB a ulaşınca neler yapmalıyız?
    2. Oldukça büyümüş yeni uygulamayı kullanıcıya nasıl ulaştırabiliriz?

Bu sorular cevap ararken yaptığımız testler ve topluluklar ile görüşmelerimiz sonucunda temel problemin Video Game ve 3D endüstrisinin oyun ve 3D assetlere yaklaşım stratejilerinde olduğunu gördük. 

Video Game ve 3D sektöründe 3D assetlere atomik data blokları olarak değil de monolith data blokları olarak yaklaşılıyor. Örneğin bir 3D model içerisine yeni bir birim/parça eklendiğinde bu yeni birim doğrudan o 3D modele eklemleniyor. Yani o modelin ayrılamaz/unmodüler bir parçası haline geliyor. Cloud-Native dünya’da modüler olmayan ürünlerin yaşama şansı çok azdır.

3D dosyalar veya file formatlar 3D model ve scene’ler için bir databese’dir. 3D model/scene database’i algoritması kadar dinamik ve hızlı olacaktır. 

Reminder: Aslında Video Game ve 3D endüstrisinin 98%’i sadece kullanıcıdır. Yani bazı platform, game engine, game editör ve 3D designer araçları var ve bunlarla oyun ya da 3D model geliştirmeye çalışan kullanıcılar var. O nedenle çoğu kullanıcı atomik parçalarla ya da teknolojinin core mimarisi ile çok ilgilenmiyor.

Arsuite ise olaya çok farklı açılardan yaklaşmaktadır. Arsuite’de herşey dinamik ve güncellenebilir birer atomik veri bloğudur. Arsuite’de her asset kendi içerisinde ve büyük resimde SoC prensibi çerçevesinde atomik parçalara bölünerek saklanmakta ve yönetilmektedir. Böylece Arsuite’de herşey, her yerde ve her zaman plug-and-play olarak kullanılmaktadır.

Globalde yaygın birkaç 3D dosya formatını Arsuite/Arsx ile karşılaştırmalı inceleyelim. Bu karşılaştırmadan sonra neden Arsx sorusunu cevaplamaya çalışalım. Bu inceleme bir eleştiri değil, sadece bir analizdir.

USD/USDz dosya formatı bir 3D sahnede olması gereken tüm animasyon ve interaktif özellikleri taşıyabiliyor. Ancak usd tüm texture, material vb dataları tek bir dosyada tutuyor. Run-time’da değiştiremiyor ve sıkıştıramıyorsunuz. Arsuite/arsx dosya format ile 10MB olan bir AR sahnesi/3Dmodel usd formatında 80-100MB civarında olabiliyor. Ek olarak Usd/usdz yi draco vb bir algoritma ile sıkıştırabilirsiniz ancak iPhone telefonlarda AR olarak açamıyorsunuz. (.arsx, usd’den 8 kat küçük ve 14 kat hızlıdır.)

OBJ dosya formatı herşeyi düz bir text/string olarak tutuyor. Animasyon, pinteraktivite ve gelişmiş sıkıştırmayı desteklemiyor. Linkte görebileceğiniz 3 Million Polygons Sample – Aston Martin DBX örneğindeki araba modelinin .obj dosya formatındaki boyutu 445 MB’tır. Arsuite/arsx dosya formatındaki boyutu ise 65 MB’tır. (.arsx, obj’den 7 kat küçük ve ortalama 320 kat hızlıdır.)

FBX dosya formatı dataları LinkedList mimarisine yakın bir algoritmada tek bir dosyada tutuyor. Animasyon, interactivite ve binary compression gibi özellikleri destekliyor. Yine 3 Million Polygons Sample – Aston Martin DBX örneğindeki araba modeli .fbx binary compression ile 118 MB’tır. Arsuite/arsx dosya formatındaki boyutu ise 65 MB’tır. (.arsx, fbx’ten yaklaşık 2 kat küçük ve 30 kat hızlıdır.)

GLTF/GLB şu anda Arsuite/arsx rakip olarak gördüğümüz tek dosya formatıdır. Gltf, draco gibi bir algoritma ile sıkıştırıldığında şimdilik .arsx ten 10-30 % civarında daha küçüktür. Ancak her koşulda arsx load/render time olarak gltf ‘ten yaklaşık 10 kat daha hızlıdır. 

Özetle, OBJ dosya formatı 1980’de, FBX dosya formatı ise 1996 yılında yayınlanmıştır. Bugüne kadar sektöre başarıyla hizmet ettiklerinden en yaygın iki dosya formayı olmayı başardılar. Bu dosya formatları için birçok güncelleme yapıldı. Ancak hiçbiri yapısal anlamda günümüz cloud-native gereksinimleri göz önünde bulundurularak yapılmadı. Cloud-Native mimariler için bu dosya formatları ile birçok ara çözüm üretilebilir ancak bu ara çözümler süreci daha da karmaşıklaştıracaktır, biz denedik, siz denemeyin. 🙂

Dosya formatı bu kadar önemli mi diyenler, sizi de duyuyoruz. Bu dosyalar 3D polygon ve assetler için birer database’dir. Database ve data algoritamalarının önemine değinmeye bile gerek yok. Siz database’inizi ne kadar iyi seçer ve kurgularsanız elde edeceğiniz sonuçlar o kadar şaşırtıcı olacaktır. Bu bağlamda  Arsx kendine has data mimarisi ve dynamic asset loading vb özellikler ile çok daha farklı bir konumdadır. Örneğin .arsx 3D modele ait sadece temel bilgileri özel bir algoritma ile tutmaktadır.  

Arsuite & Others Comparison Table daki average speed kolonuna bakmanızı rica ederiz. Buradaki testler 1.5 milyon polygona sahip bir 3D model ve Nvidia GTX860 ekran kartı ile yapılmıştır. Arsuite Youtube kanalında videosunu bulabilirsiniz. 

Arsuite/arsx engine ile diğerleri arasındaki gerçek fark dosya boyutu büyüdükçe ortaya çıkmaktadır. Örneğin 1.5 milyon polygona sahip bir .obj 3D modelin load/render zamanı 320sn civarında iken 3 milyon polygona sahip bir  obj 3D modelin load/render süresi 960-1200 saniyelere çıkmaktadır. 1.5 milyon polygona sahip aynı 3D modelin Arsuite/arsx load/render süresi sadece 1 saniye iken  3 milyon polygona sahip aynı modelin Arsuite/arsx load/render süresi sadece 1.1-1.2 saniye arasındadır. Yani dosya boyutu büyüdükçe Arsuite/Arsx engine ailesinin gerçek gücü ortaya çıkmaktadır. This is the Magic.

Burada sadece Obj, Fbx, Usd, Gltf dosya formatlarını inceledik.  Dikkat ederseniz sadece bu 4 dosya formatı bile mimari, boyut ve hız açısından birbirinden çok farklıdır. Arsuite/arsx ile olan performans farklılıklarından yola çıkarak kendi aralarındaki farkları hesaplayabilirsiniz. Piyasada 60 dan fazla 3D model dosya formatı var, hepsinin temelde birbirine benzer algoritmalara sahip olduğunu söyleyebiliriz. En önemli nokta cloud/stream based web/mobile oyun ve uygulamaları için uygun değillerdir. Hepsi 3D modelleri monolith bir data blok olarak oluşturmaktadır.

 

Günümüzde dinamik olduğunu iddia eden tüm platformlar dinamik bir 3D sahne yaratırken tüm 3D model, texture ve materyalleri 3D sahne içerisine koymakta, bake/build/export almaktadır. Örneğin bir sandalye için XR sahnesine ihtiyacımız olsun. Bu sandalye 10 farklı ahşap, 10 farklı kumaş’a sahip olsun. Çapraz kombinasyonları yok sayarak 20 farklı görünüm yaratıldığını varsayalım. Bu durumda matematik şöyle oluşacaktır.

• 10 farklı ahşap görünüme sahip 10 tane photorealistic sandalye XR sunumu elde etmek için en az 10 x 6 = 60 tane texture/materyal XR app içerisine yüklenmelidir.
• 10 farklı kumaş görünüme sahip 10 tane photorealistic sandalye XR sunumu elde etmek için en az 10 x 6 = 60 tane texture/materyal XR app içerisine yüklenmelidir.

Bu durumda XR app’imiz toplamda 120 texture/materyale sahip olacaktır. Bu rakamlar minimize rakamlardır. Daha yüksek bir görüntü kalitesi istediğinizde bu rakam 240’a kadar çıkacaktır. Bu sandalye XR app’i kullanıcıya gönderilmek istenildiğinde tüm materyal ve assetler tek bir app/dosya içerisinde tek bir paket olarak gönderilecektir. 

Oyuncu ya da son kullanıcı belki de hiç kullanmayacağı birçok dosyayı download etmek zorunda kalacaktır. Belkide bir kullanıcı olarak bana sadece 2 farklı deseni denemek yeterli olacaktı. Bu durumda 3D model ve  8-10 texture’dan sonra benim başka dosyaya ihtiyacım kalmayacaktı. Ancak 3D model + 120 dosya indirmek zorunda kaldım. 3D designer’lar bilirler ki yüksek kaliteli texture’ler 3D modellerden daha büyük dosya boyutlarına sahiptirler. Bir son kullanıcı olarak ben neden 7-8mb yerine 100-240 mb dosya indireyim?

Daha kötüsü bu 3D sahne/model/app artık değiştirilemezdir. Yani sonradan yeni bir desen/texture eklemek istediğinizde bu app’i yeniden bake/build/export almak zorundasınız. Kullanıcı ise en güncel sahne için tüm app’i yeniden indirmelidir. Günümüz cloud-based dünyada değiştirilemez/güncellenemez statik asla data kabul edilemezdir. Arsuite/Arsx bu ve buna benzer birçok soruna çözüm olarak geliştirilmiştir ve geliştirilmeye devam etmektedir.

 

The Rise of Arsuite Modularity and Cloud Computing – Streaming

Hangi mühendislik alanında olursanız olun yeni, farklı ve daha gelişmiş birşeyler yaratmak isteyen herkes projesine en temelden başlamalıdır. En atomik parçaları yaratmak zorunda olmasak da en atomik parçaları iyice özümsemeli, içlerinden en uygun olanı seçip projeye öyle başlanmalıdır.

Arsuite olarak biz de kendi data mimarimizi ve cloud platformumuzu en temelden tasarlayıp sıfırdan yaratmak zorunda kaldık. Bazı bileşenlerin hazır olmasını çok isterdik ancak maalesef böyle bir şansımız olmadı.

Arsuite Dynamic Asset Loading – aDAL

Arsuite/Arsx sadece 3D modele ait temel bilgileri taşıyan bir veritabanıdır. Hiçbir detay ve sahiplik bilgisi barındırmaz. Örneğin texture, materyal veya animasyon gibi bileşenler Arsx’e run time ‘da yüklenir. Bu sayede Arsx her zaman, her şartta çağrıldığı sahne gereksinimlerine göre şekillenir. Bu yükleme yöntemi core yazılım mühendisliğinde Dependency Injection ile benzerlik gösterir. Ancak Arsuite olarak biz buna Dynamic Asset Loading diyoruz. Arsuite Platformunda sadece Arsx değil her bileşen dinamik ve modülerdir.  Arsuite’de herşey atomik modüller olarak ele alınır ve her atomik bileşen run time’da sahneye yüklenir.

Dynamic Asset Loading modülarite ve cloud-native işlemler için çok elzem bir özelliktir. Dynamic Asset Loading sadece mikro işlemlerde olduğu kadar makro işlemlerde de harikalar yaratmaktadır. Geliştirdiğimiz bu teknoloji sayesinde 3D sahne ve modelleri çok küçük paraçalara bölerek modül modül istediğimiz istediğimiz yere hızlıca iletebilmekteyiz. Küçük parçalar olarak ele alınan 3D sahneler modüler olarak kullanılacakları yerde run-time’da  birleştirilip kullanılmaktadır. 

Arsuite Cloud Computing & Streaming

 

Arsuite 3D dünyanın farklı gereksinimleri ve performans kaygıları nedeniyle hazır cloud servisleri kullanmamaktadır. Arsuite globalde değişik lokasyonlarda kendisine ait serverlar üzerinde cloud service provider olarak hizmet vermektedir. 

Arsuite server-side rendering yapmamaktadır. Her Arsuite/Arsx sahne client cihazlarında run-time’da load ve render edilir. Bu kural en küçüğünden en büyüğüne kadar tüm sahneler için geçerlidir. Client Side Rendering Arsuite/Arsx engine ailesinin en önemli alameti farikalarındandır.

Eğer altyapınız ve teknolojileriniz özel olarak tasarlanmamış ve top-nutch optimizasyonlara sahip değilse Hyper-Realistic ya da Photo-Realistic sahnelerin client-side yaratılması oldukça zorlayıcı olabilir. Yüksek kaliteli dosyaların client’a ulaştırılması, client’ta load/render edilmesi ve client’lar arasındaki iletişimi yönetmek için özelleştirilmiş akıllı araçlar geliştirmelisiniz.

Assetlerin sınıflandırılamsı ve yönetilmesi Video Game ve 3D dünyasında geliştirme ve tasarım yapan herkesin çok yakından bildiği bir problemdir. Dosyaların büyüklüğü ve çeşitliliği assetlerin yönetimini güçleştirmektedir. 

3D file formatların birer database olduğunu söylemiştik. Çok büyük ve monolith 3D dosyalar/database’ler aslında 3D dünyadaki bu dosya/veri çeşitliliğini yönetebilmek için ortaya çıkmıştır diyebiliriz. Bir 3D model/sahne için 3D mesh, texture, material, rig ve animasyon gibi birçok bilgi gerekmektedir. Bu kadar çok ve farklı özelliklere sahip verilerin yönetilmesi sıkıntılı bir süreçtir. Game developer ve 3D designer’in bu gibi konularla vakit kaybetmemesi gerektiğinden 3D design tool geliştiricileri 3D dosya formatlarını tüm bu datayı içinde tutacak şekilde geliştirmeyi tercih etmişlerdir. Bu tercih o günün şartlarında iyi bir çözüm olsa da bu günün cloud-native dünyasının kurallarına uyum sağlayamamaktadır. 

Arsuite Smart Asset Manager – aSAM

Arsuite smart ve centralized asset manager bir 3D sahne için gerekli olan 3D mesh, texuture, material, skybox ve animatiom gibi bileşenleri unique ve çok gelişmiş bir algoritma ile dağıtık olarak saklar ve yönetir. Örneğin yukarıdaki gibi bir sandalye 3D modelini Arsuite’ye bir kez yükleyip milyonlarca 3D sahne içerisinde kullanabilirsiniz. Bu sandalyeyi her sahne içinde farklı bir texture veya material kombinasyonu ile kullanabilirsiniz. 

Arsuite bu sahnenin oluşması gerekli tüm data ve assetleri distrubited olarak değişik yerlerde saklar. Client/Kullanıcı bu sahneyi incelemek istediğinde aSAM tüm bileşenleri bulur ve bir stream şeklinde kullanıcıya gönderir. Tüm render  ve load işlemleri client/kullanıcı makinasında run time’da yapılır.

• Tasarımcı bu sahnede herhangi bir değişiklik yaptığında sahne anında yeni değişiklilere göre render edilir. Bunun için sahnenin yeniden yaratılmasına gerek yoktur.
• Kullanıcı bu sahneye ait farklı varyasyonları incelemek istediğinde sadece istediği varyasyonun datası kullanıcıya gönderilir. Böylece gereksiz dosya ve data transferi yapılmaz.

Arsuite Smart Connection Router – aTUBE

Cloud-Native ve Distributed bir ürün geliştiriyorsanız load balancing hayatınızda oldukça önemli bir yere sahip olacaktır. Load balancing ürünler basitçe platformlar üzerindeki yük dağılımını yönetrler. Ancak buraya kadar sık sık ifade ettiğimiz nedenlerle cloud gaming ve 3D dünyada geleneksel bir load balancing ürünü çok yetersiz kalacaktır. 

Örneğin bir oyuncu herhangi bir noktadan bir oyuna bağlandığında LB o oyuncuyu en uygun server’a yönlendirecektir. 3D dünya ve game’ler klasik web sitelerinden oldukça farklıdır. 3D dünya ve game’lerde kullanıcılar veya oyuncular sürekli bir aksiyon ve birbirlleri ile iletişim içinde olmalıdırlar. Singapur’daki bir oyuncu ile İngiltere’deki bir oyunun birbirleri ile en hızlı ve kesintisiz şekilde iletişimde halinde olmaları gerekebilir. Bu durumda klasik LB lerin yapacağı hiçbir şey yoktur. Bu kesintisiz bağlantıyı kurmak için daha farklı ve akıllı çözümlere ihtiyaç vardır.

Arsuite smart Connection Router herhangi bir kullanıcı/oyuncuya sisteme giriş yaptığı andan çıkış yaptığı ana kadar yardımcı olur ve bağlantısını yönetir. Server ile kullanıcı arasındaki en iyi bağlantıyı kurarken oyuncular arasındaki tüm bağlantıların sağlıklı ve adil olmasını da sağlar. aTUBE tüm client-server bağlantıları ile server durumlarını sürekli olarak kontrol eder ve en iyi bağlantı performansının sağlandığından emin olur. Örneğin X oyunundaki A oyuncusu ile B oyuncusunun sahip olduğu bağlantı hızları oyun kalitesini ve fair-play’i etkileyecek seviyede ise oyunları uyarır ya da match etmez.

Arsuite Smart Stream API – aSSA

3D assetleri ve dataları atomik olarak dağıtık mimaride sakladık, client-server ve client-client bağlantılarını oldukça optimize şekilde kurduktan sonra geriye data’ları kullanıcılara göndermek kalıyor.  Gönderilecek datalar çok çeşitli, 3D ve büyük boyutlarda olacağından daha dikkatli ve farklı yaklaşılması gerekiyor. Arsuite Smart Stream API client’ın cihaz özelliklerine ve bağlantı gücüne bağlı olarak 3D sahneleri ve assetleri client’a gödermektedir. Örneğin yukarıdaki sandalye bir kullanıcıya 2K texture ve 2K skybox ile gönderilirken başka bir kullanıcıya 4K texture ve 4K skybox ile gönderilebilir. 

Sonuç

Arsuite ai-powered bir platform değildir. Arsuite platformu oldukça gelişmiş bir AI’dır.

3D sahnelerin tasarımından, client’a ulaştırılmasına kadar her bir adım Arsuite akıllı araçları tarafından izlenmekte ve yönetilmektedir. 

Şöyle bir örnek verelim. Bir A kullanıcısı herhangi bir T anında X sahnesini çağırdığında unique bir key üretilir ve bu key ile A kullanıcısının tüm hareketleri izlenir. Bu izleme esnasında kullanıcı her zaman en kesintisiz düğüm noktasına ve uygun server’a yönlendirilir. Kullanıcı deneyiminde bir hata varsa sistem anında uyarı üretir ve kullanıcı en iyi servise yönlendirilir. Böylece kullanıcının/oyuncunun en iyi hizmeti alması sağlanır. Oluşan hatalar senaryo bazlı olarak uçtan-uca takip edilebildiğinden anında çözüm üretilir.

Reminder: Bu izleme sadece kullanıcı deneyimini iyileştirmek için yapılan anonim bir izlemedir. Kullanıcın kişisel bilgileri hiçbir zaman bu izlemenin scope’u içerisinde değildir.

Arsuite, Architecting Tomorrow’s Immersion, Today!

Alper Akalin