AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
AWS Japan YouTube 公式チャンネルでライブ配信された 2022年4月26日の AWS Developer Live Show 「Infrastructure as Code 談議 2022」 の資料となります。 当日の配信はこちら からご確認いただけます。
https://youtu.be/ed35fEbpyIE
AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
202204 AWS Black Belt Online Seminar Amazon Connect Salesforce連携(第1回 CTI Adap...Amazon Web Services Japan
AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
* AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
* 過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
企業間の連携においてもSaaS活用シフトが進む一方で、インターネット経由というイメージからセキュリティーに不安を感じて踏みとどまるユーザーは多くいます。こうした懸念を払しょくするAWS PrivateLinkを活用した企業間のプライベート接続や閉域網との構成例、SaaS事業者様からなるPrivateLinkパートナーコミュニティ形成の取り組みをご紹介します。
2021年12月9日に開催された「SaaS on AWS Day 2022」での講演内容です。
パッケージソフトウェアをお持ちのお客様が新たにSaaS版のアプリケーションを検討したいというニーズが増えています。一方で"SaaS版を作っても成功するかわからない"、"WEBアプリケーションを作る技術力や知見がない"といった不安からSaaS化における課題があることも事実です。本セッションでは、小さく早くSaaSビジネスを始めたいお客様に向けて、Amazon AppStream2.0を用いた既存アプリケーションのSaaS化手法をご紹介します。
2021年12月9日に開催された「SaaS on AWS Day 2021」での講演内容です。
AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
AWS Black Belt Online Seminarの最新コンテンツ: https://aws.amazon.com/jp/aws-jp-introduction/#new
過去に開催されたオンラインセミナーのコンテンツ一覧: https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-service-cut/
【DLゼミ】XFeat: Accelerated Features for Lightweight Image Matchingharmonylab
公開URL:https://arxiv.org/pdf/2404.19174
出典:Guilherme Potje, Felipe Cadar, Andre Araujo, Renato Martins, Erickson R. ascimento: XFeat: Accelerated Features for Lightweight Image Matching, Proceedings of the 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR) (2023)
概要:リソース効率に優れた特徴点マッチングのための軽量なアーキテクチャ「XFeat(Accelerated Features)」を提案します。手法は、局所的な特徴点の検出、抽出、マッチングのための畳み込みニューラルネットワークの基本的な設計を再検討します。特に、リソースが限られたデバイス向けに迅速かつ堅牢なアルゴリズムが必要とされるため、解像度を可能な限り高く保ちながら、ネットワークのチャネル数を制限します。さらに、スパース下でのマッチングを選択できる設計となっており、ナビゲーションやARなどのアプリケーションに適しています。XFeatは、高速かつ同等以上の精度を実現し、一般的なラップトップのCPU上でリアルタイムで動作します。
セル生産方式におけるロボットの活用には様々な問題があるが,その一つとして 3 体以上の物体の組み立てが挙げられる.一般に,複数物体を同時に組み立てる際は,対象の部品をそれぞれロボットアームまたは治具でそれぞれ独立に保持することで組み立てを遂行すると考えられる.ただし,この方法ではロボットアームや治具を部品数と同じ数だけ必要とし,部品数が多いほどコスト面や設置スペースの関係で無駄が多くなる.この課題に対して音𣷓らは組み立て対象物に働く接触力等の解析により,治具等で固定されていない対象物が組み立て作業中に運動しにくい状態となる条件を求めた.すなわち,環境中の非把持対象物のロバスト性を考慮して,組み立て作業条件を検討している.本研究ではこの方策に基づいて,複数物体の組み立て作業を単腕マニピュレータで実行することを目的とする.このとき,対象物のロバスト性を考慮することで,仮組状態の複数物体を同時に扱う手法を提案する.作業対象としてパイプジョイントの組み立てを挙げ,簡易な道具を用いることで単腕マニピュレータで複数物体を同時に把持できることを示す.さらに,作業成功率の向上のために RGB-D カメラを用いた物体の位置検出に基づくロボット制御及び動作計画を実装する.
This paper discusses assembly operations using a single manipulator and a parallel gripper to simultaneously
grasp multiple objects and hold the group of temporarily assembled objects. Multiple robots and jigs generally operate
assembly tasks by constraining the target objects mechanically or geometrically to prevent them from moving. It is
necessary to analyze the physical interaction between the objects for such constraints to achieve the tasks with a single
gripper. In this paper, we focus on assembling pipe joints as an example and discuss constraining the motion of the
objects. Our demonstration shows that a simple tool can facilitate holding multiple objects with a single gripper.
76. Cloud Canvas
• Visually script common AWS
services for databases, storage,
and compute (e.g. DynamoDB,
Amazon S3, AWS Lambda) to
create simple backend gameplay
more easily.
• Resource Manager – easily deploy
AWS resources from the Editor
(with support for Beta, Gamma,
QA configurations, etc).
• Pre-integrated with the AWS C++
SDK
• Support for visually scripting cloud
logic coming this year
OITを使用しない場合、透明なオブジェクトは、正しいブレンド順序を保証するために複数のパスでレンダリングされなければならず、結果は正しく表示されません。
Without OIT, transparent objects must be rendered in multiple passes to ensure correct blending order, and the result still doesn’t look correct.
OITでは、別々のパスで透明なオブジェクトを特定の順序でレンダリングする必要がなくなり、レンダリングのパフォーマンスが向上します。
With OIT, there is no need to render transparent objects in specific order in separate passes, improving rendering performance.
TODO: fix this slide
Message of the Day – ゲームクライアントへのメッセージの配信 (たとえば、新製品のご案内や休日のお知らせ) をスケジュールします。
Leaderboard – プレイヤーのハイスコアを保存し、プレイヤーのランキングを示すリーダーボードを提供します。
動的コンテンツ – クラウドにアップロードした新しいゲームアセットと更新されたゲームアセットを自動的にダウンロードすることで、クライアントに最新のゲームコンテンツが維持されるようにします。
Player Account – ニーズに合わせてカスタマイズ可能な、ゲームのスタンドアロンプレイヤー認証および管理ソリューションを提供します。
GameLift is a Managed AWS Service designed to help developers scale their multiplayer games
Features fall into two broad responsibilities:
Infrastructure Management. The parts of GameLift that handles the cloud
Session Management: The parts of GameLift that handle making player sessions and game sessions, and all the record keeping that goes with it
In Infrastructure management
GameLift auto-scaling is based on rules that you create. Rules based on the number of game sessions running, the number of player slots available, or how long people are waiting to connect.
GameLift is high-availability. If one AZ in a region goes down, new servers will spin up in a different AZ automatically based on your scaling rules
GameLift also has automatic cross-region failover. You can place players in the best region based on latency, and if a region disappears then players in that region will automatically be routed to the region with the next best latency until the original region recovers
There’s not a lot of functional difference between an extremely popular game launch and a DDoS attack, so you might have expected that GameLift also allows you to weather DDoS attacks. AWS also employs techniques to detect and defeat DDoS attacks against its APIs and EC2 instances.
In Session Management
The Gamelift service keeps track of the status of all the player and game sessions in your back-end.
GameLift is available in most regions, and players can be routed to the region with best latency. Or all players can be served out of one region. Or anything in between.
And finally, GameLift provides a matchmaking service called FlexMatch. This feature was released in August. Before I dive into it, I’d like to quickly walk through a brief history…
GameLift has come a long way in a year and a half.
Many of these features are based on conversations that Yamamoto-san and I had with developers in Japan over the past year
GameLift launched in early 2016 as a beta service available to developers using Lumberyard, Amazon’s game engine
In August 2016, we added support for multiple server processes on each EC2 instance
This helps developers optimize EC2 resource utilization
Maximizes player count while minimizing compute cost
This is one of many features we’ve added (and will continue to add) that reduce cost to developers
By popular request, we added support for Linux servers in September 2016.
This was a large undertaking for us as much of GameLift (beta) was built on a Windows framework
We did this as another measure to help developers control costs
Early this year we added support for player queues
These queues allow you to have players wait for a game session
For example if you put a maximum cap on the number of servers
A player queue can also route players to the best GameLift Fleet based on latency
This also provides automatic cross-region failover. If an AWS region goes down, queues will route users to the region with the next-best latency
At GDC in March we announced that GameLift would be available separate from Lumberyard
Along with this announcement we launched plugins for Unreal and Unity
GameLift Server SDKs in C++ and C# were also released for use in custom servers
One thing developers told us was that the iteration time with GameLift was slow
It takes time to bake an Amazon Machine Image for each new server version a developer uploads, before Fleets can scale
And so we released GameLift Local in April
GameLift Local lets developers test GameLift service interactions on their local machine
This eliminates the time to upload builds and bake machine images, creating a faster development loop
In July, we localized the GameLift web console into Japanese.
This might seem like a minor thing, because developer documentation has been available in Japanese for a while
But we did this because of the high interest from the region.
To date, the only languages supported in the GameLift console are English and Japanese
In August we launched FlexMatch
A set of GameLift APIs that provide a complete Matchmaking Solution
Free for games running on GameLift
Now let’s dive a little deeper into FlexMatch
What does FlexMatch do?
Matching is based on powerful rules that you define, which we’ll get into soon
There’s support for player groups or parties, so that multiple players can queue for matchmaking together
You can match players of similar latency together
It’s also easy to relax the rules if it’s taking a long time for players to find a match
We have an optional feature where you can require each player to agree to the match before the session begins
And we support placing the entire match into the best region considering the latency of all players
Matchmaking has a direct impact on player experience
Can’t afford to make mistakes
Also sensitive to tuning, so you need real data to base your changes on
The FlexMatch dashboard lets you view historical metrics including
Success/failure rates of the matchmaker.
Player demand
How long it takes the matchmaker to find a valid match
And pass/fail rates for the rules you create.
This graph is showing some information about the number of matches created and pending
This graph shows the pass/fail rate for the matchmaking rules we created.
So now we know what Flexmatch can do, but how do we integrate it?
This is a basic FlexMatch architecture. I’ll cover each part in detail, but first I want to explain how to read this diagram
In orange we have bits that are built and managed by the developer. From left to right:
The game clients
The Front Door server that talks to GameLift.
Matchmaking rule sets
And on the far right, the game servers themselves
In purple, we have the bits that are managed by Amazon. From left to right:
The AWS SDK that a developer must integrate into their Front Door server
The GameLift service itself, including FlexMatch
The GameLift player queues
On the far right, the GameLift fleet management in each region
And the GameLift Server SDK that a developer must integrate into their game servers that run on GameLift
That’s a lot to take in, so let’s break it down
The process begins with clients (users) who want to play the multiplayer mode for your game
They initiate this in your game client. They click “Quick Play” or “Ranked” or something similar in a menu
The game client then contacts your Front Door server through whatever mechanism you normally use. HTTP, TCP, UDP.
Your clients tell the Front Door server any relevant information such as desired game settings, party information, and so on
Your front door server performs game-specific logic when clients want to play multiplayer
Is this player allowed to play this game mode? High enough level, enough currency, not banned, etc
Is this player in a group or party?
This information is then passed to GameLift in a Matchmaking Request. The request includes:
which matchmaker to use (because you might have multiples)
a unique matchmaking ticket ID
an array of player data (unique player IDs, custom player attributes that get fed to the rules, latency information, etc)
In response to StartMatchmaking, a MatchmakingTicket is returned
This ticket includes the information that was part of the original request, including Ticket Id
Now we need to poll for MatchmakingTicket status changes
Now that the Front Door has started the matchmaking process, it must periodically poll for the status of live MatchmakingTickets
(It’s also possible to use the SNS to do an event-based architecture instead of polling, if that’s your preference)
We poll by calling DescribeMatchmaking, and pass along a list of all the matchmaking ticket IDs we want to get an update for
Each time we poll with DescribeMatchmaking, we receive a list of MatchmakingTickets in response
The status of each ticket (SEARCHING, COMPLETED, TIMED_OUT, and so on) is how we know what to do for each player
At this time, the Matchmaking Tickets will also contain information about the players we have been matched with
The GameLift FlexMatch service automatically queues players for a GameLift server once a match is made.
Our FrontDoor knows about this status change by continuing to poll with DescribeMatchmaking
The status of the MatchmakingTicket at this point is PLACING
Queued matches are processed into the best regions available based on latency
When a match has moved through the queue and has a server reserved for the players, MatchmakingTicket status changes to COMPLETED
Our Front Door server becomes aware of this status change by polling DescribeMatchmaking.
When polled in this status, the MatchmakingTicket we receive back will also contain all of the information our players need to connect to the server
With the reserved server info in the MatchmakingTicket, your game clients make a direct connection to the game servers
No middlemen, no additional latency
Now we’ve got it all integrated, how do we actually create matchmaking rules?
You’ll recall from the architecture diagram that FlexMatch can be home to one ore more rule sets.
Those rule sets look like this
And when we made our BeginMatchmaking request, we passed along which rule set we want to use
The first thing you’ll have to consider when using FlexMatch is what your rules are going to be
FlexMatch supports multiple Rule Sets for different game modes. You can have different rules for Quick Match, Ranked, 1v1, 3v3…
Rule sets contain attributes (which are like user-defined properties), team definitions, rules, and expansions
playerAttributes are custom variables that you will pass to the matchmaker when queueing players
In this case we have a playerAttribute called “skill” that we’ll use below
Remember when we made our BeginMatchmaking request, we passed in custom player data. That’s where this skill attribute comes from
Teams are also defined in the rules
In this case, Cowboys vs Aliens
Each rule set supports multiple rules
The FlexMatch rule set also has advanced features for even more granular control over player experience.
You can group together players who prefer certain game modes, like Capture the Flag, or certain groups of maps.
You might decide that a valid team requires at least one warrior, one rogue, and one mage before a game starts.
You can also allow asymmetric matches, like 1v5, in order to support new game modes.
In this case we have one rule for player skill, and one rule for team size
In the FairTeamSkill rule, we measure the “skill” attribute we defined above
This rule makes sure that no player’s skill is more than 10 away from the average skill of both teams.
In the EqualTeamSizes rule we state simply that a match can not be made unless the count of each team’s players is equal
Rule sets also support rule expansions. These relax the rules over time to make matches easier if players have been waiting too long
Here we are altering the maxDistance property of the FairTeamSkill rule we defined above
It started out at 10…
After 5 seconds of waiting, we relax the value to 50 skill difference
After 15 seconds of waiting, we relax the value to 100 skill difference
That’s a basic rule set, but it doesn’t mean much without an integration. So let’s talk architecture.
Entity=物体
Instance=実体
Slice=断片
Add “Static Mesh”
Add “Rigid Body Physics”, and uncheck At rest initially
Add “Mesh Collider”
Without OIT, transparent objects must be rendered in multiple passes to ensure correct blending order, and the result still doesn’t look correct.
With OIT, there is no need to render transparent objects in specific order in separate passes, improving rendering performance.