DEV Community: Ana Coimbra

Mostrando conteúdo rápido no Android: App Actions & Slices

Ana Coimbra — Mon, 27 Apr 2020 20:22:03 +0000

Atualmente está cada vez mais frequente o uso de assistentes virtuais, principalmente em smartphones. Eu, por exemplo, sempre apago a luz do meu quarto por comando de voz, dentre outras inúmeras possibilidades. Neste cenário, os aplicativos Android conseguem obter ainda mais engajamento dos usuários através de respostas rápidas de seus conteúdos integrando com o Google Assistant. Para isso, a Google lançou o App Actions.

Antes de continuar, é necessário pontuar que essa ferramenta, no dia da publicação deste artigo, se encontra em Developer Preview e tem algumas limitações: apenas um conjunto limitado de ações está disponível e para algumas linguagens específicas (que varia de acordo com a ação). Veja a lista de ações reconhecidas (Built-in intents) aqui.

Como funciona

Na percepção do usuário, uma App Action é como se fosse um “atalho” do Google Assistant para o app. Na realidade, o que acontece é que o Assistant faz o reconhecimento da requisição do usuário e interpreta esses dados como um Intent (necessariamente precisam ser aqueles Built-in, conforme mencionado anteriormente) com seus fullfilments (url, parâmetros, etc.) relacionados. Após a interpretação, é feito um mapeamento com as ações correspondentes aos Intents que estiverem registrados no arquivo de ações (actions.xml) do app.

Ao identificar um Intent relacionado a uma(s) ação(ões), o Assistant interpretra os parâmetros como uma entidade - que deve seguir o padrão schema.org - e também a url (deep link) mapeado no arquivo de ações do app. Por fim o sistema identifica e direciona o usuário direto para o conteúdo do app. No caso do uso de Slice, a informação é mostrado diretamente no Assistant (Veremos melhor mais pra frente).

Comando no assistant	Resultado no App

Exemplo de funcionamento do App Actions

Projeto

Como exemplo de código para este artigo, criei um projeto de assistente de receitas, em que você pergunta ao Google Assistant coisas como “Olá Google, abrir receita de Pão de queijo” e assim é mostrado um slice do app diretamente no assistant. Para dispositivos em que os slices não estiverem disponíveis é apresentado uma Activity com os detalhes da receita.

Os dados das receitas foram alimentados por um json presente no Gist. Para facilitar um eventual escalonamento nos dados, pensando numa possibilidade de adicionar novas receitas futuramente, importei esse json para um banco de dados no Firestore do Firebase.

Resumindo: o app recebe o nome da receita como parâmetro do assistant, faz a busca no Firestore e, assim que encontrado, mostra ao usuário o conteúdo.

Configurações iniciais

Antes de começar, precisamos configurar o ambiente para conseguir testar as ações que implementarmos.

Criar um projeto na Playstore

Para que as ações sejam reconhecidas pelo Google Assistant (mesmo em teste) é necessário criar um projeto na Playstore e subir pelo menos um build (APK ou aab) com o arquivo das ações do app registrado no Manifest. Não é necessário publicar o app, basta ter um artefato salvo.

Para mais informações sobre como inserir um app na Playstore, veja na documentação.

Instalar plugin para testar as ações

Para rodar os testes, antes de publicar o app, é necessário instalar o plugin App Actions Test Tool no Android Studio. Para saber como instalar veja aqui. Essa ferramenta permite configurar os parâmetros da ação a ser testada.

É importante pontuar que esse plugin tem algumas restrições:

Funciona apenas com dispositivos físicos
Suporta apenas algumas localidades (en-US, en-GB, en-CA, en-IN, en-BE, en-SG, e en-AU). Com exceção de alguns built-in intents que aceitam algumas outras localidades, mas ainda bem limitado.

Após instalado, também é necessário fazer o login no Android Studio com a mesma conta do dispositivo que você irá usar para os testes.

App Actions Test Tool - Página de instalação do plugin no Android Studio.

Adicionar suporte a deep links no app

Por fim, é necessário configurar quais telas do app devem tratar os deep links transferidos do assistant. No caso do projeto, foi configurado apenas que o link recipes://detail abre a tela de detalhe da receita:

<!-- AndroidManifest.xml -->
<activity android:name=".RecipeDetailActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />

        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />

        <data
            android:host="detail"
            android:scheme="recipes" />
    </intent-filter>
</activity>

Para adicionar suporte a deep link, basta adicionar dentro da tag <activity> desejada no manifest as configurações de <intent-filter> com <action> do tipo android.intent.action.VIEW e com as categorias android.intent.category.DEFAULT e android.intent.category.BROWSABLE (essa última é bem importante para o funcionamento das ações). Além disso é necessário definir o schema (protocolo) e o host da url que abrirá essa activity. É possível adicionar também definições de parâmetros esperados e path da url, mas não é necessário no momento. Para mais informações sobre deep links em Android, veja na documentação.

Configurando as ações

Com todas as configurações preliminares finalizadas, vamos inserir nossa primeira ação. O primeiro passo é adicionar o arquivo actions.xml dentro da pasta res/xml. É possível criar esse arquivo de forma automática no Android Studio: Arquivo > Novo > XML > Arquivo XML App Actions. Em seguida, determinar as ações possíveis do app nesse local:

<!-- actions.xml -->
<actions>
    <action intentName="actions.intent.OPEN_APP_FEATURE">
        <fulfillment urlTemplate="recipes://detail{?recipe}">
            <parameter-mapping
                intentParameter="feature"
                urlParameter="recipe" />
        </fulfillment>
    </action>
</actions>

Inicialmente, configurei dessa forma a ação do app. O primeiro ponto é relacionado ao intentName que precisa de ser um daqueles Built-in intents já mencionados anteriormente. No caso deste app de receitas não existe um intent pré-definido de “ver receita” então usei o genérico que é “abrir funcionalidade” (actions.intent.OPEN_APP_FEATURE). Na documentação desta ação, precisamos obter apenas um parâmetro do intent, que é o feature. Neste caso, os parâmetros acabam se resumindo em apenas uma string, mas poderia ser qualquer estrutura de dados desde de que se encaixe no padrão schema.org. Por exemplo, outros intents exigem uma estrutura fixa, como por exemplo actions.intent.ORDER_MENU_ITEM que exige que os parâmetros sejam correspondentes ao schema de MenuItem.

Para facilitar a obtenção das receitas no Firestore, configurei um padrão para o parâmetro de feature em que o texto falado pelo usuário é mapeado para o id do documento no Firestore relativo a receita escolhida.

