Metodtips för visuella mesh-skript för prestanda
Översikt
Visuella skript är inte i sig långsamma, men de är betydligt långsammare än till exempel C#-kod.
När du skapar visuella skript i din miljö är det bäst att använda dem för att ansluta befintliga funktioner, inte för tunga lyft: gör lim, inte balkar. Det enklaste sättet att se till att dina visuella skript inte påverkar den övergripande prestandan i din miljö är att se till att de inte gör mycket alls i första hand.
Skripthändelser med hög och låg frekvens
Visual Scripting erbjuder ett brett urval av händelser som du kan använda för att utlösa visuella skriptflöden.
Försök att undvika:
Vid uppdatering, vid fast uppdatering, vid sen uppdatering och liknande. Dessa händelser utlöses mycket ofta (ofta i samma takt som återgivningsramar), och även om skriptet inte gör så mycket, har även just start av det ett omkostnader som märkbart kan påverka miljöns prestanda om det sker på många platser samtidigt.
Stanna kvar vid utlösaren och stanna vid kollision. Även om dessa händelser endast är aktiva under vissa förhållanden (till exempel när ett fysikobjekt finns inuti en fysikutlösarvolym eller vidrör en kolliderare), utlöses dessa villkor mycket ofta.
Det finns ingen direkt föredragen ersättning för dessa högfrekventa händelser. De är inte inaktiverade, så du kan använda dem om det är absolut nödvändigt, men vi rekommenderar att du försöker använda inbyggda funktioner, till exempel Animator-komponenten, som kan styras av visuella skript, eller strukturera om skriptlogik så att den är reaktiv i stället för aktiv, till exempel med hjälp av händelser som ändrats av tillståndet.
Om du inte kan undvika dessa högfrekventa händelser kanske du kan minska deras påverkan genom att hålla hela komponenten skriptdator inaktiv när den inte behövs. Ett annat visuellt skript kan använda Skriptmaskinuppsättning | aktiverad för att inaktivera och aktivera en hel skriptgraf. När den är inaktiverad utlöses ingen av dess händelsenoder, och den har noll körningskostnader.
Dessa är något farliga för prestanda men ibland nödvändiga:
- Vid kollision anger och vid kollisionsavslut. Normalt utlöses dessa händelser bara en gång när en fysikkropp rör vid kollideraren, och återigen när den slutar röra. Men ibland fastnar en fysikkropp mellan två kolliderare; I så fall kan det börja darrande snabbt fram och tillbaka, vilket utlöser många händelser vid kollision i mycket snabb följd. Vi rekommenderar att du använder Vid utlösare-händelser i stället.
Dessa är okej att använda i vissa situationer:
Med Intervall kan du utlösa skriptflöden i anpassningsbara intervall (till exempel en gång per sekund) som definierats via dess intervallinställning . Du kan använda inställningen Fördröjning för att sprida körningen av olika händelser med vid intervall som har samma intervall.
Timernoden är inte en händelse, men utlöser sin tickport en gång per bildruta under tidsåtgången när den har startats genom att ange startporten. När timern inte körs har den noll körningskostnader.
Försök att inte använda de här händelserna för att kontrollera om vissa variabler, egenskaper eller villkor har ändrats– i stället är det bättre att använda en händelse som ändrats vid tillstånd för att lyssna på ändringar utan inaktiv kostnad.
Dessa är alltid okej att använda:
I Tillståndsändring utlöses endast om och när någon av dess indataportar ändrar sitt värde. För skriptvariabler och komponentegenskaper implementeras detta mycket effektivt på ett sätt som medför noll körningskostnader så länge ingenting ändras.
I Tillstånds ändras kan också användas för att observera mer komplexa indata (till exempel resultatet av en beräkning) som kräver att den utvärderar indata en gång per bildruta för att avgöra om den har ändrats. Du måste aktivera alternativet Tillåt avsökning för att aktivera den här funktionen. Användargränssnittet för skriptredigering informerar dig om detta och varnar dig om den potentiella prestandapåverkan. Trots detta är det fortfarande lite mer effektivt än att skripta din egen avsökningslogik med hjälp av en händelse vid uppdatering .
På ordlisteobjektet som har lagts till och på ordlisteobjektet har tagits bort fungerar det på ett liknande sätt och har noll körningskostnad så länge ingenting ändras.
Vid Utlösarens retur och Vid utlösaravslut finns ingen av de potentiella prestandariskerna för motsvarande händelser vid kollision (se ovan).