von Eventmanager » 10. August 2019, 20:36
"Gekachelte"Bilder als "monochrome" BG-Grafiken müssen nicht grösser als 1x1 pix sein. Ich hab für alle meine ENS und ihre speziellen "Farbschemas" JEWEILS ca. 50 potenzielle BG-Bilder in EINEM Einzel-PNG (ANIMATION!),
(also schnell per IDX anwählbar). Dieses File muss nur EINMAL auf resize XY oder wie das heisst angeklickt werden, dann kann jedes Grafik-Element sofort auf SEINE gewünschte Grösse skaliert werden. Als IDX Null, hab ich da (in jedem farbschema auch ein KOMPLETT Alfa-"Pic", man braucht keine 144x144 extra TRANSPARENT-BG, das 1X! hier am richtigen Index in bspw. Poly-Displays als BG angemeldet reicht vollkommen, es skaliert sich automatisch mit jedem Poly, Multi...Display und jedem anderen GUI-Element auf die jeweils spezifische Grösse. Ein 1x1 Pix grosses "bild" reicht. Und mehere solcher "Bilder" in einer "Animationsline" und schon kannste problemlos sämtliche Hintergründe in diversen Transparent-Stufen gestalten. Ich hab (pro frabschema) als IDX
= 0 komplett transparent
1-10 (benutzte) Farben und zwar solid/opac!
11-20 = dieselben Farben , aber 25% transparent
21-30 = dieselben Farben , aber 50% transparent
usw, usf.
Die 10 Hauptfarben (meistens nutz ich nur 5...) erstelle ich mir beim grundsätzlichen Background_Design in meinem Grafik-Editor (ich nehm Affinity Photo, fürs reine GUI wäre Affinity Designer noch stringenter, aber ich mach noch anderes damit...).
Bei jedem neuen ENS, nachdem ich ein paar Minuten (manchmal auch länger) rumgespielt habe... auf jeden Fall, wenn ich ne etwaige Vorstellung habe, wie das ENS look&feal soll, ist einer der eretsen Handlungen mir ne Projekt-Pallete zu erstellen (also meine 10 Farben) festzusetzen. Davon gehe ich später nichtv mehr ab! Also lieber nochmal ne Nacht drüber schlafen, bevor sich hier VERBINDLICH zu machen. (SOlche Palletten lassen scih dann auch System-Paletten speichern und Reaktor kann auf Sytem-Palletten zugreifen...) Aber mit meiner "Animation" an allen relavanten Farben (solid) und in diversen Transparenz-Abstufungen, stattdessen "scharen" sich alle "BG"-Element, Pictures, Muliti_Pics.... meine EINE Datei in unterschiedlichen IDXs. Das Thouwabouho im Picture-"Ordner" lässt sich gehörig reduzieren, ebenso die Ens-Grösse minimieren, ergio schlussendlich die Load-Time beschleunigen. Keine Ahnung warum manche Entwickler extra Transparent-Bilder mit bspw. 128x128 erstellen, es macht keinen Sinn, da jedes grafik-fähige-Modul in Reaktor MONOCHROME PNGs auch wenn sie nur 1x1pixel vorliegen korrekt skalieren....
Um Verläufe, spezial-rwiederholungen..., bspw. ein "kleines" Pic mit 100pix ABSOLUTER Länge (bspw. ein "Label" mit nem Frame, einem "Frame" mit nem optischen Ende (bspw. Rundung) ) länge soll ab Ende des "Lables" das sich nur noch der "Frame" bspw. 300pix gedehnt wird und dann aber mit dem korrekten Ende wieder abschliessst.
Nicht sofort selbsterklärend, aber sehr schnell machbar! Der "Repeat/Loop-Punkt muss halt ausserhalb des "Labels" liegen und vor dem Ende wieder verlassen werden. Wenn der Frame keinen Verlauf hat, einfach einen !_Pixel hinter dem Label sowohl als Ein- als auch Austieg wählen. Mit Verläüfen, anderen Übergängen wirds dann natürlich schwierig aber PNGs die ne "monochromatische" Grundstruktur haben lassen sich schnell und einfach auf diverse Grössen "skalieren", am Nutzpunkt "kacheln"....
Was partout NICHT geht, ist es EIN und DEMSELBEN Bild/Png VERSCHIEDENE Animations-Nummern zuzuweisen. Nehmen wir an ich hab nen Text-Animation für 24 EINZEL-Frames. Die ich mir vorher in bspw. Knob-Man* erstellt habe. Die Einzel_Animationen heissen jetzt Filter 1, Filter 2, Filter 3, .... Filter 24. Definiere ich nun in den Picture-Probs die number of Animation auf 24, sehe ich immer nur ein Einzel-"Frame". Sinnvoll wenn ich mit nem Knob (range 0-23, stepsize 1 und DIESEM "bild") durcfahre erhalte ich bei value 17 auch den Bild-Idx 1 (Filter 16) , oder bei value 21 auch Bild-Idx 22 (Filter 20) (das eine zählt beginnend bei Null, das picture aber bei 1). .... Soweit so klar!
Ich kann auch statt "Number of Animition" = 1, bspw. 6 setzen! Dann sehe ich GLEICHZEITIG 6 Frames also im Beispiel Filter 1- 6 wenn der Knob =0 ist, und ich sehe , Filter 13-18, wenn Knob=2 ist).
Wir können "Number of Animation" auch auf 2 oder gar 1 begrenzen.... im Falle 2 sehen wir nur 2 Möglichkeiten Filter1-12 Bei = und Filter 13-24 bei Zustand 1.
Im Falle "Number of Animation" = 1 sehen wir das komplette Pic, jederzeit, egal welcher IDX anliegt. Auch das soweit so klar, zumindest für die meisten von Euch!
Worauf ich aber hinaus will: Es gibt derzeit keine Möglichkeit den "Number of Animation" FÜR DASSELBE (gescharte Pic) unterschiedlich zu verwenden. Reaktor kennt kein "make alias of this Pic", ich kann NICHT ein und DASSELBE (interne) Bild verwenden um 2 Instanzen mit unterschiedlichen "Number of Animation", oder unterschiedlichen Pixel-Repeat....Areas zu erstellen... Um das zu tun, muss ich EIN und dasselbe nochmal laden, irgendwie bennen und erst dann hab ich AUTARKE "Pseudo-Aliase" denn defacto belastet EIN und DASSELBE bei solchen STunts den Speicher doppelt!
Ganz anders eben bei 1x1 "hHntergrund"-Kram, "Number of Animation", "Repeat-Punkt"... immer identisch-Kram!
Das sollte man im Hinterkopf behalten.
Richtig eklig, hochgradig reudig... ist es Bild-Leichen zu finden /Bilder zu erstzen.... Es ist relativ einfach einen Knob (also sein bspw. 128 Einzel-Frame-PNG) mit ein anderes zu erstzen und du kannst das auch für ALLE knobs die diese ANGEMELDETES Bild nutzen, im Batch-Prozess tun. Nicht ganz so offensichtlich, aber es vglw. einfach möglich, das alle Knobs die auf Bild X zugreifen, unisono Bild Y übernehmen, wenn statt Knob die Ansicht von X geändert wird.
Soweit so gut. Aber nehmen wir du "mergst" 2 Instrumente zusammen. Du möchtest nun, das in Ins 2 bspw. alle (main-) Knobs auf DENSELBEM Picture# wie die Brüder in Ins1 beruhen. Das geht mW nur manuell, in dem du JEDEM einzelnen Knob von Ins 2 auch das entsprechende reaktor-IMAGE zuweist. Das lässt sich nicht batchen, auch nicht über Umwege das IMAGE mit den SELBEN Dateien, einstellungen... zu füttern, dann hats du 2 IMages... die zwar exakt sind, aber am ende einzeln gelistetd, gespeichert werden...
Noch viel schliemmer ist es unbenunzte "Images! zu finden. (Auch ein Grund, warum ich Blocks komplett meide... falls ich irgendwas davon verwenden sollte, die müllen mir meine IMAGE so überdimensional zu.... ekelhaft).
Zumindest kann R6 die "Images ! schon mal alphabetisch ordnen... das war in R5 noch um einiges grauenvoller, mit 5.5 haben sie zumindest DAS eingefügt... aber hochkompl
exe ENs mit hunderten "Images"... hier sollte man schleunigst einiges tun, statt noch die nächste Schippe auf "Blocks" draufzulegen... Nichts gegen LEGO, aber es gibt auch ENTWICKLER komplett jenseits davon!
*Grossen Respekt vor Knob-Man, meinem Pfannkuchen-Freund... hervorragendes Tool für quick&dirty! Wer es dann doch etwas detaillierter, genauer, "schöner" haben will... kommt um ne dezidiertes Grafik-App nicht rum. Die Einsteíegskurve ist aber extrem hoch, die Möglichkeiten dann aber auch deutlich beeindruckender, die Ergebnisse "schöner"... aber doch eher Lupen-Modus... KNOB-Man erledigt nen hervorragende Job, das Tool ist jeden Pfannkuchen wert, aber FALLS du eh dich auch auch irgendwie GRAFIS>CH betätigst, und BESONDERS auf optische Feinheiten achtes, dann, aber nur dann... schau mal bspw. bei Affinity Design/photo nach... ! Es wird garantiert nicht einfacher, es wird aber "minimal"???? schöner... zwar zu einem ziemlichen hohen Einsatz, aber das muss jeder für sich entscheiden.... wie sind (noch) ein (halbwegs) freies Land!