<!-- actions.xml -->
<actions>
    <action intentName="actions.intent.OPEN_APP_FEATURE">
        <fulfillment urlTemplate="recipes://detail{?recipe}">
            <parameter-mapping
                intentParameter="feature"
                urlParameter="recipe" />
        </fulfillment>

        <parameter name="feature">
            <entity-set-reference entitySetId="RecipeEntitySet" />
        </parameter>
    </action>

    <entity-set entitySetId="RecipeEntitySet">
        <entity
            name="@string/frozen_yogurt"
            alternateName="@array/frozen_yogurt"
            identifier="2gbkANgwMJYMUnYgoRHn" />
        <entity
            name="@string/cheese_bread"
            alternateName="@array/cheese_bread"
            identifier="6aRoFUbVuMp3EP48uO8M" />
        <entity
            name="@string/mac_and_cheese"
            alternateName="@array/mac_and_cheese"
            identifier="7BnVOHJMxqHzUNxnYY5D" />
        ...
    </entity-set>
</actions>

Agora o parâmetro feature está configurado para aceitar qualquer valor dentro do conjunto RecipeEntitySet. Repare que cada <entry> possui o name que é um nome principal que o assistant vai identificar a entidade; também tem alternateName que são sinônimos ou nomes alternativos da entidade, por exemplo: pão de queijo, biscoito de queijo, etc. O identifier é o identificador do documento desta entidade no Firestore. Ao fazer o mapeamento dos parâmetros com as entidades suportadas, o Assistant inicia o intent substituindo o identifier no lugar da feature e aí cabe ao app fazer o tratamento da informação.

Existem diversas possibilidades de configurações de parâmetros e entidades. Por exemplo, no lugar de um identifier, é possível configurar uma url para cada entidade, e aí dentro de fullfilment não será necessário tratar o parameter-mapping pois já foi feito na entidade.

Após configurar o arquivo actions.xml é necessário registrá-lo no AndroidManifest.xml:

<!-- AndroidManifest.xml -->
<application ...>
  ...
  <meta-data
    android:name="com.google.android.actions"
    android:resource="@xml/actions" />
</application>

Testando as ações

Para testar as novas ações, basta inicial o plugin do App Actions Test Tool que foi instalado anteriormente. Ao iniciar, será pedido um nome e uma localidade para criar um preview. Ambos os campos são opcionais. Lembrando que a localidade precisa ser uma daquelas já mencionadas no início do artigo.

App Actions Test Tool — Create preview

Após criar o preview, a ferramenta já obtém todas as ações configuradas do app, que no nosso caso agora é apenas actions.intent.OPEN_APP_FEATURE. No campo feature vamos inserir o nome da “funcionalidade” que ficou configurado como sendo o nome da receita. Repare que a localidade precisa ser em inglês, então coloquei como feature “cheese bread”.

App Actions Test Tool Preview	Resultado no App

Rodando uma ação através do Android App Action Test Tool

Ao clicar em run o plugin inicia o assistant do dispositivo com o intent de abrir funcionalidade e com o parâmetro recipe=<id_recipe> pois foi o mapeamento que ele fez com as configurações que colocamos no preview. Assim que é recebido pelo dispositivo, ele já reconhece que existe o app responsável por tratar essa ação e abre diretamente a tela de detalhe da receita.

Android Slices

Aproveitando que já fizemos uma forma rápida do usuário acessar as funcionalidades do app através das ações, porque não mostrar o conteúdo de forma mais direta e simples? Para isso, precisamos configurar um Android Slice. Que é uma forma dinâmica e interativa de mostrar o conteúdo do app diretamente no assistant, sem a necessidade de abrir o app efetivamente. Também é possível tomar algumas ações rápidas sem estar dentro de todo o contexto da aplicação.

Existem diversos templates de slices que podem ser usados conforme a necessidade do aplicativo. Além disso também é possível inserir dados de forma dinâmica através de uma conexão com servidor, controladores de entrada do usuário, live data, e outras diversas funcionalidades. Para saber mais sobre os Slices do Android, veja na documentação.

Instalar visualizador de slices

Antes de começar a criar os slices precisamos baixar um app que vai nos permitir visualizar esses componentes.

Primeiro, é preciso baixar o app na página de releases do Slice Viewer. Em seguida, basta instalar o APK no dispositivo. Se preferir use diretamente o comando do adb: adb install -r -t slice-viewer.apk

Criar provedor de slices

O próximo passo agora é criar um SliceProvider que pode ser feito diretamente pelo Android Studio: Arquivo > Novo > Outros > Slice Provider. Lembrando também que é necessário registrar esse provedor no AndroidManifest.xml:

<!-- AndroidManifest.xml -->
<application ...>
 ...
 <provider
     android:name=".app.RecipeSliceProvider"
     android:authorities="${applicationId}"
     android:exported="true">
     <intent-filter>
         <action android:name="android.intent.action.VIEW" />

         <category android:name="android.app.slice.category.SLICE" />

         <data
             android:host="${applicationId}"
             android:pathPattern="/detail"
             android:scheme="content" />
     </intent-filter>
 </provider>
</application>

No caso, o RecipeSliceProvider possui apenas um atributo que é uma lista mutável de receitas e, a cada nova ação acionada pelo usuário que mostra o assistant, é feito uma busca no Firestore com o id obtido na uri e, quando retornado sucesso é mostrado um conteúdo resumido da receita no slice vinculado. A decisão de usar uma lista é porque podem existir inúmeros slices aparecendo juntos em uma sessão do assistant. Por isso ficamos com diversas referências que são associadas por seus identificadores de forma que cada slice mostra o conteúdo correto da receita que corresponde.

/ **RecipeSliceProvider.kt** /
class RecipeSliceProvider : SliceProvider() {

    override fun onCreateSliceProvider() = true

    override fun onMapIntentToUri(intent: Intent?): Uri {
        var uriBuilder: Uri.Builder = Uri.Builder().scheme(ContentResolver.SCHEME_CONTENT)
        if (intent == null) return uriBuilder.build()
        val data = intent.data
        val dataPath = data?.path
        if (data != null && dataPath != null) uriBuilder = uriBuilder.path(dataPath)
        context ?: return uriBuilder.build()
        uriBuilder = uriBuilder.authority(context!!.packageName)

        return uriBuilder.build()
    }

    override fun onBindSlice(sliceUri: Uri): Slice? {
        val context = context ?: return null
        return if (sliceUri.path == "/") {
          //TODO("Return slice with content")

        } else {
          //TODO("Return slice with not found error")
        }
    }

    override fun onSlicePinned(sliceUri: Uri?) {
      //TODO("get dynamic initial data, subscribe to any observers")
    }

