Realidade aumentada no celular do seu cliente, não no seu: o que fazer quando o público tem aparelho simples

A realidade aumentada funciona lindamente no celular de quem a desenvolve. O problema é que o cliente final quase nunca tem esse celular.

Essa é uma das lições mais caras de quem entrega RA para público amplo: a experiência é aprovada num aparelho recente, em sala com boa luz, e chega a alguém com um telefone de entrada, comprado há quatro anos, numa cozinha à noite. A tecnologia é a mesma. O resultado, não.

Este post é o que aprendemos atendendo esse tipo de suporte — e o que dá para fazer no projeto para o problema simplesmente não existir.

Por que não abre: são quatro motivos diferentes

"Não consigo ver" costuma esconder causas distintas, e cada uma tem solução própria.

1. O aparelho não é compatível — e isso não depende de ser novo

No Android, a RA nativa depende do ARCore, e o Google só habilita aparelhos certificados: o modelo passa por checagem de câmera, sensores de movimento, arquitetura e desempenho de processador. Não basta rodar Android 7.0 ou superior e ter a Play Store — se o fabricante não fez a calibração com o Google, aquele modelo não entra na lista, mesmo sendo recente. É por isso que dois celulares parecidos, do mesmo ano, se comportam de forma diferente.

No iPhone, a régua é mais simples: ARKit exige processador A9 ou superior — ou seja, do iPhone 6s em diante — com iOS 11 ou mais novo. Recursos avançados, como o sensor LiDAR, existem só nos modelos Pro.

2. Falta o componente do sistema

Mesmo em aparelho compatível, o Android precisa do Google Play Services para RA instalado e atualizado. Em celulares com pouco espaço livre — situação comum em aparelhos de entrada — esse componente costuma não ser instalado ou ficar desatualizado silenciosamente.

3. O link foi aberto dentro de outro aplicativo

Este é o campeão de chamados, e não tem nada a ver com a qualidade do telefone. Quando a pessoa toca no link dentro do WhatsApp, Instagram ou Facebook, a página abre no navegador interno daqueles aplicativos — e esse navegador não aciona a RA nativa. A experiência precisa ser aberta no Chrome, no Android, ou no Safari, no iPhone.

4. O ambiente físico não colabora

A RA que "coloca o objeto no chão" precisa reconhecer uma superfície, e para isso depende de textura visual e de luz. Piso liso e brilhante, parede branca lisa, mesa de vidro ou pouca luz deixam o rastreamento sem pontos de referência — daí a mensagem de que o chão não foi identificado. Não é defeito do app: é o limite de detectar plano por câmera.

O erro de projeto que causa tudo isso

O erro não é técnico, é de decisão: escolher o tipo de RA olhando o celular da equipe, e não o do público. Quando o produto vai para um público amplo — um livro, uma embalagem, um material distribuído em escola —, boa parte dos leitores terá aparelho de entrada, memória cheia e conexão instável. Projetar para o topo da lista é garantir chamado de suporte.

A saída técnica: mudar o tipo de RA, não o público

Existem dois jeitos bem diferentes de fazer RA, e eles têm exigências muito distintas:

• RA de superfície (detecção de plano). O aparelho precisa mapear o ambiente em tempo real. É a mais impressionante e a mais exigente — sensor, processamento e ambiente favorável.
• RA por imagem-alvo. O conteúdo aparece quando a câmera reconhece uma imagem específica: a capa do livro, a página, o rótulo, um cartão impresso. Como o ponto de referência é a própria imagem, não é preciso detectar chão nem mapear a sala — o que a torna sensivelmente mais tolerante a aparelho simples e a ambiente ruim.

Para material impresso, a imagem-alvo costuma ser a escolha certa não por ser mais barata, mas por ser mais robusta: a página já é o marcador, o enquadramento é natural e o usuário entende sozinho o que fazer — apontar a câmera para a figura.

E quando já é imagem-alvo e mesmo assim não abre?

Trocar para imagem-alvo elimina a parte mais frágil — mapear o ambiente —, mas não torna a experiência imune. O reconhecimento continua dependendo de a câmera enxergar o desenho com nitidez suficiente, e é aí que o aparelho simples aparece de novo. O que costuma atrapalhar, em ordem de frequência:

• Foco. Muitas câmeras de entrada têm foco fraco ou fixo. Imagem levemente borrada não casa com o alvo — e a pessoa jura que está apontando certo, porque para o olho dela está.
• Reflexo do papel. Página brilhante, plastificada ou envernizada devolve a luz direto para a lente e apaga o desenho. É o motivo mais comum de "funciona na loja e não funciona na casa do cliente", porque muda a lâmpada.
• Pouca luz. No escuro a câmera aumenta o ganho, a imagem ganha ruído e o padrão se perde.
• Distância e ângulo. Perto demais corta o alvo, longe demais deixa poucos pixels, e muito inclinado deforma o padrão. O intervalo que funciona é mais estreito em câmera ruim.
• A curvatura da página — em livro, este é o problema estrutural. O reconhecimento de imagem-alvo parte do princípio de que o desenho está numa superfície plana. Perto da lombada a página curva, e essa curva deforma o padrão de forma contínua: as distâncias entre os pontos de referência mudam, e o casamento com o alvo original falha. Quanto mais grosso o livro e mais rígida a lombada, pior — livro de lombada colada praticamente não abre a 180 graus, e a curva engole justamente a metade interna da página.
• O próprio alvo é pobre em detalhe. Ilustração com cores chapadas, muito espaço vazio, padrão repetido ou simetria dão poucos pontos de referência. Duas páginas parecidas podem até ser confundidas entre si.
• Desempenho. Aparelho lento processa menos quadros por segundo: o reconhecimento demora, a pessoa desiste antes.

O que fazer no projeto: posicionar o alvo no terço externo da página, longe da lombada, e nunca fazê-lo atravessar as duas páginas — a dobra central corta o padrão em dois planos diferentes; preferir, quando houver escolha, encadernação que abra plana (costurada ou espiral); escolher como alvo as ilustrações com mais textura e contraste (e testar cada uma antes de imprimir, com o livro aberto na mão, não com a folha solta sobre a mesa); evitar acabamento brilhante nas páginas que serão escaneadas; imprimir na própria página a instrução de distância e de luz; e — o detalhe que mais reduz chamado — mostrar na tela o que o app está vendo, com uma moldura indicando o enquadramento certo, em vez de deixar a câmera aberta sem nenhuma pista.

E o plano B, que quase ninguém entrega

Sempre vai existir alguém cujo aparelho não suporta RA de jeito nenhum. Para essa pessoa, o projeto precisa ter uma segunda porta:

1. Modelo 3D girável sem câmera. A mesma peça, na tela, que a pessoa arrasta com o dedo. Roda em quase tudo e entrega 80% do valor.
2. Vídeo curto da experiência. Gravado uma vez, mostra o que ela veria.
3. Mensagem que ensina, não que culpa. "Seu aparelho não é compatível" fecha a porta. "Toque aqui para ver em 3D" mantém a pessoa dentro.

Checklist antes de lançar para público amplo

• Testar no aparelho mais simples que o seu público realmente usa — comprar um de entrada usado sai mais barato que perder cliente.
• Testar com pouca luz e sobre superfície lisa, não só na mesa de madeira do escritório.
• Testar abrindo o link de dentro do WhatsApp, porque é assim que ele vai circular.
• Incluir instrução no material impresso: qual navegador abrir e o que apontar.
• Ter a segunda porta pronta antes do lançamento, não depois do primeiro e-mail de reclamação.

O que responder a quem escreve dizendo que não funciona

Um roteiro curto resolve a maioria dos casos, na ordem: peça o modelo do aparelho; pergunte se o link foi aberto dentro de algum aplicativo e peça para abrir no Chrome ou no Safari; sugira testar com mais luz e apontando para uma superfície com textura; e, se nada disso resolver, mande o vídeo ou o modelo 3D. A pessoa não quer entender de ARCore. Ela quer ver a figura mexer.

Se você está planejando um projeto assim, vale ler antes quanto custa criar um aplicativo de realidade aumentada — inclusive para descobrir quando você não precisa de um. E se quiser essa decisão tomada com o público real em mente, é o que fazemos em realidade aumentada e em desenvolvimento de aplicativos.