Práticas recomendadas de script visual de malha para desempenho
Visão geral
Os scripts visuais não são inerentemente lentos, mas são significativamente mais lentos do que, digamos, o código C#.
Quando você cria scripts visuais em seu ambiente, é melhor usá-los para conectar a funcionalidade existente, não para trabalho pesado: faça cola, não vigas. A maneira mais simples de garantir que seus scripts visuais não afetem o desempenho geral do seu ambiente é garantir que eles não estejam fazendo muito em primeiro lugar.
Eventos de script de alta e baixa frequência
O Visual Scripting oferece uma ampla seleção de eventos que você pode usar para disparar fluxos de script visual.
Tente evitar:
Na atualização, Na atualização fixa, Na atualização tardia e similares. Esses eventos são acionados com muita frequência (geralmente na mesma taxa que os quadros de renderização) e, mesmo que seu script não faça muito, até mesmo iniciá-lo tem uma sobrecarga que pode afetar visivelmente o desempenho do ambiente se isso acontecer em muitos lugares ao mesmo tempo.
On Trigger Stay e On Collision Stay. Mesmo que esses eventos estejam ativos apenas sob certas condições (por exemplo, quando um objeto físico está dentro de um volume de gatilho físico ou tocando um colisor), enquanto essas condições são fornecidas, eles serão acionados com muita frequência.
Não há substituto preferencial direto para esses eventos de alta frequência. Eles não estão desabilitados, portanto, você pode usá-los se for absolutamente necessário, mas recomendamos que você tente aproveitar a funcionalidade interna, como o componente Animator, que pode ser controlado por scripts visuais, ou reestruture sua lógica de script para ser reativa em vez de ativa, por exemplo, usando eventos On State Changed .
Se você não puder evitar esses eventos de alta frequência, poderá reduzir seu impacto mantendo todo o componente da Máquina de Script inativo quando não for necessário. Outro script visual pode usar o Conjunto de Máquinas | de Script Habilitado para desabilitar e habilitar um grafo de script inteiro. Enquanto desabilitado, nenhum de seus nós de evento é acionado e tem custo de tempo de execução zero.
Estes são ligeiramente perigosos para o desempenho, mas às vezes necessários:
- Na colisão, entre e na colisão saia. Normalmente, esses eventos são acionados apenas uma vez quando um corpo físico toca o colisor e, mais uma vez, quando ele para de tocar. No entanto, às vezes um corpo físico fica preso entre dois colisores; nesse caso, ele pode começar a tremer rapidamente para frente e para trás, acionando muitos eventos On Collision em uma sucessão muito rápida. Recomendamos que você use eventos On Trigger .
Eles podem ser usados em determinadas situações:
On Interval permite acionar fluxos de script em intervalos personalizáveis (por exemplo, uma vez por segundo) definidos por meio de sua configuração Interval . Você pode usar a configuração Delay para escalonar a execução de diferentes eventos On Interval que tenham o mesmo intervalo.
O nó Timer não é um evento, mas acionará sua porta Tick uma vez por quadro durante a duração do temporizador assim que for iniciado inserindo sua porta inicial . Quando o temporizador não está em execução, ele tem custo de runtime zero.
Tente não usar esses eventos para continuar verificando se determinadas variáveis, propriedades ou condições foram alteradas – em vez disso, é melhor usar um evento On State Changed para ouvir as alterações a custo ocioso zero.
Estes são sempre bons para usar:
On State Changed é acionado somente se e quando qualquer uma de suas portas de entrada alterar seu valor. Para variáveis de script e propriedades de componentes, isso é implementado de forma muito eficiente de uma forma que incorre em custo de tempo de execução zero, desde que nada mude.
On State Changed também pode ser usado para observar entradas mais complexas (por exemplo, os resultados de um cálculo) que exigem que ele reavalie a entrada uma vez por quadro para determinar se ela foi alterada. Você terá que habilitar a opção Permitir sondagem para habilitar esse recurso; a interface do usuário de edição de script irá informá-lo sobre isso e avisá-lo sobre o possível impacto no desempenho. Mesmo assim, ainda será um pouco mais eficiente do que criar um script de sua própria lógica de sondagem usando um evento On Update .
No item de dicionário adicionado e no item de dicionário removido funcionam de maneira semelhante e têm custo de runtime zero, desde que nada seja alterado.
On Trigger Enter e On Trigger Exit não têm nenhum dos perigos potenciais de desempenho dos eventos On Collision correspondentes (veja acima).