    override fun onSliceUnpinned(sliceUri: Uri?) {
        super.onSliceUnpinned(sliceUri)
        //TODO("tear down every observer and remove unecessary resources")
    }
}

Neste provedor temos alguns pontos de atenção: onCreateSliceProvider é usado para iniciar qualquer objeto que seja necessário e retornar true caso o provedor tenha sido criado com sucesso, caso contrário, retorna false.

A implementação deonMapIntentToUri é necessária apenas no caso em que o app precisa obter e mapear as requisições de url e converter urls comuns em content uri. No caso desse app, o mapeamento do slice foi feito diretamente via um content uri, então não foi necessária toda essa implementação.

O método onBindSlice é responsável por construir o slice e vincular os dados necessários. Também é neste método que fazemos o mapeamento do conteúdo, através do path do sliceUri.

/ **RecipeSliceProvider.kt** /
override fun onBindSlice(sliceUri: Uri): Slice? {
    val context = context ?: return null
    val id = sliceUri.getQueryParameter("recipe")
    val resource = getResource(id)
    return if (sliceUri.path == "/detail") {
        when (resource) {
            is Resource.Success -> createContentSlice(context, sliceUri, resource.data)
            is Resource.Error -> createErrorSlice(context, sliceUri)
            else -> createLoadingSlice(context, sliceUri)
        }

    } else {
        createErrorSlice(context, sliceUri)
    }
}

Em onSlicePinned o slice foi atrelado a um serviço e está prestes a ser exibido pro usuário. Neste momento é hora de buscar os dados do servidor, sobrescrever para algum observable, ou ações semelhantes, quando necessário. Ao final, quando obter os dados necessários, basta chamar context.contentResolver.notifyChanged(sliceUri, null) para que seja atualizado o onBindSlice com o novo conteúdo.

/ **RecipeSliceProvider.kt** /
override fun onSlicePinned(sliceUri: Uri?) {
    val id = sliceUri.getQueryParameter("recipe")
    FirestoreManager.getRecipeById(id) { task ->
        if (task.isSuccessful && task.result?.exists() == true) {
            val doc = task.result
            recipes.add(Resource.Success(doc?.data?.toRecipe(doc.id)))
            context?.contentResolver?.notifyChange(sliceUri, null)
        } else {
            recipes.add(Resource.Error(id))
            task.exception?.printStackTrace()
            context?.contentResolver?.notifyChange(sliceUri, null)
        }
    }
}

Para o caso exclusivo deste app e para facilitar o desenvolvimento, foi usado o SDK puro do Firestore para obtenção dos dados, de forma que foram usados apenas callbacks sem interação com live data, e observables por exemplo.

Por fim, no onSliceUnpinned é a hora de remover os observers e fazer qualquer limpeza para evitar vazamentos de memória. No caso do app de receitas, é feito apenas a limpeza dos dados dentro da lista recipes.

Usar templates para slices

Os Slices são construídos através de um sistema de lista (ListBuilder) que pode ter diferentes tipos de formato de linhas. O primeiro é o cabeçalho (HeaderBuilder) que possuem as informações principais do slice e também é o conteúdo mostrado quando o slice está no modo de visualização compacto. Outro formato é a linha em si (RowBuilder) para um conteúdo mais simples, e podendo ter uma ou mais ações rápidas atreladas. De forma semelhante tem o formato de grid (GridBuilder) que mostra o conteúdo em diferentes colunas dentro da mesma linha. Também é possível adicionar uma barra de progresso ou um slider através do RangeBuilder. Para mais informações sobre templates dos slices veja na documentação.

Para o app de receitas usei o HeaderBuilder para mostrar o nome da receita no modo reduzido do slice e nas outras partes, foi usado o RowBuilder por ser um conteúdo mais simples e único, precisando apenas de linhas mesmo. Contudo, foi configurado três tipos de slices: um para ser exibido enquanto os dados são carregados, outro para quando a receita foi retornada e outro para o caso de ter retornado algum erro ou não ter sido encontrada a receita.

/ **RecipeSliceProvider.kt** /
private fun createLoadingSlice(context: Context, sliceUri: Uri) =
  list(context, sliceUri, ListBuilder.INFINITY) {
      header {
          setTitle(context.getString(R.string.loading_recipe), true)
      }
}

Para os slices é importante que apareça alguma informação instantânea para o usuário mesmo ainda não tendo todos os dados a serem mostrados .. por isso, foi criado o slice para mostrar que o conteúdo está carregando.

/ **RecipeSliceProvider.kt** /
private fun createContentSlice(context: Context, sliceUri: Uri, recipe: Recipe?) =
  if (recipe != null)
    list(context, sliceUri, ListBuilder.INFINITY) {
      header {
          setTitle(recipe.name.orEmpty(), false)
          subtitle = recipe.baseIngredients?.joinToString().orEmpty()
          summary = recipe.baseIngredients?.joinToString().orEmpty()
          primaryAction = createDetailAction(recipe)
      }
      gridRow {
          cell {
              val bitmap = Glide.with(context)
                  .asBitmap()
                  .load(recipe.image)
                  .submit()
                  .get()
              val image =
                  IconCompat.createWithBitmap(bitmap)
              addImage(image, ListBuilder.LARGE_IMAGE)
          }
      }
      row {
          title = context.getString(R.string.directions)
          subtitle = recipe.directions.orEmpty()
      }
  } else createErrorSlice(context, sliceUri)

Para o carregamento da imagem da receita foi utilizada a biblioteca Glide que transforma uma url de imagem em um bitmap no android e, com isso foi gerado o IconImage necessário para ser inserido no slice.

/ **RecipeSliceProvider.kt** /
private fun createErrorSlice(context: Context, sliceUri: Uri) =
  list(context, sliceUri, ListBuilder.INFINITY) {
      header {
          title = context.getString(R.string.error_recipe_not_found)
          primaryAction = createAppAction()
      }
  }

Por fim, repare que em diversos momentos foi configurado também uma primaryAction que é uma SliceAction na qual possui informações de intents e pending intents.

/ **RecipeSliceProvider.kt** /
private fun createDetailAction(recipe: Recipe?) =
  createAction(RecipeDetailActivity.intent(context, recipe))

private fun createAppAction() = 
  createAction(Intent(context, MainActivity::class.java))

private fun createAction(intent: Intent?): SliceAction =
  SliceAction.create(
      PendingIntent.getActivity(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT),
      IconCompat.createWithResource(context, R.drawable.ic_launcher_foreground),
      ListBuilder.ICON_IMAGE,
      context?.getString(R.string.open_app).orEmpty()
  )

