Configurações do World Locking Tools Context e Manager
O World Locking Tools Context permite a personalização paramétrica do World Locking Tools Manager no Unity Inspector.
Embora o componente WorldLockingContext apresente uma interface do usuário para o WorldLockingManager, é importante entender que eles são diferentes e, em algumas situações, pode ser importante entender sua relação.
O Manager é um singleton
O WorldLockingManager é um singleton criado sob demanda e persistente durante o tempo de vida do aplicativo. Se nenhuma chamada for feita ao WorldLockingManager, uma instância nunca será criada para ele. Após a criação da instância, ele permanecerá ativo até que o aplicativo seja desligado. Ele nunca será destruído e uma nova instância não será criada.
O WorldLockingManager não é um objeto do Unity, mas uma classe C# genérica. Sua Atualização é controlada por um componente de proxy do Unity, uma instância da classe privada WorldLockingManager.UpdateProxy. Ele é independente dos ciclos de criação/atualização/destruição do Unity.
O Contexto é um componente do Unity
O WorldLockingContext é um componente do Unity que é adicionado a um objeto na cena da maneira habitual. Seus campos aparecem no Unity Inspector, assim como qualquer outro componente regular do Unity.
Embora não seja um erro ter vários WorldLockingContexts ativos em uma única cena, isso provavelmente não é desejado, pois o comportamento seria indefinido, dependendo da ordem desconhecida de carregamentos de objeto.
As configurações em um contexto são aplicadas quando o WorldLockingContext é carregado. Especificamente, o contexto envia por push suas configurações para o World Locking Tools Manager em sua chamada OnEnable e sempre que a cena se torna a cena ativa. O segundo caso será aplicado como parte do retorno de chamada Unity.SceneManager.activeSceneChanged se, e somente se, a nova cena ativa for a cena à qual o contexto pertence.
Todas as configurações podem ser aplicadas do script
O aplicativo pode aplicar as configurações personalizadas ao WorldLockingManager através do script a qualquer momento no runtime. Se a desinstalação e recompilação dos recursos for necessária para efetivar uma alteração nas configurações, essa reconstrução ocorrerá imediatamente na alteração das configurações.
Embora seja conveniente para alguns membros obter os valores individuais da propriedade do WorldLockingManager, por exemplo, Salvamento Automático, a configuração dos parâmetros sempre ocorre de forma agregada. Por exemplo, o código para alternar os recursos AutoMerge e AutoRefreeze pode ter esta aparência:
/// Get a copy of the current settings
var settings = WorldLockingManager.GetInstance().Settings;
/// Modify the copy
settings.AutoMerge = !settings.AutoMerge;
settings.AutoRefreeze = !settings.AutoRefreeze;
/// Update the current settings to the values in the copy.
WorldLockingManager.GetInstance().Settings = settings;
O mesmo ocorre com as configurações de diagnóstico.
Observe que a alteração de várias configurações de uma só vez incorre apenas no custo de uma única recompilação (se necessária).
Precedência das configurações
As regras para as configurações atualmente aplicadas ao WorldLockingManager são muito simples:
Se nenhuma cena contendo um contexto tiver sido carregada e nenhuma configuração tiver sido definida explicitamente do script, o WorldLockingManager terá as configurações padrão.
Uma configuração manterá seu valor até que seja substituída por um carregamento do WorldLockingContext com uma cena ou uma alteração explícita invocada do aplicativo no script.
Tenha cuidado ao misturar as configurações do World Locking Tools Manager de contextos e configurações de scripts. Como o contexto sempre aplica suas configurações na carga, um script aplicando manualmente a configuração durante a carga, especialmente de seu retorno de chamada OnEnable, provavelmente enfrentará condições de corrida e comportamento indeterminado.
Configurações disponíveis
As configurações disponíveis para controlar o comportamento do World Locking Tools estão divididas em grupos conforme descrito abaixo.
Configurações de automação
As configurações de automação controlam o comportamento de runtime do World Locking Tools Manager. Os campos disponíveis para modificação e suas implicações estão documentados na classe ManagerSettings. Eles focam na habilitação ou desabilitação de ações periódicas automatizadas pelo gerente. Qualquer ação automatizada desabilitada pode ser executada manualmente.
Configurações de vínculo
As configurações de vínculo são usadas para definir explicitamente a cena GameObjects cujas transformações serão usadas para aplicar correções do World Locking Tools.
O campo "Usar os existentes" permite que os objetos vinculados sejam definidos uma vez na cena com o simulador de câmera (com "Usar os existentes" false) e não substituídos por carregando cenas de conteúdo subsequentes (com "Usar os existentes" true).
Por outro lado, a definição de "Usar os existentes" como false permite que várias cenas, cada uma com um simulador de câmera diferente, se vinculem aos locais apropriados na hierarquia da câmera.
Ao criar e gerenciar a hierarquia de câmera do script, o campo "Usar os existentes" deve ser definido como true em todos os Contextos e os vínculos são atualizados explicitamente da câmera que gerencia os scripts.
Quando as transformações necessárias não são fornecidas, todos os Contextos ficarem nulos ou possuírem "Usar os existentes", o sistema emite um aviso e tenta fazer boas escolhas. É recomendável, mas não necessário, definir explicitamente as transformação apropriadas, em vez de fazer com que o sistema estime.
Há duas opções adicionais que controlam como a correção de transformação da câmera será aplicada.
O padrão da primeira caixa de seleção, para "Aplicar ajuste", é habilitado. Isso informa ao sistema para aplicar a correção da câmera computada a cada quadro ao "Quadro de Ajuste" GameObject. Essa desabilitação é um recurso muito avançado e só deve ser tentado depois que todos os outros problemas forem resolvidos e uma compreensão profunda do World Locking Tools for obtida. Em resumo, ele informa ao sistema que a correção da câmera não deve ser aplicada à câmera, mas será aplicada por outros meios. Normalmente, isso é feito através de um componente AlignSubtree, mas não precisa ser.
A segunda caixa de seleção, para "Sem rotação sobre o eixo x e rolagem", informa ao sistema para zerar qualquer rotação sobre o eixo x e rolagem computadas na transformação de Playspace em Espaço com Bloqueio. (Consulte esta discussão sobre espaços de coordenadas do WLT). Isso não tem nenhum efeito sobre a rotação aplicada pelo sistema SpacePin, mas afeta apenas a transformação de correção da câmera de bloqueio calculada pelo Frozen World Engine.
Configurações de Gerenciamento de Ancoragem
O Gerenciamento de Ancoragem configura toda a seleção explícita do sistema de acompanhamento de ancoragem. Atualmente, essa seleção é feita apenas na inicialização e, uma vez selecionada, não pode ser alterada.
Outras configurações aqui permitem o controle sobre a densidade do grafo de âncora interno subjacente. Eles podem ser alterados a qualquer momento, embora seu efeito possa levar algum tempo para se propagar pelo grafo interno.
Ao abranger áreas muito grandes, talvez seja interessante reduzir a densidade do grafo de âncora, o que diminui a precisão mas aumenta o desempenho. O aumento de MinNewAnchorDistance faz exatamente isso. Ao aumentar a distância mínima necessária antes de adicionar uma nova âncora interna, o espaçamento entre as âncoras aumenta e, portanto, a densidade das âncoras diminui.
Observe que, para passar no teste de criação de borda, MaxAnchorEdgeLength deve ser maior que MinNewAnchorDistance. Na prática, MaxAnchorEdgeLength 10-20% maior que o MinNewAnchorDistance funciona bem.
O parâmetro MaxLocalAnchors, em vez de modificar a densidade, limita diretamente o número de âncoras internas. Atualmente, quando a contagem de âncoras está acima do limite, as âncoras mais distantes da câmera são recicladas para reduzir o número. No entanto, outros algoritmos são interessantes e estão sendo investigados, portanto, um aplicativo não deve depender dessa implementação específica.
Mais detalhes estão sendo documentados no struct AnchorSettings.
Configurações de diagnóstico
As configurações de Diagnóstico controlam a coleta de diagnósticos para análise de comportamento e depuração. Normalmente, eles devem ser deixados com "Usar padrões" definido, que, entre outras coisas, desabilita a coleção de diagnósticos. A coleção de diagnósticos é uma entrave de desempenho, portanto, deve ser evitada, a menos que seja necessário.
Durante o desenvolvimento, quando um comportamento inesperado e indesejável estiver sendo visto, os dados de diagnóstico coletados desabilitando Usar padrões e habilitando DiagnosticsSettings.Enabled, permitirão a coleta de dados que podem ser instrumentais no entendimento e na correção desse comportamento.
Os campos disponíveis para modificação estão descritos na classe DiagnosticsSettings.
Configurações padrão
As configurações de gerenciador e diagnóstico contêm uma caixa de seleção "Usar padrões" nas configurações. A propriedade "Usar padrões" também está disponível no script.
Quando a propriedade "Usar padrões" for true, as configurações padrão atuais serão usadas. Se os valores padrão de uma propriedade mudarem em uma nova versão, a propriedade "Usar padrões" instrui o sistema a usar o novo valor da propriedade.
Definir a propriedade "Usar padrões" como true a qualquer momento redefinirá todos os valores para o padrão atual. Para bloquear os valores em um instantâneo dos valores padrão em um determinado momento, habilite a propriedade "Usar padrões" para redefinir todos os campos para os padrões atuais e, em seguida, remova a definição da caixa de seleção para impedir que eles sejam alterados com uma atualização.
É sugerido deixar "Usar padrões" definido como true, exceto durante o desenvolvimento para experimentação e depuração.