Die Build-Größe hängt von Plattform, Architekturen, Stripping und Kompression ab. Glyphenatlanten entstehen zur Laufzeit. Schriftassets enthalten ihre eigenen Nutzdaten; ursprüngliche .ttf- und .otf-Dateien sind nur Editor-Referenzen. Native Player lesen einen Datenträgercache, WebGL bettet die Daten ein.

Schriftassets enthalten ihre eigenen Nutzdaten; ursprüngliche .ttf- und .otf-Dateien sind nur Editor-Referenzen. Native Player lesen einen Datenträgercache, WebGL bettet die Daten ein.

Nein. Du kannst ein UniTextFont aus einer .ttf erstellen, die irgendwo auf deiner Festplatte liegt — über das UniText-Tool-Fenster (der Dateidialog liest die Bytes direkt). Die Schrift ins Projekt zu importieren ist optional.

Die Build-Größe hängt von Plattform, Architekturen, Stripping und Kompression ab. Glyphenatlanten entstehen zur Laufzeit.

Systemschriften werden automatisch gewählt. Eigene Schriftdateien sind auf Desktop und Mobilgeräten optional; WebGL verwendet zugewiesene Schriften. Neue Glyphen erfordern Rasterung und Upload. Vorhandene Glyphen werden bis zur Änderung oder Verdrängung aus dem Cache wiederverwendet.

Ja — das liegt auf der Seite des Entwicklers, und UniText steht dir nicht im Weg. Lade die Schrift-Bytes mit deinem eigenen Code herunter (UnityWebRequest) und erstelle daraus zur Laufzeit ein UniTextFont via CreateFontAsset(byte[]). Um eine Schrift auf genau die Zeichen zu reduzieren, die du brauchst (Subsetting), nutze das Build-Zeit-Tool von UniText. Es gibt keinen eingebauten CDN-Auto-Loader im Paket — das ist bewusst die Verantwortung des Projekts, nicht der Engine.

Systemschriften werden automatisch gewählt. Eigene Schriftdateien sind auf Desktop und Mobilgeräten optional; WebGL verwendet zugewiesene Schriften.

Systemschriften werden automatisch gewählt. Eigene Schriftdateien sind auf Desktop und Mobilgeräten optional; WebGL verwendet zugewiesene Schriften.

Große Schriftdateien werden bei Bedarf vom Datenträger gelesen, ohne vollständige Kopie im verwalteten Speicher. Ungenutzte Schriftassets bleiben komprimiert. WebGL und eingebettete Editor-Schriftassets halten Daten im Speicher. Dateibasierte Schriften verwenden Memory Mapping.

Scharfe Pixel, automatische Rastererkennung sowie rastergebundene Effekte und Animation. Vektor-Pixelschriften und reine Bitmap-Schriften teilen dasselbe Stilsystem. Ganzzahlige Vielfache von Pixel Grid sind pixelgenau. Snap To Pixel Grid richtet auch Effekte und Animation aus; deaktiviert erlaubt es Subpixelbewegung.

Glyphen liegen in Kacheln von drei Größen — 64, 128, 256 — und die Größe ergibt sich aus der Kontur-Komplexität (viele Segmente → 128/256, eine einfache Kontur → 64). • SDF Detail (Detailgrad) ist ein Multiplikator auf die Komplexitätsschätzung. Erhöhe ihn, und ein ohnehin nicht-triviales Glyph wandert eher in eine größere Kachel. (Eine wirklich einfache Form bleibt bei 64 — der Multiplikator wirkt nur auf Glyphen oberhalb des Schwellenwerts.) • Tile Size Offset (Kachelgrößen-Versatz) ist ein harter Schritt entlang der Größenleiter (gewählt 64 + Versatz 1 → 128; Bereich −2..+2).

Keine für sich allein — beide bestimmen nur die finale Kachelgröße, und die Kosten hängen allein von dieser Größe ab. Zwei Kombinationen, die zur selben Kachelgröße führen, kosten exakt gleich viel. Ziele auf die kleinste Kachelgröße, die noch akzeptable Qualität liefert.

Neue Glyphen erfordern Rasterung und Upload. Vorhandene Glyphen werden bis zur Änderung oder Verdrängung aus dem Cache wiederverwendet.

Neue Glyphen erfordern Rasterung und Upload. Vorhandene Glyphen werden bis zur Änderung oder Verdrängung aus dem Cache wiederverwendet.

Core koordiniert Textarbeit vor dem Rendering. Worker und Burst verarbeiten große Aufgaben; lokale Änderungen invalidieren betroffene Stufen.

Core koordiniert Textarbeit vor dem Rendering. Worker und Burst verarbeiten große Aufgaben; lokale Änderungen invalidieren betroffene Stufen.