Testar slice no dispositivo

Para testar no Slice Viewer instalado anteriormente, é necessário criar uma nova configuração de execução no Android Studio.

Adicionar nova configuração de execução para mostrar o Slice no Slice Viewer

Nomeie-a como preferir e em nas opções de lançamento (Launch Options) selecione o modo URL e na url coloque slice-content://<application_id>/path de acordo com o que você configurou no SliceProvider dentro do AndroidManifest.xml. No caso do app de receitas, também foi necessário adicionar o parâmetro recipe porque precisamos dele para saber qual a receita mostrar pro usuário. Após adicionado, basta rodar essa nova configuração.

Slice carregando	Slice de conteúdo	Slice de erro

Slice Viewer — Exemplos de slice

Configurar ação para usar o slice

Finalmente, vamos configurar o arquivo actions.xml para mostrar o slice criado. Para isso, basta adicionar um novo fullfiment dentro da ação com fullfilmentMode="actions.fullfilment.SLICE e o urlTemplate de acordo com o que ficou no AndroidManifest.

<!-- actions.xml -->
<actions>
    <action intentName="actions.intent.OPEN_APP_FEATURE">
        <fulfillment
            fulfillmentMode="actions.fulfillment.SLICE"
            urlTemplate="content://com.anacoimbra.android.recipes/detail{?recipe}">
            <parameter-mapping
                intentParameter="feature"
                required="true"
                urlParameter="recipe" />
        </fulfillment>
      ...
  </action>
  ...
</actions>

Pronto! Agora já está configurado para abrir o slice direto no Google Assistant. Para testar essa parte agora, basta abrir o Android App Actions Test Tool novamente e, se tiver um preview já criado, clique em Update Preview para que a ferramenta possa atualizar suas informações com as alterações feitas em actions.xml.

Slice no Google Assistant

Considerações finais

Implementar ações e slices para o app pode ser algo bem interessante que ajuda muito no engajamento e na interação do usuário. Contudo, muitas coisas ainda estão em fase experimental, por isso algumas questões ainda podem se alterar e tem muito a ser aprimorado.

De qualquer forma, é uma funcionalidade incrível que vale a pena testar e aprender pois está cada vez mais comum obtermos conteúdo através de assistentes virtuais e ter isso a favor do nosso aplicativo pode ser um alto ganho de usabilidade e negócio.

O código completo do projeto abordado neste artigo pode ser encontrado no Github.

Realidade Aumentada para Android: ARCore e Sceneform

Ana Coimbra — Sun, 19 Apr 2020 20:31:52 +0000

Com a quantidade de aplicativos e soluções digitais atualmente, os usuários estão exigindo cada vez mais interações mais imersivas e que sejam cada vez mais próxima da realidade. Com isso, vemos crescer o número de aplicações com o uso de realidade aumentada.

O que é Realidade Aumentada?

Realidade Aumentada é uma experiência interativa em que objetos do mundo virtual sobrepõe o mundo real e, dessa forma, os dois coexistem e podem interagir entre si.

Um aplicativo bem famoso que usa esse recurso é o Pokémon GO.

Aplicativo Pókemon GO usando Realidade Aumentada. Fonte: Tumisu from Pixabay

Também é usado em aplicativos de lojas de móveis e acessórios pra casa, para que se possa visualizar o objeto no ambiente real.

Posicionamento de móveis usando realidade aumentada

Com o avanço dos hardwares disponíveis em diversos dispositivos do mercado, principalmente nos smartphones intermediários, essa tem se tornado uma tecnologia emergente que muitas empresas estão investindo.Se quiser saber mais informações, fiz também um texto mais teórico sobre realidade aumentada.

Google ARCore

ARCore é a plataforma da Google pra construir experiências em realidade aumentada para Android, Unit, e até mesmo pra web. Para deixar a interação entre mundo real e virtual mais completa, faz uso de três características principais através da câmera do dispositivo:

O rastreamento de movimento permite entender e rastrear a posição do dispositivo em relação ao espaço.
O entendimento do ambiente permite que o dispositivo reconheça o tamanho e localização de todos os tipos de superfícies disponíveis.
A estimativa de luz permite que o dispositivo estime as condições atuais de luz ambiente.

Basicamente, o ARCore rastreia posição do dispositivo conforme ele se move e ao mesmo tempo constrói seu entendimento do mundo real. Para fazer isso ele utiliza pontos chaves ( feature points ) na imagem da câmera que ajudam a detectar diversos tipos de superfícies e também as mudanças de localização.

Se tem vontade de aprender mais a fundo sobre o ARCore e seus fundamentos, basta verificar a sua documentação.

Limitações

Para uma boa experiência, é necessário demonstrar ao usuário o espaço necessário para o pleno funcionamento da aplicação. No caso de grandes espaços e lugares públicos, o grande desafio é, principalmente, a oclusão , quando um objeto virtual sobrepõe objetos físicos mas na verdade não deveria. No caso do ARCore atualmente não é possível tratar esse problema, mas a Google já anunciou o desenvolvimento da ARCore Depth API.

Um dos fatores essenciais em algumas aplicações com ARCore é a detecção do(s) plano(s) onde serão inseridos os objetos virtuais. Contudo alguns fatores podem limitar ou dificultar a detecção destes planos:

Superfícies muito lisas e sem textura como uma parede branca
Ambientes com pouca iluminação
Ambientes com iluminação em excesso
Superfícies refletivas ou transparentes como espelho ou vidro
Superfícies em movimento como aqueles robôs que varrem a casa
Superfícies verticais são mais difíceis de serem detectadas que as horizontais

Nestes casos, pode ser que o plano demore muito a ser detectado ou nem aconteça e para ajudar o usuário a entender o que está acontecendo, e ele não achar que é um “erro no sistema” sempre deixe claro as condições necessárias.

Visualização da detecção de plano - Fonte: Google

Quando acionado, o ARCore está sempre ampliando seu entendimento do ambiente e, com isso, pode ser que as primeiras detecções de feature points não sejam tão fidedignas ao mundo real mas, com o tempo isso é ajustado a medida que a aplicação entende melhor o ambiente. Esse ponto pode causar frustração no usuário, tendo em vista que os objetos a serem inseridos em um plano detectado precocemente podem estar fora de escala com o mundo real. Portanto, é recomendado que, após a primeira detecção do plano, o usuário saiba que precisa continuar movendo o dispositivo para o pleno entendimento do ambiente pela aplicação.

Boas práticas

Diversas experiências com realidade aumentada acabam ocorrendo em ambientes não controlados e o usuário é livre para fazer o que bem entende durante sua interação. Portanto, é necessário deixar bem claro pra ele qual o espaço necessário para que os objetos virtuais tenham uma boa visualização dentro do mundo real.

Além disso, essa relação entre mundo virtual e físico precisa ser coerente, por exemplo: não é estranho um guarda-roupa virtual aparecer em cima de um banco? Pois é, por isso é necessário que a pessoa interagindo com o aplicativo saiba qual o espaço ela deve usar: se é uma mesa, um cômodo ou um espaço ao ar livre, por exemplo. Lembrando que também é necessário ser responsivo tendo em vista que existem inúmeros tamanhos de mesa, de cômodos, etc.

Durante a detecção de plano, informe na interface que é necessário mover o dispositivo com imagens e animações. Após o(s) plano(s) ser(em) detectado(s) informe o que o usuário deve fazer em seguida como, por exemplo, adicionar um objeto à cena ao clicar em um plano. Além disso, é necessário realçar a(s) superfície(s) encontrada(s) para que o usuário saiba o espaço que possui pra interagir, mas apenas uma superfície por vez e apenas se o usuário estiver apontando para ela.

Usuários de smartphones estão acostumados a usarem aplicativos de forma estática ou seja, não saem do lugar ou de sua posição. Contudo, em uma aplicação com ARCore, é possível (e recomendado) que a pessoa se movimente e explore o ambiente e tudo que cerca o mundo virtual inserido no mundo físico. Por isso, é dar indicações para que ela se mova e tenha uma experiência mais imersiva (que é o principal propósito da realidade aumentada).

Pistas na cena para o usuário saber que pode se movimentar - Fonte: Google

É claro que terão momentos em que o usuário não estará habilitado a se movimentar, para isso é recomendado dar alternativas para que ele possa imergir na experiência também, como opção de rotacionar, transladar e escalonar os objetos virtuais da cena.

Os usuários quando estão interagindo com uma experiência de realidade aumentada tendem a ficar tão imersos nela que acabam esquecendo do (resto do) mundo real. Por isso, é imprescindível mantê-lo seguro:

Nunca faça o usuário andar para trás, ele não verá se tem algum obstáculo e pode colidir e/ou sofrer uma queda.
Evite experiências que duram um longo período de tempo pois o indivíduo pode se sentir cansado e ter dores após um uso intenso de uma aplicação com realidade aumentada. Proponha pontos de “parada” para que ele tire um tempo para descansar.

Evite situações que o usuário tenha que andar para trás - Fonte: Google

Sceneform

Sceneform é uma biblioteca opensource que permite utilizar todos os recursos do ARCore no Android sem a necessidade direta de manipulação das informações no OpenGL. Ela já nos oferece diversas facilidades também se tratando de funcionalidades padrões de uma aplicação em realidade aumentada como: posicionamento de um objeto no ambiente, renderização de um objeto através de augmented image que utiliza uma imagem como padrão para reconhecer o espaço e determinar posicionamento e orientação, também chamado de fiducial marker.

Histórico

Até a versão 1.15.0 do Sceneform, a bibilioteca não era totalmente opensource e, portanto tínhamos total acesso apenas às funcionalidades diretamente relacionadas a interface com usuário e alguns exemplos de código. Agora, a partir da versão 1.16.0 ela está 100% opensource e os códigos de exemplos anteriores foram descontinuados. Antes, existiam duas formas de carregar um modelo: uma utilizando um arquivo .sfb , que era obtido pelo plugin da própria biblioteca no Android Studio e o outra é utilizando um arquivo .glTF ou .glb que não necessita a utilização do plugin e pode ser carregado diretamente via url do arquivo. O suporte a utilização de arquivos .sfb foi descontinuada e agora só é possível através da segunda forma, por isso os exemplos anteriores foram removidos.

Exemplo Sceneform - Fonte: Google

Conceitos

O Sceneform facilita muito o desenvolvimento de aplicações com ARCore, mas mesmo assim, ainda trás alguns conceitos importantes que devem ser entendidos bem para um bom funcionamento da experiência.

Renderable é a classe base para renderizar qualquer objeto dentro do mundo 3D. Pode ser dois tipos: ViewRenderable que renderiza componentes visuais como TextView, Button dentro do espaço e o ModelRenderable que renderiza objetos 3D em geral, como um cubo, esfera ou qualquer objeto no formato .gLTF ou .glb.
Node representa um item de transformação dentro da cena. Pode ter um renderable atrelado a ele que será apresentado na cena. Um node pode ter inúmeros nodes “filhos” e um “pai”, que pode ser outro node ou a cena(scene).Além de ser possível personalizar o próprio node, existem vários tipos já pré-determinados: AnchorNode, que é automaticamente posicionado na cena de acordo com seu ponto âncora atrelado; AugmentedFaceNode, usado para renderizar funcionalidades de reconhecimento de face e contém dois componentes: face mash que utiliza imagens em 2D e coloca na face reconhecida e renderables para regiões da face e aí é possível detectar pontos como nariz, boca, olhos, etc.; TransformableNode que é um node que pode ser manipulado no espaço com rotação, translação e escala; Camera representa a câmera virtual e mostra a perspectiva pela qual a cena vai ser renderizada; SkeletonNode representa as partes do “esqueleto” de um ModelRenderable; Sun representa o “sol” da cena que nada mais é que uma luz direcional.
Scene mantém a estrutura de dados dos componentes da cena, que nada mais é que um grafo, mais especificamente uma árvore, que tem como raíz a cena(scene) e tem inúmeros filhos(nodes) que por sua vez podem ter outros filhos nodes.
Light representa a luz aplicada a um node. Pode ser direcional ( DIRECTIONAL ) que representa uma luz infinitamente longe; pontual ( POINT ) que irradia raios de luz em todas as direções a partir de um único ponto de luz; holofote ( SPOTLIGHT ) que é parecida com a luz pontual mas irradia os raios em um cone; holofote focado ( FOCUSE_SPOTLIGHT ) é igual ao holofote normal mas a percepção da intensidade é a mesma independente do angulo do cone.
Plane descreve os atributos de uma superfície planar identificada pela aplicação. É possível que mais de um plano sejam fundidos em um plano “pai” que por sua vez é mais amplo que seus “filhos”. Para visualizar os planos detectados, é usado o PlaneRenderer.
Anchor ou âncora descreve uma posição fixa no mundo real, contento localização (coordenadas) e direção e também ajuda no entendimento do ambiente feito pelo ARCore.
CollisionShape possui a representação matemática de alguma forma geométrica que é usada em cálculo de colisões ou tamanho relativo entre os objetos (virtuais) da cena. Pode ser um cubo, uma esfera ou um raio.

Conclusão

O ARCore tem se tornado uma excelente ferramenta para criação de experiências com Realidade Aumentada para diversas plataformas, principalmente o Android. Apesar de ainda ter algumas limitações, tem resolvido de forma eficiente as demandas de aplicações em RA que tenho observado. Além disso, essas limitações conseguem ter menos impacto quando mantemos o usuário sempre informado do que está acontecendo e do que ele pode e/ou precisa fazer para melhorar a experiência.

Além disso, com o Sceneform é possível fazer excelentes experiências com realidade aumentada de forma simples e rápida. Contudo, fazer customizações de visualização e renderização pode ser um grande desafio, tendo em vista que a documentação tem certa limitação em relação aos componentes da cena e também não se encontra muito material avançado sobre o assunto.

Política de Cross-Origin

Ana Coimbra — Sun, 19 Apr 2020 03:04:00 +0000

É muito comum uma pessoas que desenvolvem Front-End se depararem com um erro frequente que é parecido com:

Origin http://localhost is not allowed by Access-Control-Allow-Origin

E então vamos procurar na internet como resolver esse problema e nos deparamos com diversas soluções e cada uma funcionando de forma diferente e as vezes só copiamos e colamos e não entendemos muito bem.

Resposta do StackOverflow falando para adicionar um header no servidor

Pensando neste exemplo de resposta do StackOverflow, a recomendação é adicionar um header no servidor e tudo será resolvido. Se alguém que passou por essa questão e fez apenas o que foi sugerido na imagem, acredito que não resolveu 100% do problema (sim, já aconteceu comigo). Além disso, nem sempre temos acesso a este servidor.

Resposta do StackOverflow para abrir o chrome em modo sem segurança

Neste outro caso, é recomendado que a pessoa abra o navegador com a segurança desativada que os requests vão funcionar. Já testei esse modo também e é incrível! Tudo funciona perfeitamente! Mas será que todos os usuários do meu site vão fazer isso também? É, acho que não.

Neste artigo vou mostrar um pouco do que é essa política cross-origin, mais conhecida como CORS.

O que é CORS?

Cross-Origin Resource Sharing é a sigla atribuída ao mecanismo dos navegadores que gerencia o compartilhamento de recursos entre diferentes origens.

Por padrão, quando fazemos uma requisição através do XMLHttpRequest ou utilizando a API Fetch do javascript, os navegadores utilizam a política same-origin que só autoriza a troca de recursos entre as mesmas origens (domínios). Se for necessário essa troca entre diferentes origens, é necessário configurar as chamadas para que contenham os cabeçalhos CORS corretos.

A utilização do CORS é importante porque além de poder restringir QUEM pode acessar os recursos de um servidor também pode especificar COMO esses recursos devem ser acessados. Mais para frente retornaremos nesta parte com exemplos.

O que é uma origem?

Uma origem, ou domínio é composto por três partes: protocolo, host e porta.

Definição de Origem ou Domínio: conjunto de protocolo, host e porta

Pegando como exemplo o domínio http://exemplo.com acima temos como protocolo HTTP, o host exemplo.com e a porta (oculta) 80. Se for necessário obter um recurso que mude qualquer um destes 3 itens, já não está dentro da mesma origem e, portanto a política same-origin não é mais válida e por isso precisamos configurar as chamadas para utilizarmos a política cross-origin.

Políticas de compartilhamento de recursos

Como funciona o CORS?

O mecanismo funciona adicionando cabeçalhos HTTP nas respostas dos servidores para que estabeleçam um compartilhamento de recursos seguro entre diferentes origens. Com ele é possível configurar as origens permitidas para acessar o recurso e quais métodos (GET, POST, PUT, DELETE, etc.) elas podem utilizar.

Além disso, quando o site faz uma requisição que pode causar efeitos colaterais no servidor, o navegador realiza uma “pré-requisição” ou preflight request para que o servidor retorne que é possível realizar a requisição que é pedida originalmente e só então ela é enviada ao servidor.

Preflight — Simulação de uma conversa entre o Servidor A e o Servidor B

A figura acima mostra como seria essa requisição se ela fosse uma conversa entre humanos. O Servidor A está precisando realizar uma ação no Servidor B que causa um efeito colateral nos dados do Servidor B e por isso, é necessário fazer a pré-chamada que é o mesmo que pedir autorização para fazer a ação 𝞪 no recurso 𝞫 sendo a origem 𝟃.

Mas então, pra toda requisição que meu site faz, na verdade são feitas duas requisições? A preflight e a original? Bom, na verdade existem algumas condições que necessitam de fazer as pré-chamadas. Portanto existem dois tipos de requisições:

as requisições simples
as requisições que exigem preflight.

Requisições Simples

Uma requisição simples é basicamente uma requisição que, em teoria não causa efeitos colaterais no servidor. Além disso tem que atender a todas as condições abaixo:

Métodos permitidos: GET, HEAD, POST (com ressalvas relacionadas ao cabeçalho, como mostra os próximos tópicos)
Além dos cabeçalhos pré-configurados pela conexão, apenas alguns outros são permitidos, como: Accept, Accept-Language, Content-Language, Content-Type (com ressalvas), DPR, Downlink, Save-Data, Viewport-Width, Width
Valores permitidos para Content-Type: application/x-www-form-urlencoded, multipart/form-data, text/plain

Nos códigos abaixo podemos verificar exemplos de chamada de uma requisição simples e como ela deve ser tratada no servidor.

fetch("http://localhost:8080", {
  method: "GET"
});

Requisição simples — Cliente

app.get("/", (req, res) => {
  res.setHeader("Access-Control-Allow-Origin", "http://localhost:3000");
  res.send("Hello Cors Test");
});

Requisição simples — Servidor

Nesta chamada podemos verificar os cabeçalhos da requisição e não é necessário fazer a pré-requisição pois está dentro das condições anteriores. Contudo, mesmo nas chamadas simples, precisamos configurar o CORS como podemos ver no cabeçalho Access-Control-Allow-Origin.

Cabeçalhos — Requisição simples

Requisições que exigem pré-requisições

Quando a requisição não atende às condições citadas acima, ela precisa enviar uma pré-requisição que nada mais é que um OPTIONS com algumas informações sobre a requisição original.

fetch("http://localhost:8080", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: { key: "value" }
});

Requisição preflight — Cliente

No caso dessas requisições é necessário configurar os cabeçalhos para a chamada OPTIONS porque ela que realiza a autorização da requisição original.

app.options("/", (req, res) => {
  res.setHeader("Access-Control-Allow-Origin", "http://localhost:3000");
  res.setHeader("Access-Control-Allow-Headers", "Content-Type");
  res.send(true);
});

app.post("/", (req, res) => {
  res.send("POSTED on root");
});

Requisição preflight — Servidor

As imagens abaixo mostram os cabeçalhos da pré-chamada e da chamada efetiva respectivamente. É possível reparar que, na parte do Request Headers o cliente envia ao servidor que deseja adicionar um cabeçalho não autorizado por padrão — content-type — e também uma ação que pode causar um efeito colateral — POST — e por isso é preciso enviar esses cabeçalhos requisitando esses recursos. Na parte de Response Headers é possível observar que o servidor autoriza a origem http://localhost:3000 a acessar seu recurso e também autoriza o cliente a adicionar o cabeçalho content-type.

Preflight Headers	Post Headers

Cabeçalhos — Preflight e Efetivo

Boas práticas utilizando CORS

É claro que quando conhecemos mais sobre o que estamos usando, configurando e trabalhando consequentemente já teremos uma nova visão e um senso crítico para tal. Mas como tudo, as configurações de CORS também exigem algumas boas práticas para manter a segurança e consistência da comunicação entre diferentes origens.

Na configuração de Access-Control-Allow-Origin, ao invés de utilizar ”*” que libera qualquer origem de acessar o seu servidor, coloque exatamente a(s) origens que realmente devem ter acesso.
O princípio do CORS é manter sua conexão segura, e por isso se liberarmos qualquer origem, qualquer método e/ou qualquer cabeçalho, este princípio não será atingido. Portanto precisamos deixar nossas requisições seguras e apenas autorizar as origens, métodos e cabeçalhos necessários para a conexão.
Existem alguns workarounds/gambiarras, como vimos nos posts do stack overflow, ou resolver apenas no lado do cliente usando técnicas como jsonp do jquery e no-cors na API Fetch (não é recomendável). O ideal é estar configurado com o mínimo de abertura, apenas o necessário.

Conclusão

Bom, o objetivo desse artigo é compartilhar alguns conhecimentos que adquiri ao me deparar com problemas relacionados a política cross-origin e, como sei que pra mim foi difícil entender o problema e encontrar soluções, imagino que outras pessoas também tenham essa dificuldade e por isso eu resolvi ajudar com esse texto. Espero que tenham gostado e comentários e/ou informações a acrescentar são sempre bem vindos!

Referências

Agradecimento especial a Vanessa e Diogo por revisarem esse texto ❤

Realidade Aumentada Fundamentos e Conceitos

Ana Coimbra — Sun, 19 Apr 2020 01:28:21 +0000

Atualmente, com a o avanço cada vez mais rápido das tecnologias e da capacidade de processamento dos dispositivos tecnológicos, a realidade aumentada tem sido um recurso muito usado para diversas aplicações. Este artigo tem como objetivo apresentar de forma mais conceitual o que significa e o que contempla essa experiência.

Frequentemente tentamos sempre fazer associações do mundo virtual com o mundo real mas isso ocasionalmente gera um certo esforço cognitivo. A realidade aumentada então chega com um propósito de ligar o mundo real com componentes digitais de forma direta e automática. O princípio básico da realidade aumentada é apresentar informações dentro do ambiente físico. É como se o conteúdo digital fizesse parte do mundo real na percepção do usuário.

Dando um passo atrás, precisamos definir primeiro o que nós percebemos como realidade: um conjunto de sensações, seja auditiva, visual, palatável, olfativa ou gestual que associamos a memórias e modelos mentais pré adquiridos. Portanto, perceba que cada um tem uma percepção diferente de realidade, pois cada indivíduo tem um conjunto de modelos e memórias diferentes entre si, mesmo que as sensações sejam as mesmas. Com isso, quando uma realidade é "aumentada" - ou estendida - com objetos e/ou informações virtuais, é necessário que estes sejam coerentes ao mundo real em relação a posição e tamanho independente do dispositivo usado. Ou seja, quanto mais consistente for a aplicação dos objetos virtuais no mundo físico, mais transparente é essa experiência.

Uma experiência de realidade aumentada precisa ter, necessariamente, três características:

Combinar o real e o virtual: o usuário se mantém no mundo real, podendo sentir (ver, ouvir, cheirar, tocar) tudo que ele sentiria independente da experiência em RA. As informações adicionadas de forma digital devem fazer sentido para ele dentro daquela realidade no momento.
Interativo em tempo real: toda informação virtual tem uma localização ou espaço físico a ser inserido dentro do mundo real. E isto precisa se manter constante independente da movimentação ou ponto de vista do usuário.
Feito em 3D: como seres humanos com dois receptores de imagem (olhos), nós percebemos o mundo real em 3D, portanto as informações digitais que serão inseridos nele precisam estar compatíveis com esse modelo.

Repare que não existe nenhuma limitação de dispositivo e muito menos tem o requisito de ser uma interação visual. Podendo ser também auditiva, gestual ou até mesmo degustativa ou olfativa. Contudo é necessário que o usuário tenha controle em tempo real das informações e um registro do espaço. Portanto é preciso que, independente da movimentação do dispositivo utilizado, as informações estejam atreladas ao ambiente corretamente.

Componentes da Realidade Aumentada

Em geral, duas coisas precisam acontecer em uma aplicação de realidade aumentada, de forma cíclica e contínua:

A aplicação precisa determinar o estado atual do mundo real e do mundo virtual.
A aplicação precisa mostrar o conteúdo virtual sobreposto ao mundo real de forma que o usuário sinta o mundo virtual como parte do mundo físico.

Existem três componentes em uma aplicação de realidade aumentada:

Sensores que determinam o estado do mundo real onde a aplicação está rodando.
Processador que avalia as informações adquiridas pelos sensores, aplica as leis da física e outras regras necessárias pelo mundo virtual para gerar os sinais necessários para o display das informações.
Um display - ou algum sistema interativo adequado para criar a impressão que o mundo real e o virtual são coexistentes e "confundir" o usuário para que ele perceba tudo como uma realidade única.

Sensores

Para responder corretamente ao ambiente, o mundo virtual precisa de dados atualizados em tempo real do mundo físico. Para isso, são usados diversos sensores, que podem ser divididos em três categorias:

Sensores de rastreamento: como a realidade aumentada tem como princípio ser registrada espacialmente, é necessário ter algum mecanismo que determine informações sobre a posição do participante, o mundo real e qualquer que seja o dispositivo usado na interação com RA. Neste caso, posição inclui localização e orientação. Exemplos de sensores de rastreamento: Câmera, GPS. Giroscópio, Acelerômetro e Bússola. Para determinar de forma completa uma posição é necessário informação sobre seis graus de liberdade de cada entidade que é rastreada, segundo a figura abaixo.

Seis graus de liberdade incluem coordenadas X, Y e Z e também inclinação, direção e rotação do objeto no eixo em que ele se encontra.

Sensores de variáveis do ambiente: Existem uma série de sensores que são menos utilizados em uma experiência de realidade aumentada, mas podem prover diversas informações relevantes sobre o mundo físico. Por exemplo: sensores de temperatura, umidade, pH, etc. Uma forma de aplicar esses sensores seria utilizar a aplicação como uma "lente mágica" que permite ao usuário visualizar as informações que seriam apenas "dados numéricos" em uma tela de computador. Sensores de entrada do usuário: Enquanto nos outros sensores o usuário não tem controle sobre o que é rastreado ou medido, neste caso os sensores incluem componentes como botões, teclado, ou qualquer interface interativa em que o usuário possa tomar decisões sobre a experiência de realidade aumentada.

Processador

O processador é o componente que obtém e analisa todos os dados dos sensores e coordena todas as tarefas de um sistema de realidade aumentada. Além de mandar todas a informações necessárias para o display mostrar as informações.
O processador precisa ter poder computacional suficiente para fazer tudo isso citado em tempo real (na percepção do usuário). Para cada ação ou modificação nos dados dos sensores, as informações devem ser atualizadas sem nenhum atraso para o indivíduo.
Por padrão, uma aplicação em realidade aumentada precisa sustentar, no mínimo, uma taxa de 15 frames por segundo - o ideal é que seja maior - para que o participante perceba o display como algo contínuo.

Display

O display é o componente que vai causar uma "confusão" na percepção de realidade do usuário. Um display pode ser tanto o dispositivo que mostra os sinais computados no processador e vai misturar o mundo real e o mundo virtual como também podem ser os sinais apresentados na interação. Por exemplo, se tenho uma tela de smartphone mostrando uma cena de uma mesa, então essa tela é um display, assim como a mesa. Neste caso, a cena é um display que é apresentado por outro display.

Conceitos relacionados a Realidade Aumentada

Para entender plenamente o funcionamento da realidade aumentada, é necessário saber também de alguns conceitos relacionados.

Visão computacional

Uma posição (localização e orientação) pode ser tanto absoluta: independe de qualquer outra coisa, ou seja, é relativo ao ambiente global com também pode ser relativa: determinada a partir da posição de outro objeto.

Exemplo: Temos nas imagens um vaso virtual e uma mesa real. Na parte de cima, o vaso está posicionado em relação a mesa e, por isso, ao mover a mesa automaticamente o vaso é movido junto. Na parte de baixo, o vaso está posicionado de forma absoluta no ambiente, então, ao mover a mesa, o vaso permanece na mesma posição.

O sensor (câmera) "enxerga" o mundo real e, baseado no que "vê", consegue determinar onde ela se encontra e sua orientação em relação a cena. Para trabalhar com visão computacional, é necessário analisar as imagens coletadas pela câmera para determinar o que é que ela "vê". Para isso, é necessário que existam pistas no ambiente que serão usados como pontos de referência para que ajude a determinar a localização e orientação em relação a esses pontos. Contudo, nem sempre é possível ou fácil (para o software) de detectar esses pontos.

Para facilitar este problema, diversas aplicações de realidade aumentada utilizam imagens facilmente reconhecíveis que viram pontos de referência colocadas no ambiente de forma artificial. Essas imagens são chamadas de fiducial markers ou fiducial symbols (marcações ou símbolos impacientes). Quando o sistema encontra essas marcações consegue determinar mais facilmente onde a câmera está e qual sua orientação em relação ao símbolo. Uma marcação fiducial precisa ter um padrão único, um bom contraste para que seja muito fácil para um software de visão computacional reconhecer e também precisa ser assimétrico de forma que seja mais simples o cálculo da orientação da câmera sobre o marcador.

Exemplo de uma Fiducial marker

Computação gráfica

Conforme já mencionado, os objetos de uma experiência de uma realidade aumentada são descritos em 3D, mas esses objetos devem ser renderizados em uma imagem que será visualizada em um display 2D. E essa imagem deve ser gerada respeitando o ponto de vista, iluminação, propriedades do material, perspectiva, etc. Para isso usamos diversos conceitos de computação gráfica, como por exemplo descrever o objeto como uma malha de polígonos em um sistema de coordenadas tridimensional.

Além disso, os objetos possuem propriedades que descrevem a aparência dele, como cor, refletividade, textura, etc. Com o mapeamento de textura uma imagem bidimensional pode ser aplicada a uma malha e mapeada como uma propriedade de superfície.

Por fim, é possível também adicionar luzes na cena que serão incorporadas na renderização final da imagem e podem afetar as cores, sombra e outros aspectos gráficos da cena.

Dimensionalidade

Conforme visto anteriormente, o mundo físico é tridimensional enquanto o mundo virtual pode existir em inúmeras dimensões. Na realidade aumentada, o mundo real e o virtual são combinados em um display de apenas duas dimensões. Para resolver esse "dilema", além dos conceitos de computação gráfica, também é utilizado uma série de recursos que permitem ao usuário a percepção de profundidade (deph cues). Esses recursos nos permitem determinar quão distante estão as coisas de nós e como entendemos o mundo tridimensional em que vivemos. Exemplos de deph cues: tamanho - um objeto menor tende a estar mais longe que o objeto maior; iluminação - objetos com menos luz estão mais longe.

Registro e Latência

Os conceitos de registro e latência se referem ao alinhamento do mundo virtual e real.

O registro se refere a quão preciso o mundo virtual se alinha fisicamente com o mundo físico. Quando os registros estão inadequados podem atrapalhar o efeito de realidade aumentada, principalmente se a aplicação é puramente uma "fusão" dos dois mundos. Um registro bem feito depende de diversas variáveis e a principal é a acurácia do sistema de rastreamento do ambiente.

A latência é a quantidade de tempo que um componente do mundo virtual demora a ser atualizado em relação ao que deveria ocorrer idealmente (no mesmo instante). Assim, é possível dizer que a latência é um tipo de registro temporal.

Embora ainda não vemos tantas aplicações em realidade aumentada frequentemente no nosso dia a dia, cada vez mais ela tem se difundido, principalmente nos aplicativos de jogos, varejo de móveis, além da sua utilização em eventos e campanhas promocionais (muitas vezes com o uso das fiducial markers).

Por isso acredito ser cada vez mais importante entender a essência dessa experiência que tem um grande potencial na tecnologia e nos negócios.

Referências